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