Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

From: Salvatore Loreto <[email-masked]>
Date: Wed, 1 Oct 2014 07:29:32 +0000

Hi Christian,

thanks a lot for reading and reviewing the draft 
see more in line

On Sep 30, 2014, at 3:48 PM, Christian Groves <[email-masked]> wrote:

> I seemed to have got cut and paste happy in 1) below. The "1*(SP sctp-fmt)" should only apply to "DTLS/SCTP".
> 
> Christian
> 
> On 30/09/2014 10:12 PM, Christian Groves wrote:
>> Hello Salvatore,
>> 
>> There seems to be several issues with the updated syntax:
>> 
>> 1) Cl.4.1 Media Description: With the updated syntax the ability to have more than one usage of the SCTP association has been lost as "sctp-fmt" is a single value.

<Sal>
there have been several discussion about the ability to have more than one usage of the SCTP association, 
and has been agreed not to allow it.
So each 'm' line describes a single SCTP association;  each association has only one single specify usage.
</Sal>

>> Also "space" should be SP to be consistent with RFC4566.

<Sal>
thanks, you are right. I will correct it in my private copy, so it will appear correct in the next version. 
</Sal>

>> 
>> To address these I suggest the following update:
>> e.g.
>> sctp-m-line = %x6d "=" ("application" space sctp-port space "SCTP" 1*(SP sctp-fmt) CRLF) / ("application" space sctp-port space "SCTP/DTLS" 1*(SP sctp-fmt) CRLF) / ("application" space udp-port space "DTLS/SCTP" 1*(SP sctp-fmt) CRLF) sctp-port = port
>> 
>> sctp-fmt = association-usage
>> 
>> association-usage = token
>> 
>> 2) Cl. 4.1.1 sctp-port: The syntax for sctp-port indicates the dual use of "=", i.e.
>> 
>> sctp-port-attr = "a=sctp-port=" portnumber
>> port-number = port
>> 
>> That doesn't appear to be consistent with the example in clause 4 which has:
>> a=sctp-port 4060
>> 
>> To match that the syntax needs to be updated, something like:
>> 
>> sctp-port-attr = "a=sctp-port" SP portnumber
>> port-number = port
>> I'm not sure why "portnumber" is used when "port" is commonly used in clause 4.1?
>> 
>> The syntax could be simplified to:
>> sctp-port-attr = "a=sctp-port" SP port

<Sal>
good suggestion. I am including it in my private copy. 
</Sal>

>> 
>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from the syntax between association-usage and max-message-size.
>> 
>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size]
>> 
>> should be:
>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size]
>> 
>> The current syntax allows an fmtp usage with no max-message-size parameter, e.g. "a=fmtp:bfcp". Should this be allowed?

<Sal>
this has been discussed back in April or May. It has been decided that the max-message-size parameter is optional.
In the case it is not present the default value is 64K
</Sal>

>> 
>> 4) Cl.4.1.2: The last sentence of the 1st paragraph and the first sentence of the second paragraph appears to be a repeat.

<Sal>
got it. 
</Sal>

>> 
>> 5) Cl.4.1.2: "If the parameter is not present, the implementation should provide a
>> default, with a suggested value of 64K." Is this 64,000 or is 65,535 bytes?
>> 
>> 6) Cl.4, 4.1 and 10 refer to the <fmt> sub-field. These should be updated to refer to the <sctp-fmt> field.

<Sal>
got it. 
</Sal>

>> 
>> 7) Cl.10: How will this registry relate to the “WebSocket Subprotocol Name Registry” (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)?

<Sal>
It is not related. The 'association-usage' specifies how the SCTP association will be used.
For example in the case of webrtc-datachannel value it would indicate how to pair certain streams,
how to consider specific stream etc.
as described in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in 
http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/

the WebSocket Subprotocol Name Registry is used to populate the protocol field in the
protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5

</Sal>

