Subject: Re: [rtcweb] RTCWEB data channel protocol: Do both endpoints need to send DATA_CHANNEL_OPEN?

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 11:58:20 +0000

>>>> Q1: Assuming that both endpoints want to use the data channel, do both
>endpoints need to send DATA_CHANNEL_OPEN
>>>> (on separate SCTP streams)? Or, can one of the endpoints, if it has received
>DCO, start using the data channel (using a SCTP stream of its choice)?

[Raju] As explained by others already, DC is bidirectional, however both directions have to use the same SCTP stream that was assigned for the data channel (which is done as part of DC OPEN an DC ACK). In fact the PeerConnection send() API does not allow stream # to be specified by the app, stream # is internally tied to DC.

-Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 12:03:25 +0000

Hi,

> [Raju] As explained by others already, DC is bidirectional, however both directions have to use the same SCTP stream that was assigned for the data channel (which is done as part of DC OPEN an DC ACK).

When I send DC OPEN, do I know on which stream the DC ACK will arrive? If not, if there are DC OPEN/ACKs for multiple data channels, how is a DC ACK mapped to the associated DC OPEN? There is no "transaction id", or similar, in the messages.

> In fact the PeerConnection send() API does not allow stream # to be specified by the app, stream # is internally tied to DC.

My understanding is that it is possible to "manually" assign a stream id when creating the data channel. But, I may be wrong.

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 12:29:28 +0000

> > [Raju] As explained by others already, DC is bidirectional, however both
> directions have to use the same SCTP stream that was assigned for the data
> channel (which is done as part of DC OPEN an DC ACK).
> 
> When I send DC OPEN, do I know on which stream the DC ACK will arrive? If
> not, if there are DC OPEN/ACKs for multiple data channels, how is a DC ACK
> mapped to the associated DC OPEN? There is no "transaction id", or similar,
> in the messages.

[Raju] 
http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#section-6 says stream id in ACK is same as the one in DC OPEN:
   If a DATA_CHANNEL_OPEN message is received on an unused stream, the
   stream identifier corresponds to the role of the peer and all
   parameters in the DATA_CHANNEL_OPEN message are valid, then a
   corresponding DATA_CHANNEL_ACK message is sent on the stream with the
   same stream identifier as the one the DATA_CHANNEL_OPEN message was
   received on.

> > In fact the PeerConnection send() API does not allow stream # to be
> specified by the app, stream # is internally tied to DC.
> 
> My understanding is that it is possible to "manually" assign a stream id
> when creating the data channel. But, I may be wrong.
[Raju] Yes, it is possible.
For createDataChannel() API (http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-createdatachannel) set 'negotiated' to 'true' and 'id' to the stread id you want. Then it is the responsibility of the application to convey this info to the other end and the internal DC protcol (DC OPEN/ACK etc.) won't be used to manage the data channel/streams.
However, I am not sure if "negotiated=false" and specifying "id" is a valid combination. For id the above spec says the following, so may be it is allowed, but then user have to manage stream ids to avoid collisions:
	id of type unsigned short
		Overrides the default selection of id for this channel.

It is also interesting to note that the spec allows within the same SCTP link, some DCs can be negotiated using inband internal protocol while other DCs can be negotiated using external out-of-band protocol! However, I think applications should try to avoid mixing these methods to avoid conflicts in using stream ids.

-Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 12:39:09 +0000

Hi,

>>> [Raju] As explained by others already, DC is bidirectional, however 
>>> both directions have to use the same SCTP stream that was assigned for the 
>>> data channel (which is done as part of DC OPEN an DC ACK).
>>> 
>> When I send DC OPEN, do I know on which stream the DC ACK will arrive? 
>> If not, if there are DC OPEN/ACKs for multiple data channels, how is a 
>> DC ACK mapped to the associated DC OPEN? There is no "transaction id", 
>> or similar, in the messages.
>
> [Raju]

And if the stream id is already used? 

The "core" data channel draft does not mandate the usage of the same stream id values in both directions. 

Are you saying that, when using the DCP, one must use the same stream id value in both directions?

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 12:52:11 +0000

> > [Raju]
> > http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#section-6
> says stream id in ACK is same as the one in DC OPEN:
[Raju] DC protocol says:

   If a DATA_CHANNEL_OPEN message is received on an already used SCTP
   stream or there are any problems with parameters within the
   DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is
   not well-formed, the receiver MUST reset the corresponding outgoing
   SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK
   message in response to the received message.

> value in both directions?

[Raju] Correct.
When external DC negotiation is used, I expect most implementations to use same stream ids, but not a MUST, in both directions. This not only simplifies the procedures but also aligns with internal DCP allocation of streams.

-Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 12:57:27 +0000

Hi,

>>> [Raju]
>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-01#sectio
>>> n-6 says stream id in ACK is same as the one in DC OPEN:

Is there a reason why we couldn't mandate usage of the same id in the core spec? Then the correlation would not be dependent on the negotiation mechanism(s).

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 6 Feb 2014 20:00:21 +0000

> Is there a reason why we couldn't mandate usage of the same id in the core
> spec? Then the correlation would not be dependent on the negotiation
> mechanism(s).

[Raju] WebRTC does not provide any rules for external negotiation of data channels, so it should leave all the procedures, including stream id management, outside the scope. Having "symmetric stream id" restriction puts unnecessary hurdle on external negotiation procedures, which adds no value overall. Like an example app may not care which data channel/stream-id is used for send or receive, it just wants to know data is received and sent (the data itself may have some identification info).
 
Btw, the SDP based external negotiation draft http://tools.ietf.org/id/draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt is already proposing to use symmetric stream ids. Other external negotiation protocols may put such restriction as they fit.

-Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 20:26:26 +0000

Hi,

> [Raju] WebRTC does not provide any rules for external negotiation of data channels, so it should leave all the procedures, including stream id 
> management, outside the scope. Having "symmetric stream id" restriction puts unnecessary hurdle on external negotiation procedures, which 
> adds no value overall. Like an example app may not care which data channel/stream-id is used for send or receive, it just wants to know data 
> is received and sent (the data itself may have some identification info).
>

So, as far as the data channel mechanism itself is concerned, we do define that it consists of two uni-directional SCTP streams, but we don't define how those streams are associated with the data channel. For that some external mechanism is needed.

Regards,

Christer