WebRTC SDP sets 0.0.0.0 in c line in Nightly

RESOLVED DUPLICATE of bug 1091242

Status

()

RESOLVED DUPLICATE of bug 1091242
4 years ago
4 years ago

People

(Reporter: alan.ford, Unassigned)

Tracking

35 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
Testing against Nightly (35, 2014-09-24), Firefox generates SDP with a c=IN IP4 0.0.0.0 line:

c=IN IP4 0.0.0.0
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=setup:actpass
a=rtcp-mux
a=candidate:0 1 UDP 2130379007 192.168.1.111 61133 typ host
a=candidate:0 2 UDP 2130379006 192.168.1.111 59869 typ host

This is causing an ICE mismatch (ref RFC5245 section 15.3) against standard SIP endpoints, since they expect to see a c= line that contains an IP address that is present in at least one of the ICE candidates.

I can understand that 0.0.0.0 could be valid to use with Trickle ICE, when no candidates are known (although I would probably expect the host address should be used here).

However, given my SIP endpoint does not support trickling, I am waiting for ICE candidate gathering to be complete, and as such Firefox really should populate that c= line before sending the final SDP.

Firefox 33 beta behaves correctly here.
Byron this looks like to me like fall out from the full trickle ICE support.

Comment 2

4 years ago
We could add logic to set the c-line at the same time the first candidate is added.
(In reply to Byron Campen [:bwc] from comment #2)
> We could add logic to set the c-line at the same time the first candidate is
> added.

Sounds reasonable.

Comment 4

4 years ago
Also, by advertising that IPv4 address chances are that the other end won't send FF any RTP or RTCP packet as specified in RFC 3264 section 8.4. 

I'm aware of the the trickle ICE draft, but it chooses the null IPv6 address along with the media port "9", instead of the IPv4 one.

Updated

4 years ago
Duplicate of this bug: 1106688

Comment 6

4 years ago
So, this is fixed in bug 1091242, just need to get that landed. We might also consider patching Aurora with a smaller fix.

Comment 7

4 years ago
sdparta is all the way to release now, so no need for a stopgap.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1091242
You need to log in before you can comment on or make changes to this bug.