Re: BUNDLE nightmare when first media section becomes inactive

>
> If you stopped the _transceiver_, then the offerer and answerer would need
> to recognize that the original bundle transport was gone, and to establish
> a new one, in the same manner as they would with an initial offer/answer,
> or adding a new m-section that isn't bundled.


I don't think this is correct. From the perspective of the BUNDLE spec,
this is "Disabling A Media Description In A BUNDLE Group" (section 8.5.4).
There's a note that specifically addresses this scenario:

   NOTE: If the removed "m=" line is associated with the previously
>    selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
>    [Section 8.2.1].


Note that this only says you need to select a new BUNDLE-tag, not a new
address.

In other words, the subsequent offer (or answer) with a rejected "audio"
section needs to use "a=BUNDLE: video", but it doesn't need to use a new
transport for video.

This has been a longstanding issue in Chrome. But I've always considered it
a bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=6704

On Thu, Aug 24, 2017 at 1:00 PM, Byron Campen <docfaraday@gmail.com> wrote:

> On 8/24/17 2:50 PM, Iñaki Baz Castillo wrote:
>
>> On Thu, Aug 24, 2017 at 9:07 PM, Byron Campen <docfaraday@gmail.com>
>> wrote:
>>
>>      Since the first two m-sections contain your audio/video send tracks,
>>> and
>>> at no point are you calling transceiver.stop(), I would not expect those
>>> to
>>> be disabled at any point in the above steps. The SFU _might_ disable
>>> them in
>>> an offer for some reason, but that would cause more problems than just
>>> forcing new ICE/DTLS. In the latest spec, the only time a browser will
>>> disable an m-section is after transceiver.stop() is called, or SDP
>>> negotiation completely fails on that m-section (eg; no codecs in common).
>>> What a gateway/middlebox does is anyone's guess.
>>>      A note; if you want to have a bundle tag that is likely to stick
>>> around
>>> regardless of transceiver.stop() and SFUs deciding to disable m-sections
>>> due
>>> to track changes, DataChannel is not a bad choice.
>>>
>> Thanks, Byron. Please let me try to summarize:
>>
>> So, assuming that BUNDLE is always desired/forced, whether the same
>> ICE+DTLS transport remains open and used just depends on the FIRST m=
>> section being always active (for sending and/or receiving), am I
>> right? This is:
>>
>
>     It can even be a=inactive, just so long as the m-section isn't
> disabled/rejected (ie; port 0 in answer m-section).
>
>
>> 1) If I have a pc with audio and video in just a=sendonly mode (no
>> remote tracks) and call `audioRtpSender.stop()`, then the first
>> transceiver becomes "inactive" so the transport is closed and
>> restarted and, since there is still an active video section, the
>> peerconnection is supposed to... what? initiate a new ICE + DTLS
>> handshake? with same ICE and DTLS parameters as before? Or should
>> pc.createOffer() generates new ICE and DTLS parameters?
>>
>
>     Nope; a=inactive is not enough to kill the transport. If you stopped
> the _transceiver_, then the offerer and answerer would need to recognize
> that the original bundle transport was gone, and to establish a new one, in
> the same manner as they would with an initial offer/answer, or adding a new
> m-section that isn't bundled.
>
> 2) Having a DataChannel just avoids the panic if it's in the first m=
>> section, am I right?
>>
>
>     As long as nobody closes the DataChannel, yeah. Dunno how well that
> interops though, a lot of implementations expect audio -> video ->
> application. And there isn't a way to let JS reorder the bundled mids that
> I'm aware of.
>
> Best regards,
> Byron Campen
>
>
>