Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments

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

Hi,

I gave some comments off-line to Salvatore, which have been addressed in the new version.

Some additional comments. I do realize some are pure editorial, but rather to write then down in some notes I put them directly into the e-mail :)

Section 1:
------------

Q1 (EDITORIAL):

The text says:

   "Since
   no-one so far has implemented SCTP over TLS, due to some serious
   limitations described in [RFC6083], this document does not make use
   of TLS over SCTP as described in RFC3436 [RFC3436]."

I suggest to simply say something like:

   "As described in [RFC6083], there are limitations associated with implementing
  SCTP over TLS. For that reason, SCTP over TLS is outside the scope of this document."

Q2 (EDITORIAL):

The text says:

  "Additionally, this document specifies the use of the 'setup' and
   'connection' SDP attributes to establish SCTP associations.  These
   attributes were defined in RFC4145 [RFC4145] for TCP.  This document
   discusses their use with SCTP."

I suggest to remove the last sentence, as it only repeats what is said in the first sentence.

Section 3:
------------

Q3 (EDITORIAL):

The text says:

   "This document defines three new values for the 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."

I would suggest to say:

   "This document defines three new protocol identifier values for the 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."

...because, you use "protocol identifier" terminology later.

Q4 (CLARIFICATION):

The text says:

   "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
   further qualify the application-layer protocol using an fmt
   identifier."

I do understand what you are trying to say, but I think the "qualify" word is a little confusing.

Maybe something like:

   "An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
   further include an fmt value that identifies the application-layer protocol
   carried on top of the SCTP association."

Section 4.1:
--------------

Q5 (TECHNICAL):

The text says:

   "For the payload type assignments the "a=sctpmap:"
   attribute (see Section 5.1) SHOULD be used to map from a port number
   to a media encoding name that identifies the payload format
   transported by the association or the actual application protocol
   running on top of it."

It is very difficult for me to parse this, and figure out the semantics of the sctpmap attribute.

First, what do you mean by "media encoding name"?

Second, when you talk about "application protocol", I assume you refer to the SCTP protocol?

Third, the text say SHOULD. When is it ok to not use the sctpmap attribute?

Section 5:
------------

Q6 (EDITORIAL):

I suggest to rename section 5 to "SDP sctpmap attribute", rename section 5.1 to "General", and add a new section 5.2 named "ABNF".

Q7 (TECHNICAL):

The text says:

   "The sctpmap MUST include the app parameter indicating the application
   running on top of the association."

This is fine if the sctpmap attribute maps to an application. But, what if the sctpmap attribute maps to a "media encoding" or "payload"?

Q8 (EDITORIAL):

The text says:

   "The sctpmap line should also contain the max-message-size parameter
   indicating the maximum message size, in bytes, the endpoint is
   willing to accept."

I suggest to replace "accept" with "receive on the associated SCTP association".

Q9 (EDITORIAL):

The text says:

      "The peer should assume that larger message will be rejected by the
      endpoint, though it is up to the endpoint decide the appropriate
      behaviour."

I suggest to either remove this paragraph, OR replace it with a sentence saying that a peer must/should not send messages bigger than the indicated max value.

Q10 (CLARIFICATION):

The text says:

      "If the parameter is not present, the implementation should provide
      a default, with a suggested value of 64K."

I don't understand "suggested". If the default value is 64K the text should specify (rather than suggest) that.

The same comment applies to the stream parameter, described later in the section.

Q11 (CLARIFICATION):

The text says:

   "It may also provide the stream parameter to specify the initial
   number of incoming streams to be supported by each side of the
   association."

First, to be consistent with previous text, I suggest to replace "It may also provide" with "The sctpmap line may also contain"

Second, I don't understand "incoming streams to be supported by each side of the association". Doesn't each peer indicate the number of streams it is willing to receive? Then, we can always recommend that the peer indicates the same number of streams, if possible.

Q12 (EDITORIAL):

The text that follows the ABNF should be put into a separate "SDP Offer/Answer Procedures" section.

Section 7:
------------

Q13 (EDITORIAL):

Please don't talk about re-INVITEs, or other SIP messages. Simply talk about offers and answers.

Q14 (EDITORIAL):

The text says:

   "It is worth to underline that when using SCTP on top of DTLS,.."

To have consistent terminology, please say "SCTP over DTLS".

That's all for now! :)

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic [mailto:[email-masked]] Puolesta [email-masked]
Lähetetty: 13. helmikuuta 2014 16:21
Vastaanottaja: [email-masked]
Kopio: [email-masked]
Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

        Title           : Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)
        Authors         : Salvatore Loreto
                          Gonzalo Camarillo
        Filename        : draft-ietf-mmusic-sctp-sdp-06.txt
        Pages           : 14
        Date            : 2014-02-13

Abstract:
   SCTP (Stream Control Transmission Protocol) is a transport protocol
   used to establish associations between two endpoints.  This document
   describes how to express media transport over SCTP in SDP (Session
   Description Protocol).  This document defines the 'SCTP', 'SCTP/DTLS'
   and 'DTLS/SCTP' protocol identifiers for SDP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-06

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

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

On 2/13/14 3:57 PM, Christer Holmberg wrote:

> *Q4 (CLARIFICATION):*
> The text says:
>     “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
>     identifier.”
> I do understand what you are trying to say, but I think the “qualify”
> word is a little confusing.
> Maybe something like:
>     “An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
>     carried on top of the SCTP association.”

The clarification would be fine, but both the original and the 
clarification are misleading. The fmt value does not identify an 
application-layer protocol - it identifies a port number. This is 
explained later in section 4.1.

I think this paragraph could just be omitted, or else be replaced by a 
forward reference to section 4.1.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Feb 2014 10:49:07 +1100

Hello,

Some further comments:

Section 11.1 (Editorial) - 11.1 The first paragraph regarding 'sctpmap' 
attribute appears to be repeated.

Section 4.1 (Technical): I see the draft has removed the using using 
"bfcp" and "t38" as values for the "App" field under one m-line. However 
that also removes any hint about multiple a=sctpmaps being used under 
one m-line. For example should there be one a=sctpmap per 'fmt' or could 
there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this 
should be clarified.

General: There was a discussion on the CLUE mailing list whether there 
could be multiple CLUE protocol instances per SCTP association. We 
couldn't identify a use case but couldn't rule it out either. I assume 
this would apply to other "apps" also.
For example something like:
m=application 54111 DTLS/SCTP 5000
c=IN IP4 79.97.215.79
a=sctpmap:5000 clue max-message-size=100000 streams=1
a=sctpmap:5000 clue max-message-size=100000 streams=1
a=sctpmap:5000 clue max-message-size=100000 streams=1
Do we need a "label" to uniquely identify a particular 'app' instance? 
i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol 
uses.
e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1
a=sctpmap:5000 clue max-message-size=100000 streams=1 label2
a=sctpmap:5000 clue max-message-size=100000 streams=1 label3

Regards, Christian

On 14/02/2014 7:57 AM, Christer Holmberg wrote:
> Some additional comments. I do realize some are pure editorial, but 
> rather to write then down in some notes I put them directly into the 
> e-mail J
> *Section 1:*
> *------------*
> *Q1**(EDITORIAL)**:*
> The text says:
> "Since
> *Q2**(EDITORIAL)**:*
> *Section 3:*
> *------------*
> *Q3 (EDITORIAL):*
> “This document defines three new values for the 'proto' field: 'SCTP', 
> 'SCTP/DTLS' and 'DTLS/SCTP'.”
> I would suggest to say:
> “This document defines three new *protocol identifier* values for the 
> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.”
> …because, you use “protocol identifier” terminology later.
> *Q4 (CLARIFICATION):*
> The text says:
> *Section 4.1:*
> *--------------*
> *Q5 (TECHNICAL):*
> “For the payload type assignments the "a=sctpmap:"
> running on top of it.”
> First, what do you mean by “media encoding name”?
> Second, when you talk about “application protocol”, I assume you refer 
> to the SCTP protocol?
> *Section **5**:*
> *------------*
> *Q6 (EDITORIAL):*
> I suggest to rename section 5 to “SDP sctpmap attribute”, rename 
> section 5.1 to “General”, and add a new section 5.2 named “ABNF”.
> *Q7 (TECHNICAL):*
> The text says:
> “The sctpmap MUST include the app parameter indicating the application
> running on top of the association.”
> This is fine if the sctpmap attribute maps to an application. But, 
> what if the sctpmap attribute maps to a “media encoding” or “payload”?
> *Q8 **(EDITORIAL):*
> The text says:
> “The sctpmap line should also contain the max-message-size parameter
> willing to accept.”
> I suggest to replace “accept” with “receive on the associated SCTP 
> association”.
> *Q9 (EDITORIAL):*
> The text says:
> “The peer should assume that larger message will be rejected by the
> behaviour.”
> I suggest to either remove this paragraph, OR replace it with a 
> sentence saying that a peer must/should not send messages bigger than 
> the indicated max value.
> *Q10 (CLARIFICATION):*
> The text says:
> “If the parameter is not present, the implementation should provide
> a default, with a suggested value of 64K.”
> I don’t understand “suggested”. If the default value is 64K the text 
> should specify (rather than suggest) that.
> *Q11 (CLARIFICATION):*
> “It may also provide the stream parameter to specify the initial
> association.”
> First, to be consistent with previous text, I suggest to replace “It 
> may also provide” with “The sctpmap line may also contain”
> Second, I don’t understand “incoming streams to be supported by each 
> side of the association”. Doesn’t each peer indicate the number of 
> streams it is willing to receive? Then, we can always recommend that 
> the peer indicates the same number of streams, if possible.
> *Q12 (EDITORIAL):*
> The text that follows the ABNF should be put into a separate “SDP 
> Offer/Answer Procedures” section.
> *Section 7:*
> *------------*
> *Q13 (EDITORIAL):*
> Please don’t talk about re-INVITEs, or other SIP messages. Simply talk 
> about offers and answers.
> *Q14 (EDITORIAL):*
> The text says:
> “It is worth to underline that when using SCTP on top of DTLS,..”
> To have consistent terminology, please say “SCTP over DTLS”.
> That’s all for now! :)
> Regards,
> Christer
> Title : Stream Control Transmission Protocol (SCTP)-Based Media 
> Transport in the Session Description Protocol (SDP)
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 06:56:40 +0000

Hi Christian,

