Subject: [clue] CLUE Data Channel: Identical stream ID values in both directions?

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Feb 2014 11:43:30 +0000

Hi,

Paul earlier suggested that we, for the SCTP streams that form the CLUE Data Channel, shall mandate the usage of identical stream ID values in each direction.

Perhaps I missed it, but what was the reason for that? To use the stream ID in order know on which stream CLUE messages are received?

I do agree that we need a way to know on which stream CLUE messages are received, and we can for sure recommend using the same values, but until we know what will be negotiated in SDP I'd like to keep the MUST as an open issue.

Also, the rtcweb data channel draft says:

"Note that there's no requirement for the SCTP streams used to create
                a bidirectional channel have the same number in each direction.  How
                stream values are selected is protocol and implementation dependent."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Feb 2014 09:12:41 -0500

On 2/4/14 6:43 AM, Christer Holmberg wrote:
> Hi,
>
> Paul earlier suggested that we, for the SCTP streams that form the CLUE
> Data Channel, shall mandate the usage of identical stream ID values in
> each direction.
>
> Perhaps I missed it, but what was the reason for that? To use the stream
> ID in order know on which stream CLUE messages are received?
>
> I do agree that we need a way to know on which stream CLUE messages are
> received, and we can for sure recommend using the same values, but until
> we know what will be negotiated in SDP I’d like to keep the MUST as an
> open issue.
>
> “Note that there's no requirement for the SCTP streams used to create
>
>                  stream values are selected is protocol and
> implementation dependent.”

I was thinking they had to match in rtcweb. If they *don't* have to 
match, then how are they correlated?

I just looked, and found the text you quote. I *guess* if the 
negotiation is done externally they can just wave their hands like this.
But for channels opened using the rtcweb data channel protocol I don't 
see how they can avoid specifying how the correlation is done. But I 
looked there too, and they don't seem to say. I think it is a hole in 
their spec.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Feb 2014 14:18:59 +0000

Hi,

>> Paul earlier suggested that we, for the SCTP streams that form the 
>> CLUE Data Channel, shall mandate the usage of identical stream ID 
>> values in each direction.
>>
>> Perhaps I missed it, but what was the reason for that? To use the 
>> stream ID in order know on which stream CLUE messages are received?
>>
>> I do agree that we need a way to know on which stream CLUE messages 
>> are received, and we can for sure recommend using the same values, but 
>> until we know what will be negotiated in SDP I'd like to keep the MUST 
>> as an open issue.
>>
>> implementation dependent."
>
> I was thinking they had to match in rtcweb. If they *don't* have to match, then how are they correlated?

As we discussed before, at the moment it seems like they assume a single usage per association.

...which is perhaps the only thing rtcweb requires, but the mechanism have to be general.

> I just looked, and found the text you quote. I *guess* if the negotiation is done externally they can just wave their hands like this.
> But for channels opened using the rtcweb data channel protocol I don't see how they can avoid specifying how the correlation is done. But I looked there too, and they don't seem to say. I think it is a hole in their spec.

Yes - among the others :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Feb 2014 11:17:54 -0500

> ...which is perhaps the only thing rtcweb requires, but the mechanism have to be general.

It depends on what you mean by "usage".

I agree that they are assuming that when an association is used by 
rtcweb, then the *entire* association is used by rtcweb.

But it is entirely clear to me that the intent is to support multiple 
channels. So there will be multiple SCTP streams in each direction. And 
then it becomes essential to correlate *which* incoming stream pairs 
with each outgoing stream.

> Yes - among the others :)

I just posted a question about this.
We will see what the answer is.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 05 Feb 2014 10:29:21 +1100

Hello,
> Yes - among the others :)
[CNG] I agree. I've been looking at this also in terms of gateway 
support for SCTP and CLUE, BFCP, T.38 etc. The differences between the 
SCTP SDP draft and RTCWEB transport ones and holes with regards to STCP 
channel -> protocol assignment makes it hard to specify any generic 
behaviour.

Regards, Christian

>
> Regards,
>
> Christer
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Wed, 12 Feb 2014 03:53:34 +0000

Hello Christian, Paul and Christer,

    Although, the rtcweb data channel draft does NOT say identical stream ID values in both directions.

    The rtcweb data protocol draft does says it as below:

           3.  Terminology

           This document uses the following terms:

           Association:  An SCTP association.

           Stream:  A unidirectional stream of an SCTP association.  It is
                   uniquely identified by an SCTP stream identifier (0-65534).  Note:
                   the SCTP stream identifier 65535 is reserved due to SCTP INIT and
                   INIT-ACK chunks only allowing a maximum of 65535 streams to be
                   negotiated (0-65534).

           Channel:  Two Streams with the same SCTP stream identifier, one in
                    each direction, which are managed together.

   In addition, I have a question to ask for you as below. 

Best Regards,
Scarlett

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: Wednesday, February 05, 2014 7:29 AM
To: [email-masked]
Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Hello,
On 5/02/2014 1:18 AM, Christer Holmberg wrote:
>>> are received, and we can for sure recommend using the same values, 
>>> but until we know what will be negotiated in SDP I'd like to keep 
>>> the MUST as an open issue.
>>>
[CNG] I agree. I've been looking at this also in terms of gateway support for SCTP and CLUE, BFCP, T.38 etc. The differences between the SCTP SDP draft and RTCWEB transport ones and holes with regards to STCP channel -> protocol assignment makes it hard to specify any generic behaviour.
[Scarlett] If there are more than one usage per association, the usages can be identified by different PPID. I am not sure about the discussion as above.
Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Feb 2014 16:29:20 -0500

Hi Scarlett,

(welcome back from your holiday)

>                      each direction, which are managed together.

Yes, we did find that the *protocol* document does specify this. (Also 
in section 6.)

But that is only when the data channel protocol is used - not when 
channels are used without the data channel protocol.

> [Scarlett] If there are more than one usage per association, the usages can be identified by different PPID. I am not sure about the discussion as above.

PPID is used for a different purpose. (It is used to distinguish OPEN 
and ACK messages from data messages, and to indicate the encoding of 
data messages.) And we need to follow rtcweb on that to maintain 
compatibility.

	Thanks,
	Paul

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 13 Feb 2014 03:49:40 +0000

Hello Paul,

    Thanks. :-)
    I have a different understanding about PPID, and please check my reply at the bottom of this e-mail.

Best Regards,
Scarlett

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, February 13, 2014 5:29 AM
To: [email-masked]
Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Hi Scarlett,

>                      each direction, which are managed together.

Yes, we did find that the *protocol* document does specify this. (Also in section 6.)

But that is only when the data channel protocol is used - not when channels are used without the data channel protocol.

PPID is used for a different purpose. (It is used to distinguish OPEN 
and ACK messages from data messages, and to indicate the encoding of 
data messages.) And we need to follow rtcweb on that to maintain 
compatibility.
[Scarlett] I see the PPID's usage in section 5 of draft data-channel as below:
              Each SCTP user message contains a so called Payload Protocol
              Identifier (PPID) that is passed to SCTP by its upper layer and sent
              to its peer.  This value can be used to multiplex multiple protocols
              over a single SCTP association.  The sender provides for each
              protocol a specific PPID and the receiver can demultiplex the
              messages based on the received PPID.  
    I think that the PPID of OPEN messages is the same as the PPID of ACK messages as described in data-protocol.
    This draft data-protocol says in section 8.1 as below:
                  | Value       | SCTP PPID | Reference |
                  +-------------+-----------+-----------+
                  | WebRTC DCEP | 50        | [RFCXXXX] |
                  +-------------+-----------+-----------+
    And it says in section 8.2 as below:
               +-------------------+-----------+-----------+
               | Name              | Type      | Reference |
               +-------------------+-----------+-----------+
               | Reserved          | 0x00      | [RFCXXXX] |
               | Reserved          | 0x01      | [RFCXXXX] |
               | DATA_CHANNEL_ACK  | 0x02      | [RFCXXXX] |
               | DATA_CHANNEL_OPEN | 0x03      | [RFCXXXX] |
               | Unassigned        | 0x04-0xfe |           |
               | Reserved          | 0xff      | [RFCXXXX] |
               +-------------------+-----------+-----------+
   So, if a data channel for CLUE and another data channel for WebRTC are simultaneously used per association, they PPIDs is different. 

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Feb 2014 08:13:27 +0000

Hi,

> But that is only when the data channel protocol is used - not when channels are used without the data channel protocol.

The definition of the data channel is in section 6.4 of draft-ietf-rtcweb-data-channel-07:

	"The realization of a bidirectional Data Channel is a pair of one
   	incoming stream and one outgoing SCTP stream having the same stream
   	SCTP identifier."

I.e. it is not dependent on whether you use DCP or not.

....

>> PPID is used for a different purpose. (It is used to distinguish OPEN and ACK messages from data messages, and to
>> indicate the encoding of data messages.) And we need to follow rtcweb on that to maintain compatibility.
>>

That is not true - at least not if we want to be compatible with the WebRTC data channel. In such case the PPIDs will be the same, and another mechanism (e.g. DCP or Richard's draft) is needed to indicate what application protocol (e.g. CLUE) the data channel is used for.

Regards,

Christer

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Thu, 13 Feb 2014 11:06:30 +0000

Hello Christer,

    I still have a question, and please see as below.
    Thanks.

Best Regards,
Scarlett 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 4:13 PM
To: Liuyan (Scarlett); Paul Kyzivat; [email-masked]
Cc: Lijing (Jessie)
Subject: RE: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Hi,

I.e. it is not dependent on whether you use DCP or not.
[Scarlett] Yes, I also find it in data-channel draft. :-)
....

>> and ACK messages from data messages, and to indicate the encoding of data messages.) And we need to follow rtcweb on that to maintain compatibility.
>>

That is not true - at least not if we want to be compatible with the WebRTC data channel. In such case the PPIDs will be the same, and another mechanism (e.g. DCP or Richard's draft) is needed to indicate what application protocol (e.g. CLUE) the data channel is used for.
[Scarlett] You said " In such case the PPIDs will be the same ". I am confused what cases you said.
If CLUE is compatible with the WebRTC data channel, WebRTC client using CLUE protocol uses the same data channel for WebRTC and CLUE ?? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Feb 2014 11:38:57 +0000

Hi Scarlett,

>> That is not true - at least not if we want to be compatible with the WebRTC data channel. In such case the PPIDs will be the 
>> same, and another mechanism (e.g. DCP or Richard's draft) is needed to indicate what application protocol (e.g. CLUE) the data channel is used for.

Yes. A browser only understands WebRTC data channels.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Feb 2014 13:15:13 -0500

Scarlett,

To elaborate on what Christer said:

WebRTC is defining a way for browsers to do real-time communication. It 
isn't an application, it is a platform for applications.

The key is that a this allows browser applications to do so without 
plugins like Flash.

We have a few possible situations for clue and data channels:

1) two native sip clue endpoints. They use the data channel, but no 
browser is involved.

2) one native sip clue endpoint talking to an a clue endpoint 
implemented in a browser using WebRTC. They have a data channel between 
them. For use by the browser it must meet all the requirements of a 
WebRTC Data Channel. And it also must meet all the requirements of a 
CLUE channel.

3) two browsers talking to each other using CLUE over WebRTC.

With WebRTC, there are only a few PPIDs that can be used. They are being 
used to distinguish DCP messages from user messages, and to distinguish 
the encoding of data messages as strings or binary. If we were to use a 
different PPID for CLUE then a browser app wouldn't be able to deal with it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Feb 2014 19:17:43 +0000

Paul just said what I meant :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Paul Kyzivat [mailto:[email-masked]] 
Lähetetty: 13. helmikuuta 2014 20:15
Vastaanottaja: Christer Holmberg; Liuyan (Scarlett); [email-masked]
Kopio: Lijing (Jessie)
Aihe: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Scarlett,

WebRTC is defining a way for browsers to do real-time communication. It isn't an application, it is a platform for applications.

The key is that a this allows browser applications to do so without plugins like Flash.

1) two native sip clue endpoints. They use the data channel, but no browser is involved.

2) one native sip clue endpoint talking to an a clue endpoint implemented in a browser using WebRTC. They have a data channel between them. For use by the browser it must meet all the requirements of a WebRTC Data Channel. And it also must meet all the requirements of a CLUE channel.

With WebRTC, there are only a few PPIDs that can be used. They are being used to distinguish DCP messages from user messages, and to distinguish the encoding of data messages as strings or binary. If we were to use a different PPID for CLUE then a browser app wouldn't be able to deal with it.

	Thanks,
	Paul

On 2/13/14 6:38 AM, Christer Holmberg wrote:
> Hi Scarlett,
>
>>>>> PPID is used for a different purpose. (It is used to distinguish 
>>>>> OPEN and ACK messages from data messages, and to indicate the encoding of data messages.) And we need to follow rtcweb on that to maintain compatibility.
>>>>>
>>> That is not true - at least not if we want to be compatible with the 
>>> WebRTC data channel. In such case the PPIDs will be the same, and another mechanism (e.g. DCP or Richard's draft) is needed to indicate what application protocol (e.g. CLUE) the data channel is used for.

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Sat, 15 Feb 2014 09:44:58 +0000

Hello Paul and Christer,

    Thanks your patiently reply.

    I seem to understand the possible situations you mentioned. There is indeed a hole in some drafts.
    Maybe I need to fill some knowledge about RTCWEB.:-)
    
Best Regards,
Scarlett

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 2:15 AM
To: Christer Holmberg; Liuyan (Scarlett); [email-masked]
Cc: Lijing (Jessie)
Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Scarlett,

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Feb 2014 09:55:58 +0000

Hi Scarlett,

If you are interested in the CLUE Data Channel, you should definately take a look at the RTCWEB drafts and discussions :)

Regards,

Christer

________________________________________
From: Liuyan (Scarlett) [[email-masked]]
Sent: Saturday, 15 February 2014 11:44 AM
To: Paul Kyzivat; Christer Holmberg; [email-masked]
Cc: Lijing (Jessie)
Subject: RE: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Hello Paul and Christer,

Best Regards,
Scarlett

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, February 14, 2014 2:15 AM
To: Christer Holmberg; Liuyan (Scarlett); [email-masked]
Cc: Lijing (Jessie)
Subject: Re: [clue] CLUE Data Channel: Identical stream ID values in both directions?

Scarlett,

        Thanks,
        Paul