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

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

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:[e-mail]]
> Sent: Monday, March 03, 2014 1:03 AM
> To: Paul Kyzivat; Makaraju, Maridi Raju (Raju); Christer Holmberg; Mary
> Barnes; [e-mail]
> Cc: Richard Ejzak; DRAGE, Keith (Keith); Liuyan (Scarlett)
> Subject: Re: IETF#89: First version of CLUE Data Channel slide set.
> 
> 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
> >>
> >>
> >
> >