Here is a little guide to troubleshoot webrtc issues with Asterisk.
Always try to use the latest WebRTC API with the latest Asterisk branch(11 or 12). Be sure you have the icessuport enabled in the rtp.conf
ISSUE: I get this response on JSSIP or SIPML5 debug:tRemoteDescription failed: Called with an SDP without ice-ufrag and ice-pwd.
This issue is caused because you asterisk don’t have ICE support, you can solve that by installing the uuid/libuuid and uuid-devel/libuuid-devel packages on your system. Then recompile asterisk(be sure to rerun the configure script before the make command).
ISSUE: I get this response on JSSIP or SIPML5:Failed to get local SDP
This issue can be caused as the same cuase described above, be sure you aren’t getting the above message in the javascript debug.
If you aren’t getting the lack of ice-ufrag and ice-pwd then check your peer settings in the asterisk side. Remember you need in your peer settings:
– avpf=yes
– icesupport=yes
– encryption=yes
– transport=ws
And disable the videosupport if you don’t set the use of the vide in the WebRTC API.
ISSUE: I get this in the Asterisk cli Rejecting secure audio stream without encryption details: audio RTP/SAVPF:
Be sure that each webrtc peer have in the settings these values:
– avpf=yes
– encryption=yes
Setting that globally doesn’t work.
ISSUE: Not getting audio at all
Usually this is caused by two reasons:
** Wrong NAT settings in your Asterisk side.
** The ICE server is setting the wrong IP to use in the SDP.
Fixing the NAT settings:
First check how are you making your tests in your enviroment:
If you are in the same LAN then your webrtc peers no need NAT at all, so define the setting nat=no.
If you are connecting your peer to a NATed Asterisk box then define the setting nat=force_rpot,comedia.
Workaround for the ICE issue:
If setting the nat settings correctly doesn’t solve your issue then you need to get the Debug on Asterisk and Chrome.
On the Asterisk side you need to enable the SIP debug by running the command:
Then try a call from your WebRTC API you will get an output like this:
[code]<— SIP read from WS:[client-ip]:[client port] —>
INVITE sip:[called number]@[asterisk-server-ip] SIP/2.0
bunch of SIP HEADERS
c=IN IP4 [client-ip]
more sip headers and SDP options
[/code]
If the [Client-iP] is different in the <—SIP read from WS: ----> part and in the c= IN IP4 then the ICE server is choosing the wrong IP, for example this output:
[code]<— SIP read from WS:179.213.21.254:59385 —>
INVITE sip:1000@mypublicip.no-ip.org SIP/2.0
Via: SIP/2.0/WS 7h1b1f5fc8gi.invalid;branch=z9hG4bK9976051
Max-Forwards: 69
To: sip:1000@mypublicip.no-ip.org
From: “G” sip:8001@mypublicip.no-ip.org;tag=i6i4nniqbv
Call-ID: cgu3s60etphsvr40mneg
CSeq: 5919 INVITE
Contact: sip:06sfurc9@7h1b1f5fc8gi.invalid;transport=ws;ob
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.7
Content-Length: 2242
v=0
o=- 3652154159910496246 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS 5RwvfIQD4tReS2G5yvV1x6j62I2NOFA1nO36
m=audio 54280 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 192.168.101.103
a=rtcp:54280 IN IP4 192.168.101.103
a=candidate:1117122343 1 udp 2122260223 192.168.101.103 54280 typ host generation 0
a=candidate:1117122343 2 udp 2122260223 192.168.101.103 54280 typ host generation 0
a=candidate:1755041049 1 udp 2122194687 192.168.74.1 54281 typ host generation 0
a=candidate:1755041049 2 udp 2122194687 192.168.74.1 54281 typ host generation 0
a=candidate:4254299990 1 udp 2122129151 10.246.40.1 54282 typ host generation 0
a=candidate:4254299990 2 udp 2122129151 10.246.40.1 54282 typ host generation 0
a=candidate:202773463 1 tcp 1518280447 192.168.101.103 0 typ host generation 0
a=candidate:202773463 2 tcp 1518280447 192.168.101.103 0 typ host generation 0
a=candidate:639119849 1 tcp 1518214911 192.168.74.1 0 typ host generation 0
a=candidate:639119849 2 tcp 1518214911 192.168.74.1 0 typ host generation 0
a=candidate:3004205990 1 tcp 1518149375 10.246.40.1 0 typ host generation 0
a=candidate:3004205990 2 tcp 1518149375 10.246.40.1 0 typ host generation 0
a=ice-ufrag:eNWxE4gTTqnCVyMu
a=ice-pwd:ZoVKNOv2HlfHE9VNyW3NSIAO
a=ice-options:google-ice
a=fingerprint:sha-256 36:BB:11:6A:0A:2B:56:26:D5:E0:1F:98:8A:A0:4E:EF:93:0A:3A:D3:84:A5:EF:14:C6:C8:86:D1:AF:1A:08:84
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:tCMlVm6sT9MJMxbzKEmsDV1e3VVvNa5MwkUKPKzN
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qHzInMoGik8HNFMVgi6IjHdClreeyslHlw11nvn8
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:3951139034 cname:1GEOwdZBp2a0BbWt
a=ssrc:3951139034 msid:5RwvfIQD4tReS2G5yvV1x6j62I2NOFA1nO36 9cda3eb5-5a5c-4cb3-ad6d-0a153309d435
a=ssrc:3951139034 mslabel:5RwvfIQD4tReS2G5yvV1x6j62I2NOFA1nO36
a=ssrc:3951139034 label:9cda3eb5-5a5c-4cb3-ad6d-0a153309d435
<------------->[/code]
Note that the signalling came with the IP 179.213.21.254:59385 meanwhile the SDP use the IP 192.168.101.103
That can be caused by a bad NAT setting config.
If you received an output like:
[code] <— SIP read from WS:192.168.0.106:51709 —>
INVITE sip:202@192.168.0.109 SIP/2.0
Via: SIP/2.0/WS hat7f7lbgktt.invalid;branch=z9hG4bK1640168
Max-Forwards: 69
To: sip:202@192.168.0.109
From: sip:200@192.168.0.109;tag=p8tsev60np
Call-ID: 6egc17kuvl2je0o87b4o
CSeq: 2789 INVITE
Authorization: Digest algorithm=MD5, username=“200”, realm=“asterisk”, nonce=“21fdd8c0”, uri="sip:202@192.168.0.109", response="077edbb83494203045c541edc89fb9e5"
Contact: sip:ugioubt2@hat7f7lbgktt.invalid;transport=ws;ob
Allow: ACK,CANCEL,BYE,OPTIONS
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2150
v=0
o=- 7117681503785597723 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS kmOganHLCy2vMNaUchD012reLNNUCaUv7Dtp
m=audio 64863 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 147.175.216.240
a=rtcp:64863 IN IP4 147.175.216.240
a=candidate:1560575937 1 udp 2122260223 169.254.65.8 64862 typ host generation 0
a=candidate:1560575937 2 udp 2122260223 169.254.65.8 64862 typ host generation 0
a=candidate:1516508954 1 udp 2122194687 192.168.0.106 64863 typ host generation 0
a=candidate:1516508954 2 udp 2122194687 192.168.0.106 64863 typ host generation 0
a=candidate:327648049 1 tcp 1518280447 169.254.65.8 0 typ host generation 0
a=candidate:327648049 2 tcp 1518280447 169.254.65.8 0 typ host generation 0
a=candidate:350743530 1 tcp 1518214911 192.168.0.106 0 typ host generation 0
a=candidate:350743530 2 tcp 1518214911 192.168.0.106 0 typ host generation 0
a=candidate:3677098414 1 udp 1685987071 147.175.216.240 64863 typ srflx raddr 192.168.0.106 rport 64863 generation 0
a=candidate:3677098414 2 udp 1685987071 147.175.216.240 64863 typ srflx raddr 192.168.0.106 rport 64863 generation 0
a=ice-ufrag:agqGIusA/g+2fZhV
a=ice-pwd:CVzSoqyvRnAYZeqmpqyWg9Bg
a=ice-options:google-ice
a=fingerprint:sha-256 EB:69:64:1E:F8:7A:E6:9B:4C:A5:FA:16:F1:2D:5C:66:A4:64:E5:39:68:DD:E2:E3:FF:F0:1C:C8:31:7E:62:84
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:dHjkiwclb9U+ZuoKJ4+s30/i5j/nsLrWzMG3IzCF
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:J3A2MBWJgw5LgudzvuQuBm5W+zXcNk2t0ATUvlJq
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:729560918 cname:6uOjmNuEFKaaJcWh
a=ssrc:729560918 msid:kmOganHLCy2vMNaUchD012reLNNUCaUv7Dtp c7fe212f-f4b7-401c-9e9e-d47988069681
a=ssrc:729560918 mslabel:kmOganHLCy2vMNaUchD012reLNNUCaUv7Dtp
a=ssrc:729560918 label:c7fe212f-f4b7-401c-9e9e-d47988069681
<-------------> [/code]
Note that the Sip signalling come from a LAN IP while the SDP is using a Public IP address, so the ICE server is setting your public IP in the SDP to solve that set the stun as null in your API.
For SIPML5 set as :
For JsSIP set as:
That will force to use the local IP address.
ISSUE:I have all settings correct but I don’t have audio
Check that your asterisk is sending the Audio to the correct IP using ICE. Enable the RTP debug in asterisk and be sure that you see an output like this:
Got RTP packet from 10.0.1.102:41739 (type 00, seq 007702, ts 2401199386, len 000160)
Sent RTP packet to 10.0.1.102:41739 (via ICE) (type 00, seq 009610, ts 031680, len 4294967284)
Please note the (Via ICE) if you dont see that maybe the asterisk don’t have the icesupport enable in the pper or in the rtp.conf file.
How to collect debugs
– For get the SIP debug in Asterisk:
– For get the RTP debug in Asterisk:
– For get the Chrome log(Javascript debug):
If you are using Doubango’s media gateway(WebRTC2SIP) then disable in the peer configuration the setting:
avpf=yes
encription=yes
icesupport=yes
ISSUE I have Installed libuuid/uuid but asterisk never send the ice-ufrag & ice-pwd in the SDP
There is a bug report for Branch 11.7 to 11.8 issues.asterisk.org/jira/browse/ASTERISK-23425 where Asterisk never send those settings Upgrade asterisk to 11.9 and it should work out of the box.
Added 4-June-2014
ISSUE After upgrade Chrome to the version 35 SIPML5 stop working
As all we know Chrome dropped the support of SDES as default and now use DTLS-SRTP, you can follow the thread in the Asterisk Jira page and see the progress with the patches.
The developers from doubango kindly give me a link to a temporary work around(until SDES will be removed in v37) code.google.com/p/sipml5/issues/detail?id=183