W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2017

Re: BUNDLE nightmare when first media section becomes inactive

From: Byron Campen <docfaraday@gmail.com>
Date: Fri, 25 Aug 2017 12:08:40 -0500
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <0e46b2f2-fd5d-04f2-5b50-b5f32cf5a058@gmail.com>

On 8/25/17 11:45 AM, Taylor Brandstetter wrote:
>     It cannot unless there is spec language that says it needs to be
>     different for each transport.
>  It's not very clear, but there is:
>        When an offerer associates a unique address with a bundled "m="
>     line
>        (excluding any bundle-only "m=" line), the offerer MUST
>     associate SDP
>        'candidate' attributes (and other applicable ICE-related
>     media-level
>        SDP attributes), containing unique ICE properties (candidates etc),
>        with the "m=" line, according to the procedures in
>        [I-D.ietf-mmusic-ice-sip-sdp].
> In other words, an initial offer that offers fallback to not being 
> bundled MUST use unique ICE properties per m= section.
> Chrome doesn't do this either. But again, I consider that a bug: 
> https://bugs.chromium.org/p/webrtc/issues/detail?id=6351

     If neither Chrome nor Firefox does this, our hopes of other 
implementations doing it anytime soon is pretty slim indeed. And yeah, 
that language _could_ be interpreted that way, but it is so vague as to 
be useless for anything other than candidate attributes. So at a minimum 
we would need to:

1. Update the ice-sip-sdp spec to clarify that ufrag needs to be 
different for each unique address.
2. Update the bundle spec (either modify the bundle spec, or create a 
subsequent spec) to say that ufrag is taken into account along with the 
3. Try to get everyone to catch up.

     This is probably the best long-term strategy. In the meantime, 
adhering to "transport follows m-section" is probably reasonable.

Best regards,
Byron Campen
Received on Friday, 25 August 2017 17:09:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC