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

Christer Holmberg <> Wed, 01 October 2014 11:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FAD01A0296 for <>; Wed, 1 Oct 2014 04:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rLkqR7GJP5nJ for <>; Wed, 1 Oct 2014 04:43:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BF121A0324 for <>; Wed, 1 Oct 2014 04:43:07 -0700 (PDT)
X-AuditID: c1b4fb3a-f79da6d0000008c7-9e-542be8c9dfef
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 79.38.02247.9C8EB245; Wed, 1 Oct 2014 13:43:05 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 1 Oct 2014 13:43:05 +0200
From: Christer Holmberg <>
To: Christian Groves <>, Salvatore Loreto <>
Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg
Date: Wed, 1 Oct 2014 11:43:04 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7JF9ohBv1tGhZf3jeyWExd/pjF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4MqY0RxW8EOp4sa/2AbG/TJdjJwcEgImEic+ f2OFsMUkLtxbz9bFyMUhJHCUUeLdkuXMEM5iRom+861ADgcHm4CFRPc/bZAGEYEMidYz99hA bGYBTYkndw4wgtjCAj4Sf04+ZIeo8ZVY1XuVEcJ2k1h2/D0jyBgWARWJ2/+LQcK8QCUbXn5n gVv1/sk1FpAEp4COxKbbf8BsRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5+B8ryHwJ AUWJ5f1yEOU6Egt2f4I6U1ti2cLXzBB7BSVOznzCMoFRbBaSqbOQtMxC0jILScsCRpZVjKLF qcXFuelGRnqpRZnJxcX5eXp5qSWbGIGRc3DLb6sdjAefOx5iFOBgVOLhTZihHSLEmlhWXJl7 iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgtLUs9P+a+OSrT+3rRMtlF /s0TeW6yXGg79eCx7oQFK5bsnVzFfz1Ea7by+uIaoR/zt/6u2HdhXeLtz6qOAdy2DAUrJdTP /GRMf5q5VvYJy+HJMZsqnb83nI00LV79Y/cipeSOuoc551mVuN58jVSLDYq2e2WuwyHfPSlk l+a5lgurJ36s7DiqxFKckWioxVxUnAgAQlycG30CAAA=
Cc: "<>" <>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Oct 2014 11:43:09 -0000


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).



-----Original Message-----
From: mmusic [] On Behalf Of Christian Groves
Sent: 1. lokakuuta 2014 10:45
To: Salvatore Loreto
Cc: <>
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 <> 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" (
> <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 and in
> the WebSocket Subprotocol Name Registry is used to populate the protocol field in the
> protocol field in
> </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