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

Juergen Stoetzer-Bradler <> Fri, 09 October 2015 12:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6806A1B3C0B for <>; Fri, 9 Oct 2015 05:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NlA52KE8Jqbj for <>; Fri, 9 Oct 2015 05:54:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 642351B3C09 for <>; Fri, 9 Oct 2015 05:54:52 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 09B4D676499EF for <>; Fri, 9 Oct 2015 12:54:47 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id t99CsOZX029985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Fri, 9 Oct 2015 14:54:49 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Fri, 9 Oct 2015 14:54:43 +0200
References: <> <> <> <> <> <>
From: Juergen Stoetzer-Bradler <>
Message-ID: <>
Date: Fri, 09 Oct 2015 14:54:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090206050209060206000907"
X-Originating-IP: []
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: Fri, 09 Oct 2015 12:54:55 -0000

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 UDP/DTLS/SCTP
    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.


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 for sctp: SCTP, SCTP/DTLS, 
>> 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