[asterisk-users] Incoming webrtc call succeeds in Firefox but fails in Google Chrome

Alex Villací­s Lasso a_villacis at palosanto.com
Wed Jan 20 17:33:07 CST 2016


El 20/01/16 a las 16:25, Alex Villací­s Lasso escribió:
> I am having trouble getting Google Chrome to accept a WebRTC call coming from Asterisk, even though Firefox can (now) accept the same call without issue.
>
> My setup is as follows:
>
> Server:
> CentOS 7 x86_64 (Elastix 4 RC) with IP: 10.1.0.4 192.168.5.146
> asterisk-11.21.0 patched to work around https://issues.asterisk.org/jira/browse/ASTERISK-25659
> openssl-1.0.1e-51.el7_2.2.x86_64
> [root at elx4 ~]# openssl version
> OpenSSL 1.0.1e-fips 11 Feb 2013
> [root at elx4 ~]# openssl ecparam -list_curves
>   secp384r1 : NIST/SECG curve over a 384 bit prime field
>   secp521r1 : NIST/SECG curve over a 521 bit prime field
>   prime256v1: X9.62/SECG curve over a 256 bit prime field
>
> Client:
> Fedora 23 x86_64
> Linphone (linphone-3.6.1-10.fc23.x86_64)
> Firefox 43 (firefox-43.0.3-1.fc23.x86_64)
> Google Chrome (google-chrome-stable-47.0.2526.111-1.x86_64)
> SIP.js 0.7.2
>
> I set up my SIP configuration to have two SIP accounts. Account 1000 is the Linphone and 1001 is the webrtc:
>
> [general]
> faxdetect=no
> vmexten=*97
> context=from-sip-external
> callerid=Unknown
> notifyringing=yes
> notifyhold=yes
> tos_sip=cs3
> tos_audio=ef
> tos_video=af41
> alwaysauthreject=yes
> useragent=FPBX-2.11.0(11.20.0)
> disallow=all
> allow=g723
> allow=ulaw
> allow=gsm
> allow=alaw
> allow=g729
> allow=speex
> allow=g722
> allow=h264
> allow=h263p
> allow=h263
> allow=h261
> tlsenable=yes
> tlsbindaddr=0.0.0.0
> tlscipher=ALL
> tlsclientmethod=tlsv1
> tlscertfile=/etc/asterisk/keys/asterisk.pem
> tlscafile=/etc/asterisk/keys/ca.crt
> callevents=no
> jbenable=no
> videosupport=yes
> allowguest=no
> srvlookup=no
> defaultexpiry=120
> minexpiry=60
> maxexpiry=3600
> registerattempts=0
> registertimeout=20
> g726nonstandard=no
> maxcallbitrate=384
> canreinvite=no
> rtptimeout=30
> rtpholdtimeout=300
> rtpkeepalive=0
> checkmwi=10
> notifyringing=yes
> notifyhold=yes
> nat=yes
>
> [1000]
> deny=0.0.0.0/0.0.0.0
> secret=6ff108122cce3b0b45e0abf374c14ef4
> dtmfmode=rfc2833
> canreinvite=no
> context=from-internal
> host=dynamic
> trustrpid=yes
> sendrpid=no
> type=friend
> nat=yes
> port=5060
> qualify=yes
> qualifyfreq=60
> transport=udp
> avpf=no
> icesupport=no
> dtlsenable=no
> dtlsverify=no
> dtlssetup=actpass
> encryption=no
> callgroup=
> pickupgroup=
> dial=SIP/1000
> mailbox=1000 at device
> permit=0.0.0.0/0.0.0.0
> callerid=Usuario 1 elx4 <1000>
> callcounter=yes
> faxdetect=no
>
> [1001]
> deny=0.0.0.0/0.0.0.0
> secret=ce93963b0751ed9a88ec1badbc073fce
> dtmfmode=rfc2833
> canreinvite=no
> context=from-internal
> host=dynamic
> trustrpid=yes
> sendrpid=no
> type=friend
> nat=yes
> port=5060
> qualify=yes
> qualifyfreq=60
> transport=wss,ws,udp,tcp,tls
> avpf=yes
> icesupport=yes
> dtlsenable=yes
> dtlsverify=no
> dtlssetup=actpass
> dtlscertfile=/var/lib/asterisk/keys/localhost.crt
> dtlsprivatekey=/var/lib/asterisk/keys/localhost.key
> encryption=yes
> callgroup=
> pickupgroup=
> dial=SIP/1001
> mailbox=1001 at device
> permit=0.0.0.0/0.0.0.0
> callerid=Usuario Alex <1001>
> callcounter=yes
> faxdetect=no
>
>
> With this setup, I can make calls using the SIP softphone as usual, both into and out of asterisk. After approving the certificate exceptions, I can also use the webrtc account to generate a call from either Firefox or Google Chrome into asterisk, out to 
> the SIP softphone.
>
> The problem arises when I try to make asterisk send a call into the browser. When using Firefox 43 I can receive the call normally (this required patching around ASTERISK-25659) and all is well. However, in Google Chrome, the call is rejected with a 
> message of "Failed to set remote video description send parameters.." as shown in this SIP trace in the browser console:
>
>
>
> Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.transport | received WebSocket text message:
>
> INVITE sip:8dgpkoa2 at 192.0.2.210;transport=wss SIP/2.0
> Via: SIP/2.0/WS 10.1.0.4:5060;branch=z9hG4bK4f80b96d;rport
> Max-Forwards: 70
> From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as37a33245
> To: <sip:8dgpkoa2 at 192.0.2.210;transport=wss>
> Contact: <sip:anonymous at 10.1.0.4:5060;transport=WS>
> Call-ID: 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060
> CSeq: 102 INVITE
> User-Agent: FPBX-2.11.0(11.20.0)
> Date: Wed, 20 Jan 2016 18:54:52 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Content-Type: application/sdp
> Content-Length: 1799
>
> v=0
> o=root 469858785 469858785 IN IP4 10.1.0.4
> s=Asterisk PBX 11.21.0
> c=IN IP4 10.1.0.4
> b=CT:384
> t=0 0
> m=audio 14814 UDP/TLS/RTP/SAVPF 4 0 3 8 18 110 9 101
> a=rtpmap:4 G723/8000
> a=fmtp:4 annexa=no
> a=rtpmap:0 PCMU/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=no
> a=rtpmap:110 speex/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=ice-ufrag:0e746cd50c88ce6e383ff3882acebb80
> a=ice-pwd:1a9a09862254ae253f06a0bb184fd1b5
> a=candidate:Ha010004 1 UDP 2130706431 10.1.0.4 14814 typ host
> a=candidate:Hc0a80592 1 UDP 2130706431 192.168.5.146 14814 typ host
> a=candidate:Ha010004 2 UDP 2130706430 10.1.0.4 14815 typ host
> a=candidate:Hc0a80592 2 UDP 2130706430 192.168.5.146 14815 typ host
> a=connection:new
> a=setup:actpass
> a=fingerprint:SHA-256 A1:9E:D0:11:26:AA:30:00:AF:06:87:9C:A7:C2:70:4F:A3:3F:89:B5:7D:5C:FA:90:89:7E:D0:8A:F0:72:F5:2A
> a=sendrecv
> m=video 13042 UDP/TLS/RTP/SAVPF 99 98 34 31
> a=ice-ufrag:68dab2b617fb033e5e3ed2821c99488a
> a=ice-pwd:0ab624a87de92ca424db5af41da0cef3
> a=candidate:Ha010004 1 UDP 2130706431 10.1.0.4 13042 typ host
> a=candidate:Hc0a80592 1 UDP 2130706431 192.168.5.146 13042 typ host
> a=candidate:Ha010004 2 UDP 2130706430 10.1.0.4 13043 typ host
> a=candidate:Hc0a80592 2 UDP 2130706430 192.168.5.146 13043 typ host
> a=connection:new
> a=setup:actpass
> a=fingerprint:SHA-256 A1:9E:D0:11:26:AA:30:00:AF:06:87:9C:A7:C2:70:4F:A3:3F:89:B5:7D:5C:FA:90:89:7E:D0:8A:F0:72:F5:2A
> a=rtpmap:99 H264/90000
> a=fmtp:99 redundant-pic-cap=0;parameter-add=0;packetization-mode=0;level-asymmetry-allowed=0
> a=rtpmap:98 H263-1998/90000
> a=fmtp:98 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0
> a=rtpmap:34 H263/90000
> a=fmtp:34 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0
> a=rtpmap:31 H261/90000
> a=sendrecv
>
>
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.sipmessage | header "Content-Disposition" not present
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.transport | sending WebSocket message:
>
> SIP/2.0 100 Trying
> Via: SIP/2.0/WS 10.1.0.4:5060;branch=z9hG4bK4f80b96d;rport
> To: <sip:8dgpkoa2 at 192.0.2.210;transport=wss>
> From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as37a33245
> Call-ID: 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060
> CSeq: 102 INVITE
> Supported: outbound
> User-Agent: SIP.js/0.7.2
> Content-Length: 0
>
>
>
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.dialog | 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060kqug9lojk8as37a33245 | new UAS dialog created with status EARLY
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.inviteservercontext | 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060as37a33245 | invalid SDP (A)
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.inviteservercontext | 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060as37a33245 | Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set 
> remote video description send parameters..
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.transport | sending WebSocket message:
>
> SIP/2.0 488 Not Acceptable Here
> Via: SIP/2.0/WS 10.1.0.4:5060;branch=z9hG4bK4f80b96d;rport
> To: <sip:8dgpkoa2 at 192.0.2.210;transport=wss>;tag=kqug9lojk8
> From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as37a33245
> Call-ID: 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060
> CSeq: 102 INVITE
> Supported: outbound
> User-Agent: SIP.js/0.7.2
> Content-Length: 0
>
>
>
> sip-0.7.2.js:2892 Wed Jan 20 2016 13:54:53 GMT-0500 (ECT) | sip.transport | received WebSocket text message:
>
> ACK sip:8dgpkoa2 at 192.0.2.210;transport=wss SIP/2.0
> Via: SIP/2.0/WS 10.1.0.4:5060;branch=z9hG4bK4f80b96d;rport
> Max-Forwards: 70
> From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as37a33245
> To: <sip:8dgpkoa2 at 192.0.2.210;transport=wss>;tag=kqug9lojk8
> Contact: <sip:anonymous at 10.1.0.4:5060;transport=WS>
> Call-ID: 61c6be5b44d587c80b56f98e756037ab at 10.1.0.4:5060
> CSeq: 102 ACK
> User-Agent: FPBX-2.11.0(11.20.0)
> Content-Length: 0
>
>
> From what I could trace, the failing call is one on RTCPeerConnection.setRemoteDescription() with a string parameter containing the SDP body. However, the error message tells me nothing about what exactly is wrong with the SDP. A Google search with the 
> error message returns me only three results, which only point right into the guts of the source code of public repositories for Chrome.
>
> I have looked into http://forums.digium.com/viewtopic.php?f=1&t=90167&sid=66fdf8cc4be5d955ba584e989a23442f as suggested by the SIP.js guide in Asterisk configuration, and none of the scenarios outlined match what I am seeing. I have tried setting 
> force_avp=yes without it making any difference.
>
> Is there something that stands out as being incorrect about my configuration, or the SDP, that could explain the Chrome failure? Is there a known way to make the browser show more information, short of recompiling, so that I can get a clue on how to 
> debug this?
>

