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

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

I think the only person who will still be sad is the developer who adds
media, calls createOffer, etc, and then later calls createDataChannel and
needs renegotiation.  But they are just as sad with the status quo, so this
proposal of yours does them no harm.

On Wed, Apr 29, 2015 at 1:00 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> One tangential point (which is why I changed the subject here) is what
> we want to have happen when there's no audio, no video and no data channel.
>
> At the moment, this results in no m-lines, no candidates and no
> connection setup. Which means that in this unique situation, we don't
> know if communication will work until we renegotiate - the ICE state
> will not move to "connected".
>
> This seems very odd.
>
> What would be less harmful to the overall experience - adding a data
> channel request to an otherwise-empty offer, or letting the
> inconsistency in ICE behavior after negotiation remain as-is?
>
>
> Den 29. april 2015 06:50, skrev Peter Thatcher:
> >
> >
> > On Tue, Apr 28, 2015 at 5:03 PM, Justin Uberti <juberti@google.com
> > <mailto:juberti@google.com>> wrote:
> >
> >
> >
> >     On Tue, Apr 28, 2015 at 9:35 AM, Peter Thatcher
> >     <pthatcher@google.com <mailto:pthatcher@google.com>> wrote:
> >
> >         On Tue, Apr 28, 2015 at 9:18 AM, Martin Thomson
> >         <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com
> >>wrote:
> >
> >             What is the material difference between:
> >
> >             var pc = new RTCPeerConnection({yesIWantADataChannel: true});
> >             negotiate(pc).then(_ => {
> >                var dc = pc.createDataChannel();
> >                useDataChannel(dc);
> >             });
> >
> >             ...and:
> >
> >             var pc = new RTCPeerConnection();
> >             var dc = pc.createDataChannel();
> >             negotiate(pc).then(_ => {
> >                useDataChannel(dc);
> >             });
> >
> >             Both require that you do something before negotiating.
> >
> >
> >         ​The second leads to more confusion, and least judging by how
> >         many people come to be me confused.
> >
> >
> >
> >             If the suggestion were to have a data channel created by
> >             default, with
> >             an option instead to suppress that behaviour; *that( I might
> >             be able
> >             to understand.
> >
> >
> >         ​I'd be even more happy if "offerDataChannel" were true by
> >         default, just like "offerToReceiveAudio" is. ​
> >
> >
> >     This is a bit too far. Since the default bundle policy is balanced,
> >     having this be true by default will have additional transport costs
> >     to existing applications.
> >
> >
> > That's a fair point about default balanced BundlePolicy.  On the other
> > hand, if either the remote side responds with BUNDLE or without any data
> > transport (which is almost all the time, I would guess, since almost all
> > endpoints that can do data channels can also do BUNDLE), the additional
> > transport costs are small and temporary.
> >
> > Actually, this almost makes me wish max-bundle were the default.  But
> > that's probably a bit farther than a bit too far :).
> > ​  ​
> >
> >
> >     FWIW, offerToReceiveAudio is 0 by default, unless you have attached
> >     an audio track.
> >
> >
> > ​Yeah, as pointed out earlier, I was mis-remembering the previous state
> > of affairs around offerToReceiveAudio.​
> >
>
>
>