>> 
>> 8) Cl.8.2: What's the significance of the the "*" in the examples in terms of "association usage"?

<Sal>
good catch I will clarify it.
</Sal>

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 01 Oct 2014 17:44:55 +1000

Hello Salvatore,

Thanks for the replies. Please see some comments below.

Regards, Christian

> So each 'm' line describes a single SCTP association;  each association has only one single specify usage.

[CNG] So how would I specify in SDP a scenario where BFCP uses a 
DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they 
both use the same DTLS connection? Are these to be separate m-lines?
> ..snip..
[CNG] I agree that the max-message-size parameter is optional, in that 
case an endpoint wouldn't specify the whole a=ftmp: line. It seems 
strange to allow the endpoint to specify half a line?

>>> default, with a suggested value of 64K." Is this 64,000 or is 65,535 bytes?
[CNG] I think you skipped this?

> protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5
[CNG] So if I use the SCTP association for "bfcp" then i'd need to 
document this in the new registry associated with the draft? and if I 
then used "bfcp" for webrtc-datachannel then i'd need to update the 
websocket registry. Two places for the same protocol?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Oct 2014 11:43:04 +0000

Hi,

I think we need to be careful with the terminology.

As far as I understand, the m- lines describes an SCTP connection - not an SCTP association - and the sctp-fmt defines the usage of that SCTP connection.

Depending on the usage, there may then be multiple SCTP associations - for example as in the case of a data-channel connection usage, where the number of SCTP associations will depend on the number of data channels.

So, if you want to use BFCP and MSRP, my understanding is that you would need two m- lines (unless, of course, you transport BFCP and MSRP within data channels).

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 1. lokakuuta 2014 10:45
To: Salvatore Loreto
Cc: <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Hello Salvatore,

Regards, Christian

On 1/10/2014 5:29 PM, Salvatore Loreto wrote:
> Hi Christian,
>
> thanks a lot for reading and reviewing the draft see more in line
>
> there have been several discussion about the ability to have more than 
> one usage of the SCTP association, and has been agreed not to allow it.

[CNG] So how would I specify in SDP a scenario where BFCP uses a DTLS/SCTP association and MSRP uses a DTLS/SCTP association where they both use the same DTLS connection? Are these to be separate m-lines?

>>> 7) Cl.10: How will this registry relate to the "WebSocket Subprotocol Name Registry" (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)?
> <Sal>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 1 Oct 2014 12:42:44 +0000

> As far as I understand, the m- lines describes an SCTP connection - not an SCTP association - and the sctp-fmt defines the usage of that SCTP connection.

Christer, 
there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather SCTP association, SCTP path, SCTP stream.

If you are refering implicitly to the OSI concept of a (N)-connection (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the IETF SCTP association in my understanding.

Regards,
Albrecht

PS
Perhaps you mean sth like, ".. the m- lines describes an IP transport connection for SCTP, which relates to an SCTP association ..."

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Mittwoch, 1. Oktober 2014 13:43
To: Christian Groves; Salvatore Loreto
Cc: <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Hi,

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 1. lokakuuta 2014 10:45
To: Salvatore Loreto
Cc: <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Hello Salvatore,

Regards, Christian

> In the case it is not present the default value is 64K </Sal>
[CNG] I agree that the max-message-size parameter is optional, in that case an endpoint wouldn't specify the whole a=ftmp: line. It seems strange to allow the endpoint to specify half a line?

>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation 
>>> should provide a default, with a suggested value of 64K." Is this 64,000 or is 65,535 bytes?

> For example in the case of webrtc-datachannel value it would indicate 
> how to pair certain streams, how to consider specific stream etc.
> as described in 
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and in 
> the WebSocket Subprotocol Name Registry is used to populate the 
> protocol field in the protocol field in 
> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section
> -5
>
> </Sal>
[CNG] So if I use the SCTP association for "bfcp" then i'd need to document this in the new registry associated with the draft? and if I then used "bfcp" for webrtc-datachannel then i'd need to update the websocket registry. Two places for the same protocol?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Oct 2014 12:45:56 +0000

My mistake: I meant SCTP association, which then can contains multiple SCTP streams.

Sorry for the confusion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]] 
Sent: 1. lokakuuta 2014 15:43
To: Christer Holmberg; Christian Groves; Salvatore Loreto
Cc: <[email-masked]>
Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Christer,

