Re: PeerConnection Data Channel

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) 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.

 > - 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.

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.

 >
 > 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).

 > - 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).


 >
 > 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.

Received on Monday, 5 September 2011 13:09:39 UTC