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

Paul Kyzivat <> Wed, 21 October 2015 15:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 89DFF1AD09B for <>; Wed, 21 Oct 2015 08:49:43 -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 vBWQ9F89cSGO for <>; Wed, 21 Oct 2015 08:49:42 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D9381AD08F for <>; Wed, 21 Oct 2015 08:49:41 -0700 (PDT)
Received: from ([]) by with comcast id Xrof1r0022LrikM01rphyX; Wed, 21 Oct 2015 15:49:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Xrpg1r00R3Ge9ey01rpgPB; Wed, 21 Oct 2015 15:49:41 +0000
References: <> <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Wed, 21 Oct 2015 11:49:39 -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=1445442581; bh=O0MVNKqK/7KKS91Vtuub0+mGra2rOkUeNh8RReBOThM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uqXJBISnXKEopKDN6DUKaq7FTjH9ma+PhAX8uF7p2aZwrS0XqcPfFc0lz74wcFVca CbOfCDzZ2t0Ahp0QtoDTu3X3kqbCawPMv/lIcwTGBtH8n0Wy4j3//4PXJbnTm9XYbW bfzskhKsqvIhrirZXNPYtQ1/OH8km7YL/L21JLgRerAdcBjHUsZ6uMGGhuyoJaNPx6 SWtzamKO3aBwvjHpQm8k1l3MBFH0X6fDlLKIbkKjUpNmJtWdbvmAJItO4Hws7BlWrA btC39xkewJHR2+GH85h4HEPWXXyEB9jvrhOoq/GMvc7mUfeDdUdulhE9mltTrLCUbX pZcINnezw0HCA==
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: Wed, 21 Oct 2015 15:49:43 -0000

Sorry for not responding sooner. I see you put the proposed language 
into -06. I'm satisfied with that.


On 10/9/15 8:54 AM, Juergen Stoetzer-Bradler wrote:
> Hello Paul, Christian,
> Thank you for your feedback.
> I was indeed much focused on the WebRTC data channel protocol stacks
> (SCTP over DTLS) when writing the mux category sections for dcmap and dcsa.
> My reading of draft-ietf-rtcweb-data-channel-13 (e.g. sec 6.1) is that
> DTLS transport of SCTP must actually be used.
> However, in order not to explicitly restrict potential future usage of
> the dcmap and dcsa attributes to x/DTLS/SCTP m-lines I'd propose to
> modify the text in section
> as follows. (And correspondingly to also modify the dcsa related
> text in
> Would you agree to following wording?
>  dcmap Multiplexing Category
>     Multiplexing characteristics of SDP attributes are described in
>     [I-D.ietf-mmusic-sdp-mux-attributes].  Various SDP attribute
>     multiplexing categories are introduced there.
>     The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
>     As the usage of multiple SCTP associations on top of a single DTLS
>     connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
>     "a=dcmap:" attribute multiplexing rules are specified for the
>     and TCP/DTLS/SCTP proto values.
>     This document also does not specify multiplexing rules for this
> attribute
>     for SCTP or SCTP/DTLS proto values.
>     If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to
> negotiate
>     multiplexing of multiple SCTP associations of top of a single DTLS
> connection
>     or how to multiplex multiple SCTP associations within one BUNDLE group,
>     then multiplexing rules for the "a=dcmap:" attribute need to be
> defined as
>     well, for instance in an extension of this SDP based data channel
>     negotiation specification.
> Thanks,
> Juergen
> On 09.10.2015 05:17, Christian Groves wrote:
>> Hello Juergen and Paul,
>> You're updates look OK to me. I think this is ready for WGLC.
>> Please see below.
>>>>> 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
>>> 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.
>> Do we really need to extend the scope to SCTP or SCTP/DTLS? The
>> mechanism is clearly related to the use of WebRTC data channel. Is
>> SCTP and SCTP/DTLS going to be used for data channel in the future?
>> There is "something" preventing data channels being used on SCTP or
>> SCTP/DTLS its draft-ietf-rtcweb-data-channel which clearly shows the
>> stack as UDP/DTLS/SCTP and TCP/DTLS/SCTP.
>> Regards, Christian
>> _______________________________________________
>> mmusic mailing list
> _______________________________________________
> mmusic mailing list