Re: PeerConnection Data Channel

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

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

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

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 Wednesday, 7 September 2011 12:20:49 UTC