Re: [MMUSIC] IETF#89: First version of CLUE Data Channel slide set.

Christian Groves <> Mon, 03 March 2014 07:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A43B91A0D48 for <>; Sun, 2 Mar 2014 23:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eoJxIAH_1XuU for <>; Sun, 2 Mar 2014 23:03:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E1A31A0D4D for <>; Sun, 2 Mar 2014 23:03:37 -0800 (PST)
Received: from [] (port=52072 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1WKMop-00061O-Am; Mon, 03 Mar 2014 17:57:44 +1100
Message-ID: <>
Date: Mon, 03 Mar 2014 18:03:26 +1100
From: Christian Groves <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Paul Kyzivat <>, "Makaraju, Maridi Raju (Raju)" <>, Christer Holmberg <>, Mary Barnes <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; 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:
Cc: "DRAGE, Keith \(Keith\)" <>
Subject: Re: [MMUSIC] IETF#89: First version of CLUE Data Channel slide set.
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: Mon, 03 Mar 2014 07:03:46 -0000

I support Raju's comments. By not having an SDP approach to negotiate 
what protocol/s are being used  the SCTP association are going to 
complicate things for gateways that have to provide some interworking 
between endpoints.
DCEP is useful for opening the SCTP streams but I don't see where the 
negotiation of what will go over the streams will take place in 
non-rtcweb systems?

Regards, Christian

On 3/03/2014 11:06 AM, Paul Kyzivat wrote:
> I started out preferring an SDP approach (such as Richard's draft) for 
> negotiating the clue channel. But IMO *the* reason we are using SCTP 
> is to get interop with CLUE. (Otherwise we could just use TLS.)
> And at the moment going with DCEP appears to be the low risk approach 
> for us. With it we have fewer dependencies, and the ones we have are 
> on paths that will be well exercised in the short run. There is less 
> total stuff to implement, and it is sufficient for our needs. And it 
> will be the path of least resistance for getting an webrtc clue client 
> working.
> (I'm fairly confident that Simon will have one going sooner rather 
> than later. They already have prototypes of pieces, and we don't have 
> the specs done yet.)
>     Thanks,
>     Paul
> On 3/2/14 11:00 PM, Makaraju, Maridi Raju (Raju) wrote:
>> Comments inline.
>>> From: Paul Kyzivat []
>>> On 3/2/14 5:11 PM, Makaraju, Maridi Raju (Raju) wrote:
>>>> + mmusic to cover some of the discussions.
>>>> Hi,
>>>> Please see comments inline.
>>>> Hi,
>>>> For the gateway use-case, do we really need to indicate the SCTP 
>>>> stream
>>>> during Offer/Answer?
>>>> Or, would it be enough if we indicate that the data channel is 
>>>> going to
>>>> be used for CLUE, and the gateway then figures out which stream is 
>>>> used
>>>> when it receives DCEP OPEN?
>>>> */[Raju] This approach has 2 implications:/*
>>>> */1./**//*The gateway needs to look at bearer packets and notify the
>>>> signaling layer about the streams. Though possible, this is
>>>> computationally intensive and new mechanism needed for such 
>>>> notification
>>>> between bearer and signaling layers.
>>>> Why does it need to inform the signalling layer about the streams? The
>>>> controller needs to tell the media gateway: "please let CLUE go 
>>>> through"
>>>> */[Raju] "Please let CLUE through" is a simple scenario without much
>>>> interworking and other needs./*
[CNG] It's not about simply letting "CLUE go through." CLUE will need to 
be interworked/encodings updated etc depending on the gateway 
>>>> */I want to point out couple of other interworking scenarios:/*
>>>> */1./*Lawful intercept (LI): A CLUE channel may have to be reported to
>>>> LI agents per regulatory requirements. For various reasons such
>>>> reporting may have to be interworked with non-data channel SCTP/dTLS
>>>> transport (e.g. TCP).
>>> By explicit policy we don't consider lawful intercept in IETF.
>>> The same issue exists for the RTP.
>> [Raju] I understand LI is a very sensitive subject and by no means I 
>> am making any statements about it. My comment was providing one use 
>> case to which a service provider may be legally obligated to oblige.
>> There are other cases that may require interworking at gateways.
>>>> */2./*For Non-LI reasons, a CLUE could be interworked to a TCP based
>>>> transport in an end-to-access-edge kind of approach.
>>> ??? CLUE protocol over TCP? Why? Who will specify that? The intent 
>>> is to
>>> use DTLS/SCTP based data channel even when no webrtc in use.
>>> Or do you mean interworking with some non-clue TP protocol?
>> [Raju] I meant both. None of these are defined yet for CLUE. I am 
>> thinking of these future possibilities. If one approach allows these 
>> future possibilties with little overhead, my vote is to go with such 
>> approach.
>> Also, as stated earlier such SDP framework makes it easy to negotiate 
>> subprotocol attributes which comes naturally with SDP and fits well 
>> with SDP based approach.
[CNG] I agree.
>> Thanks
>> Raju