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: Thu, 24 Aug 2017 15:00:27 -0500
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <375801b3-a072-7ac5-100a-28fc1494dec2@gmail.com>
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
Received on Thursday, 24 August 2017 20:00:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC