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

Christian Groves <> Fri, 09 October 2015 03:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3E9811B30A7 for <>; Thu, 8 Oct 2015 20:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F5oq3Kipy39D for <>; Thu, 8 Oct 2015 20:17:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CA9A1B30A5 for <>; Thu, 8 Oct 2015 20:17:11 -0700 (PDT)
Received: from ([]:52807 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <>) id 1ZkOBB-002bfB-2U for; Fri, 09 Oct 2015 14:17:09 +1100
References: <> <> <> <> <>
From: Christian Groves <>
Message-ID: <>
Date: Fri, 09 Oct 2015 14:17:02 +1100
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: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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 03:17:12 -0000

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 

Regards, Christian