Closed Bug 814038 Opened 9 years ago Closed 9 years ago
Incorrect, inconsistent handling of initial offer with c=IN IP4 0
.0 .0 .0
[This is on mozilla-incoming head] Presently, Chrome send initial offers with no addresses, followed by trickle ICE candidates as they are collected. An example of such an offer is: v=0 o=- 1713781661 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video m=audio 1 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126 a=fingerprint:sha-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lBrbdDfrVBH1cldN a=ice-pwd:rzh23jet4QpCaEoj9Sl75pL3 a=ice-options:google-ice a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:RzrYlzpkTsvgYFD1hQqNCzQ7y4emNLKI1tODsjim a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:111 opus/48000 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=ssrc:661333377 cname:KIXaNxUlU5DP3fVS a=ssrc:661333377 msid:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5 a0 a=ssrc:661333377 mslabel:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5 a=ssrc:661333377 label:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5a0 m=video 1 RTP/SAVPF 100 101 102 a=fingerprint:sha-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:lBrbdDfrVBH1cldN a=ice-pwd:rzh23jet4QpCaEoj9Sl75pL3 a=ice-options:google-ice a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:RzrYlzpkTsvgYFD1hQqNCzQ7y4emNLKI1tODsjim a=rtpmap:100 VP8/90000 a=rtpmap:101 red/90000 a=rtpmap:102 ulpfec/90000 a=ssrc:3012607008 cname:KIXaNxUlU5DP3fVS a=ssrc:3012607008 msid:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5 v0 a=ssrc:3012607008 mslabel:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5 a=ssrc:3012607008 label:A5UL339RyGxT7zwgyF12BFqesxkmbUsaycp5v0 The reply from Firefox looks like: v=0 o=Mozilla-SIPUA 19 0 IN IP4 0.0.0.0 s=SIP Call t=0 0 a=ice-ufrag:8f7e50a7 a=ice-pwd:6232f265ee2d8ec8e2c857b7731b3bc8 a=fingerprint:sha-256 D0:26:65:51:78:17:2B:18:0C:FF:18:45:62:BD:44:45:C7:B6:86:F3:A2:D8:C2:AE:C8:60:54:10:D5:86:54:8C m=audio 0 RTP/SAVPF 26492 c=IN IP4 0.0.0.0 m=video 64389 RTP/SAVPF 120 c=IN IP4 188.8.131.52 a=rtpmap:120 VP8/90000 a=inactive a=candidate:... [ice candidates elided] There are actually several issues here. First, even though the audio and video in the offer are congruent (they both offer connection addresses of 0.0.0.0), the answer handles them differently: audio is disabled (note the port number of 0), while video is merely inactive. Regardless of how these *should* be handled, it needs to be the same between audio and video. Second, the response of "m=audio 0..." is a rejection of the audio stream, which isn't what should happen here. RFC3264 actually allows offers to send a connection address of 0.0.0.0 "[W]hen the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer." Since the stream will presumably be taken off hold at some point in the future, we need to accept the stream. It's not clear whether we should be supplying ICE candidates at this time. That said, trickle ice candidates will not take the streams off hold: we need a new offer with an address other than "0.0.0.0" before that can happen.
The use of "26492" as a payload type in the m=audio line in the answer is also suspect, and probably indicates reading into uninitialized memory.
The audio inactivation appears to be a codec negotiation failure, unrelated to the use of "0.0.0.0" in the offer. This issue is also impacting bug 810220.
The attached patch takes care of the two issues I describe above, but I'm not yet convinced that it's 100% correct (since the codec negotiation still fails to find a codec in common under all circumstances).
Okay, I don't think we should be inactive here. Given that we're willing to receive streams, and that the remote party has indicated sendrecv, I think we should at *least* be recvonly.
Actually, scratch that previous comment. As long as we come out of inactive gracefully when we get new SDP from the remote end activating the streams, then this behavior is just fine. I'm going to consider the "codec negotiation fail" to be part of bug 810220, and call this one finished.
Comment on attachment 684110 [details] [diff] [review] Fixing codec negotiation to use actual payload in SDP rather than preferred payload when populating codec-specific parameters Review of attachment 684110 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. You'll want to update the patch to apply onto the latest M-I. Watch for the .rej file it creates.
Attachment #684110 - Flags: review?(ethanhugg) → review+
New patch applies to m-i 6c898c401b60 cleanly
Attachment #684154 - Attachment description: Fixing codec negotiation to use actual payload in SDP rather than preferred payload when populating codec-specific parameters → Fixing codec negotiation to use actual payload in SDP rather than preferred payload when populating codec-specific parameters r=ehugg
Target Milestone: --- → mozilla20
Attachment #684165 - Flags: checkin?(rjesup) → checkin+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.