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:32:20 -0500
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <75641efb-8c6e-89d2-3827-fcdc8b7c693c@gmail.com>
On 8/24/17 3:11 PM, Iñaki Baz Castillo wrote:
> 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

     Yeah, that's broken, and will be fixed in the transceivers 

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


Best regards,
Byron Campen
Received on Thursday, 24 August 2017 20:32:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:36 UTC