Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt

Paul Kyzivat <> Tue, 06 October 2015 16:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D8861ACDF6 for <>; Tue, 6 Oct 2015 09:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i1pf9g4aUOQj for <>; Tue, 6 Oct 2015 09:37:37 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 648451ACDEC for <>; Tue, 6 Oct 2015 09:37:32 -0700 (PDT)
Received: from ([]) by with comcast id RscM1r00726dK1R01sdXyo; Tue, 06 Oct 2015 16:37:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id RsdX1r0063Ge9ey01sdXbA; Tue, 06 Oct 2015 16:37:31 +0000
References: <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Tue, 06 Oct 2015 12:37:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
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=1444149451; bh=ckPAta6egMrKptZHpByDD4rhXgyGVUFf1wDN7i51R+k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oYO19hmou+ycdpOMOtFjSGGpmR4sTaX6jvpwby4EqtOmBzgRKeaZaMyblWwYCtTeY UfEEe6fdbXIxTIJEwf2wYxcWObbJji8RDP9HMXESmVkM3H+wO4MN6mlK2RhXqyF+Rz 9W8JhQCx6oguQN30YLBT55RbxOTC6kMVvaCF0SCynjJ6Pr/F1LiRE2Rvlzy6OGQqBw ejtq4w1Sz51SnAgMflMoGzfJCZr9Dyi7q/qfljqUjWsA1seP/wNn56VQnTVz4/0rQj RoKq0mx2hlCt0imHMrKqjIBlPyYgEGwEE68CVlVQG5aVRde1UIjySI1RCTN/BjnM9P xplinYTomXMMA==
Archived-At: <>
Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt
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: Tue, 06 Oct 2015 16:37:39 -0000

See inline.

On 10/6/15 11:18 AM, Juergen Stoetzer-Bradler wrote:
> Hello Paul,
> Thanks much for your comments.
> Please see my replies inserted below.
> Thank you,
> Juergen
> On 05.10.2015 23:12, Paul Kyzivat wrote:
>> These changes mostly seem good. I have a couple of small points:
>> * Section
>> This section starts with:
>>    The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
>>    Usage of this attribute is only applicable when associated with
>>    UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines.
>> One issue is that usage of this attribute is also defined over pure
>> SCTP. So I think it would be more accurate to say "*Multiplexing* of
>> this attribute...".
> [Juergen] In this second paragraph of I wanted to express that
> this document defines the a=dcmap attribute only for
> X/DTLS/SCTP attribute lines - quite similar to the mux category
> description of the a=sctp-port attribute in section 5.3 of
> draft-ietf-mmusic-sctp-sdp-15.
> As multiplexing of multiple SCTP associations over one DTLS connection
> is not considered by draft-ietf-mmusic-sctp-sdp,
> and as there can be just one DTLS connection within one BUNDLE group
> (potentially used by multiple media descriptions within this BUNDLE group)
> my understanding is that in fact there can be just one SCTP association
> over DTLS within such a BUNDLE group.
> Therefore I thought there's no need to define a multiplexing semantic
> for the a=dcmap (and a=dcsa) attribute (as described in the 3rd paragraph).
> I am not sure "Multiplexing of this attribute is only applicable when
> associated with X/DTLS/SCTP "m" line" would be consistent
> with the intended meaning of the 3rd paragraph.
>> Also, saying this is *only applicable* unnecessarily blocks future
>> changes. I think it would be better to say *only defined*, or *outside
>> the scope*.
> [Juergen] Agree. How about the following?
> "This document defines usage of this attribute only when associated with
> UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines".

Ahh! I think we disagree on what the scope of this draft should be.

draft-ietf-mmusic-sctp-sdp defines several transport configurations for 

draft-ietf-rtcweb-data-channel defines data channels over sctp, but 
doesn't anything about allowed transport configurations of sctp.

Elsewhere webrtc specifies that only UDP/DTLS/SCTP and TCP/DTLS/SCTP are 
to be used for webrtc data channels.

I guess this draft is trying to restrict its applicability to only 
UDP/DTLS/SCTP and TCP/DTLS/SCTP. I see no reason to do that. This draft 
defines the dcmap and dcsa attributes. AFAIK there is *nothing* that 
prevents using data channels and these attributes over SCTP or 
SCTP/DTLS. That ought to be allowed and covered by this document.

Multiplexing in bundles is a different matter. As you point out, use in 
bundles is not defined for SCTP and SCTP/DTLS, while UDP/DTLS/SCTP and 
TCP/DTLS/SCTP can appear at most once in a bundle. So multiplexing of 
these attributes in bundles is currently undefined. This needs to be 
noted (and left for future work), but without excluding *unbundled* use 
with the other transports.

>> * Section
>> Analogous comment to that for
>> * Section 8.2:
>> IIUC current practice is for documents coming through WGs to list the
>> WG chair (e.g. as the contact.
> [Juergen] I see, thanks,
> Thus contact name would then e.g. be "MMUSIC Chairs"?

Yeah, I think so.


>> On 10/5/15 8:56 AM, Juergen Stoetzer-Bradler wrote:
>>> Hello,
>>> This version 05 adds the IANA registration sections for the dcmap and
>>> dcsa attributes
>>> and adds new mux category related sections for both attributes.
>>> It also adds [I-D.ietf-mmusic-sdp-mux-attributes] to the list of
>>> normative references,
>>> as that draft is referenced by the two new mux category sections.
>>> Additionally, this version updates section regarding the dmap's
>>> 'subprotocol' parameter
>>> as per the related MMUSIC discussion initiated by Christian in August,
>>> Thanks,
>>> Juergen
> _______________________________________________
> mmusic mailing list