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

Christian Groves <Christian.Groves@nteczone.com> Mon, 03 March 2014 07:03 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43B91A0D48 for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 23:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoJxIAH_1XuU for <mmusic@ietfa.amsl.com>; Sun, 2 Mar 2014 23:03:44 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1A31A0D4D for <mmusic@ietf.org>; Sun, 2 Mar 2014 23:03:37 -0800 (PST)
Received: from [130.129.152.129] (port=52072 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1WKMop-00061O-Am; Mon, 03 Mar 2014 17:57:44 +1100
Message-ID: <5314293E.7090409@nteczone.com>
Date: Mon, 03 Mar 2014 18:03:26 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
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 <pkyzivat@alum.mit.edu>, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Mary Barnes <mary.ietf.barnes@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D1C0E03@ESESSMB209.ericsson.se> <CAHBDyN75R1Wr5BODSQ9RNmNP9G7QZdOjZ9Lw+Vz3DCEUUYh4-Q@mail.gmail.com> <CAHBDyN5aDiJHy0fZ3=A8bLyCGAEhSojxu0_kAdLvOTykykE36Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1C2DF7@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003463@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1C3A97@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003836@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1C4C1F@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826E003961@US70UWXCHMBA02.zam.alcatel-lucent.com> <53139A10.1040502@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826E003DC8@US70UWXCHMBA02.zam.alcatel-lucent.com> <5313C778.2040105@alum.mit.edu>
In-Reply-To: <5313C778.2040105@alum.mit.edu>
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 - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Wp3iD2cb-rRf8FrE1jVSb3dDCmU
Cc: "DRAGE, Keith \(Keith\)" <keith.drage@alcatel-lucent.com>
Subject: Re: [MMUSIC] IETF#89: First version of CLUE Data Channel slide set.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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 [mailto:pkyzivat@alum.mit.edu]
>>> 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 
policy/capabilities.
>>>>
>>>> */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
>>
>>
>
>