Re: Proposal: offerDataChannel in RTCOfferOptions

On Tue, Apr 28, 2015 at 5:03 PM, Justin Uberti <juberti@google.com> wrote:

>
>
> On Tue, Apr 28, 2015 at 9:35 AM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> On Tue, Apr 28, 2015 at 9:18 AM, Martin Thomson <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.​