Regards,
Albrecht

PS

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Mittwoch, 1. Oktober 2014 13:43
To: Christian Groves; Salvatore Loreto
Cc: <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Hi,

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 1. lokakuuta 2014 10:45
To: Salvatore Loreto
Cc: <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Hello Salvatore,

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 10:05:33 -0400

> sctp-port-attr = "a=sctp-port" SP port

The above is not a valid syntax for an SDP attribute. The value of an 
attribute must be separated from the name by a ":".

Please take a look at draft-ietf-mmusic-rfc4566bis-12 for more on this.

That includes my proposal for cleaning up how attributes are defined. I 
suggest using that style in this draft.

In a similar vein, I suggest that when defining the new fmtp usage, just 
provide the new syntax for format-specific-params, not for the whole 
attribute.

(While writing this I'm realizing that the new text defining the fmtp 
parameter in 4566bis should specify *how* this should be done.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 10:14:09 -0400

On 10/1/14 3:44 AM, Christian Groves wrote:

>> So each 'm' line describes a single SCTP association;  each
>> association has only one single specify usage.
>> </Sal>
>

To have two different SCTP associations over the same DTLS connection, 
they would have to be distinguished by sctp-port. To achieve that you 
could write two m-lines. They would share the same ip address and port, 
and would have different "a=sctp-port" lines. Then they would have to be 
bundled.

Doing that would require extending the definition of bundle to cover 
that case. (There is no *technical* problem in doing this.)

OTOH, in principle they don't need their own SCTP association. AFAIK 
they each only use one sctp stream-pair (channel). If they could agree 
on how to choose channels then they could share an SCTP association. 
That is where draft-ejzak... comes in.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 10:20:17 -0400

> protocol field in https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5

I agree.

The association-usage is describing how the association as a whole, 
including all of the streams, is used/managed.

It doesn't provide a means to separately describe how individual streams 
within it are to be used. If that is to be done in SDP then something 
like draft-ejzak... would be required.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 02 Oct 2014 08:40:09 +1000

Hello Paul,

I agree, good idea to use the new style.

Regards, Christian

On 2/10/2014 12:05 AM, Paul Kyzivat wrote:
> That includes my proposal for cleaning up how attributes are defined. 
> I suggest using that style in this draft.
>
> In a similar vein, I suggest that when defining the new fmtp usage, 
> just provide the new syntax for format-specific-params, not for the 
> whole attribute.
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 02 Oct 2014 08:46:42 +1000

Hello Christer and Salvatore,

I'm happy to use to m-lines. I think it would be good to have something 
in the draft describing the usage of multiple DTLS/SCTP m-lines (with 
the same port) so that its clear that's the intention.

Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 19:04:53 -0400

> the same port) so that its clear that's the intention.

The thing is - it would be bad to give an example using bundle while 
there is no definition of how bundle works for that. (It is not included 
in the bundle spec.)

That would mean adding the interaction with bundle into this draft, or 
in a new draft. While that is possible, do we want to take that on now?

This would be a good time for Christer to chime in. :-)

	Thanks,
	Paul

>> From: Schwarz, Albrecht (Albrecht)
>> [mailto:[email-masked]]
>>> As far as I understand, the m- lines describes an SCTP connection -
>>> not an SCTP association - and the sctp-fmt defines the usage of that
>>> SCTP connection.
>> Christer,
>> there isn't any concept of an "SCTP connection" (see RFC 4960)! Rather
>> SCTP association, SCTP path, SCTP stream.
>>
>> If you are refering implicitly to the OSI concept of a (N)-connection
>> (ITU-T X.200), then an OSI (SCTP)-connection would be mapped to the
>> IETF SCTP association in my understanding.
>>
>> Regards,
>> Albrecht
>>
>> PS
>> Perhaps you mean sth like, ".. the m- lines describes an IP transport
>> connection for SCTP, which relates to an SCTP association ..."
>>
>>
>> As far as I understand, the m- lines describes an SCTP connection -
>> not an SCTP association - and the sctp-fmt defines the usage of that
>> SCTP connection.
>>
>> Depending on the usage, there may then be multiple SCTP associations -
>> for example as in the case of a data-channel connection usage, where
>> the number of SCTP associations will depend on the number of data
>> channels.
>>
>> So, if you want to use BFCP and MSRP, my understanding is that you
>> would need two m- lines (unless, of course, you transport BFCP and
>> MSRP within data channels).
>>
>> Regards,
>>
>> Christer
>>
>>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP
>>>> sctp-fmt)" should only apply to "DTLS/SCTP".
>>>>
>>>> Christian
>>>>
>>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability to
>>>>> have more than one usage of the SCTP association has been lost as
>>>>> "sctp-fmt" is a single value.
>>> <Sal>
>>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from
>>>>> the syntax between association-usage and max-message-size.
>>>>>
>>>>> The current syntax allows an fmtp usage with no max-message-size
>>>>> parameter, e.g. "a=fmtp:bfcp". Should this be allowed?
>>> <Sal>
>>> this has been discussed back in April or May. It has been decided
>>> that the max-message-size parameter is optional.
>>>>> 7) Cl.10: How will this registry relate to the "WebSocket
>>>>> Subprotocol Name Registry"
>>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)?
>>>>>
>>> <Sal>

---

From: Christian Groves <[email-masked]>
Date: Thu, 02 Oct 2014 09:24:44 +1000

Hello,

On 2/10/2014 12:20 AM, Paul Kyzivat wrote:
>>>> 7) Cl.10: How will this registry relate to the “WebSocket 
>>>> Subprotocol Name Registry” 
>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-5
>
> I agree.
>
> It doesn't provide a means to separately describe how individual 
> streams within it are to be used. If that is to be done in SDP then 
> something like draft-ejzak... would be required.

[CNG] My comments on this are in the context of the note in cl.10 of the 
draft: "[Note] TBD whether a new registry is necessary to register the 
different possible "association-usage" values."

I'm just thinking of the specification effort to introduce new 
sub-protocols. Consider a gateway scenario where I have a DTLS/SCTP 
association running datachannel with bfcp and on the other side a SCTP 
association running BFCP. In either scenario bfcp runs in an SCTP 
stream. However it means to introduce BFCP (and any other protocol) we 
have to update two registries with essentially the same value.

If we do have a new registry just for "association-usage" it would be 
good to have some text with regards to a template of information that 
someone registering the information would need to consider. i.e. what 
information would someone need to specify to registry BFCP as opposed to 
just registering BFCP as websocket sub-protocol.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 02 Oct 2014 09:57:02 +1000

What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00?

It has expired and is based on the old SDP SCTP syntax. Particularly the 
example in cl.4:

    m=application 54111 DTLS/SCTP 5000 5001 5002
    c=IN IP4 79.97.215.79
    a=sctpmap:5000 webrtc-datachannel
    a=sctpmap:5001 bfcp
    a=sctpmap:5002 t38

Wouldn't apply if we're saying to use multiple m-lines.

I guess cl.5.1.1.3 would use the same Websocket subprotocol name 
registry as data channel does?

Regards, Christian

On 2/10/2014 12:14 AM, Paul Kyzivat wrote:
> could write two m-lines. They would share the same ip address and 
> port, and would have different "a=sctp-port" lines. Then they would 
> have to be bundled.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 21:36:56 -0400

> What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00?

I don't know the status. The thought Keith Drage had indicated that he 
was picking up responsibility for it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Oct 2014 21:49:06 -0400

> different possible "association-usage" values."

Well, the alternatives to establishing a new registry are:

- use an existing registry
- define all the values directly in the draft.
   (This will then require a revision to define new ones.)

I don't see how we could use an existing one, since the semantics of 
what are being defined are entirely new. (The websocket protocol 
registry isn't right for this. It defines a *protocols* that run over a 
websocket, or at least something similar in nature to a websocket. What 
we are defining here isn't a protocol in the same sense - it is a 
*convention* for how to use an SCTP association including the many 
streams it contains. Each of those streams may have its own protocol.)

We could live without any registry *if* we think there is very low 
likelihood of needing to define new values. But I think it is already 
clear that is a bad assumption.

> just registering BFCP as websocket sub-protocol.

One approach would be to define one new association-usage (beyond the 
one for rtcweb), that says the usages of the individual streams will be 
negotiated with SDP, using something like draft-ejzak. Then go ahead and 
finish that draft.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Oct 2014 09:39:20 +0000

Hi,

>> I'm happy to use to m-lines. I think it would be good to have 
>> something in the draft describing the usage of multiple DTLS/SCTP 
>> m-lines (with the same port) so that its clear that's the intention.
>
> The thing is - it would be bad to give an example using bundle while there is no definition of how bundle works for that. (It is not included in the bundle spec.)
>
> That would mean adding the interaction with bundle into this draft, or in a new draft. While that is possible, do we want to take that on now?
>

As Paul said, BUNDLE does not specify the usage of multiple DTLS m- lines within a BUNDLE group, and explicitly says that such usage would have to be defined in another specification.

Personally, I'd be quite surprised if people started to transport BFCP, MSRP etc over DTLS/SCTP. People haven't used SCTP for that in the past, so why would they suddenly start now?

I think DTLS/SCTP is going to be used mainly for data channel usage, and one can then define data channels to transport whatever (including BFCP and MSRP).

Regards,

Christer

>> there isn't any concept of an "SCTP connection" (see RFC 4960)! 
>> Rather SCTP association, SCTP path, SCTP stream.
>>
>> Depending on the usage, there may then be multiple SCTP associations 
>> - for example as in the case of a data-channel connection usage, 
>> where the number of SCTP associations will depend on the number of 
>> data channels.
>>
>>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability 
>>>>> to have more than one usage of the SCTP association has been lost 
>>>>> as "sctp-fmt" is a single value.
>>> <Sal>
>>> there have been several discussion about the ability to have more 
>>> than one usage of the SCTP association, and has been agreed not to allow it.
>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where 
>> they both use the same DTLS connection? Are these to be separate m-lines?
>>>
>>> ..snip..
>> [CNG] I agree that the max-message-size parameter is optional, in 
>> that case an endpoint wouldn't specify the whole a=ftmp: line. It 
>> seems strange to allow the endpoint to specify half a line?
>>
>>> For example in the case of webrtc-datachannel value it would 
>>> indicate how to pair certain streams, how to consider specific stream etc.
>>> as described in
>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and 
>>> in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Oct 2014 11:59:51 +0000

Hi,

Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate the usage of the SCTP association.

It is assumed that the usage of the SCTP association is data channel, and the draft defines a mechanism to negotiate data channels on that SCTP association.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 2. lokakuuta 2014 4:37
To: [email-masked]
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

> What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00?

I don't know the status. The thought Keith Drage had indicated that he was picking up responsibility for it.

	Thanks,
	Paul

> It has expired and is based on the old SDP SCTP syntax. Particularly 
> the example in cl.4:
>
>> To have two different SCTP associations over the same DTLS 
>> connection, they would have to be distinguished by sctp-port. To 
>> achieve that you could write two m-lines. They would share the same 
>> ip address and port, and would have different "a=sctp-port" lines. 
>> Then they would have to be bundled.
>>
>> they each only use one sctp stream-pair (channel). If they could 
>> agree on how to choose channels then they could share an SCTP association.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Oct 2014 12:16:28 +0000

Hi,

>   (This will then require a revision to define new ones.)

I think we should have a registry (I don't care whether it's new, or an existing one).

> I don't see how we could use an existing one, since the semantics of what are being defined are entirely 
> new. (The websocket protocol registry isn't right for this. It defines a *protocols* that run over a websocket, or 
> at least something similar in nature to a websocket. What we are defining here isn't a protocol in the same sense - it is a
> *convention* for how to use an SCTP association including the many streams it contains. Each of those streams may have its 
> own protocol.)

I agree with that.

Then, IF someone e.g. would like to run RTP over SCTP, I guess they would need a new m= line protocol value. " DTLS/SCTP/RTP/AVP", or something like that...

> We could live without any registry *if* we think there is very low likelihood of needing to define new values. But I think it is already clear that is a bad assumption.

Let's also keep in mind that, while we have been discussing mostly "DTLS/SCTP", the draft also defines "SCTP" and "SCTP/DTLS". Hopefully we could use a single registry for all of them...

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2014 14:24:16 -0400

> It is assumed that the usage of the SCTP association is data channel, and the draft defines a mechanism to negotiate data channels on that SCTP association.

The purpose is to negotiate the use of channels, which is almost the 
same as negotiating the use of individual SCTP streams within an SCTP 
association.

The reason it was tied to data channels was so that it would be usable 
from webrtc browser apps.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Oct 2014 18:31:56 +0000

Hi,

>> It is assumed that the usage of the SCTP association is data channel, and the draft defines a 
>> mechanism to negotiate data channels on that SCTP association.
>
> The purpose is to negotiate the use of channels, which is almost the same as negotiating the use of > individual SCTP streams within an SCTP association.

Correct. But, it is not used to negotiate the SCTP association usage, which I think is what Christian has been talking about. It assumes that the SCTP association is used for data channels.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2014 14:55:38 -0400

> Correct. But, it is not used to negotiate the SCTP association usage, which I think is what Christian has been talking about. It assumes that the SCTP association is used for data channels.

Yes. But for the most part Christian is talking about stream/channel 
usages that have not yet been defined. When the are defined, they could 
be done so using channels or something else. The main constraint here is 
enabling this stuff to work with webrtc.

I think that constraint is effectively forcing the use of the data 
channel association usage.

And this is all hypothetical because draft-ejak is far from complete. 
So, if it goes forward at all it may end up different from what it is now.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2014 14:52:49 +1100

Hello Christer,

> Personally, I'd be quite surprised if people started to transport BFCP, MSRP etc over DTLS/SCTP. People haven't used SCTP for that in the past, so why would they suddenly start now?
[CNG] It seems now people are being forced to use to SCTP due to 
interoperation with WebRTC. They may want to run over a secure 
association etc. There will be new protocols that will be defined.
> I think DTLS/SCTP is going to be used mainly for data channel usage, and one can then define data channels to transport whatever (including BFCP and MSRP).
[CNG] Mainly or only? If its mainly then there's a possibility to run 
something else in another SCTP association. If this "something else" 
runs in across a separate SCTP association on a seperate DTLS port then 
its no issue. If this "something else" is a separate SCTP association on 
the same DTLS port then it is an issue. There has been a suggestion to 
use bundle, but bundle doesn't cover this. I think the draft should 
offer some guidance or at least highlight the issues with respect to this.

With regards to the data channels if I do as you say and use 
datachannels for bfcp and msrp in the one DTLS/SCTP association. How 
would I go about signalling that via SDP? Do I use the same method as 
CLUE and define a group for each of these? Do I use ejzak? Do I use 
both? CLUE decided that it didn't need to consider other protocols. 
However shouldn't the scope of the mmusic work be to look at the 
scenarios where you could have multiple protocols?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2014 14:54:33 +1100

