SIPML5 Failures on Chrome 24
554 views
Skip to first unread message
Nick Foster
Nov 29, 2012, 11:47:50 AM11/29/12
to doub...@googlegroups.com
Since the launch of Chrome 23 on stable I have been unable to get the SIPML5 library and the Asterisk server to handle a webrtc call on the dev channel aka Chrome 24.
In the browser I get a "SetRemoteDescription Failed" notification but no further information. After a bunch of Google searching I found a hint that Asterisk might not be able to handle more than one crypto lines in the SDP. This was confirmed when looking at the SDP and found that the answer SDP from asterisk was using the wrong tag for the crypto it choose (ex below). And further confirmed with the error in the asterisk logs "SRTP unprotect failed with: authentication failure 110"
So I tried to strip one of the crypto lines before sending to asterisk and the that seems to work. The error is no longer in asterisk and chrome 24 seems to get further, however I still get a "SetRemoteDescription Failed" in the chrome console (SDP below).
Looking at the chrome debug logs I see this error:
[80023:-1399733568:1128/221209:VERBOSE1:webrtcsession.cc(514)] SetRemoteDescription called with action in wrong state, action: 2 state: 14
I have done some searching and cannot find anything on this error except the source code on code.google.com. The state it is in is STATE_INPROGRESS but chrome seems to be expecting the state to be in STATE_SENTINITIATE.
Has anyone run into this or done anything to get SIPML5 working with Asterisk on Chrome 24 (the dev tree)?
- Nick
FYI - This is important since Chrome 24 is likely launching to stable in the coming weeks.
Chrome 24 Offer (just crypto lines):
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:mlNpHzy64PQuJqw0rfe814MY8HfYF9rHyhYgUmjH
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:pBYD2q50iqS4YWmtgCSiXYO10BE70LkKJrG2MZko
Asterisk Answer (just crypto lines):
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:onFxSJ+EZwf0xgrWPsOZGPDgcU0RSDDQtdVU9IhO
Notice tag is 1 but the type for tag 1 in the offer is _80 but in the answer it is _32
After fixing multiline crypto lines SDP:
v=0
o=root 230334263 230334263 IN IP4 173.255.113.207
s=Asterisk PBX SVN--r
c=IN IP4 173.255.113.207
t=0 0
m=audio 16952 RTP/SAVPF 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=ice-ufrag:0a1c05ed23b7154617d977a7214d5483
a=ice-pwd:10e946af53d122075ee84d0a33e8c223
a=ice-options:google-ice
a=candidate:Ha18678b 1 udp 2130706431 10.24.103.139 16952 typ host generation 0 svn 16
a=candidate:Hadff71cf 1 udp 2130706431 173.255.113.207 16952 typ host generation 0 svn 16
a=candidate:Ha18678b 2 udp 2130706430 10.24.103.139 16953 typ host generation 0 svn 16
a=candidate:Hadff71cf 2 udp 2130706430 173.255.113.207 16953 typ host generation 0 svn 16
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:cXcJ7ORKzUdDMztPTEPp4UtAI5pSRLTmCopPxAnS
Nick Foster
Nov 29, 2012, 4:33:42 PM11/29/12
to doub...@googlegroups.com
The errors found within the chrome logs may be something else entirely.
I am currently not getting any media flowing but all parties think the call is setup.
I have a theory that this is because of this issue http://code.google.com/p/webrtc/issues/detail?id=932
Basically it seems that chrome 24 is now requiring a=ssrc lines in the SDP, at least until they fix the bug and support no ssrc lines.
Does anyone know how to get the ssrc lines in the SDP? Has anyone had to solve this issue for chrome 24 yet?
- Nick
Mamadou
Dec 7, 2012, 7:01:43 PM12/7/12
to discuss-doubango
check my comment at https://groups.google.com/group/discuss-webrtc/browse_thread/thread/4829ea5497e4a290
On Nov 29, 10:33 pm, Nick Foster <n...@firespotter.com> wrote:
> The errors found within the chrome logs may be something else entirely.
> I am currently not getting any media flowing but all parties think the call
> is setup.
> I have a theory that this is because of this issuehttp://code.google.com/p/webrtc/issues/detail?id=932
On Nov 29, 10:33 pm, Nick Foster <n...@firespotter.com> wrote:
> The errors found within the chrome logs may be something else entirely.
> I am currently not getting any media flowing but all parties think the call
> is setup.
Nick Foster
Dec 10, 2012, 1:30:57 PM12/10/12
to doub...@googlegroups.com
I replied to the same thread but haven't heard anything back yet.
I am trying hard to find a solution here because i have a feeling chrome 24 will move to stable tomorrow or shortly after that. Trying to find a way to fix this issue before it launches.
Any help you can provide is much appreciated.
Thanks,
- Nick
--
Mamadou
Dec 10, 2012, 1:55:30 PM12/10/12
to doub...@googlegroups.com, Nick Foster
It's hard to help as you never provide
traces when replying. The crypto issue you reported is fixed in
the new Asterisk patch.
Chrome stable is 23.xx and both Canary and Dev 25.xx. You're talking about 24.xx but I'm not using this version and the only way I can help is with full logs and network trace.
I'd be surprised if they release the same code as what's in dev or canary as there are regressions (for example: https://groups.google.com/group/discuss-webrtc/browse_thread/thread/64de068f36447685#).
My status:
stable: working
dev: working if you make changes as I explained.
Chrome stable is 23.xx and both Canary and Dev 25.xx. You're talking about 24.xx but I'm not using this version and the only way I can help is with full logs and network trace.
I'd be surprised if they release the same code as what's in dev or canary as there are regressions (for example: https://groups.google.com/group/discuss-webrtc/browse_thread/thread/64de068f36447685#).
My status:
stable: working
dev: working if you make changes as I explained.
--
Nick Foster
Dec 10, 2012, 2:35:35 PM12/10/12
to Mamadou, doub...@googlegroups.com
I used to work at Google and worked very closely with many chrome and webrtc engineers. They have confirmed that chrome 24 will be coming out in Dec, and Google Chrome usually likes to deploy to stable on a Tuesday. They have acknowledged http://code.google.com/p/webrtc/issues/detail?id=932 and made it blocker for 25, however not for 24. This isn't an issue for chrome as peer to peer webrtc works as these attributes exist in both SDPs so the audio can flow. However it is an issue for us that are using a non chrome endpoint.
I have also fixed the crypto line issue by stripping it out of the offer sent from the browser but still have no audio.
Here are traces for my calls on chrome 24 and chrome 25, the chrome logs, the laptop pcaps and the asterisk pcaps.
Mamadou
Dec 10, 2012, 5:08:41 PM12/10/12
to doub...@googlegroups.com, Nick Foster
I've checked: "chrome25_asterisk.pcap"
and "chrome25_debug.log"
==chrome25_debug.log==
*Chrome:
1) SDP in INVITE
2) expect media on ports 56542(rtp) and 56542(rtcp)
3) SSRC signaled in the SDP=1763898
*Asterisk:
1) SDP in 200 OK
2) expect media on ports 12818(rtp) and 12819(rtcp)
3) SSRC signaled in the SDP=111857632
==chrome25_asterisk.pcap==
1) there is RTP (PCMU) from 56542 (chrome) to 12818(asterisk): ssrc = 1763898, example = pkt #120
2) there is RTP(PCMU) from12818(asterisk) to 56542(chrome): ssrc = 111857632, example = pkt #124
==diagnostic==
there is audio on both sides and SSRC values are correct.
who are you calling (sip client, another chrome, voice mail...)?
what's the expected sound (echo, voice mail...)?
do you have error messages about crypto on asterisk?
are you sure the mic and speaker are ok?
==chrome25_debug.log==
*Chrome:
1) SDP in INVITE
2) expect media on ports 56542(rtp) and 56542(rtcp)
3) SSRC signaled in the SDP=1763898
*Asterisk:
1) SDP in 200 OK
2) expect media on ports 12818(rtp) and 12819(rtcp)
3) SSRC signaled in the SDP=111857632
==chrome25_asterisk.pcap==
1) there is RTP (PCMU) from 56542 (chrome) to 12818(asterisk): ssrc = 1763898, example = pkt #120
2) there is RTP(PCMU) from12818(asterisk) to 56542(chrome): ssrc = 111857632, example = pkt #124
==diagnostic==
there is audio on both sides and SSRC values are correct.
who are you calling (sip client, another chrome, voice mail...)?
what's the expected sound (echo, voice mail...)?
do you have error messages about crypto on asterisk?
are you sure the mic and speaker are ok?
--
Nick Foster
Dec 10, 2012, 5:14:15 PM12/10/12
to Mamadou, doub...@googlegroups.com
On Mon, Dec 10, 2012 at 2:08 PM, Mamadou <diopm...@doubango.org> wrote:
I've checked: "chrome25_asterisk.pcap" and "chrome25_debug.log"
==chrome25_debug.log==
*Chrome:
1) SDP in INVITE
2) expect media on ports 56542(rtp) and 56542(rtcp)
3) SSRC signaled in the SDP=1763898
*Asterisk:
1) SDP in 200 OK
2) expect media on ports 12818(rtp) and 12819(rtcp)
3) SSRC signaled in the SDP=111857632
==chrome25_asterisk.pcap==
1) there is RTP (PCMU) from 56542 (chrome) to 12818(asterisk): ssrc = 1763898, example = pkt #120
2) there is RTP(PCMU) from12818(asterisk) to 56542(chrome): ssrc = 111857632, example = pkt #124
==diagnostic==
there is audio on both sides and SSRC values are correct.
who are you calling (sip client, another chrome, voice mail...)?
Asterisk echo test
what's the expected sound (echo, voice mail...)?
Repeat back to you what is said
do you have error messages about crypto on asterisk?
Nope.
are you sure the mic and speaker are ok?
Yup, I am conducting similar tests on chrome 23 and the echo test works as expected.
I have been studying the chrome logs between 23 and 24 and I found that on 23 chrome is creating a stream connection between 8 possibilities, where chrome 24 is only trying it for 4. And infact it isn't using its external ip, just internal.
I just sent this to Justin Uberti of the webrtc team who I have been talking with about these issues:
Here is the a=candidates from 23:
Invite:
a=candidate:4149022451 1 udp 2113937151 192.168.1.221 51006 typ host generation 0
a=candidate:4149022451 2 udp 2113937151 192.168.1.221 51006 typ host generation 0
a=candidate:1980041287 1 udp 1677729535 206.80.0.70 57593 typ srflx generation 0
a=candidate:1980041287 2 udp 1677729535 206.80.0.70 57593 typ srflx generation 0
a=candidate:3117347331 1 tcp 1509957375 192.168.1.221 51416 typ host generation 0
a=candidate:3117347331 2 tcp 1509957375 192.168.1.221 51416 typ host generation 0
Answer:
a=candidate:Hac58b8d 1 udp 2130706431 10.197.139.141 10502 typ host
a=candidate:H6c3b5c27 1 udp 2130706431 108.59.92.39 10502 typ host
a=candidate:Hac58b8d 2 udp 2130706430 10.197.139.141 10503 typ host
a=candidate:H6c3b5c27 2 udp 2130706430 108.59.92.39 10503 typ host
And the corresponding stream creation logs in chrome_debug:
[650:-1314787328:1210/094540:VERBOSE3:webrtcvoiceengine.cc(2038)] SetOutputScaling to left=1 right=1 for channel 0 and ssrc 380642523
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:aOaRmhrz:1:0:stun:udp:206.80.0.70:57593->:1:0:local:udp:10.197.139.141:10502|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (1 total)
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:1:0:local:udp:10.197.139.141:10502|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (2 total)
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(825)] Jingle:Channel[audio|1|__]: New best connection: Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:1:0:local:udp:10.197.139.141:10502|C-wW|-]
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:aOaRmhrz:1:0:stun:udp:206.80.0.70:57593->:1:0:local:udp:108.59.92.39:10502|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (3 total)
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:1:0:local:udp:108.59.92.39:10502|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (4 total)
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:aOaRmhrz:1:0:stun:udp:206.80.0.70:57593->:2:0:local:udp:10.197.139.141:10503|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (1 total)
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:2:0:local:udp:10.197.139.141:10503|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (2 total)
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(825)] Jingle:Channel[audio|2|__]: New best connection: Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:2:0:local:udp:10.197.139.141:10503|C-wW|-]
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:aOaRmhrz:1:0:stun:udp:206.80.0.70:57593->:2:0:local:udp:108.59.92.39:10503|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (3 total)
[650:-1314787328:1210/094540:VERBOSE3:port.cc(755)] Jingle:Conn[audio:FAroNQog:1:0:local:udp:192.168.1.221:51006->:2:0:local:udp:108.59.92.39:10503|C-wW|-]: Connection created
[650:-1314787328:1210/094540:VERBOSE3:p2ptransportchannel.cc(569)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (4 total)
And the same for 24:
Offer
a=candidate:2079668366 1 udp 2113937151 192.168.1.221 50816 typ host generation 0
a=candidate:2079668366 1 udp 1677729535 206.80.0.70 50816 typ srflx generation 0
a=candidate:2079668366 2 udp 2113937151 192.168.1.221 50816 typ host generation 0
a=candidate:2079668366 2 udp 1677729535 206.80.0.70 50816 typ srflx generation 0
a=candidate:3117347331 1 tcp 1509957375 192.168.1.221 51160 typ host generation 0
a=candidate:3117347331 2 tcp 1509957375 192.168.1.221 51160 typ host generation 0
Answer
a=candidate:Hac58b8d 1 udp 2130706431 10.197.139.141 11776 typ host
a=candidate:H6c3b5c27 1 udp 2130706431 108.59.92.39 11776 typ host
a=candidate:Hac58b8d 2 udp 2130706430 10.197.139.141 11777 typ host
a=candidate:H6c3b5c27 2 udp 2130706430 108.59.92.39 11777 typ host
logs:
[570:-1314787328:1210/094020:VERBOSE3:webrtcvoiceengine.cc(2042)] SetOutputScaling to left=1 right=1 for channel 0 and ssrc 1863547539
[570:-1314787328:1210/094020:VERBOSE3:port.cc(809)] Jingle:Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:1:0:local:udp:10.197.139.141:11776|C--W|-]: Connection created
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(573)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (1 total)
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(828)] Jingle:Channel[audio|1|__]: New best connection: Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:1:0:local:udp:10.197.139.141:11776|C--W|-]
[570:-1314787328:1210/094020:VERBOSE3:port.cc(809)] Jingle:Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:1:0:local:udp:108.59.92.39:11776|C--W|-]: Connection created
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(573)] Jingle:Channel[audio|1|__]: Created connection with origin=2, (2 total)
[570:-1314787328:1210/094020:VERBOSE3:port.cc(809)] Jingle:Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:2:0:local:udp:10.197.139.141:11777|C--W|-]: Connection created
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(573)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (1 total)
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(828)] Jingle:Channel[audio|2|__]: New best connection: Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:2:0:local:udp:10.197.139.141:11777|C--W|-]
[570:-1314787328:1210/094020:VERBOSE3:port.cc(809)] Jingle:Conn[audio:qYHElTaL:1:0:local:udp:192.168.1.221:50816->:2:0:local:udp:108.59.92.39:11777|C--W|-]: Connection created
[570:-1314787328:1210/094020:VERBOSE3:p2ptransportchannel.cc(573)] Jingle:Channel[audio|2|__]: Created connection with origin=2, (2 total)
Notice that the candidates dont change really between 23 and 24, both have 2 ips to try.
However on chrome 24 all the connections created are between the local address (192.168.1.221 and either of the remotes IPs) but on 23 also the secondary ip is used (206.80.0.70). AKA in 23 there are 8 (2 pairs of 4) connections created but on 24 only 4 (2 pairs of 2).
Not sure what this means yet but seems to be the biggest difference in the logs. Any ideas as to why the 206 IP wasn't used in chrome 24?
Mamadou
Dec 10, 2012, 5:23:27 PM12/10/12
to Nick Foster, doub...@googlegroups.com
oops... they (Google) made a mistake.
The ICE foundation Ids on the candidates are not correct.
RFC 5245:
The ICE foundation Ids on the candidates are not correct.
RFC 5245:
4.1.1.3. Computing Foundations
Finally, the agent assigns each candidate a foundation. The
foundation is an identifier, scoped within a session. Two candidates
MUST have the same foundation ID when all of the following are true:
o they are of the same type (host, relayed, server reflexive, or
peer reflexive).a=candidate:2079668366 1 udp 2113937151
192.168.1.221 50816 typ host generation 0
a=candidate:2079668366 1 udp 1677729535 206.80.0.70
50816 typ srflx generation 0
a=candidate:2079668366 2 udp 2113937151
192.168.1.221 50816 typ host generation 0
a=candidate:2079668366 2 udp 1677729535 206.80.0.70
50816 typ srflx generation 0
a=candidate:3117347331 1 tcp 1509957375 192.168.1.221 51160
typ host generation 0
a=candidate:3117347331 2 tcp 1509957375 192.168.1.221 51160
typ host generation 0
Mamadou
Dec 10, 2012, 5:26:46 PM12/10/12
to doub...@googlegroups.com, Nick Foster
please report the bug at
https://groups.google.com/group/discuss-webrtc and share with us
the thread id
--
Nick Foster
Dec 13, 2012, 3:43:59 PM12/13/12
to Mamadou, doub...@googlegroups.com
To close the loop on this thread I have figured out what was wrong with chrome 24+
My final problem on this was that in chrome 24 there is now a requirement to add the audio stream to an <audio> tag on the page. Otherwise chrome wont play the media it is receiving. I found the solution in this bug,
However the bug report isn't 100% accurate, to add the stream I did this:
remoteAudio = webkitURL.createObjectURL(event.stream);
webkitObjectURL.create wasn't an function available.
- Nick
Reply all
Reply to author
Forward
0 new messages