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

Paul Kyzivat <> Thu, 02 October 2014 01:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED9501A888A for <>; Wed, 1 Oct 2014 18:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZlbYjLpvBeYg for <>; Wed, 1 Oct 2014 18:49:08 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 137F11A888C for <>; Wed, 1 Oct 2014 18:49:07 -0700 (PDT)
Received: from ([]) by with comcast id y1ou1o0035FMDhs011p7iu; Thu, 02 Oct 2014 01:49:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id y1p61o00M3Ge9ey011p6az; Thu, 02 Oct 2014 01:49:07 +0000
Message-ID: <>
Date: Wed, 01 Oct 2014 21:49:06 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1412214547; bh=iBMowgfZV1M2CbaMvyMojtyNY7tNdGie/r9k7VbnRtw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HGYwFeqWxIRovuc/9ooT0DdJKPh+S6rk+y3QwbK9VkATBsWq3fZ3LIq5FtPQST0Sa W7GVCyfUWFZS+aXTuIfdd3lxyB3Zt5YZR3K9BxCnepH3AvkVzwQR+PNa6DS35WTKAF xYyhkTSwG96SQp6k3GxUp6PreUKA+ZCH0xcg2jtj7h4BH5jHUjI8xUNYEU42npT+JH +jbzzX9lEufrG0b4QZHde/0ls3bqREr7EvaPJHFkivz4hZ0w/eSpG00TJ7vLzrKYLa W5YE0AVYrmdtfKj/jNQ/GKFuADCC5SI4E7pn8lIPQC0Zt9y49h0fJKHZBstpP2uhc6 EsgGTmQAOOSEA==
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: Thu, 02 Oct 2014 01:49:09 -0000

On 10/1/14 7:24 PM, Christian Groves wrote:

>> 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.
> [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."

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.

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

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.