1308641 - invalid iceConnectionState

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect)

Description

[dsolovey]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36

Steps to reproduce:

Create peer connection and set SDP(offer) with:

audio: recvonly
video: sendrecv

v=0
o=mozilla...THIS_IS_SDPARTA-49.0 1343403849142464395 1 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 08:E2:09:DF:A5:52:B8:A5:FA:60:81:55:89:66:7B:56:FA:C7:11:89:EE:3F:F7:96:6C:EF:98:56:04:4A:A6:0F
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *

m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=recvonly
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:ec139784645d5fc3a65dac6009f872c0
a=ice-ufrag:7d5c85d0
a=mid:sdparta_0
a=rtcp-mux
a=setup:actpass
a=ssrc:1888303926 cname:{742672d9-6d34-1647-85fb-41aa8ba13fcb}
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1


m=video 9 UDP/TLS/RTP/SAVPF 100
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:ec139784645d5fc3a65dac6009f872c0
a=ice-ufrag:7d5c85d0
a=mid:sdparta_1
a=msid:{6121eaa0-6d2a-0146-a7e0-701e2bfb45f6} {8c434cf0-70c2-8b45-92f1-d7271e5f9edd}
a=rtcp-mux
a=setup:actpass
a=ssrc:2269423031 cname:{742672d9-6d34-1647-85fb-41aa8ba13fcb}
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc

Create another peer connection and set SPD(answer)

audio: inactive
video: recvonly

v=0
o=5 168614711845293630 1 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
a=ice-ufrag:DIUH5gGExCbSSlPr
a=ice-pwd:FEeQ9QJdpXSKZLlglWretbg3
a=fingerprint:sha-256 71:CC:93:24:2F:8C:AC:4E:95:5B:27:E6:79:1C:8A:76:A2:93:44:33:3D:71:5B:7B:DA:D7:5D:67:C6:1F:83:74

m=audio 9 UDP/TLS/RTP/SAVPF 111 9 0 8
c=IN IP4 0.0.0.0
a=mid:sdparta_0
a=inactive
a=rtcp-mux
a=maxptime:60
a=setup:active
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=rtpmap:111 opus/48000/2
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=fmtp:111 minptime=10;useinbandfec=1;maxplaybackrate=0;stereo=0
a=ssrc:17 cname:weEMeWE6LdqsZ8VD

m=video 9 UDP/TLS/RTP/SAVPF 100
c=IN IP4 0.0.0.0
b=AS:10000
a=mid:sdparta_1
a=recvonly
a=rtcp-mux
a=maxptime:60
a=setup:active
a=ice-ufrag:DIUH5gGExCbSSlPr
a=ice-pwd:FEeQ9QJdpXSKZLlglWretbg3
a=fingerprint:sha-256 71:CC:93:24:2F:8C:AC:4E:95:5B:27:E6:79:1C:8A:76:A2:93:44:33:3D:71:5B:7B:DA:D7:5D:67:C6:1F:83:74
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=rtpmap:100 VP8/90000
a=fmtp:100 max-fs=12288;max-fr=60
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=ssrc:18 cname:YVh0zxyTPS7YYdZg

Exchange ICEs and connect peers.



Actual results:

Connections established but FF reports:

pc.signalingState: “stable"
pc.iceConnectionState: “failed"
pc.iceGatheringState: “gathering"

Also in console FF reports error: "ICE failed, see about:webrtc for more details”

It makes pc.iceConnectionState useless because it says “failed” while connection is actually established.
Most likely the reason of this: FF always reports state only of first stream (for audio m-line), while connection is established via second stream (video m-line), since audio m-line is inactive.



Expected results:

Connection established and FF reports :

pc.signalingState: “stable"
pc.iceConnectionState: “connected"
pc.iceGatheringState: “complete

Comment 1

[Alex Chronopoulos [:achronop]]

drno or bwc, can you confirm or not this issue?

Comment 2

[Byron Campen [:bwc]]

You still need to do ICE on an inactive m-section, unless it is also rejected (has port 0 in the m-line).

Comment 3

[Nils Ohlmeier [:drno]]

In a little bit more verbose words then Byron's answer:

The SDP answer you provided appears to have unbundled the first m section with mid sdparta_0. But that m section is not rejected with port 0. Therefore what should happen here is that ICE gets established with two streams over two different ports, one for the first m section which is inactive state (see Byrons comment), and the second for the second m section with mid sdparta_1.

If your implementation tries to establish two ICE streams here and Firefox reports an ICE failure via the event, please let us know and we can investigate this scenario.

Comment 4

[dsolovey]

"Port 0" solves our problem.
Thanks  a lot!