Re: BUNDLE nightmare when first media section becomes inactive

On Thu, Aug 24, 2017 at 10:00 PM, Byron Campen <docfaraday@gmail.com> wrote:
> On 8/24/17 2:50 PM, Iñaki Baz Castillo wrote:
>> 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).

OK. However, do you expect that WebRTC implementations really
distinguish between a=inactive and port 0? At least Firefox does not.
It automatically closes the transport as far as there is no *sending*
tracks (no matter there is a datachannel or an active receiving
track):

https://bugzilla.mozilla.org/show_bug.cgi?id=1355486


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

Clear.



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

I don't think that any of those "implementations" would even
understand a SDP with more than 2 m= sections with same media type...

Thanks a lot.


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