A comment, based on your example. I don't think we would indicate "clue" in the sctpmap attribute. We would indicate "webrtc-datachannel", in order to be able to interwork with browsers. Then, on that webrtc-datachannel, we would run the CLUE protocol (which we would negotiate e.g. using the DCP, Richard's draft, or some other mechanism).

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 14. helmikuuta 2014 1:49
To: [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments

Hello,

Some further comments:

Section 4.1 (Technical): I see the draft has removed the using using "bfcp" and "t38" as values for the "App" field under one m-line. However that also removes any hint about multiple a=sctpmaps being used under one m-line. For example should there be one a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the m-line? If think this should be clarified.

General: There was a discussion on the CLUE mailing list whether there could be multiple CLUE protocol instances per SCTP association. We couldn't identify a use case but couldn't rule it out either. I assume this would apply to other "apps" also.
For example something like:
m=application 54111 DTLS/SCTP 5000
c=IN IP4 79.97.215.79
a=sctpmap:5000 clue max-message-size=100000 streams=1
a=sctpmap:5000 clue max-message-size=100000 streams=1
a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a "label" to uniquely identify a particular 'app' instance? 
i.e. Similar to the optional label that draft-ietf-rtcweb-data-protocol uses.
e.g. a=sctpmap:5000 clue max-message-size=100000 streams=1 label1
a=sctpmap:5000 clue max-message-size=100000 streams=1 label2
a=sctpmap:5000 clue max-message-size=100000 streams=1 label3

Regards, Christian

On 14/02/2014 7:57 AM, Christer Holmberg wrote:
> e-mail J *Section 1:*
> limitations described in [RFC6083], this document does not make use of 
> TLS over SCTP as described in RFC3436 [RFC3436]."
> "As described in [RFC6083], there are limitations associated with 
> implementing SCTP over TLS. For that reason, SCTP over TLS is outside 
> the scope of this document."
> *Q2**(EDITORIAL)**:*
> The text says:
> "This document defines three new *protocol identifier* values for the 
> 'proto' field: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'."
> .because, you use "protocol identifier" terminology later.
> *Q4 (CLARIFICATION):*
> The text says:
> further include an fmt value that identifies the application-layer 
> protocol carried on top of the SCTP association."
> *Section 4.1:*
> *--------------*
> *Q5 (TECHNICAL):*
> The text says:
> I suggest to rename section 5 to "SDP sctpmap attribute", rename 
> section 5.1 to "General", and add a new section 5.2 named "ABNF".
> *Q7 (TECHNICAL):*
> The text says:
> what if the sctpmap attribute maps to a "media encoding" or "payload"?
> *Q8 **(EDITORIAL):*
> The text says:
> indicating the maximum message size, in bytes, the endpoint is willing 
> to accept."
> "If the parameter is not present, the implementation should provide a 
> default, with a suggested value of 64K."
> I don't understand "suggested". If the default value is 64K the text 
> First, to be consistent with previous text, I suggest to replace "It 
> may also provide" with "The sctpmap line may also contain"
> Second, I don't understand "incoming streams to be supported by each 
> side of the association". Doesn't each peer indicate the number of 
> Aihe: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-06.txt A New 
> Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> Transport in the Session Description Protocol (SDP) Authors : 
> Salvatore Loreto Gonzalo Camarillo Filename : 
> draft-ietf-mmusic-sctp-sdp-06.txt Pages : 14 Date : 2014-02-13
> Abstract:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 08:34:44 +0000

Hi,

> The clarification would be fine, but both the original and the clarification are misleading. The fmt value does not identify an application-layer protocol - it identifies a port number. This is explained later in section 4.1.

Correct. The SDP sctpmap attribute then associates that port number with an SCTP application.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Feb 2014 20:05:31 +1100

Hello Christer,

I'm not assuming the use of webrtc-data channel. The issue would apply 
to any "app" being used multiple times in an SCTP association.

Are you suggesting any time that you want to use multiple instances of 
an "app" that you must use "webrtc-datachannel" even if there are no web 
browsers involved?

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 09:21:27 +0000

Hi Christian,

> I'm not assuming the use of webrtc-data channel. The issue would apply to any "app" being used multiple times in an SCTP association.

Correct. 

My comment was not on multiple apps per SCTP association (which I agree was the main focus of your e-mail), but simply on the example :)

> Are you suggesting any time that you want to use multiple instances of an "app" that you must use "webrtc-datachannel" even if there are no web browsers involved?

No. Only if you want interoperability with a browser.

BUT, even if there are no browser involved, you can still use the webrtc-datachannel if you want. The name should probably be changed to something more generic, though.

Regards,

Christer

On 14/02/2014 5:56 PM, Christer Holmberg wrote:
>> "The sctpmap MUST include the app parameter indicating the 
>> application running on top of the association."

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Feb 2014 12:34:01 -0500

> an "app" that you must use "webrtc-datachannel" even if there are no web

How do we *know* there won't be browsers involved?

IMO we have a problem because the "webrtc-datachannel" suggests it 
necessarily has something to do with webrtc, when it need not. I'd like 
to see that name changed.

