Subject: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Feb 2014 14:03:13 +0000

Hi,

The draft submission deadline has passed, but I still wrote some more text, shown below, for the SDP Offer/Answer Procedures section.

Regards,

Christer

PS. Note that I will be on vacation next week, so I will once again do my best trying to stay away from e-mails :)

-----------------------

4.  SDP Offer/Answer Procedures

4.1.  General

   This section describes how the SDP media description ("m=") line for
   a CLUE data channel is created, and how it is used in SDP offers and
   answers.

   NOTE: The proceudres associated with "m=" lines for other media types
   (e.g. audio and video) used in a CLUE session are outside the scope
   of this document.

   OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel
   Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]
   will be used with the CLUE data channel.

   NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used
   with the CLUE data channel, a new associated 'sub-protocol' value
   needs to be registered with IANA.

4.2.  SDP Media Description Fields

   The field values of the "m=" line for the CLUE data channel are set
   as following:

   +----------------+----------------+------------------------+----------------+
   |     media      |      port         |      proto               |      fmt         |
   +----------------+----------------+------------------------+----------------+
   | "applicationS |   DTLS port   | "UDP/TLS/UDPTL" |   SCTP port   |
   |                    |     value       |                             |     value       |
   +----------------+----------------+------------------------+---------------+

                     Table 1: SDP "proto" field values

4.3.  SDP sctpmap Attribute

   The field values of the SDP sctpmap attribute associated with the
   CLUE data channel "m=" are set as following:

   +---------------------+---------------------------+-----------------------+---------+
   | sctpmap-number |         app                  | max-message-size | stream |
   +---------------------+---------------------------+-----------------------+---------+
   |  fmt value of       | "webrtc-datachannel" |  Implemenation     |  "1"     |
   | the "m=" line      |                                |     specific             |           |
   +---------------------+---------------------------+-----------------------+---------+

                     Table 2: SDP "proto" field values

4.4.  SDP Offerer Procedures

   The procedures for the offerer follow the normal proceures defined in
   [ref-to-3264].

   When the offerer creates an offer, which contains an "m=" line for a
   CLUE data channel, it assigns the field values to the "m=" line
   according to the procedures in Section 4.2.  In addition, the offerer
   MUST insert an SDP sctpmap attribute associated with the "m=" line.

   In an offer, the offerer MUST NOT insert more than one "m=" line for
   a CLUE data channel.

   NOTE: CLUE does not support the usage of multiple CLUE data channels.

   The offerer MUST NOT insert more than one SDP sctpmap attributes in
   an "m=" line for a CLUE data channel.

   If an offerer, in a subsequent offer, wants to disable the CLUE data
   channel, it assigns a zero port value to the "m=" line associated
   with the CLUE data channel.  The answerer MUST NOT insert an SDP
   sctpmap attribute associated with the "m=" line.

4.5.  SDP Answerer Procedures

   The procedures for the answerer follow the normal proceures defined
   in [ref-to-3264].

   If the answerer receives an offer, which contains an "m=" line for a
   CLUE data channel, and the answerer accepts the "m=" line, it creates
   and inserts an "m=" line in the associated answer.  The answerer
   assigns the field values to the "m=" line according to the procedures
   in Section 4.2.

   If, in the offer, a zero port value has been assigned to the "m="
   line for the CLUE channel, or it the answerer does not accept the
   "m=" line, but accepts other "m=" lines in the offer (i.e. the
   answerer will not reject the whole offer), it still inserts an "m="
   line for a CLUE data channel in the associated answer.  The answerer
   then assigns a zero port value to the "m=" line.  The answerer MUST
   NOT insert an SDP sctpmap attribute associated with the "m=" line.

4.6.  Example

        m=application 54111 SCTP/DTLS 54111
        a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1

          Figure 1: SDP Media Description for a CLUE data channel

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Feb 2014 10:35:32 +1100

Hello Christer,

With the use of webrtc-datachannel how do I negotiate via SDP whether I 
want to use clue or not?

A SCTP association (and thus webrtc-datachannel) for example could be 
used for BFCP,CLUE and T.38. It seems wasteful to establish the SCTP 
association to figure out that the endpoints support webrtc-datachannel 
put don't support the application that you want.

In the example in section 4.6 there's no way of distinguishing that 
description for CLUE vs BFCP vs anything else. Its not a CLUE data 
channel is a generic data channel.

Regards, Christian

On 16/02/2014 1:03 AM, Christer Holmberg wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Feb 2014 00:16:22 +0000

Hi Christian,

If you want to negotiate usage of CLUE (or, any other specific usage of a webrtc-datachannel) in SDP, one option is to use Richard's draft. The usage of that draft is listed as an open issue in the CLUE data channel draft.

SIP also provides other mechanisms, e.g. media feature tags, for indicating support of features.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Christian Groves <[email-masked]> wrote:

Hello Christer,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Feb 2014 11:56:09 +1100

Hello Christer,

I think that for the signaling we must specify a way of negotiating at 
the SDP level whether CLUE is supported. I agree there's lots of ways it 
could be done but we need to indicate which one/s CLUE should use.

So for the SDP O/A procedures and example I think you have to assume the 
use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't say 
its a CLUE data channel according to the SDP given. You're just opening 
a generic channel, which may or may not be clue. Particularly in the 
Answerer's case, it doesn't know that the Offer is going to use the 
channel for CLUE.

However:
m=application 54111 SCTP/DTLS 54111
a=sctpmap:54111 webrtc-datachannel max-message-size=100000 streams=1
a=dcmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3

would unambiguously define it as a CLUE data channel.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Feb 2014 01:11:29 +0000

Hi,

If the offerer offers a data channel, AND also some way indicates support of CLUE, we can always specify that the offerer MUST be able to use the data channel for CLUE. The WebRTC data channel protocol can then be used to open the channel for CLUE.

But, never the less, it would probably be good to have an example showing how things would look like using Richard's draft, until we've decided whether we are going to use it or not. I'll add that.

Regards,

Christer

Hello Christer,

However:

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Feb 2014 12:35:32 +1100

Hello Christer,

Please see below.

Regards, Christian

> If the offerer offers a data channel, AND also some way indicates support of CLUE, we can always specify that the offerer MUST be able to use the data channel for CLUE. The WebRTC data channel prot…
[CNG] I agree.

I'm still uncomfortable with the way these drafts are layered. The SCTP 
draft allows the specification of "app"s that relate to the SCTP 
association as a means of negotiating what goes in the SCTP association. 
One of those "app"s may be the webrtc data channel. It has its own means 
of negotiating of what is in the SCTP association (i.e. Richard's 
draft). Both these methods are basically just indicating what will be in 
the SCTP streams. Rather than have two methods for negotiating what is 
in the SCTP association it almost seems better to have one method for 
negotiation of what apps there are and then to tag whether or not the 
webrtc data channel will be used to open it.

e.g.

m=application 54111 SCTP/DTLS 54111
a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; max_retr=3; webrtc-datachannel-tag
a=webrtc-datachannel:max-message-size=100000 streams=1
  
webrtc-datachannel-tag would take whether an "app" uses the webrtc data channel open protocol.
a=webrtc-datachannel attribute would give the attributes of the protocol.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Feb 2014 22:36:01 -0500

Christer,

inline

On 2/15/14 9:03 AM, Christer Holmberg wrote:
>     |     media      |      port|      proto             |      fmt       |
>     | "application"  |   DTLS port    | "UDP/TLS/UDPTL"        |   SCTP port    |
>     |                |     value      |                        |     value      |

Note: AFAIK it doesn't matter what value is used for SCTP port number.
(Or does rtcweb require a particular value?)

*In principle* there should be no reason why there couldn't be more than 
one SCTP Port Value, though only one would be used for CLUE. IMO we 
should follow rtcweb on this.

>     CLUE data channel "m=" are set as following:

I don't think we should specify "1" be used for stream. That means that 
the CLUE stream would be the *only* stream - preventing use of the 
association for anything else.

>     In an offer, the offerer MUST NOT insert more than one "m=" line for

The m-line isn't solely for a CLUE data channel. I see no reason to 
forbid more than one SCTP m-line. All we need to do is specify which one 
is used for the CLUE channel if there is more than one. Again I think we 
can follow rtcweb on this. (I don't know if it forbids more than one.)

>     NOTE: CLUE does not support the usage of multiple CLUE data channels.

Agreed. But we didn't get to the part that actually specifies the clue 
channel.

>     an "m=" line for a CLUE data channel.

Same comment as above. If there were multiple SCTP ports then there 
would be multiple sctmap attributes.

>     sctpmap attribute associated with the "m=" line.

The mechanics specified here are ok, but the reason for them is not.

While this would *work*, by preventing the association that is needed 
for the clue channel, it is too extreme to require as the only way to 
indicate lack of desire for CLUE. (Might just want to use the SCTP for 
something else.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Feb 2014 22:39:17 -0500

Inline

On 2/16/14 7:56 PM, Christian Groves wrote:
> the SDP level

or SIP level!!!

> whether CLUE is supported. I agree there's lots of ways it

Yes. That is one way.

Another way is to signal CLUE support in SIP (e.g., feature tag), and 
then open the actual channel dynamically using the rtcweb data channel 
protocol.

	Thanks,
	Paul

>> If you want to negotiate usage of CLUE (or, any other specific usage
>> of a webrtc-datachannel) in SDP, one option is to use Richard's draft.
>> The usage of that draft is listed as an open issue in the CLUE data
>> channel draft.
>>
>>> The draft submission deadline has passed, but I still wrote some more
>>> text, shown below, for the SDP Offer/Answer Procedures section.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> PS. Note that I will be on vacation next week, so I will once again
>>> do my best trying to stay away from e-mails :)
>>>
>>> -----------------------
>>>
>>>      Negotiation mechanism
>>> [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg]
>>>      |                    |     value
>>> |                             |     value       |

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 16 Feb 2014 23:09:12 -0500

On 2/16/14 8:35 PM, Christian Groves wrote:
>> If the offerer offers a data channel, AND also some way indicates
>> support of CLUE, we can always specify that the offerer MUST be able
>> to use the data channel for CLUE. The WebRTC data channel protocol can
>> then be used to open the channel for CLUE.
> [CNG] I agree.
>
> I'm still uncomfortable with the way these drafts are layered.

I'm troubled too, but maybe not exactly the same way you are.
IMO it isn't that the layering is so wrong. Rather it is that the 
terminology used is confusing.

> The SCTP
> draft).

I agree with your interpretation here. That doesn't mean the layering is 
wrong - just the terminology.

The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But 
in reality its purpose is not at all analogous to a=rtpmap. So the name 
confuses.

And that mis-analogy is continued, by language that says sctpmap is 
defining a mapping from a port number to a payload format. Again, that 
is not what it is doing. (If it were, then you would be restricted to 
one payload format for all the streams on the association.) AFAICT, the 
name you are giving in sctpmap describes some sort of "convention" for 
how all the streams in the association are to be managed and used. E.g., 
"webrtc-datachannel" says that the streams will be managed in pairs, as 
channels, and that webrtc data channel protocol may be used to 
dynamically assign channels. (That is the same conclusion you have reached.)

IMO a lot of the language should be changed to be less confusing.

> Both these methods are basically just indicating what will be in
> the SCTP streams.

Both? Which? The only thing that actually says, in SDP, what will be in 
the individual SCTP streams is Richard's draft.

> Rather than have two methods for negotiating what is

There are problems with this - not for CLUE, but for webrtc, or anything 
that doesn't want to use O/A to define every channel.

The webrtc data channel open protocol does not take a stream ID as an 
argument. It internally assigns stream IDs. Rtcweb has specified how you 
can use preassigned channels without the open, but then it isn't using 
the data channel protocol.

IMO, from an mmusic perspective, we need to support both the static and 
dynamic assignment of channels. We just want it to be done more clearly.

 From a CLUE perspective, we need to decide if we want to use the static 
or dynamic assignment. IMO the preferred choice is not obvious - both 
have their attractions. At the moment I am *slightly* preferring the 
dynamic.

	Thanks,
	Paul

>>
>> But, never the less, it would probably be good to have an example
>> showing how things would look like using Richard's draft, until we've
>> decided whether we are going to use it or not. I'll add that.
>>
>> Regards,
>>
>> Christer
>>
>>> of a webrtc-datachannel) in SDP, one option is to use Richard's
>>> draft. The usage of that draft is listed as an open issue in the CLUE
>>> data channel draft.
>>>
>>>> The draft submission deadline has passed, but I still wrote some
>>>> more text, shown below, for the SDP Offer/Answer Procedures section.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>

