Re: PeerConnection Data Channel

On Fri, Sep 2, 2011 at 12:59 PM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote:

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


I'm far from sold on RTP for this, but since I think we need a sequence
number (for congestion control) and a stream id (for demux), it seems we're
already halfway there. Will look at the other methods - do you recall if
these were mentioned in a public draft or on the mailing list?

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