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

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 2 Mar 2014 17:11:04 +0000

+ 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).

2.       For Non-LI reasons, a CLUE could be interworked to a TCP based transport in an end-to-access-edge kind of approach.
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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Mar 2014 20:52:32 +0000

On 3/2/14 5:11 PM, Makaraju, Maridi Raju (Raju) wrote:
> 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.
>
> */[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
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Sun, 2 Mar 2014 23:00:30 +0000

Comments inline.

> From: Paul Kyzivat [mailto:[email-masked]]
> > controller needs to tell the media gateway: "please let CLUE go through"
> >
> > */[Raju] "Please let CLUE through" is a simple scenario without much

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

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Mar 2014 00:06:16 +0000

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 03 Mar 2014 18:03:26 +1100

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:
> negotiating the clue channel. But IMO *the* reason we are using SCTP 
> is to get interop with CLUE. (Otherwise we could just use TLS.)
>
> 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
>
>>>> For the gateway use-case, do we really need to indicate the SCTP 
>>>> stream
>>>> during Offer/Answer?
>>>>
[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.
>> [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.
>>
>> [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.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 03 Mar 2014 09:41:49 +0100

> There are other cases that may require interworking at gateways.

When stating the use case, just say that one of the participants in a
CLUE channel (including the gateway) may choose to share the content (or
the existence of the channel - I can't tell which you mean by "report"
here) with a third party.

There are lots of reasons why someone may choose to do that, including,
for instance, the requirement for recording financial advice given over
the phone in many countries, and calling out legal intercept is just
going to generate lots of heat but little light.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 3 Mar 2014 13:20:42 +0000

IMHO, we should not just think about "low risk/resistance" 
vs. "high risk" approach, rather do the right thing and select the 
right approach to serve near and long term needs. The "risk" mentioned
wrt ejzak's adaption is completely within MMUSIC control and can be
managed IMHO. For this draft, besides CLUE, there are other strong use 
cases to interwork existing subprotocols such as MSRP; no support 
is needed for this draft from rtcweb (or from browsers)!

Issues summary:
===============
There are three issues that need to be addressed if DCEP is used:
a. How middle boxes know about the data channel streams (DCS)?
b. How to negotiate subprotocol properties per DCS?
c. How to select stream ids? Who initiates DC OPEN?
Issue (c) is relatively easy to handle by associating it to TLS role.
But actual TLS role is typically NOT available to the application.
Application need to determine the role by looking into a=setup.
(will it ever be different from the actual role used at DTLS layer?)

But issue (a) requires complex changes at media gateways, which are
questionable and probably not allowed with current architecture.
Issue (b) requires DCEP to make changes to allow exchange of 
subprotocol properties as part of DC OPEN. Then media gateways
have to inform controllers of these properties as needed.

I understand that 
- some implementations want to go with internal 
- and others want to go with external negotiation; 
- yet some others want to go with internal but want 
  to negotiate stream ids and/or subprotocol properties 
  externally. 

To facilitate all these possibilities, I want to make 
the following proposal.

PROPOSAL
========
1. Use of DCEP only
   SDP offer does not have Ejzak's a=dcmap, a=dcsa
   This results in using DCEP. The applicaion is fully aware
   of the limitations, if any, and fine with them.
   Issue (c) need to be addressed explictly.

2. Use of DCEP only (essentially same as (1)).
   SDP offer has Ejzak's a=dcmap, optionally a=dcsa
   Answerer ignores a=dcmap and a=dcsa (per SDP rules)
   and won't include them in SDP answer.
   DCEP will be used.
   
3. External or DCEP negotiated, no subprotocol parameters 
   SDP offer has Ejzak's a=dcmap, optionally a=dcsa
   A new parameter "protocol" will be added to a=dcmap.
   protocol=external (default) indicates offerer wants to use
   external negotiation for that stream; protocol=internal 
   indicates DCEP. SDP answerer may decide just to use a=dcmap 
   to get stream id, subprotocol and changes 'protocol' parameter 
   as needed and include it in SDP answer.
   a=dcsa are ignored and not sent back in SDP answer. 
   NOTE: if offer says "external" and answer selects "internal"
   then the previously created data channel, at offering side,
   with external negotiation (negotiated=true in PeerConnection 
   API case) has to be closed and has to be reopened with 
   same stream id but with internal protocol(negotiated=false).

4. External or DCEP negotiated, with subprotocol parameters 
   SDP offer has Ejzak's a=dcmap and a=dcsa.
   External or DCEP is negotiated per (3).
   SDP answerer decides to use both dcmap and dcsa and 
   echoes them back in SDP answer.

CLUE applications can go with any of the above 4 options 
as they sees fit.

Thanks
Raju

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, March 03, 2014 1:03 AM
> To: Paul Kyzivat; Makaraju, Maridi Raju (Raju); Christer Holmberg; Mary
> Barnes; [email-masked]
> Cc: Richard Ejzak; DRAGE, Keith (Keith); Liuyan (Scarlett)
> Subject: Re: IETF#89: First version of CLUE Data Channel slide set.
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 3 Mar 2014 13:24:38 +0000

> From: mmusic [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: Monday, March 03, 2014 2:42 AM

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

[Raju] Both (existence/control, content) are possible with various levels of "reporting".

> going to generate lots of heat but little light.

[Raju] Thanks for providing a non-controversial use case! :-)

Thanks
Raju