Partial fix: Google Chrome accepts the call if videosupport is set to "no". This is the SDP of the successful INVITE that Chrome accepts:

INVITE sip:8cj802p8 at 192.0.2.240;transport=wss SIP/2.0
Via: SIP/2.0/WS 10.1.0.4:5060;branch=z9hG4bK65071dc5;rport
Max-Forwards: 70
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=as474012b5
To: <sip:8cj802p8 at 192.0.2.240;transport=wss>
Contact: <sip:anonymous at 10.1.0.4:5060;transport=WS>
Call-ID: 73b82a5b6fbaab50741cd99424b1f31a at 10.1.0.4:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.11.0(11.20.0)
Date: Wed, 20 Jan 2016 23:27:51 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 937

v=0
o=root 2094440180 2094440180 IN IP4 10.1.0.4
s=Asterisk PBX 11.21.0
c=IN IP4 10.1.0.4
t=0 0
m=audio 18758 UDP/TLS/RTP/SAVPF 4 0 3 8 18 110 9 101
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:110 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=ice-ufrag:0033e2a20fe4becd1c34b13f5efcf1e3
a=ice-pwd:65693b30588f061710baa3584253eaba
a=candidate:Ha010004 1 UDP 2130706431 10.1.0.4 18758 typ host
a=candidate:Hc0a80592 1 UDP 2130706431 192.168.5.146 18758 typ host
a=candidate:Ha010004 2 UDP 2130706430 10.1.0.4 18759 typ host
a=candidate:Hc0a80592 2 UDP 2130706430 192.168.5.146 18759 typ host
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 A1:9E:D0:11:26:AA:30:00:AF:06:87:9C:A7:C2:70:4F:A3:3F:89:B5:7D:5C:FA:90:89:7E:D0:8A:F0:72:F5:2A
a=sendrecv

However, I want to enable full video passthrough. Is this some kind of video codec incompatibility?



More information about the asterisk-users mailing list