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

[Christian Groves <[e-mail]>]

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:[e-mail]]
>>> 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
>>
>>
>
>