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

[Paul Kyzivat <[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.

> */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?

	Thanks,
	Paul

> In either of these cases, the media gateway will not be aware of how to
> do such interworkings. Even if controller can ask gateway ahead of time
> what to do (in a yet to be defined complex way by protocols like
> H.248/Megaco) then still gateway have to report the TCP transport
> address back to controller so that it can inform LI agents about this
> address.
>
> Essentially, not having external negotiation will complicate other
> protocols (like H.248/Megaco MG-MGC protocol) and still won’t avoid
> per-data channel notification to the signaling entity (controller).
> Please note that such “media gateway centric/driven” complex procedures
> may not even be allowed by H.248/Megaco as controllers wants be the one
> making such decisions as they happen.
>
> */2./**//*There could be several streams using the same subprotocol.
> Then how does gateway know which maps to what? CLUE may have just one
> data channel stream; but we may also have to think about CLUE combined
> with other data channels under same SCTP association. Even for single
> CLUE stream case item (1) is still an issue though.
>
> The gateway is going to get DCEP for each subprotocol, so it knows which
> one is CLUE.
>
> */[Raju] As noted, since in this specific case there is one single CLUE
> data channel a gateway unambigously can map. But still the above
> mentioned interworking requires controller involvement as the data
> channels are open./*
>
> *//*
>
> */Regards/*
>
> */Raju/*
>
> Regards,
>
> Christer
>