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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 29 Apr 2015 10:00:22 +0200
Message-ID: <55408F96.7010101@alvestrand.no>
To: public-webrtc@w3.org
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 Wednesday, 29 April 2015 08:00:53 UTC

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