Re: Proposal: offerDataChannel in RTCOfferOptions

On Tue, Apr 28, 2015 at 12:18 PM, 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 proposed constraint was for RTCOfferOptions, not RTCConfiguration, but
leaving that aside, here's the comparison I'm thinking of:

var pc = new RTCPeerConnection({yesIWantADataChannel: true});
negotiate(pc).then(_ => {
  setConnectionReady(true);
});

// In this app, datachannels are only created in response to certain user
actions.
this.onsomeuseraction = _ => {
  var dc = pc.createDataChannel(getLabel());
  useDataChannel(dc);
};

pc.ondatachannel = this.gotChannel;

vs.

var pc = new RTCPeerConnection();
// The initial channel is not associated with a user action, so it's just a
dummy
// to get the right m-lines in the offer.
var dc = pc.createDataChannel('dummyLabel');
negotiate(pc).then(_ => {
  setConnectionReady(true);
});

this.onsomeuseraction = _ => {
  // The labels of useful channels must be limited so that they can be
  // distinguished from the dummy channel.
  var dc =
pc.createDataChannel(getLabelThatDoesntCollideWithTheDummyChannel());
  useDataChannel(dc);
};

pc.ondatachannel = (e) => {
  // The incoming label must be checked (at least on the answering side), so
  // that the dummy channel can be ignored.
  if (e.channel.label === 'dummyLabel') {
    return;
  }
  this.gotChannel(e);
};

More broadly, I think createDataChannel should be for creating data
channels ... not for some weird side effect that allows you to avoid
renegotiation.  I think we should try to avoid creating situations where
you are supposed to call createDataChannel, even though you don't actually
want to create a data channel right now.


> 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.
>
> On 28 April 2015 at 08:53, Peter Thatcher <pthatcher@google.com> wrote:
> > I like this idea because I've had many bugs/questions from people new to
> the
> > API where somewhere says something like "I call createOffer, and there's
> > nothing in there for data channels".  And saying "you have to call
> > createDataChannel before calling createOffer" can be awkward and
> confusing
> > because tthe natural mental model of people new to PeerConnection for the
> > purpose of using data channels seems to be:
> >
> > 1.  Setup a PeerConnection (with createOffer, createAnswer,
> > setLocalDescription, setRemoteDescription)
> > 2.  Create a data channel (with createDataChannel)
> > 3.  Send data on the data channel
> >
> > But then I have to explain that the "right" way to do things is:
> >
> > 1. Create a useless data channel
> > 2. Setup a PeerConnection
> > 3. Send data on the previously useless data channel, or create a new one.
> >
> > So, the "right" way is non-intuitive and awkward, and the natural thing
> to
> > do is wrong.  A "use data channels" flag such as "offerDataChannel"
> would be
> > more clear.
> >
> >
> >
> > On the other hand, it does add a tiny bit of API surface for which we'll
> > have to answer questions like "what if the offerDataChannel is set to
> false
> > after data channels are up and running?".  So it seems like a small gain
> for
> > a small cost.  On balance, I'm in favor of it since we pay the small cost
> > and the developers get the small gain.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Apr 27, 2015 at 3:01 PM, Benjamin Schwartz <bemasc@google.com>
> > wrote:
> >>
> >> Currently, RTCPeerConnection has "offerToReceiveVideo" in the
> >> RTCOfferOptions, which is a convenience to allow creating an offer with
> a
> >> m-line for video without first having to attach a video
> MediaStreamTrack.
> >> This is useful; without it, pages would have to attach a track and then
> >> renegotiate, even if they only want to receive video.
> >>
> >> However, with data channels, we don't have this convenience.  The
> offerer
> >> must call createDataChannel before createOffer, or suffer a
> renegotiation,
> >> even if they have no immediate need for a data channel.
> >>
> >> So what do you think of adding a boolean "offerDataChannel" attribute to
> >> RTCOfferOptions, parallel to "offerToReceive*"?  I think that would be
> >> easier to use.
> >>
> >> --Ben
> >
> >
>