Intermittent ICE hanging in "checking" status when Chrome calls Firefox

[Amstrong]

Hello,

I am trying some interoperability between Chrome and Firefox, working on Windows 8 platforms with Chrome Version 28.0.1500.95 m and Firefox V23.0

Everything works fine, except that from time to time (1 time out of 2 approximatively, but not regular), Chrome (that issued the call) remain in the "checking" ICE state and never go to "connected". There is thus no audio or video stream flowing.

I am using the following ICE servers configuration on both sides : {iceServers:[{"url":"stun:stun.services.mozilla.com"}]} and both machines are connected on a local network without any other connectivity.

You will find hereafter the offer/answer exchange when the connection is OK and when the connection in NOT OK, its seems that the candidates issued by Chrome are different in both cases.

Thanks a lot for any help !

1) When the connection is OK :

- Chrome send the following offer :

v=0

o=- 5110178286990453551 2 IN IP4 127.0.0.1

s=-

t=0 0

a=group:BUNDLE audio video

a=msid-semantic: WMS FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:ljHSW7pHCXL6kDwI

a=ice-pwd:KjJOgA2KQWGTOGXWcxtYXiAM

a=ice-options:google-ice

a=fingerprint:sha-256 7E:C8:AE:DC:34:EF:64:76:F9:56:46:41:6B:EC:D6:43:BD:91:F5:48:97:E9:4E:76:B3:6F:59:C4:7E:3F:9E:A3

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=sendrecv

a=mid:audio

a=rtcp-mux

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:M9i8GmOsn+tyZGEz96Fbzq/lGCQ03+0u/5VSSksv

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:107 CN/48000

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:1659154818 cname:++O1O6TUP21pCbT6

a=ssrc:1659154818 msid:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqia0

a=ssrc:1659154818 mslabel:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

a=ssrc:1659154818 label:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqia0

m=video 1 RTP/SAVPF 100 116 117

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:ljHSW7pHCXL6kDwI

a=ice-pwd:KjJOgA2KQWGTOGXWcxtYXiAM

a=ice-options:google-ice

a=fingerprint:sha-256 7E:C8:AE:DC:34:EF:64:76:F9:56:46:41:6B:EC:D6:43:BD:91:F5:48:97:E9:4E:76:B3:6F:59:C4:7E:3F:9E:A3

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=sendrecv

a=mid:video

a=rtcp-mux

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:M9i8GmOsn+tyZGEz96Fbzq/lGCQ03+0u/5VSSksv

a=rtpmap:100 VP8/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack 

a=rtcp-fb:100 goog-remb 

a=rtpmap:116 red/90000

a=rtpmap:117 ulpfec/90000

a=ssrc:31627300 cname:++O1O6TUP21pCbT6

a=ssrc:31627300 msid:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqiv0

a=ssrc:31627300 mslabel:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

a=ssrc:31627300 label:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqiv0

- The following candidate are sent by Chrome :

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:1270274445 1 udp 2113937151 192.168.1.11 61328 typ host generation 0\r\n"}

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:1270274445 2 udp 2113937151 192.168.1.11 61328 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:1270274445 1 udp 2113937151 192.168.1.11 61328 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:1270274445 2 udp 2113937151 192.168.1.11 61328 typ host generation 0\r\n"}

- Firefox replies with the answer :

v=0

o=Mozilla-SIPUA-23.0 425 0 IN IP4 0.0.0.0

s=SIP Call

t=0 0

a=ice-ufrag:47cd1279

a=ice-pwd:02ecf92293b1a99d49bdb3824e7c20f3

a=fingerprint:sha-256 93:2F:60:67:D9:42:E0:11:46:D2:51:EF:63:F0:BA:C1:A7:21:89:7F:2A:92:02:B6:D5:AA:45:78:E6:3D:7B:FC

m=audio 58614 RTP/SAVPF 111 126

c=IN IP4 192.168.1.2

a=rtpmap:111 opus/48000/2

a=ptime:20

a=rtpmap:126 telephone-event/8000

a=fmtp:126 0-15

a=sendrecv

a=candidate:0 1 UDP 2111832319 192.168.1.2 58614 typ host

a=candidate:0 2 UDP 2111832318 192.168.1.2 58615 typ host

m=video 58616 RTP/SAVPF 100

c=IN IP4 192.168.1.2

a=rtpmap:100 VP8/90000

a=sendrecv

a=candidate:0 1 UDP 2111832319 192.168.1.2 58616 typ host

a=candidate:0 2 UDP 2111832318 192.168.1.2 58617 typ host

a=rtcp-fb:* nack

a=rtcp-fb:* ccm fir

- the ice goes to checking

- a null candidate is issued

- the ice goes to connected and it works

1) When the connection is NOT OK :

- Chrome send the following offer :

v=0

o=- 2400528743871018497 2 IN IP4 127.0.0.1

s=-

t=0 0

a=group:BUNDLE audio video

a=msid-semantic: WMS FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:Y0fnGJZFcj8rmKLf

a=ice-pwd:PnhSwUXEOyg0nPa3dzuvXsTJ

a=ice-options:google-ice

a=fingerprint:sha-256 4C:0E:A8:7D:37:3A:5F:70:CF:CF:C5:D1:6E:54:CC:D8:8D:F5:CC:E9:23:E8:D5:C1:F5:B1:E5:1F:FC:79:ED:EB

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=sendrecv

a=mid:audio

a=rtcp-mux

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JhOyQKNLCZruQC5RTL+fYh1sp2Ug+o7VDyML58n/

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:107 CN/48000

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:3941683052 cname:r9nknM9fu00VceaO

a=ssrc:3941683052 msid:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqia0

a=ssrc:3941683052 mslabel:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

a=ssrc:3941683052 label:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqia0

m=video 1 RTP/SAVPF 100 116 117

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:Y0fnGJZFcj8rmKLf

a=ice-pwd:PnhSwUXEOyg0nPa3dzuvXsTJ

a=ice-options:google-ice

a=fingerprint:sha-256 4C:0E:A8:7D:37:3A:5F:70:CF:CF:C5:D1:6E:54:CC:D8:8D:F5:CC:E9:23:E8:D5:C1:F5:B1:E5:1F:FC:79:ED:EB

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=sendrecv

a=mid:video

a=rtcp-mux

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JhOyQKNLCZruQC5RTL+fYh1sp2Ug+o7VDyML58n/

a=rtpmap:100 VP8/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack 

a=rtcp-fb:100 goog-remb 

a=rtpmap:116 red/90000

a=rtpmap:117 ulpfec/90000

a=ssrc:28119459 cname:r9nknM9fu00VceaO

a=ssrc:28119459 msid:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqiv0

a=ssrc:28119459 mslabel:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqi

a=ssrc:28119459 label:FPPmZJCtHcNiwm7XvwLkpqnB4LWxH5VYxGqiv0

- The following candidate are sent by Chrome :

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:1270274445 1 udp 2113937151 192.168.1.11 61336 typ host generation 0\r\n"}

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:1270274445 2 udp 2113937151 192.168.1.11 61336 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:1270274445 1 udp 2113937151 192.168.1.11 61336 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:1270274445 2 udp 2113937151 192.168.1.11 61336 typ host generation 0\r\n"}

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:87369085 1 tcp 1509957375 192.168.1.11 0 typ host generation 0\r\n"}

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:87369085 2 tcp 1509957375 192.168.1.11 0 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:87369085 1 tcp 1509957375 192.168.1.11 0 typ host generation 0\r\n"}

{"sdpMLineIndex":1,"sdpMid":"video","candidate":"a=candidate:87369085 2 tcp 1509957375 192.168.1.11 0 typ host generation 0\r\n"}

- a null candidate is issued

- Firefox replies with the answer :

v=0

o=Mozilla-SIPUA-23.0 3340 0 IN IP4 0.0.0.0

s=SIP Call

t=0 0

a=ice-ufrag:e0a48b2e

a=ice-pwd:0418867fa99adf75103b559506fcd291

