Closed Bug 1106688 Opened 9 years ago Closed 9 years ago

Firefox 34 sets the sdp content data line ip is 0.0.0.0

Categories

(Core :: WebRTC: Signaling, defect)

34 Branch
x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1072384

People

(Reporter: hamdih4, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36

Steps to reproduce:

On Windows, Firefox 34 started generating 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: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=candidate:0 1 UDP 2128609535 10.0.2.15 60150 typ host
a=candidate:0 2 UDP 2128609534 10.0.2.15 60151 typ host
a=rtcp-mux


Actual results:

This is causing an ice-mismatch (according to RFC5245 section 15.3)


Expected results:

Firefox 33.1 is generating the SDP content data line ip with the corresponding ip for the ice-candidates:

c=IN IP4 10.0.2.15
a=rtpmap:109 opus/48000/2
a=ptime:20
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=candidate:0 1 UDP 2128609535 10.0.2.15 60150 typ host
a=candidate:0 2 UDP 2128609534 10.0.2.15 60151 typ host
a=rtcp-mux

Refer to this thread, as I think this is redundant, but I created this bug to include version 34 to it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1072384

(Ref: https://www.ietf.org/rfc/rfc3264.txt / page 17 )
" RFC 2543 [10] specified that placing a user on hold was accomplished
   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when 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.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer."
OS: Mac OS X → Windows 8
Hardware: x86 → x86_64
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.