Re: PeerConnection Data Channel

Stefan, thanks for your comments. Responses inline:

On Mon, Sep 5, 2011 at 9:09 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> Justin,
>
> some feedback in-line below!
>
> Stefan (in role of contributor)
>
>
> On 2011-09-02 18:52, Justin Uberti wrote:
> > Section 5 in the WEBRTC spec
> > (http://dev.w3.org/2011/**webrtc/editor/webrtc.html<http://dev.w3.org/2011/webrtc/editor/webrtc.html>)
> discusses at length a
> > mechanism for transmitting and securing datagrams over the
> > PeerConnection transport. At both an API and a wire level, this
> > mechanism is quite different from the existing mechanisms that are used
> > for transmission of audio and video data:
> > - The availability of the data stream is not easily known, whereas
> > audio/video can be negotiated and stream existence learned from the
> > *Stream methods/callbacks.
>
> I think the availability is quite clear: once the PeerConnection enters
> state 'ACTIVE' (and fires event 'open') it is available.


But that's clearly not true; in a legacy interop situation, the PC will be
ACTIVE, yet the data channel will be unavailable.

We will be providing rich information about the available media streams via
the pc.remoteStreams property; I don't see why we wouldn't want to do the
same for data streams.


>
> > - It defines its own encryption mechanism, whereas audio/video will use
> > SDES-SRTP, or DTLS-SRTP
> > - Only one data stream exists, whereas audio/video can have many streams
>
> This is true, however, is there a real need for this? Different data
> 'streams' can be created/handled in the application.


This forces the app developer to invent their own multiplexing and QoS
mechanism. Given that we are going to be multiplexing pretty much everything
else possible within PeerConnection, it's hard for me to understand why we
would choose not to do the same for data.


> One thing I like with the current approach is the (in this respect)
> similarity with WebSocket. Once it is "open" you can "send", no need for the
> web app developer to learn a new model.


 Each DataStream will get "open" notifications, and then you can "send". I
don't think the actual API usage changes that much with my proposal.


>
> >
> > I would like to propose an approach where we remove the send() method,
> > and add a createDataStream() method to PeerConnection. This method
> > creates a DataStream object, a descendant of MediaStream. This object
> > can then be added/removed from PeerConnection via the existing
> > add/removeStream APIs, and it will show up in localStreams/remoteStreams
> > like any other MediaStream. It will also fire events indicating the
> > stream status.
> >
> > Some specifics:
> > - This stream will show up in SDP, and it can be its own RTP session, or
> > muxed with other RTP sessions, just like any other audio/video stream.
> > If the remote side doesn't support/want the data stream, it can signal
> > this via its answer SDP.
> > - For encryption, it simply uses the underlying encryption of the
> > session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.
> > - Multiple DataStreams can be created, just like MediaStreams. This may
> > be of value to certain applications, who want to have multiple flows,
> > perhaps with their own QoS.
>
> True, but this can be done by the application (as outlined above), or the
> application could create several PeerConnection objects (again being similar
> to WebSocket).


I don't think we want applications to have to create multiple PCs to the
same destination. This causes additional NAT bindings, extra ICE setup, etc.
- in some ways defeating what we are trying to achieve with our various
multiplexing efforts.

>
>
> > - We can (perhaps later) add different kinds of DataStreams, i.e.
> > datagram and reliable. When creating a DataStream, you can specify what
> > kind of stream you want.
>
> This could just be a second optional argument to the 'send' method:
>
> void send(in DOMString text, in optional boolean reliable);
>
> It would not have to be in the initial version of PeerConnection, but could
> be introduced later (without breaking apps).


Having a channel that can have reliable and unreliable traffic on it seems
like asking for trouble, e.g. you have some reliable messages arriving in
order, and suddenly an unreliable message shows up in the middle.

I think everything will be cleaner if we allow multiple streams that can
each be reliable/unreliable, and have their own QoS setting.


>
>
> >
> > Example JS usage:
> >
> >
> > // standard setup from existing example
> > var local = new PeerConnection('TURNSexample.**net <http://example.net>',
> sendSignalingChannel);
>
> > local.signalingChannel(...); // if we have a message from the other side,
> pass it along here
> >
> > // (aLocalStream is some LocalMediaStream object)
> >
> > var aDataStream = local.createDataStream(**DATAGRAM);
> >
> > local.addStream(aDataStream);
> >
> > // outgoing SDP is dispatched, including a media block like:
> >
> > m=application 49200 <TBD> 127
> >
> >
> >     a=rtpmap:127 application/html-peer-**connection-data
> >
> >
> > function sendSignalingChannel(message) {
> >    ... // send message to the other side via the signaling channel
> > }
> >
> >
> > // incoming SDP is recieved, signaling completes
> > function receiveSignalingChannel (message) {
> >    // call this whenever we get a message on the signaling channel
> >    local.signalingChannel(**message);
> > }
> >
> >
> > // we start sending data on the data stream
> >
> > aDataStream.send("foo");
> >
> >
> >
> > Thoughts? If this feels like an interesting direction, I can write text
> > for inclusion in the spec.
>
>