Re: BUNDLE nightmare when first media section becomes inactive

>
> 1. Update the ice-sip-sdp spec to clarify that ufrag needs to be different
> for each unique address.


I don't know if it belongs there, because it's really only the BUNDLE
semantics I'm suggesting that would require them to be unique.

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.


I agree updating the bundle spec would be the best long-term approach.
Though it seems like it will be a while before that will happen.

In the meantime, adhering to "transport follows m-section" is probably
> reasonable.


It does work for the most part. But how do you suggest handling the
scenario where the answerer rejects the current BUNDLE-tag m-section (
https://bugs.chromium.org/p/webrtc/issues/detail?id=6704)? It looks like
this works in Firefox because the offering PeerConnection always gathers
ICE candidates for every m= section (even if they're currently being
bundled), so it's prepared in advance for the BUNDLE-tag to change. But
that doesn't seem ideal since it requires a bunch of extra candidates to be
gathered for every offer/answer, right? And I think it goes against JSEP:

   Note that gathering phases only gather the candidates needed by
>    new/recycled/restarting m= sections; other m= sections continue to
>    use their existing candidates.  Also, if an m= section is bundled
>    (either by a successful bundle negotiation or by being marked as
>    bundle-only), then candidates will be gathered and exchanged for that
>    m= section if and only if its MID is a BUNDLE-tag, as described in
>    [I-D.ietf-mmusic-sdp-bundle-negotiation].


On Fri, Aug 25, 2017 at 10:08 AM, Byron Campen <docfaraday@gmail.com> wrote:

>
> 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
>