a=fingerprint:sha-256 5F:99:46:21:DC:E1:7C:65:7A:5B:47:12:71:55:83:BB:D7:A1:6B:F8:06:2A:7C:42:87:9E:1E:BF:91:9B:1E:B6

m=audio 58620 RTP/SAVPF 111 126

c=IN IP4 192.168.1.2

a=rtpmap:111 opus/48000/2

a=ptime:20

a=rtpmap:126 telephone-event/8000

a=fmtp:126 0-15

a=sendrecv

a=candidate:0 1 UDP 2111832319 192.168.1.2 58620 typ host

a=candidate:0 2 UDP 2111832318 192.168.1.2 58621 typ host

m=video 58622 RTP/SAVPF 100

c=IN IP4 192.168.1.2

a=rtpmap:100 VP8/90000

a=sendrecv

a=candidate:0 1 UDP 2111832319 192.168.1.2 58622 typ host

a=candidate:0 2 UDP 2111832318 192.168.1.2 58623 typ host

a=rtcp-fb:* nack

a=rtcp-fb:* ccm fir

- the ice goes to checking and HANGS in "checking" status

[Alexandre GOUAILLARD]

that might be related to this bug:

http://code.google.com/p/webrtc/issues/detail?id=1530

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Vikas]

Hi,

Do you experience the same issue if you test with apprtc demo? 

/Vikas 

[Simon Tolham]

I am seeing exactly the same issue with no video being received if my local SDP contained the following in any of the media descriptions:

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

I believe this issue was new in Chrome 28, and I have seen in version 29 too.  Did you find a solution / workaround for this case?

[Uma Shunmugan]

Hi All,

I'm seeing a similar issue, though it happens intermittently when upgrading a call from audio-only to audio+video (not doing a downgrade, though - see below). The call is between two Chrome (current stable - v34, or canary - v36) instances via a gateway, and it uses media bundle on either side. When this happens (say about 50% of the time or perhaps less), the problem is always on the caller side that sends the updated offer.  However, strangely the same/caller side keeps receiving media (both audio and video), though it stops sending out any media (Stats graphs for Conn-audio-1-0 in webrtc-internals support this, but the Stats graphs for the particular SSRCs indicate media is being sent).  

It could be irrelevant that the webrtc-internals indicate that iceConnectionStateChange is stuck at ICEConnectionStateChecking.  However, I see the same in working cases too.  Also, the callee side does not even show iceConnectionStateChange events for the renegotiation, but it can still send media fine.

FYI: The ICE negotiations on the gateway side complete fine.  The problem happens when using SDES-SRTP as well.  There is no STUN or TURN involved.  The problem does not recover with additional renegotiations even if I try to go back to audio-only.

Note that this problem does not happen if  the call starts with audio+video, and additional renegotiations or downgrading to audio-only don't seem to cause the same issue (as long as the new offer is done from the caller side; if new offer is made from the callee side, then there is a different issue - see issue  #2979).

I tried to reproduce this using a modified version pc1.html demo, but I couldn't.

It does not seem related to issue #1530. If anyone knows about this issue, or any workaround, please let me know.  Otherwise, I'd create an issue for this.

Thanks,

 Uma

[Vikas]

Hi,

I would suggest you to file a new bug, attach chrome debug logs and logs from webrtc-internals. AFAIK, the ice connection state should be connected or completed for the media to be sent, if you are seeing it as checking that doesn't seem right. Also it would be useful if there is a sample that can help recreate the problem.

/Vikas

[Uma Shunmugan]

Thanks, Vikas!  I've created the webrtc issue #3303 for this, and attached log files. 

It seems that the problem is due to ICE/STUN check failures - I see a lot of these in the chrome debug log when this problem happened: Received STUN binding error: class=4 number=87 reason='Role conflict'.  I think that the ICE roles should not change once the session is established, unless there is an ICE restart, which is not the case here.

Best Regards,

 Uma

[Vikas]

Thanks i updated the issue. Regarding the role conflict errors, wireshark capture would be useful to help understand the problem.

/Vikas