Re: BUNDLE nightmare when first media section becomes inactive

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 
c-line.
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