“ICE failed” in Chrome-Firefox WebRTC

Question

Firefox version: 37

Chrome version: 40

I am calling from chrome-firefox in a WebRTC application and it is not showing a remote stream. firefox-firefox and chrome-chrome are both fine.

I add my local stream to the peer connection, create my answer and send it via my signalling method, and then start sending my ice candidates.

One possible issue is that I may be receiving (and setting on the peerConnection) ice candidates before I create my answer on the receiver side, although, I did try putting timeouts on candidate adding to ensure that doesn't happen and the problem was the same.

Here is information from the Firefox side, where I ultimately get "ICE failed, see about:webrtc for more details"

SDP settings (IP addresses censored):

Local SDP

v=0
o=mozilla...THIS_IS_SDPARTA-37.0.2 6210678986336338968 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 7D:6F:E7:3F:5A:65:27:3A:EB:41:5E:E3:B0:91:02:59:81:5F:48:8C:DE:96:FC:89:ED:9D:C4:BF:E0:0A:1D:DF
a=group:BUNDLE audio video
a=ice-options:trickle
m=audio 18943 RTP/SAVPF 111
c=IN IP4 <ip2>
a=candidate:0 1 UDP 2122252543 <ip1> 36102 typ host
a=candidate:1 1 UDP 1686110207 <ip5> 39509 typ srflx raddr <ip1> rport 36102
a=candidate:3 1 UDP 92274687 <ip2> 18943 typ relay raddr <ip2> rport 18943
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:679dfdec38e1d2899d3614d64081186a
a=ice-ufrag:d064eacb
a=mid:audio
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=setup:active
a=ssrc:2905377298 cname:{506042e1-9b66-42b4-8238-dad7d0edecf2}
m=video 18207 RTP/SAVPF 100
c=IN IP4 <ip2>
a=candidate:0 1 UDP 2122252543 <ip1> 40785 typ host
a=candidate:0 2 UDP 2122252542 <ip1> 38373 typ host
a=candidate:1 1 UDP 1686110207 <ip5> 51040 typ srflx raddr <ip1> rport 40785
a=candidate:1 2 UDP 1686110206 <ip5> 20057 typ srflx raddr <ip1> rport 38373
a=candidate:3 1 UDP 92274687 <ip2> 18207 typ relay raddr <ip2> rport 18207
a=candidate:3 2 UDP 92274686 <ip2> 18115 typ relay raddr <ip2> rport 18115
a=sendrecv
a=end-of-candidates
a=fmtp:100 max-fs=12288;max-fr=60
a=ice-pwd:679dfdec38e1d2899d3614d64081186a
a=ice-ufrag:d064eacb
a=mid:video
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 ccm fir
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=setup:active
a=ssrc:488270549 cname:{506042e1-9b66-42b4-8238-dad7d0edecf2}

Remote SDP

v=0
o=- 7318013814084266610 2 IN IP4 127.0.0.1
s=-
t=0 0
a=sendrecv
a=group:BUNDLE audio video
a=msid-semantic:WMS
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126
c=IN IP4 0.0.0.0
a=candidate:2193902281 1 udp 2122260223 <ip4> 48993 typ host generation 0
a=candidate:1313437018 1 udp 1686052607 <ip3> 49740 typ srflx raddr <ip4> rport 48993 generation 0
a=candidate:2193902281 2 udp 2122260223 <ip4> 48993 typ host generation 0
a=candidate:3427251769 2 tcp 1518280447 <ip4> 0 typ host tcptype active generation 0
a=candidate:1313437018 2 udp 1686052607 <ip3> 49740 typ srflx raddr <ip4> rport 48993 generation 0
a=candidate:3427251769 1 tcp 1518280447 <ip4> 0 typ host tcptype active generation 0
a=candidate:3785383356 1 udp 41885439 <ip6> 15958 typ relay raddr <ip3> rport 49740 generation 0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=fingerprint:sha-256 C1:CB:BF:44:C5:A0:AD:C2:72:DA:6B:1D:3B:8B:6D:EA:48:56:21:A9:70:7B:F0:A1:AA:9B:BC:38:81:CF:5E:FA
a=ice-options:google-ice
a=ice-pwd:y/RCxcbHnWBQ11TkkIgguND7
a=ice-ufrag:zwx79P612mklrN8V
a=maxptime:60
a=mid:audio
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000/1
a=rtpmap:104 ISAC/32000/1
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000/1
a=rtpmap:105 CN/16000/1
a=rtpmap:13 CN/8000/1
a=rtpmap:126 telephone-event/8000/1
a=setup:actpass
a=ssrc:3947573917 cname:sH2LQZ+VcJ2oyRhi
a=ssrc:3947573917 msid:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz 3b60d586-c63b-4ab8-962a-9f49cb304480
a=ssrc:3947573917 mslabel:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz
a=ssrc:3947573917 label:3b60d586-c63b-4ab8-962a-9f49cb304480
m=video 9 RTP/SAVPF 100 116 117 96
c=IN IP4 0.0.0.0
a=candidate:2193902281 1 udp 2122260223 <ip4> 48993 typ host generation 0
a=candidate:2193902281 2 udp 2122260223 <ip4> 48993 typ host generation 0
a=candidate:3427251769 1 tcp 1518280447 <ip4> 0 typ host tcptype active generation 0
a=candidate:1313437018 1 udp 1686052607 <ip3> 49740 typ srflx raddr <ip4> rport 48993 generation 0
a=candidate:1313437018 2 udp 1686052607 <ip3> 49740 typ srflx raddr <ip4> rport 48993 generation 0
a=candidate:3427251769 2 tcp 1518280447 <ip4> 0 typ host tcptype active generation 0
a=candidate:3785383356 1 udp 41885439 <ip5> 15958 typ relay raddr <ip3> rport 49740 generation 0
a=sendrecv
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=fingerprint:sha-256 C1:CB:BF:44:C5:A0:AD:C2:72:DA:6B:1D:3B:8B:6D:EA:48:56:21:A9:70:7B:F0:A1:AA:9B:BC:38:81:CF:5E:FA
a=ice-options:google-ice
a=ice-pwd:y/RCxcbHnWBQ11TkkIgguND7
a=ice-ufrag:zwx79P612mklrN8V
a=mid:video
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=setup:actpass
a=ssrc:1338156545 cname:sH2LQZ+VcJ2oyRhi
a=ssrc:1338156545 msid:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz a574999b-48e2-448d-abd4-8c61bea4d24f
a=ssrc:1338156545 mslabel:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz
a=ssrc:1338156545 label:a574999b-48e2-448d-abd4-8c61bea4d24f
a=ssrc:4062078076 cname:sH2LQZ+VcJ2oyRhi
a=ssrc:4062078076 msid:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz a574999b-48e2-448d-abd4-8c61bea4d24f
a=ssrc:4062078076 mslabel:f11srXWZnw7HYBbEfqK65NOcnuxjyX1nHCaz

The log has error messages like this:

ICE(PC:1429771770507818 (id=590 url=<censored>): Message does not correspond to any registered stun ctx
Inconsistent message method: 103 expected 001
(PC:1429771770507818 (id=590 url=<censored>) has no stream matching stream 142977177050781
(PC:1429771770507818 (id=590 url=<censored>) specified too many components

On the chrome side I see some ambiguous error messages when trying to add the ICE candidates sent from Firefox through the signal channel. They look like this:

RTCIceCandidate
  candidate: "candidate:3 2 UDP 92274686 <ip> typ relay raddr <ip> rport 18910"
  sdpMLineIndex: 1
  sdpMid: "null"

and the error message:

Failed to execute 'addIceCandidate' on 'RTCPeerConnectiion': The ICE candidate could not be added.

Is there some kind of inconsistency between firefox and chrome I am not addressing?

Are you using public stun/turn servers? Are you testing this across different networks or on the same network? "Message does not correspond to any registered stun ctx" seems to point to ice candidate pairs not matching due to being added in an incorrect order ... or just plain timing out during network discovery. — Michael Gorham
It is on the same network. Does the order in which the ice candidates are received an added make a difference? Because the signalling channel could deliver them at different times — Peter Ashwell
The order of sending shouldn't matter ... it does matter as far as when you add the ice candidates (I.e., first call createAnswer, then setLocalDescription, then start adding candidates.) — Michael Gorham

mido mido · Accepted Answer · 2015-04-28T07:45:49

not sure if this would work, but give the below code a try, before adding the ICE candidate, just try reforming the RTCIceCandidate from what is being sent...

...
candidate = new RTCIceCandidate({
        sdpMLineIndex: candidate.label,
        candidate: candidate.candidate
});
peerConnection.addIceCandidate(candidate, onSuccess, onFailure);

I am assuming RTCIceCandidate form is different in firefox and chrome hence the problem.

“ICE failed” in Chrome-Firefox WebRTC

2 Answers