- From: Cullen Jennings <fluffy@cisco.com>
- Date: Sun, 17 May 2015 14:40:09 -0700
- To: Harald Tveit Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
I think it is better to let the JS control what happens instead of magically doing something different than what the JS requested. If the app is one where there can be no a/v in offer, that app can easily add a data channel if that helps.
I agree it is odd, but I it is an odd app that does this. I can't think of any use case that would need this.
> On 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.
>>
>
>
Received on Sunday, 17 May 2015 21:40:38 UTC