Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03

Paul Kyzivat <> Wed, 20 March 2013 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83F1211E80D1 for <>; Wed, 20 Mar 2013 09:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 38BDXn2FEBz8 for <>; Wed, 20 Mar 2013 09:55:07 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:227]) by (Postfix) with ESMTP id DA72611E80A4 for <>; Wed, 20 Mar 2013 09:55:06 -0700 (PDT)
Received: from ([]) by with comcast id Doq31l0050SCNGk5Csv69E; Wed, 20 Mar 2013 16:55:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Dsv51l00t3ZTu2S3Vsv6wG; Wed, 20 Mar 2013 16:55:06 +0000
Message-ID: <>
Date: Thu, 21 Mar 2013 00:55:05 +0800
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1363798506; bh=AvqESaVLL1f7Q/ghyDHVoWrpKwwLlemmMEp3S0Pcfmk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=P+qUOcH1VUxhRn20/GNUS9r99RB4qLcKsW2vReC+v7kRT3siBhVUrg2P/TA+IunCH MiGmtSOkHB5hATlhZzgP0zk1XXi4guTVOnOcewBQ3jAONt54M+KBVziFQIlD7zbHGE DxdJnc8YqzIxLSS9zBjzd+oJGnbmUf5UggTCpGNzvS4PU9yQMCbop96rKLzFc1u9Mt gVzDb38bCcqPGXK1OVVQ43W7DvImzdgNOpa6e/FiqoYkBXWbgiJ6PpSUvHDr7uu+xi oC9y2P4bHi4kprYKvEswQ/jAAN+Q2J5sF8pHcvHS7OnVR6o81n84eim+wfRO/1WVlo fOsMeLo4/jfkA==
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sctp-sdp-03
X-Mailman-Version: 2.1.12
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, 20 Mar 2013 16:55:07 -0000


Some comments on your review, from a CLUE perspective:

On 3/20/13 11:11 PM, Magnus Westerlund wrote:

> 6. Section 4.1:
> This section discuss the usage of the "data channels" within the SCTP
> association. My personal position is that for the moment this appears to
> be unnecessary. The most important part is the SCTP association
> establishment. Then one can discuss the general application using the
> SCTP association as whole. Examples of such are WebRTC data channel.
> If anyone want stream level information in SDP then I propose that this
> is handled as a extension to this signaling, not an from the start
> included functionality as we don't appear to have clear requirement for
> that.

Who is "we"?

In CLUE we expect to use this mechanism for a CLUE data channel.
And we intend to do so in pure sip-sip cases as well as webrtc-sip and 
webrtc-webrtc cases.

While webrtc-webrtc may have an independent mechanism to work out the 
channel usage, that is certainly not so for sip-sip sessions.

So I think "we" (CLUE) have a requirement to negotiate channel usage in SDP.

> 7. Section 4.2:
> What are the requirements behind being able to establish multiple SCTP
> association over the same DTLS connection? I am very unclear why this
> would be required, and if not really needed I would suggest keeping
> things simple.

I agree there has been no compelling need advanced for multiple SCTP 
associations over the same DTLS connection. But the fact is that SCTP 
has its own notion of port, and that needs to be dealt with one way or 
another. At a minimum this document should specify what SCTP port is to 
be used when conforming to this specification.

> 8. Section 4.3: I guess this can for the moment be removed as it appears
> to be taken care in other places, such as the RTCWEB WG data channel
> protocol proposal.

See above. That doesn't meet CLUE needs.