- 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>
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 implementation. >>> 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... True. Best regards, Byron Campen
Received on Thursday, 24 August 2017 20:32:46 UTC