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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

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