- From: Michael Tuexen <tuexen@fh-muenster.de>
- Date: Thu, 23 Feb 2012 21:35:29 +0100
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc@w3.org, Randall Stewart <rrs@lakerest.net>, Salvatore Loreto <salvatore.loreto@ericsson.com>
On Feb 23, 2012, at 3:44 PM, Randell Jesup wrote: > On 2/23/2012 8:27 AM, Adam Bergkvist wrote: >> On 02/23/2012 02:08 PM, Michael Tuexen wrote: >>> >>> On Feb 23, 2012, at 1:39 PM, Adam Bergkvist wrote: >>>> You're right that it's not used in either of the examples given here. >>>> It's a pure API-related property to help the developer identify a >>>> particular DataChannel object if several objects (with the same >>>> transport porperties) are used. E.g. you might have a DataChannel >>>> object with label "chat" and another with the label "game-data" for >>>> different purposes. >>> OK. So if I understand this correctly, it is just a local thing and it >>> is not expected to be on the wire, right? >> >> Yes, it's not intended to be some "channel id" on the wire, but >> it would have to be transported to the other end so that the >> corresponding DataChannel object on the B-side can be initialized with >> the same label. > > Correct; the idea discussed (at the Interim, and with Randall) was to either use stream 0 as a control channel, or to use PPID values to flag a message on a stream containing metadata such as an "open dataChannel" message, which would include information needed to open the reverse stream (and avoid 'glare' when both sides are opening streams at the same time), the label, and the channel options (so it has the same attributes in both directions). I almost always agree with Randy, but we have a different perspective when it comes the the PPID. Currently upper layers of SCTP register some values at IANA and this value is used, for example, by protocol analyzers like Wireshark to determine the upper layer protocol. If possible, I would like to keep it that way. So you want that one side creates a channel with an identifier which is a string. This is transported to the other side. Right? What should happen if both sides try to open a channel with the same identifier? Should this result in one channel? It seems that we need to messages which are exchanged... I also assume that you want to map channels to streams, but you can map multiple channels to one stream, right? It looks like we need some rtcweb control message for opening and closing a channel. These would transfer the channel identifier. One would use a separate PPID for * the control messages * user messages containing a DOMString * user messages containing an ArrayBuffer * user messages containing an Blob We need to make sure that messages sent on a channel don't arrive earlier than the open message... and that the close messages are the last one... > >> >>>>> What about unordered? When do you expect a message to be abondoned >>>>> when treated unreliable? >>>> >>>> I don't really have an opinion on when to abandon messages in >>>> unreliable mode. >>> OK. But it needs to be specified. > > Right. I was trying to indicate in my response that streams would (at open time) have attributes that specify reliable, unreliable, in/out of order, and for non-reliable a value to control retry/abandonment (exact semantics TBD but should map simply to the SCTP options). I mistakenly added them to the wrong dictionary. I could imagine that for some applications want to limit the number of retransmissions (most likely to 0) or want to limit the lifetime of the message. Both it supported by our userland stack. Best regards Michael > > -- > Randell Jesup > randell-ietf@jesup.org >
Received on Friday, 24 February 2012 13:31:00 UTC