Re: PeerConnection Data Channel

On 9/2/11 5:52 PM, 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.

Agree.
> - It defines its own encryption mechanism, whereas audio/video will 
> use SDES-SRTP, or DTLS-SRTP

Agree.

> - Only one data stream exists, whereas audio/video can have many streams

Agree.

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

Great idea.

>
> Some specifics:
> - This stream will show up in SDP

I don't like SDP, but if we do SDP, that's where it'd need to be.

> , and it can be its own RTP session,

Disagree. RTP semantics are inappropriate for sending data. The data 
should be sent using one of the two methods for muxing data that were 
proposed (one by me, one by cbran).

There should be a way to demux multiple streams of data using an 
additional sub-header.
> 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.

Agree.

> - For encryption, it simply uses the underlying encryption of the 
> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.

Absolutely correct. Possibly needs masking for the "none" case 
however... need to discuss.

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

Agree. Prioritization makes sense here, especially if/when we get 
congestion control.
> - 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.

Also a good idea.

Matthew Kaufman

Received on Friday, 2 September 2011 17:00:02 UTC