asterisk users - Jan 2016 - Incoming webrtc call succeeds in Firefox but fails in Google Chrome

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
callgrouppickupgroupdial=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
callgrouppickupgroupdial=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?

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?

El 20/01/16 a las 18:33, Alex Villac??s Lasso escribi?:
> El 20/01/16 a las 16:25, Alex Villac??s Lasso escribi?:
>
> 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?
>
If I enable allow=vp8 to the set of allowed codecs, Chrome accepts the video
call, but now I get no sound with the demo-congrats command.