---

From: Christian Groves <[email-masked]>
Date: Mon, 17 Feb 2014 16:07:07 +1100

Hello Paul,

> terminology used is confusing.
[CNG] Yes the terminology isn't helping either.

> I agree with your interpretation here. That doesn't mean the layering 
> is wrong - just the terminology.
>
> in reality its purpose is not at all analogous to a=rtpmap. So the 
> name confuses.
>
> one payload format for all the streams on the association.) AFAICT, 
> the name you are giving in sctpmap describes some sort of "convention" 
> for how all the streams in the association are to be managed and used. 
> E.g., "webrtc-datachannel" says that the streams will be managed in 
> pairs, as channels, and that webrtc data channel protocol may be used 
> to dynamically assign channels. (That is the same conclusion you have 
> reached.)
>
> Both? Which? The only thing that actually says, in SDP, what will be 
> in the individual SCTP streams is Richard's draft.
[CNG] The SCTP draft does say which "apps" will be in the association. 
That what I mean by "what's in the streams" in the general sense.
> There are problems with this - not for CLUE, but for webrtc, or 
> anything that doesn't want to use O/A to define every channel.
>
> argument. It internally assigns stream IDs. Rtcweb has specified how 
> you can use preassigned channels without the open, but then it isn't 
> using the data channel protocol.
[CNG] I just threw something together here without much thought. So for 
the case where the streamID isn't specified "data channel protocol" 
could be the value to indicate that it is used?
>
> IMO, from an mmusic perspective, we need to support both the static 
> and dynamic assignment of channels. We just want it to be done more 
> clearly.
[CNG] Perhaps this is key, for a particular app in a SCTP association we 
need to say whether or not the streamID assignment is static or dynamic 
via the data channel protocol".
>
> From a CLUE perspective, we need to decide if we want to use the 
> static or dynamic assignment. IMO the preferred choice is not obvious 
> - both have their attractions. At the moment I am *slightly* 
> preferring the dynamic.
[CNG] Dynamic is probably OK so long as we have some sort of label 
mechanism to help sort out mapping when you have multiple instances of 
the same app.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Feb 2014 09:40:18 +0000

Hi,

I will read and comment on this at another moment, but to me it seems like this discussion belongs to the MMUSIC (and perhaps RTCWEB) list.

Regards,

Christer

________________________________________
From: clue [[email-masked]] on behalf of Christian Groves [[email-masked]]
Sent: Monday, 17 February 2014 7:07 AM
To: [email-masked]
Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

Hello Paul,

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Mon, 17 Feb 2014 11:00:19 +0000

Hi Paul,

   Please see about the static and dynamic assignment of channels as below. Thanks.

Best Regards,
Scarlett

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, February 17, 2014 12:09 PM
To: [email-masked]
Subject: Re: [clue] CLUE Data Channel: SDP Offer/Answer Proceudres

On 2/16/14 8:35 PM, Christian Groves wrote:
>> to use the data channel for CLUE. The WebRTC data channel protocol 
>> can then be used to open the channel for CLUE.
> [CNG] I agree.
>

I'm troubled too, but maybe not exactly the same way you are.
IMO it isn't that the layering is so wrong. Rather it is that the terminology used is confusing.

> One of those "app"s may be the webrtc data channel. It has its own 
> means of negotiating of what is in the SCTP association (i.e. 
> Richard's draft).

I agree with your interpretation here. That doesn't mean the layering is wrong - just the terminology.

The use of a=sctpmap is clearly intended as an analog to a=rtpmap. But in reality its purpose is not at all analogous to a=rtpmap. So the name confuses.

And that mis-analogy is continued, by language that says sctpmap is defining a mapping from a port number to a payload format. Again, that is not what it is doing. (If it were, then you would be restricted to one payload format for all the streams on the association.) AFAICT, the name you are giving in sctpmap describes some sort of "convention" for how all the streams in the association are to be managed and used. E.g., "webrtc-datachannel" says that the streams will be managed in pairs, as channels, and that webrtc data channel protocol may be used to dynamically assign channels. (That is the same conclusion you have reached.)

> Both these methods are basically just indicating what will be in the 
> SCTP streams.

Both? Which? The only thing that actually says, in SDP, what will be in the individual SCTP streams is Richard's draft.

> Rather than have two methods for negotiating what is in the SCTP 
> association it almost seems better to have one method for negotiation 
> of what apps there are and then to tag whether or not the webrtc data 
> channel will be used to open it.
>
> e.g.
>

There are problems with this - not for CLUE, but for webrtc, or anything that doesn't want to use O/A to define every channel.

The webrtc data channel open protocol does not take a stream ID as an argument. It internally assigns stream IDs. Rtcweb has specified how you can use preassigned channels without the open, but then it isn't using the data channel protocol.

IMO, from an mmusic perspective, we need to support both the static and dynamic assignment of channels. We just want it to be done more clearly.

 From a CLUE perspective, we need to decide if we want to use the static or dynamic assignment. IMO the preferred choice is not obvious - both have their attractions. At the moment I am *slightly* preferring the dynamic.
[Scarlett] I am not sure about the static or dynamic assignment of data channels.
Maybe the static assignment of data channel is as below：
1) According to the draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 draft, the stream id for webrtc data channel is given in SDP offer in spite of the SCTP association has not been established. 2) After the webrtc clients have finished SDP offer/answer, the SCTP association will be established. And then the data channel's state will be set open.

The dynamic assignment of data channel is as below；
1) According to the draft-ietf-mmusic-sctp-sdp-05 draft, if an SDP offer with a DTLS/SCTP request is answered successfully the corresponding SCTP association will be established.
2) According to the draft-ietf-rtcweb-data-protocol-01 draft, the webrtc client will open a data channel using an unused stream id from the stream ids of the SCTP association. 

	Thanks,
	Paul

>> I think that for the signaling we must specify a way of negotiating 
>> at the SDP level whether CLUE is supported. I agree there's lots of 
>> ways it could be done but we need to indicate which one/s CLUE should use.
>>
>> So for the SDP O/A procedures and example I think you have to assume 
>> the use of draft-ejzak-mmusic-data-channel-sdpneg otherwise you can't 
>> say its a CLUE data channel according to the SDP given. You're just 
>> opening a generic channel, which may or may not be clue. Particularly 
>> in the Answerer's case, it doesn't know that the Offer is going to 
>> use the channel for CLUE.
>>
>> However:
>>> draft. The usage of that draft is listed as an open issue in the 
>>> CLUE data channel draft.
>>>
>>> With the use of webrtc-datachannel how do I negotiate via SDP 
>>> whether I want to use clue or not?
>>>
>>> A SCTP association (and thus webrtc-datachannel) for example could 
>>> be used for BFCP,CLUE and T.38. It seems wasteful to establish the 
>>> SCTP association to figure out that the endpoints support 
>>> webrtc-datachannel put don't support the application that you want.
>>>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 17 Feb 2014 18:57:49 +0000

> Hi,
> 
> If the offerer offers a data channel, AND also some way indicates support of
> CLUE, we can always specify that the offerer MUST be able to use the data
> channel for CLUE. The WebRTC data channel protocol can then be used to open
> the channel for CLUE.
> 
> But, never the less, it would probably be good to have an example showing
> how things would look like using Richard's draft, until we've decided
> whether we are going to use it or not. I'll add that.
[Raju] We will add CLUE example SDP in Richard's draft as well.

-Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Feb 2014 16:24:49 -0500

> Hello Paul,

[snip]

> That what I mean by "what's in the streams" in the general sense.

"apps" is a cop out - it is a meaningless term.

"Loosely" I am inclined to think there is only one "app" at each end of 
the association, or maybe just one distributed app at both ends of the 
association. I find it hard to consider "webrtc-datachannel" an 
"application". It is just another layer in a stack. What we are more 
likely to recognize as the "application" is above that. (We are working 
our way up, from layer 7. But I've lost count.)

But then there is some piece of application behavior associated with 
each channel. *That* is where it gets clue-specific.

This is one of the things that deserves better terminology.

> could be the value to indicate that it is used?

That still requires declaring every channel in SDP doesn't it?
(Maybe that is your goal. But it is a non-goal for webrtc.)

My thinking is that the sctpmap attribute identifies the a discipline 
(convention) used to assign meaning to streams. Then the specification 
of that discipline provides the details of how streams are assigned/used.

Then, when the discipline is webrtc-datachannel (preferably changed to a 
better name) draft-ietf-rtcweb-data-channel spells that out. So it 
defines how streams are grouped into channels, and defines both external 
and internal negotiation. It *ought* to reference (or be merged with) 
the Ejzak draft for external negotiation.

> via the data channel protocol".

Again, for interop with rtcweb we are stuck with "webrtc-datachannel" as 
the "app".

> mechanism to help sort out mapping when you have multiple instances of

I think we would just specify an explicit "label" that CLUE uses to 
identify its channel.

	Thanks,
	Paul

>>>> the

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Feb 2014 16:28:07 -0500

> 2) According to the draft-ietf-rtcweb-data-protocol-01 draft, the webrtc client will open a data channel using an unused stream id from the stream ids of the SCTP association.

Yes.

	Thanks,
	Paul

---

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

Hello Paul,

Please see below.

Regards, Christian

On 18/02/2014 8:24 AM, Paul Kyzivat wrote:
>>>> means
[CNG] I agree, I'm just reusing the existing term. Different protocols 
will be signaled across different SCTP streams.

>
> "Loosely" I am inclined to think there is only one "app" at each end 
> of the association, or maybe just one distributed app at both ends of 
> the association. I find it hard to consider "webrtc-datachannel" an 
> likely to recognize as the "application" is above that. (We are 
> working our way up, from layer 7. But I've lost count.)
[CNG] I don't think we need to make any assumptions about the number of 
apps. A endpoint could have one or more SCTP associations. In those 
associations they could have 1 or more SCTP streams carrying one or more 
protocols.

[CNG] I agree.

>>>> a=sctpmap:54111 stream=2;label="CLUE 1"; subprotocol="CLUE"; 
>>>> max_retr=3;
>>>> webrtc-datachannel-tag
>>>> webrtc-datachannel-tag would take whether an "app" uses the webrtc 
>>>> data
>>>> channel open protocol.
[CNG] Is it a non-goal for webrtc? Isn't 
draft-ejzak-mmusic-data-channel-sdpneg declaring channels?

> of that discipline provides the details of how streams are assigned/used.
[CNG] I understand this but there seems to be a LOT of overlap between 
the SCTP SDP and the Ejzak SDP. The goal of both is out-of-band 
negotiation of what is running on the STCP streams.
>
> Then, when the discipline is webrtc-datachannel (preferably changed to 
> a better name) draft-ietf-rtcweb-data-channel spells that out. So it 
> defines how streams are grouped into channels, and defines both 
> external and internal negotiation. It *ought* to reference (or be 
> merged with) the Ejzak draft for external negotiation.
[CNG] Yes it certainly could do with being merged.
> Again, for interop with rtcweb we are stuck with "webrtc-datachannel" 
> as the "app".
[CNG] I don't think that's a problem so long as its declared that it 
will be used.
> I think we would just specify an explicit "label" that CLUE uses to 
[CNG] Is that an "app" label? :-). I don't think the problem is unique 
to CLUE so I think what ever is used here should be generic mechanism 
for indicating labels.
>>>>>> CLUE
>>>>>>>       When the offerer creates an offer, which contains an "m=" 
>>>>>>> line
>>>>>>> for a
>>>>>>>       If the answerer receives an offer, which contains an "m=" 
>>>>>>> line
>>>>>>> for a
>>>>>>>       answerer will not reject the whole offer), it still 
>>>>>>> inserts an
>>>>>>> "m="

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Feb 2014 00:18:42 -0500

> draft-ejzak-mmusic-data-channel-sdpneg declaring channels?

The ejzak draft isn't really a mainstream rtcweb-sponsored draft.
Richard and I and some other people had a discussion about the concepts 
in this once. (I forget which meeting.) I think the draft came from that.

The main rtcweb people don't want to declare channels in SDP.
We have just managed to get to a point where they can tolerate it as an 
option.

> negotiation of what is running on the STCP streams.

There is overlap because Richard is trying to improve on what the 
sctp-sdp draft proposes.

But the sctp-sdp draft only intends to define the association itself, 
and some attributes of it, such as the max number of streams. It does 
nothing on a per-channel basis.

> [CNG] Is that an "app" label? :-).

No. It is an arbitrary label. For channels opened with the channel 
protocol it shows up in the API.

> I don't think the problem is unique

That is what it is in JSEP.

	Thanks,
	Paul