Re: BUNDLE nightmare when first media section becomes inactive

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

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

> On 8/24/17 5:58 PM, Taylor Brandstetter wrote:
>
>  Right, the bundle spec does not tell us what to do here, which is a hole
>> in that spec. When you have trickle ICE, it is currently impossible for the
>> offerer to indicate which ICE transport it intends to reuse where, because
>> the c-line is not necessarily stable.
>
>
> Yeah, the BUNDLE spec is written with the assumption that the transport
> can be identified by an address, which is not true for ICE, where it's
> identified by a ufrag instead. I tried to fix this and other problems here (
> https://github.com/cdh4u/draft-sdp-bundle/pull/19), but unfortunately I
> got involved too late and my proposed changes didn't make it into the spec.
>
> 2. Some way for the offerer to unambiguously signal which transport it
>> wants to use for each bundle/lone m-section, that does not rely on the
>> c-line. Maybe some sort of tag for each transport.
>
>
> I assumed the ufrag could be used as this "tag".
>
>
>     It cannot unless there is spec language that says it needs to be
> different for each transport. There is no such language, to my knowledge.
> There's also interop to worry about; Firefox does not use a different ufrag
> for each transport, and I doubt many other implementations do either. Keep
> in mind that interoperating with gateways and such is the likeliest time to
> see bundle shenanigans...
>
> Best regards,
> Byron Campen
>