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

[Paul Kyzivat <[e-mail]>]

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./*
>>>
>>> */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.
>
> Thanks
> Raju
>
>