- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 30 Apr 2015 06:52:34 +0000
- To: Peter Thatcher <pthatcher@google.com>, Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 29/04/15 18:07, Peter Thatcher wrote: > I think it makes sense to start an ICE transport even if it isn't > attached to any media or data channels. If you add media later and > BUNDLE ends up being enabled (and most the time it will be), then you > get your ICE setup earlier than you would otherwise. And adding data > channels in the SDP seems like a good way to do that. And things Just > Work for developers using data channels and nothing else. And Justin's > argument that there is network cost for having data channels on by > default goes away. > > It's a little weird that the existence of data channels in SDP is > dependent on when you add media (before or after calling createOffer), > but it seems like a pretty good tradeoff to me. So I'm in favor of a > rule like "if you call createOffer with before you add tracks, a > transport for data channels gets negotiated in the SDP". What would be the downside with always offering a data channel m-line (by default)? Would a lot of legacy equipment choke? I assume that any endpoint that would support data would also support Bundle so the cost should be low. And (orthogonal): if the initial offer included a data channel m-line, but it was refused by the answerer, should this mean that any calls to createDataChannel should fail (it is unlikely that a renegotiation would render a different result)? Stefan
Received on Thursday, 30 April 2015 06:52:59 UTC