I'm trying to get Asterisk yesterday's trunk and Chrome 36 via WebRTC. The websocket connection is established and the client registers correctly, but when I try to make a call from the browser, I get this message from Asterisk:
chan_sip.c:10535 process_sdp: Rejecting secure audio stream without encryption details: audio 35348 UDP/TLS/RTP/SAVPF 111 103 104 0 8 106 105 13 126
I have followed https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5 and https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial (although admittedly I'm not able to import in Chrome the .pem client certificate, but I'm not sure it's needed. I have imported the server certificate though)
I also tried with the 11.11.0 version but I'm getting the same result.
Help is appreciated!
have you tried using an older version of Chrome? We had everything working till we upgraded to Chrome 36. Peers succeded in registering and composing a call, but as soon as the other party answered, the call died.
After some research of which I unfortunately am not able to provide links, we realized that that Chrome update messed things up.
We are now compelled to use the version 34.0.1847.137m which works for us. Give it a try.
Related
When the user opens a website, the browser tries to establish a TCP connection. It works if the website is using HTTP/1-2. However, it will not work if the website is using HTTP/3, since it requires QUIC. The question is: how the browser knows whether it should use TCP or QUIC?
Please direct yourself to the following URL down below which is the one for HTTP version 3 specifications.
https://datatracker.ietf.org/doc/html/rfc9114
Have a good one!
I want to send/receive data to/from website by using SIM5320E.
Connection between my PC and module SIM5320E is look good because the AT command responses OK. But the command to launch a HTTP operation gets ERROR.
It seems that my SIM5320E is NOT connected to 3G network. The GPRS is no longer available in Japan (DOCOMO) now.
How to active SIM4320E connect to 3G ?
This is my current result.
AT
OK
AT+COPS?
+COPS: 0,0,"NTT DOCOMO",2
OK
AT+CGSOCKCONT=1,"IP","line.me"
OK
AT+CSOCKSETPN=1
OK
AT+CSOCKAUTH=1,3,"line","line#line"
OK
AT+CHTTPACT=?
+CHTTPACT: "ADDRESS",(1-65535)
OK
// I got error from here
AT+CPING="google.com",1
OK
+CPING: 3,0,0,0,0,0,0
AT+CHTTPACT="google.com",80
+CHTTPACT: 237
ERROR
AT+CHTTPACT="www.google.com",80
+CHTTPACT: 237
ERROR
AT+CHTTPACT="stackoverflow.com",80
+CHTTPACT: 237
ERROR
Update 1: Also tried this
AT+CMEE=2
OK
AT+CHTTPSSTART
ERROR
AT+CHTTPSSTART\r\nAT+CHTTPSOPSE="pruebas.libelium.com",80,1\r\nAT+CHTTPSSEND=88\r\n"GET / HTTP/1.1"\r\nHost: pruebas.libelium.com\r\nContent-Length: 0"
ERROR
Update 2: Also tried
AT+CNMP?
+CNMP: 2
OK
AT+CNAOP?
+CNAOP: 2
OK
AT+CPSI?
+CPSI: WCDMA,Online,440-10,0x01C6,72728730,WCDMA IMT 2000,331,10736,0,4.5,70,31,45,500
OK
AT+CHTPSERV="ADD","www.google.com",80,1
OK
AT+CHTPUPDATE
OK
+CHTPUPDATE: 4 // Network error
Thanks!
I was able to download web site data using SIM5320E module. Haven't used SIM4320E though but should be quite similar.
Follow the exact steps in SIM5320e HTTPS Stack, can't make successful GET request which worked for me.
From what you have provided:
You have selected the correct module for DOCOMO band (2100Mhz) according to Cellular Bands in Japan. Since AT+CPSI? and AT+COPS? shows it's online with WCDMA so may assume it's connected to network. You can use AT+CREG? and AT+CGREG? to see whether your voice and data connections are registered with the network (It must be registered with the network)
If it's not connected to the network. Try AT+COPS=2 to force it to select a network.
AT+CHTTPSSTART can fail, if the HTTPS service has already been started. So you can use following commands to restart it.
AT+CHTTPSCLSE
AT+CHTTPSSTOP
AT+CHTTPSTART
If you still face problems, try using this Tutorial by SimComm. It doesn't contain the 3G connectivity stuff. But you can make sure your module works fine with your network. Once it's ensured, try following the steps mentioned above.
All the best!
I was running a asterisk 11.5 with no error. After installed Opus codec with patch in my asterisk
btw i am using browser based sip softphone jssip
Now whenever I am making audio call between 2 peer, no call is getting establish and throwing below errors:
btw i am using browser based sip softphone jssip
[Sep 29 09:27:36] WARNING[17065][C-00000003]: sip/sdp_crypto.c:173 sdp_crypto_activate: Could not set SRTP policies
[Sep 29 09:27:36] WARNING[17065][C-00000003]: sip/sdp_crypto.c:173 sdp_crypto_activate: Could not set SRTP policies
[Sep 29 09:27:36] WARNING[17065][C-00000003]: chan_sip.c:11100 process_sdp_a_audio: Got Opus minptime=10
[Sep 29 09:27:36] WARNING[17065][C-00000003]: chan_sip.c:10437 process_sdp: Rejecting secure audio stream without encryption details: audio 17002 RTP/SAVPF 111 103 104 0 8 106 105 13 126
[1000]
secret=test123
context=local
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
qualify=yes
qualifyfreq=600
transport=udp,wss,ws
encryption=yes
dial=SIP/8000
callerid=testuser <8000>
callcounter=yes
avpf=yes
icesupport=yes
directmedia=no
Can any one cooperate?
Use tcpdump or wireshark to look at the packets, and make sure that they're actually encrypted packets. I looks like it may be rejecting them because it's not SRTP. However, that is only an educated guess. Additionally at the asterisk command line you might want to look at rtp set debug on.
You may look to Asterisk 12 for Opus support, where it will be officially supported, or so it seems from the development activity for Asterisk 12.
Here's the reference to the issue and discussion of the fix. And you can see that it's been approved by the review board here.
I, too, am interested in using Opus. However, without knowing what patch you are using, and the stability of said patch -- it may be difficult (and rather time consuming) to give specific instruction here. I would recommend reporting the issue to the person/group who released the patch as it may help the community project (if it is such).
I'm working with freeswitch and I made the connection between my server and another one, for hearing each other I used the codec G729. The issue is the next: I call them, the call is established and I can hear the other part perfectly but they can't hear me and they can see the audio packets coming to their server but they can't hear me, any idea? Thanks!
I'd start by looking at the firewall on the remote machine. libpcap will allow you to see all packets hitting the box before the firewall rules are applied, so it can be a little deceptive. So there's a good chance that the firewall is blocking the packets.
Also, you didn't specify what the other user is connecting to their server with, and how. So if they're connecting to their server from behind NAT, then you could just be experiencing the typical one-way audio issues so common with NAT scenarios. Check out http://wiki.freeswitch.org/wiki/Nat for more info.
This issue doesn't seem to be directly related to the g.729 codec or you'd have most likely gotten a 488 SIP response.
It's possible that the person on the other end isn't able to decode the the G729 stream.
What kind of phone are they using?
I would google that phone model and try a known supported codec for it.
Then I would setup your Freeswitch to encode for that codec.
If that works then it's likely an issue with the phone.
Hope this helps.
So, I have a Blackberry 9000 application doing simple networking using HttpConnection. Everything works fine normally, when I go to urls of the form:
http://url.com
But I've discovered that I need to test this in wifi only situations (that is, without a BES or equivalent in sight). After some digging, I discovered that I need to add:
;interface=wifi
To all of my URLS, of the form:
http://url.com;interface=wifi
However, I'm noticing that this does not actually work, it gives me back a HTTP error 406. Which according to wiki is a:
406 Not Acceptable
The requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.[2]
Am I doing something completely wrong? Does Blackberry wrap wifi only requests in headers that require particularly formatted websites?
As explained on this page, you also need add "deviceside=true" to the URL.
To specify that the underlying TCP
connection should be opened directly
from the handheld, set this parameter
to "true". Specify "deviceside=false"
when receiving or sending data through
the BlackBerry MDS Connection Service.
So your full URL would be:
http://url.com;interface=wifi;deviceside=true