W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

Re: PeerConnection Data Channel

From: Justin Uberti <juberti@google.com>
Date: Wed, 7 Sep 2011 23:31:16 -0400
Message-ID: <CAOJ7v-2+k9SJsWJ65bjU9qtLVM6Q_=oDsdDbBN166qMqYrgxpg@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Sep 7, 2011 at 8:20 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> Hi Justin,
>
> thanks for a quick response.
>
> I think our different views somewhat comes from that I tend to view the
> data channel as "a peer-to-peer" version of WebSocket, while (I think) you
> view it more as another stream, this one just has no audio or video.


> So from my view it would be more natural to keep it more as it is in the
> current spec (possibly adding an 'bufferedAmount' attribute and later a
> reliable mode).
>

I understand your viewpoint as well, but I feel like PeerConnection is
already quite a different animal than WebSockets; it provides multi-stream,
congestion-controlled, synchronized audio and video, far more than a simple
pipe. I certainly think PeerConnection should also support application data
transfer, but I prefer it be on a sub-api, like what I propose with
DataStream, which I feel provides more flexibility.

>
> I have some short responses/comments inline below. Two questions for my
> understanding first though:
>
> - According to the current spec, the PeerConnection tries to establish a
> connection when it is created (given of course that you pass the signaling
> messages between the peers). Would you see this behavior change with you
> proposal (i.e. that a connection attempt would only be done when the
> application does createDataStream or addStream)?
>

I think the PeerConnection would still establish even with no streams added.
It just would have a mostly empty SDP, and empty local/remoteStreams.

>
> - You mention QoS a bit. Could you elaborate a bit on how you see this
> work?
>

PeerConnection will have to perform bandwidth estimation and congestion
control. When bandwidth is limited, this means it may have to drop
application data packets. Having a QoS API would let the congestion
management code take the app's QoS settings into account when deciding which
packets to drop. This code could also apply DSCP markings on a per-packet
basis, again based on these application-supplied QoS settings.

>
> Cheers,
> Stefan
>
>
> On 2011-09-06 04:43, Justin Uberti wrote:
>
>> 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 <stefan.lk.hakansson@ericsson.com>
>> <mailto:stefan.lk.hakansson@**ericsson.com<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>
>>    <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.
>>
>
> I think the app would anyway have to know that it is interoping with
> legacy, and that therefore no data channel is available.
>
> It is sort of analogous to if an API method for sending, but not for
> receiving, DTMF is added. In a browser to browser case the app would have to
> know that there is no point in sending DTMF 'cause noone can receive it.
>
>
>
>> 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.
>>
>
> As the data streams can easily be handled in the application there is no
> need IMHO. The same is not true for MediaStreams.
>
>
>
>>
>>
>>     > - 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.
>>
>
> Again, I think this is because we have different starting points. I also
> think that handling multiplexing is simple.
>
>
>
>>    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.
>>
>
> That may well be true.
>
>
>
>>
>>
>>     >
>>     > 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.
>>
>
> Agree. The natural thing would be to multiplex in the application if you
> have several streams.
>
>
>
>>
>>
>>     > - 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.
>>
>
> The reliable option (if/when introduced) in the send method would have to
> be complemented by some identifier when receiving so the application knows
> if the data has traveled on the unreliable or reliable path.
>
>
>
>> 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.
>>
>>
>>
>
Received on Thursday, 8 September 2011 03:32:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC