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

Christian Groves <> Wed, 01 October 2014 07:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFC1B1A8828 for <>; Wed, 1 Oct 2014 00:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LnUbcHEZevNJ for <>; Wed, 1 Oct 2014 00:45:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFE4F1A0024 for <>; Wed, 1 Oct 2014 00:45:01 -0700 (PDT)
Received: from ([]:58486 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1XZEZR-00054r-Sz; Wed, 01 Oct 2014 17:43:34 +1000
Message-ID: <>
Date: Wed, 01 Oct 2014 17:44:55 +1000
From: Christian Groves <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Salvatore Loreto <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 07:45:05 -0000

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?