Re: BUNDLE nightmare when first media section becomes inactive

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:

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?

2) Having a DataChannel just avoids the panic if it's in the first m=
section, am I right?


Thanks a lot (again).


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Thursday, 24 August 2017 19:51:10 UTC