On 3/10/2014 4:55 AM, Paul Kyzivat wrote:
>>>> Keep in mind that the purpose of 
>>>> draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate
>>>> the usage of the SCTP association.
>>>>
>>> same as negotiating the use of > individual SCTP streams within an 
>>> SCTP association.
>>
>> Correct. But, it is not used to negotiate the SCTP association usage, 
>> which I think is what Christian has been talking about. It assumes 
>> that the SCTP association is used for data channels.
>
> usages that have not yet been defined. When the are defined, they 
> could be done so using channels or something else. The main constraint 
> here is enabling this stuff to work with webrtc.
>

[CNG] I've been talking about both, negotiating the SCTP association 
usage and/or the usage of the individual SCTP streams/data channels. 
Paul is correct in that I'm thinking of usages/protocols that have not 
yet been defined. I'm trying to understand the process on how these 
would be added in the future to situations where data channel is used 
and situations where data channel is not used.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 07:09:41 +0000

Hi,

>>> there is no definition of how bundle works for that. (It is not 
>>> included in the bundle spec.)
>>>
> [CNG] It seems now people are being forced to use to SCTP due to interoperation with WebRTC. They may want to run over a secure association etc. There will be new protocols that will be defined.

Currently WebRTC only defines the usage of SCTP for the data channel.

> [CNG] Mainly or only? If its mainly then there's a possibility to run something else in another SCTP association. If this "something else" 
> runs in across a separate SCTP association on a seperate DTLS port then its no issue. If this "something else" is a separate SCTP association on the same DTLS port then it is an issue. 
> There has been a suggestion to use bundle, but bundle doesn't cover this. 

The core BUNDLE spec doesn't cover it, but someone can write an extension which defines how it is done. 

> I think the draft should offer some guidance or at least highlight the issues with respect to this.

I do agree that some words about why only a single SCTP association usage is allowed would be good.

>With regards to the data channels if I do as you say and use datachannels for bfcp and msrp in the one DTLS/SCTP association. How would I go about signalling that via SDP?
>
>Do I use the same method as CLUE and define a group for each of these? Do I use ejzak? Do I use both? CLUE decided that it didn't need to consider other protocols. 
>However shouldn't the scope of the mmusic work be to look at the scenarios where you could have multiple protocols?

Currently, there is no generic way to signal the datachannel usage in SDP. The ejzak draft defines SDP attributes for doing that, but the draft hasn't taken off. 

Regards,

Christer

>>>> not an SCTP association - and the sctp-fmt defines the usage of 
>>>> that SCTP connection.
>>> Christer,
>>> If you are refering implicitly to the OSI concept of a 
>>> (N)-connection (ITU-T X.200), then an OSI (SCTP)-connection would be 
>>> mapped to the IETF SCTP association in my understanding.
>>>
>>> Regards,
>>> Albrecht
>>>
>>> PS
>>> Perhaps you mean sth like, ".. the m- lines describes an IP 
>>> transport connection for SCTP, which relates to an SCTP association ..."
>>>
>>>
>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#sect
>>>> i
>>>> on
>>>> -5
>>>>
>>>> </Sal>
>>> document this in the new registry associated with the draft? and if 
>>> I then used "bfcp" for webrtc-datachannel then i'd need to update 
>>> the websocket registry. Two places for the same protocol?
>>>
>>>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 6 Oct 2014 11:13:56 +0000

> Currently, there is no generic way to signal the datachannel usage in SDP.
> The ejzak draft defines SDP attributes for doing that, but the draft hasn't
> taken off.
[Raju] Right, ejzak draft meant to fill that gap. The plan is to propose the updated ejzak draft to MMUSIC.

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 11:33:01 +0000

Hi,

>> The ejzak draft defines SDP attributes for doing that, but the draft 
>> hasn't taken off.

Any estimate on when that will happen? It has been "planned" for quite a while... :)

Regards,

Christer