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

[Christian Groves <[e-mail]>]

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

On 1/10/2014 10:45 PM, Christer Holmberg wrote:
> 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:[e-mail]]
> Sent: 1. lokakuuta 2014 15:43
> To: Christer Holmberg; Christian Groves; Salvatore Loreto
> Cc: <[e-mail]>
> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
>
>> 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.
> 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:[e-mail]] On Behalf Of Christer Holmberg
> Sent: Mittwoch, 1. Oktober 2014 13:43
> To: Christian Groves; Salvatore Loreto
> Cc: <[e-mail]>
> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
>
> 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:[e-mail]] On Behalf Of Christian Groves
> Sent: 1. lokakuuta 2014 10:45
> To: Salvatore Loreto
> Cc: <[e-mail]>
> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
>
> Hello Salvatore,
>
> Thanks for the replies. Please see some comments below.
>
> 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
>>
>> On Sep 30, 2014, at 3:48 PM, Christian Groves <[e-mail]> 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>
> [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..
>>>> 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>
> [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?
> [CNG] I think you skipped this?
>
>>>> 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>
> [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?
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>