The webrtc data channel just adds another layer of abstraction on top of 
SCTP, building bidirectional channels out of pairs of unidirectional 
streams. It also comes with an (optional) associated in-band protocol 
for dynamically establishing new channels over the sctp association, and 
with a defined javascript API that allows it to be used by browsers.

The a=sctpmap attribute is used to negotiate a particular "usage" for 
the entire SCTP association - including all the streams within it. There 
may indeed be cases where an application has a specialized need for 
that. But in many cases it will be particular channels that the 
application needs, and it can use generic mechanisms, such as come with 
"webrtc-datachannel" to manage the individual channels. Certainly that 
is the vision in rtcweb (where the lower layer mechanisms aren't exposed).

In the case of CLUE, we need one channel. It is fine with clue if the 
sctp association also carries other channels that it doesn't know about. 
If we were to use:

a=sctpmap:5000 clue ...

then we would be claiming the entire association for clue. The other 
channels wouldn't be available for anything else. And the clue channel 
wouldn't be accessible from a browser via webrtc.

	Thanks,
	Paul

>> A comment, based on your example. I don't think we would indicate
>> "clue" in the sctpmap attribute. We would indicate
>> "webrtc-datachannel", in order to be able to interwork with browsers.
>> Then, on that webrtc-datachannel, we would run the CLUE protocol
>> (which we would negotiate e.g. using the DCP, Richard's draft, or some
>> other mechanism).
>>
>> Regards,
>>
>> Christer
>>
>> "bfcp" and "t38" as values for the "App" field under one m-line.
>> However that also removes any hint about multiple a=sctpmaps being
>> used under one m-line. For example should there be one a=sctpmap per
>> 'fmt' or could there be zero or more a=sctpmaps per 'fmt' in the
>> m-line? If think this should be clarified.
>>
>> a=sctpmap:5000 clue max-message-size=100000 streams=1 Do we need a
>> "label" to uniquely identify a particular 'app' instance?

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 14 Feb 2014 18:40:03 +0000

Would agree to changing webrtc-data channel to something more generic.

Keith

> From: mmusic [mailto:[email-masked]] On Behalf Of 
> Christer Holmberg
> Sent: 14 February 2014 09:21
> To: Christian Groves; [email-masked]
> Subject: Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-sctp-sdp-06.txt - Christer's initial comments
> 
> Hi Christian,
> 
> > I'm not assuming the use of webrtc-data channel. The issue 
> would apply to any "app" being used multiple times in an SCTP 
> association.
> 
> Correct. 
> 
> My comment was not on multiple apps per SCTP association 
> (which I agree was the main focus of your e-mail), but simply 
> on the example :)
> 
> > Are you suggesting any time that you want to use multiple 
> instances of an "app" that you must use "webrtc-datachannel" 
> even if there are no web browsers involved?
> 
> BUT, even if there are no browser involved, you can still use 
> the webrtc-datachannel if you want. The name should probably 
> be changed to something more generic, though.
> 
> Regards,
> 
> Christer
> 
> 
> > A comment, based on your example. I don't think we would 
> indicate "clue" in the sctpmap attribute. We would indicate 
> "webrtc-datachannel", in order to be able to interwork with 
> browsers. Then, on that webrtc-datachannel, we would run the 
> CLUE protocol (which we would negotiate e.g. using the DCP, 
> Richard's draft, or some other mechanism).
> >
> > Regards,
> >
> > Christer
> >
> > From: mmusic [mailto:[email-masked]] On Behalf Of 
> Christian 
> > Groves
> > Subject: Re: [MMUSIC] I-D Action: 
> draft-ietf-mmusic-sctp-sdp-06.txt - 
> > Christer's initial comments
> >
> > Hello,
> >
> > Some further comments:
> >
> > Section 4.1 (Technical): I see the draft has removed the 
> using using "bfcp" and "t38" as values for the "App" field 
> under one m-line. However that also removes any hint about 
> multiple a=sctpmaps being used under one m-line. For example 
> should there be one a=sctpmap per 'fmt' or could there be 
> zero or more a=sctpmaps per 'fmt' in the m-line? If think 
> this should be clarified.
> >
> > General: There was a discussion on the CLUE mailing list 
> whether there could be multiple CLUE protocol instances per 
> SCTP association. We couldn't identify a use case but 
> couldn't rule it out either. I assume this would apply to 
> other "apps" also.
> a=sctpmap:5000 
> > clue max-message-size=100000 streams=1 a=sctpmap:5000 clue 
> > max-message-size=100000 streams=1 Do we need a "label" to 
> uniquely identify a particular 'app' instance?
> >> I gave some comments off-line to Salvatore, which have 
> been addressed 
> >> in the new version.
> >> I do understand what you are trying to say, but I think 
> the "qualify"
> >> The same comment applies to the stream parameter, 
> described later in 
> >> the section.
> >> *Q11 (CLARIFICATION):*
> >> The text says:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Feb 2014 14:42:22 -0500

> Would agree to changing webrtc-data channel to something more generic.

A couple of possibilities that would WFM:

- sctp-data-channel (or sctp-datachannel)
- data-channel (or datachannel)

The latter is appealing, but may be *too* generic.

	Thanks,
	Paul

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 14 Feb 2014 21:07:47 +0000

> The latter is appealing, but may be *too* generic.
[Raju] I am ok with either options. 
However, "sctp-datachannel" probably more appropriate as for external negotiation 
point of view, datachannel provides a bidrectional communication channel with 
one SCTP stream, using same stream id, in both the directions. "sctp-datachannel"
name captures that well.

Regards
Raju

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Feb 2014 02:10:05 +0000

I'd be happy with either.

I've just submitted draft-ejzak-mmusic-data-channel-sdpneg using the term "data channel" in the text, but the SDP is still aligned with the sctp-sdp draft.

Keith 

> Paul Kyzivat
> Sent: 14 February 2014 19:42
> To: [email-masked]
> >> Holmberg
> >> My comment was not on multiple apps per SCTP association (which I 
> >> agree was the main focus of your e-mail), but simply on 
> the example 
> >> :)
> >>
> >> BUT, even if there are no browser involved, you can still use the 
> >> webrtc-datachannel if you want. The name should probably 
> be changed 
> >> (which we would negotiate e.g. using the DCP, Richard's draft, or 
> >> some other mechanism).
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> under one 
> >> m-line. However that also removes any hint about multiple 
> a=sctpmaps 
> >> being used under one m-line. For example should there be one 
> >> a=sctpmap per 'fmt' or could there be zero or more a=sctpmaps per 
> >> 'fmt' in the m-line? If think this should be clarified.
> >>>
> >> whether there could be multiple CLUE protocol instances per SCTP 
> >> association. We couldn't identify a use case but couldn't 
> rule it out 
> >> either. I assume this would apply to other "apps" also.
> >>>> I suggest to remove the last sentence, as it only 
> repeats what is 
> >>>> said in the first sentence.
> >>>> *Section 3:*
> >>>> *------------*
> >>>> *Q3 (EDITORIAL):*
> >>>> The text says:
> >>>> I suggest to replace "accept" with "receive on the 
> associated SCTP 
> >>>> association".
> >>>> *Q9 (EDITORIAL):*
> >>>> The text says:
> >>>> The text that follows the ABNF should be put into a 
> separate "SDP 
> >>>> Offer/Answer Procedures" section.
> >>>> *Section 7:*
> >>>> *------------*
> >>>> *Q13 (EDITORIAL):*
> >>>> Please don't talk about re-INVITEs, or other SIP 
> messages. Simply 
> >>>> talk about offers and answers.
> >>>> *Q14 (EDITORIAL):*
> >>>> The text says: