W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: No-channel vs some-channel initial offers (Re: Proposal: offerDataChannel in RTCOfferOptions)

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1F7EE9@ESESSMB209.ericsson.se>
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)?

Received on Thursday, 30 April 2015 06:52:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC