Subject: [clue] Draft initial submission: draft-holmberg-clue-datachannel-00

From: Christer Holmberg <[email-masked]>
Date: Sat, 1 Feb 2014 17:36:04 +0000

Hi,

I put together an initial draft for describing the CLUE data channel.

I realize that text is still needed, but now it will be easier to document whatever we agree to, identity open issues etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Feb 2014 15:44:42 -0500

Christer,

Thanks for getting this started, even though there is still much to decide.

It is pretty early to do much reviewing of this, but here are a few 
things that I noted while reading it:

Abstract/Introduction:

    This document specifies how the usage of the Stream Control
    Transmission Protocol (SCTP) on top of the Datagram Transport Layer
    Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol
    messages between CLUE entities.

The above is an incomplete sentence. (... specified how the ... 
(what?)). One possible rewording:

    This document specifies how to use the Stream Control
    Transmission Protocol (SCTP) on top of the Datagram Transport Layer
    Security (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol
    messages between CLUE entities.

Section 2:

    CLUE data channel refers to the SCTPoDTLS connection that is
    established between two CLUE entities in order to transport CLUE
    messages.

IMO this isn't quite correct.

- for one thing, for whatever reason, a single instantiation of SCTP
   is called an "association" rather than "connection".

- CLUE doesn't use an entire SCTP association. It only uses one
   (ore maybe two) webrtc data channels.

Also, in principle, there could be more than one SCTP association in the 
session. If so, for CLUE there will be a particular one of those 
associations that hosts the clue channel(s).

I'm inclined to think, for purposes of terminology, that:

- A "CLUE data channel" is a specific usage of a webrtc data channel
   (or whatever name that eventually gets - hopefully one without
   "webrtc" in it). Or, if we are trying to refer to webrtc stuff,
   that it corresponds to a matched pair of streams (one in each
   direction).

- We may also want a term for the SCTP association hosting the clue
   data channel. E.g., "CLUE SCTPoDTLS association".

- If we decide we want to use two channels, then we will probably
   want to agree that they are both on the same association.

Section 3.2.1:

    CLUE entities MUST establish two uni-directional STCP streams between
    themselves, one for CLUE messages sent in each direction.

This seems incomplete. How about:

    CLUE entities MUST establish a pair of uni-directional STCP streams,
    one in each direction, having identical stream IDs, between
    themselves. These are then used to send CLUE messages in both
    directions.

	Thanks,
	Paul

On 2/1/14 12:36 PM, Christer Holmberg wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Feb 2014 07:52:24 +0000

Hi Paul,

Thanks for your comments! See inline.

>    messages between CLUE entities.

Correct.

>   is called an "association" rather than "connection".

Correct.

>   (ore maybe two) webrtc data channels.

That is actually an issue which I have raised on the MMUSIC list. Currently the sctp-sdp draft only seems to allow negotiation of one usage per association.

> Also, in principle, there could be more than one SCTP association in the session. If so, for CLUE there will be a particular one of those associations that hosts the clue channel(s).

Correct. There can be multiple SCTP associations on top of the same DTLS association.

>   that it corresponds to a matched pair of streams (one in each

I tried to avoid "webrtc" on purpose, and the only reference is for the PPID values.

However, I think it will be good to have some text about webrtc interoperability somewhere, in order to justify some of the technical choices.

>   data channel. E.g., "CLUE SCTPoDTLS association".

Well, in my opinion that is the definition of the CLUE data channel :)

>   want to agree that they are both on the same association.

Yes.

>    themselves. These are then used to send CLUE messages in both

Yes.

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Feb 2014 10:05:28 -0500

Inline

> That is actually an issue which I have raised on the MMUSIC list. Currently the sctp-sdp draft only seems to allow negotiation of one usage per association.

I agree this is unclear.

What I have inferred is that what the sctpmap line is negotiating is a 
usage for the collection of all the sctp streams within the association.

But the text is certainly confusing about that. Calling this a 
"media-subtype suggests some relationship with mime types. But that 
doesn't fit well. In the absence of an SDP mechanism for negotiating 
individual streams or channels, I think this would probably name a 
documented mechanism for assigning those, such as the rtcweb data 
channel protocol.

> I tried to avoid "webrtc" on purpose, and the only reference is for the PPID values.

My preferred way of avoiding the use of webrtc here is for them to 
change their terminology to simply call it a data channel. :-)

> Well, in my opinion that is the definition of the CLUE data channel :)

You think the "CLUE data channel" is defined as an entire SCTP 
association???

IIUC we have been talking about an *abstraction* called a "CLUE Channel" 
(rather than "CLUE Data Channel"). And we are trying to map it onto 
specific technology. We have decided to map it onto a particular 
instance of (webrtc) Data Channel. And each webrtc data channel exists 
within a particular SCTPoDTLS association.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Feb 2014 16:23:23 +0000

Hi,

> usage for the collection of all the sctp streams within the association.

There are two things that I think need to be possible:

1) Indicate the SCTP associations on top of the DTLS connection
2) For each SCTP association, indicate the usages

At the moment the draft does seem to allow 1), but for each SCTP association it only allows one usage.

> documented mechanism for assigning those, such as the rtcweb data

Even with that, it is unclear what the type value (e.g. webrtc-datachannel) in the sctpmap attribute really is, how such values are supposed to be registered, etc.

But, let's have THAT discussion on the MMUSIC list :)

> change their terminology to simply call it a data channel. :-)

We can suggest that :)

However, I have been working on some text for the next version of the CLUE draft, which talks about the SCTP considerations being selected in order to be compatible with the rtcweb data channel.

> You think the "CLUE data channel" is defined as an entire SCTP

No. So, the text probably needs to be modified that we are talking about the SCTP association used to transport the CLUE protocol, but clarify that the association may also have other usages.

That also means that we need to be careful about how/if the SCTP associaton affects the CLUE session. Because, even if a CLUE session is terminated, there may be other reasons to keep the SCTP assiciation alive, etc.

Regards,

Christer

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Feb 2014 12:42:11 -0500

> At the moment the draft does seem to allow 1), but for each SCTP association it only allows one usage.

And that is what the Ejzak draft addresses.

Yes.

>> change their terminology to simply call it a data channel. :-)

This is confusing because of the overlap with the Ejzak draft. I have 
asked him to make the change, and he said he would (months ago). But I 
guess that doesn't get the change in other drafts that talk about it.

Yes.

If we have trouble with the clue channel, we may want to specify a 
"reset". But in general the reset should not involve resetting the 
association, because that would impact other channel usage. So we might 
just say that a reset means to close the channel and renegotiate a new 
clue channel over the same association. But if the association is broken 
to the extent that new channels can't be negotiated, then it makes sense 
to reset the association.

(I doubt we want to specify *this* much detail, but we may need to say 
something.)

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 04 Feb 2014 11:37:00 +1100

Hello Christer,

Thanks for making a start on this.

Some comments:
General: I think the "SCTP Considerations" section could benefit by 
something like section 6/[draft-ietf-rtcweb-data-channel-05]. i.e. "The 
Usage of SCTP in the CLUE Context". I think that provides a fairly 
complete list of the features required. Section 6.1 could pretty much 
just be copied. Section 6.2 could be made CLUE specific, I guess that's 
what section 4 of your draft is related to. 6.3 probably can be copied. 
It wouldn't hurt to state that for CLUE messages. Section 6.4 could be 
altered slightly for CLUE. Section 6.5 would need to be updated for the 
CLUE.

Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for large 
messages. This is probably something we would want to support in CLUE 
given the potential for large messages. It would be captured if we were 
to follow section 6 as per above.

General: As a clue document I think we shouldn't assume that a CLUE 
implementer is across the RTCWEB work. E.g. section 3.2.2 of your draft 
would be a bit bewildering. What relevance is a DOMstring (which isn't 
well defined by draft-ietf-rtcweb-data-channel-05) PID 51 to CLUE. Why 
PID50 for CLUE?

Section 6: If we use draft-jesup-rtcweb-data-protocol then do we need to 
add an IANA consideration to add "CLUE" to the protocol element in the 
DATA_CHANNEL_OPEN message?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Feb 2014 09:19:55 +0000

Hi Christian,

> Some comments:
> General: I think the "SCTP Considerations" section could benefit by something like section 6/[draft-ietf-rtcweb-data-channel-05]. i.e. "The Usage of SCTP in the CLUE Context".

I guess we could start by re-naming section 3.2 to something like that :)

> I think that provides a fairly complete list of the features required. Section 6.1 could pretty much just be copied.

I agree that we might be able to copy most of the stuff. However, do we really need the partial reliability extension for CLUE? The suggestion is to always use a reliable channel.

> Section 6.2 could be made CLUE specific, I guess that's what section 4 of your draft is related to. 

Correct.

If we want, we could use the section, have some text talking about the usage of the SDP Offer/Answer mechanism for negotiating the channel, and then refer to section 4 for the details.

> 6.3 probably can be copied. 

To me section 6.3 is teach-yourself-SCTP :)

But, maybe we could add the text to section 2, as a definition for "SCTP stream"?

> It wouldn't hurt to state that for CLUE messages. Section 6.4 could be altered slightly for CLUE.

I think section 6.4 is more or less what I currently have in section 3.2.1. But, maybe it should be added to a "Channel Definition" section.

> Section 6.5 would need to be updated for the CLUE.

Yes. Because, as we DO have an "external mechanism" (SDP Offer/Answer) to negotiate the channel, we don't need to be a generic.

> Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for large messages. This is probably something we would want to support 
> in CLUE given the potential for large messages. It would be captured if we were to follow section 6 as per above.

Well, we need to discuss whether we need to support/mandate interleaving, or whether application fragmentation is enough.

> General: As a clue document I think we shouldn't assume that a CLUE implementer is across the RTCWEB work. E.g. section 3.2.2 of your draft 
> would be a bit bewildering. What relevance is a DOMstring (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID 51 to CLUE. Why
> PID50 for CLUE?

Yes. This is part of the general opinion that we need more details on why certain selections have been done, and that 50 and 51 are used to provide interoperability with rtcweb.

> Section 6: If we use draft-jesup-rtcweb-data-protocol then do we need to add an IANA consideration to add "CLUE" to the protocol element in the DATA_CHANNEL_OPEN message?

Yes.

I think it would be good to be able to, on the data channel, indicate when a data channel is "openend", and when it is "closed". The question is whether we would use the rtcweb data channel protocol for that, or whether we would define some message in the CLUE protocol.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 05 Feb 2014 13:01:56 +1100

Hello Christer,

Please see below.

Regards, Christian

> I guess we could start by re-naming section 3.2 to something like that :)
[CNG] OK
> I agree that we might be able to copy most of the stuff. However, do we really need the partial reliability extension for CLUE? The suggestion is to always use a reliable channel.
[CNG] See other email.
> If we want, we could use the section, have some text talking about the usage of the SDP Offer/Answer mechanism for negotiating the channel, and then refer to section 4 for the details.
[CNG] Sounds OK.
> But, maybe we could add the text to section 2, as a definition for "SCTP stream"?
[CNG] I don't think it hurt to give some back ground. We have to 
remember people who implement this won't necessarily be across of the 
discussions in RTCweb.
> I think section 6.4 is more or less what I currently have in section 3.2.1. But, maybe it should be added to a "Channel Definition" section.
[CNG] Yes pretty much along the lines of section 3.2.1. Will an endpoint 
only ever have two CLUE channels (one send/one receive) per SCTP 
association? This is what I was trying to clarify on the MMUSIC list 
with respect to CLUE and other application protocols like bfcp/t.38 etc.
> Yes. This is part of the general opinion that we need more details on why certain selections have been done, and that 50 and 51 are used to provide interoperability with rtcweb.
[CNG] If RTCweb is not used do we expect the CLUE data to be formatted 
as a "javascript strings"? What does using a "javascript string" imply 
with respect to the CLUE data model? Again we should assume no knowledge 
of RTCWEB for a CLUE implementation so I think we have to go into some 
detail what this means.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 10:38:16 +0000

Hi Christian,

> [CNG] I don't think it hurt to give some back ground. We have to remember people who implement this won't necessarily be across of the discussions in RTCweb.

No, but it would be good if they had some knowledge of SCTP :)

Anyway, what about something like the following for section 2:

   "[RFC4960] defines a SCTP stream as a unidirectional logical channel
   established from one to another associated SCTP endpoint, within
   which all user messages are delivered in sequence except for those
   submitted to the unordered delivery service.

   [RFC4960] defines a SCTP identifier as a unsigned integer, which
   identifies an SCTP stream."

> [CNG] Yes pretty much along the lines of section 3.2.1. Will an endpoint only ever have two CLUE channels (one send/one receive) per 
> SCTP association? This is what I was trying to clarify on the MMUSIC list with respect to CLUE and other application protocols like bfcp/t.38 etc.

Something like this:

"3.2.  CLUE Data Channel Definition

   The realization of a bidirectional CLUE Data Channel is a pair of one
   incoming SCTP stream and one outgoing SCTP stream.  These streams are
   then used to transport CLUE messages in both directions.

   The SCTP streams MUST belong to the same SCTP association.

   The SCTP streams SHOULD have identical SCTP stream identifier values,
   unless a specific value is already used for some other purpose.

   OPEN ISSUE: We need to see whether the usage of identical SCTP stream
   ID values need to be mandated."

>>> Section 3: [I-D.stewart-tsvwg-sctp-ndata] defines interleaving for 
>>> large messages. This is probably something we would want to support in CLUE given the potential for large messages. It would be captured if we were to follow section 6 as per above.
>>> implementer is across the RTCWEB work. E.g. section 3.2.2 of your 
>>> draft would be a bit bewildering. What relevance is a DOMstring 
>>> (which isn't well defined by draft-ietf-rtcweb-data-channel-05) PID 
>>> 51 to CLUE. Why
>>> PID50 for CLUE?
> [CNG] If RTCweb is not used do we expect the CLUE data to be formatted as a "javascript strings"? What does using a "javascript string" imply with respect 
> to the CLUE data model? Again we should assume no knowledge of RTCWEB for a CLUE implementation so I think we have to go into some detail what this means.

As far as I understand, there is nothing strange about a "javascript string" - it's a normal string.

In my opinion, as the PPID values 50 and 51 are defined in the rtcweb data channel draft, that draft needs to be clear on what it means. But, we can then of course reference that definition in our draft.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 10:30:48 -0500

Inline

On 2/5/14 5:38 AM, Christer Holmberg wrote:
>> SCTP association?

AFAIK we have not settled on that yet.
Two possibilities have been discussed:

- one bidirectional channel (one outgoing and one incoming SCTP stream)
   used for: sending clue requests and responses, receiving clue requests
   and responses.

- two bidirectional channels:
   . one for sending clue requests and receiving clue responses
     (provider role)
   . one for receiving clue requests and sending clue responses
     (consumer role)

Using two leverages sctp stream multiplexing to handle the multiplexing 
of the provider role messages with the consumer role messages. So it can 
simplify the implementation of the clue protocol.

OTOH this means that it would be harder to map the clue protocol onto a 
reliable transport that doesn't have multiple streams.

My impression is that there has been a preference for using a single 
channel, but I don't recall that we made a final decision on it.

> This is what I was trying to clarify on the MMUSIC list with respect to CLUE and other application protocols like bfcp/t.38 etc.

The use of one or two is a clue decision, not an mmusic decision.

>     unless a specific value is already used for some other purpose.

If it is *possible* that the two stream ids might not be identical, then 
we need a way to determine which ones are paired.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 15:45:35 +0000

Hi,

>>> [CNG] Yes pretty much along the lines of section 3.2.1. Will an 
>>> endpoint only ever have two CLUE channels (one send/one receive) per SCTP association?
>
> Using two leverages sctp stream multiplexing to handle the multiplexing of the provider role messages with the consumer role messages. So it can simplify the implementation of the clue protocol.
>
> OTOH this means that it would be harder to map the clue protocol onto a reliable transport that doesn't have multiple streams.
>
> My impression is that there has been a preference for using a single channel, but I don't recall that we made a final decision on it.

My suggestion is to use one bidirectional channel.

I am not even sure how/if rtcweb supports multiple data channels. At least the current drafts seem to assume that only one will be used - at least per a single SCTP association :)

> If it is *possible* that the two stream ids might not be identical, then we need a way to determine which ones are paired.

Yes, and there is a discussion (initiated by yourself, with some extra fuel added by me :) on the RTCWEB list regarding that, so let's see what the outcome will be.

(Of course, one could use the Data Channel Protocol, and then the receiver will see on which stream the messages are received, and assume that the stream will be used for whatever protocol is indicated. )

Regards,

Christer

---

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

A lot inline

> I am not even sure how/if rtcweb supports multiple data channels. At least the current drafts seem to assume that only one will be used - at least per a single SCTP association :)

Christer - how can you say that? Supporting multiple channels is a major 
part of the data channel work in rtcweb and webrtc.

In rtcweb you get multiple channels by sending multiple OPEN messages. 
(I don't follow the api work much, but the api for creating a channel 
can be called multiple times.)

I am quite certain that there is no doubt about this.

> (Of course, one could use the Data Channel Protocol, and then the receiver will see on which stream the messages are received, and assume that the stream will be used for whatever protocol is indic…

If you use the data channel protocol, then one end chooses an unused 
stream id and sends the OPEN message. The other end will receive that, 
necessarily on the *same* stream id. (That is how SCTP works.)

Then the receiver of the OPEN must send an ACK. It must choose some 
stream ID to send that ACK on. And it must choose it in such a way that 
the other end will know that the ACK correlates to the correct OPEN.

The Webrtc Data Channel Protocol says that one side always uses *even* 
stream IDs to send OPENs, and the other side always uses *odd* stream 
IDs to send OPENs. That already *implies* that the intent is that the 
paired stream use the same ID, but doesn't really require it.

Consider the following

	Alice                 Bob
	  |    OPEN(id=1)      |
	  |------------------->|
	  |                    |
	  |    OPEN(id=4)      |
	  |<-------------------|
	  |                    |
	  |    OPEN(id=3)      |
	  |------------------->|
	  |                    |
	  |    ACK(id=3)       |
	  |<-------------------|
	  |                    |
	  |    DATA(id=3)      |
	  |<-------------------|
	  |                    |
	  |    DATA(id=3)      |
	  |------------------->|
	  |                    |
	  |    ACK(id=4)       |
	  |------------------->|
	  |                    |
	  |    DATA(id=4)      |
	  |<-------------------|
	  |                    |
	  |    ACK(id=1)       |
	  |<-------------------|
	  |                    |
	  |    OPEN(id=2)      |
	  |<-------------------|
	  |                    |
	  |    ACK(id=2)       |
	  |------------------->|

The above is assuming that stream ids in one direction are paired with 
stream ids in the other direction to make a channel. So from a channel 
perspective the above would look like:

	Alice                 Bob
	  |    OPEN(id=1)      |
	  |------------------->|
	  |                    |
	  |    ACK(id=1)       |
	  |<-------------------|

	Alice                 Bob
	  |                    |
	  |    OPEN(id=2)      |
	  |<-------------------|
	  |                    |
	  |    ACK(id=2)       |
	  |------------------->|

	Alice                 Bob
	  |                    |
	  |    OPEN(id=3)      |
	  |------------------->|
	  |                    |
	  |    ACK(id=3)       |
	  |<-------------------|
	  |                    |
	  |    DATA(id=3)      |
	  |<-------------------|
	  |                    |
	  |    DATA(id=3)      |
	  |------------------->|

	Alice                 Bob
	  |                    |
	  |    OPEN(id=4)      |
	  |<-------------------|
	  |                    |
	  |    ACK(id=4)       |
	  |------------------->|
	  |                    |
	  |    DATA(id=4)      |
	  |<-------------------|

The even/odd rule ensures that the ids used by one side for open won't 
be used by the other side for open, and so will remain free to be used 
for ack.

*in principle* if an OPEN is received on an even stream id the paired 
return stream id could be some *different* even number. But then the 
issue of how to match them remains a problem.

There are a whole bunch of labels involved in the above.

Alice:
- IP address (IP-A)
- UDP port number (UDP-A)
- SCTP port number (SCTP-A)
- SCTP outgoing stream id (SID-1, SID-3)
- SCTP incoming stream id (SID-2, SID-4)

Bob:
- IP address (IP-B)
- UDP port number (UDP-B)
- SCTP port number (SCTP-B)
- SCTP outgoing stream id (SID-2, SID-4)
- SCTP incoming stream id (SID-1, SID-3)

The pairing of IP address, UDP port, and SCTP port is defined by SDP O/A:

Alice:
     m=application UDP-A DTLS/SCTP SCTP-A
     c=IN IP4 IP-A
     a=sctpmap:SCTP-A webrtc-datachannel 16

Bob:
     m=application UDP-B DTLS/SCTP SCTP-B
     c=IN IP4 IP-B
     a=sctpmap:SCTP-B webrtc-datachannel 16

But the matching outgoing and incoming SCTP stream ids is not defined by 
SDP (at least not without something like the Ejzak draft).

I wonder, are you getting the stream id issues mixed up with port number 
issues?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 11:05:04 +1100

Hello

On 6/02/2014 4:22 AM, Paul Kyzivat wrote:
>>>>>> I think section 6.4 is more or less what I currently have in 
>>>>>> section 3.2.1. But, maybe it should be added to a "Channel 
>>>>>> Definition" section.
>>> Using two leverages sctp stream multiplexing to handle the 
>>> multiplexing of the provider role messages with the consumer role 
>>> messages. So it can simplify the implementation of the clue protocol.
[CNG] How would this simplify things? When you talk about multiplexing 
the provider and consumer roles it sounds like two different protocols. 
I think we should consider one protocol and not talk about multiplexing 
roles.
>>>
>>> OTOH this means that it would be harder to map the clue protocol 
>>> onto a reliable transport that doesn't have multiple streams.
>>>
[CNG] I would also lean to one bidirectional channel.

>>
>> I am not even sure how/if rtcweb supports multiple data channels. At 
>> least the current drafts seem to assume that only one will be used - 
>> at least per a single SCTP association :)
>
> Christer - how can you say that? Supporting multiple channels is a 
> major part of the data channel work in rtcweb and webrtc.
>
[CNG] Like Paul I thought that the rtcweb did support multiple channels. 
Where is this limitation?

>>>>      unless a specific value is already used for some other purpose.
[CNG] Can there be multiple CLUE data channels per SCTP association?
>>>
>>> If it is *possible* that the two stream ids might not be identical, 
>>> then we need a way to determine which ones are paired.

>> Yes, and there is a discussion (initiated by yourself, with some 
>> extra fuel added by me :) on the RTCWEB list regarding that, so let's 
>> see what the outcome will be.
>>
>> (Of course, one could use the Data Channel Protocol, and then the 
>> receiver will see on which stream the messages are received, and 
>> assume that the stream will be used for whatever protocol is 
>> indicated. )
>
> stream ID to send that ACK on. And it must choose it in such a way 
> that the other end will know that the ACK correlates to the correct OPEN.
>
> But the matching outgoing and incoming SCTP stream ids is not defined 
> by SDP (at least not without something like the Ejzak draft).
[CNG] If we only have a single bi-directional CLUE channel per STCP 
association is this matching a problem?
Alice:
     m=application UDP-A DTLS/SCTP SCTP-A
     c=IN IP4 IP-A
     a=sctpmap:SCTP-A webrtc-datachannel 16
     a=sctpmap:SCTP-A CLUE 17

Bob:
     a=sctpmap:SCTP-B CLUE 18

By labeling the channel CLUE and the fact there is only one CLUE channel 
per association you are tying together the send and receive channels.

> I wonder, are you getting the stream id issues mixed up with port 
> number issues?
>
>     Thanks,
>     Paul
>
>> Regards,
>>
>> Christer
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 00:21:36 -0500

> I think we should consider one protocol and not talk about multiplexing

It simplifies things because we conceptually have one state machine for 
the provider role and one for the consumer role. If each is mapped onto 
a separate channel then each can operate independently. (E.g., after 
sending an advertisement, you can hang in a state awaiting a response to 
it.)

When you merge the provider and consumer roles it is messier to describe.

We can still do it, in a similar way to channels, by putting a role 
attribute into each message. But it is one more thing to do that isn't 
needed if you use two channels.

> association is this matching a problem?

Yes, if any streams may be used for any other purpose.
If the entire sctp association was devoted to clue, then no.

> per association you are tying together the send and receive channels.

You have just redefined what the last parameter on a=sctpmap is for.
It is defined as specifying the maximum number of channels for the 
association. It is not used for negotiating individual stream/channel 
IDs. Nor is it used for negotiating the protocol used on individual 
streams/channels.

What you are trying to do is what the Ejzak draft does.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 17:24:21 +1100

Hello Paul,
> IDs. Nor is it used for negotiating the protocol used on individual 
[CNG] Doh, you're right.... serves me for not reading that parameter 
properly.

Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 08:48:07 +0000

Hi,

>>> By labeling the channel CLUE and the fact there is only one CLUE 
>>> channel per association you are tying together the send and receive channels.
>>
> [CNG] Doh, you're right.... serves me for not reading that parameter properly.

This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a channel, and in CLUE we have our (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't define a channel concept to begin with.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 20:57:59 +1100

> This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a chann…
I don't know. This becomes a real problem at a gateway especially 
decomposed one. How do I map SCTP streams (particularly if they relate 
to multiple application protocols) received at one side of the gateway 
to the other?

Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 10:48:59 +0000

Hi,

>>>> association. It is not used for negotiating individual 
>>>> stream/channel IDs. Nor is it used for negotiating the protocol used 
>>>> on individual streams/channels.
>> This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a channel, and in CLUE we have our
>> (which is identical to the RTCWEB one). But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't define a channel concept to begin with.
> I don't know. This becomes a real problem at a gateway especially decomposed one. How do I map SCTP streams (particularly if they relate to multiple application protocols) received at one side of the gateway to the other?

Actually, I think all 3 of us are partly wrong. The number value at the end of the sctpmap attribute is NOT the number of channels - it's the number of incoming streams (which, of course, can be the same).

But, never the less, it still doesn't solve the mapping problem.

Regards,

Christer

---

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

Hi,

> Christer - how can you say that? Supporting multiple channels is a major part of the data channel work in rtcweb and webrtc.

I'll correct myself: The sctp-sdp draft currently seems to assume there will be a single channel per SCTP association.

> (I don't follow the api work much, but the api for creating a channel can be called multiple times.)

Correct.

> If you use the data channel protocol, then one end chooses an unused stream id and sends the OPEN message. The other end will receive that, necessarily on the *same* stream id. (That is how SCTP works.)
>
> Then the receiver of the OPEN must send an ACK. It must choose some stream ID to send that ACK on. And it must choose it in such a way that the other end will know that the ACK correlates to the correct OPEN.

Correct. And, there is currently nothing explicit (e.g. a transaction identifier) in the protocol itself for that.

> The Webrtc Data Channel Protocol says that one side always uses *even* stream IDs to send OPENs, and the other side always uses *odd* stream IDs to send 
> OPENs. That already *implies* that the intent is that the paired stream use the same ID, but doesn't really require it.

Correct.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 10:19:49 -0500

> This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general channel concept in SCTP. RTCWEB have their specific definition of a chann…

I think it is really the max number of stream ids. I don't know how it 
relates to incoming streams vs outgoing streams, but since a channel 
requires one of each, it probably works out.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Feb 2014 15:30:49 +0000

Hi,

>> This probably belongs to MMUSIC, but I wonder how "specifying the number of channels" really will work. There is no general
>> channel concept in SCTP. RTCWEB have their specific definition of a channel, and in CLUE we have our (which is identical to the RTCWEB one). 
>> But, maybe I want to use DTLS/SCTP for a protocol X, which doesn't define a channel concept to begin with.
>
> I think it is really the max number of stream ids.

Yes, it is (I think I sent another e-mail on that :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 10:36:20 -0500

> But, never the less, it still doesn't solve the mapping problem.

Did you see my reply to myself on rtcweb? There really is text in the 
rtcweb-protocol draft that says the ACK goes on the same stream ID as 
the OPEN. (I finally found it.)

	Thanks,
	Paul