Subject: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 20 Oct 2014 11:20:18 -0700

Hi Paul,

Thanks for the suggestions.  Comments below.

... snip 
> >>      Media Consumer: a CLUE-capable device that that is capable of
> >>      receiving Capture Encodings
> >>
> >>      Media Provider: a CLUE-capable device that is capable of sending
> >>      Capture Encodings
> >>
> >> I wonder if these defs should say "a CLUE-enabled* device.
> >
> > [Duckworth, Mark] We don't have a definition for "CLUE-enabled device".
> Would that be "a CLUE-capable device in a CLUE-enabled call"?
> 
> ISTM the following are different states a *device* may be in:
> 
> - is entirely clueless. It hasn't included the clue feature tag or
>    the clue group. This is already defined as a Non-CLUE device.
> 
> - it is aware of clue, but is unable or unwilling to use CLUE right now.
>    It has included the clue feature tag, but not the clue group. Or else
>    it has included the clue group but not included any SCTP m-line in
>    the clue group. Perhaps this could be called CLUE-aware but
>    CLUE-disabled.
> 
> - it is aware of clue, and wishes to use it. It has included the clue
>    feature tag, and the clue group, and has included an SCTP m-line
>    in the clue group. Perhaps we can call this a CLUE-enabled device.
>    (This doesn't mean the *call* is CLUE-enabled.)
> 
> Note that this is distinct from the state of the call. You can have a
> clue-enabled *device* yet not have a clue-enabled *call* - both ends
> must be clue-enabled before the call is.

[Duckworth, Mark] These definitions make sense, but seems to me they get too much into signaling detail for the framework document.  I still like the definitions of MC and MP given above.  Do you think a change is really necessary?  If so, how about something like "a CLUE-capable device that intends to receive Capture Encodings"? 

Mark

---

From: "Robert Hansen (rohanse2)" <[email-masked]>
Date: Tue, 21 Oct 2014 09:18:12 +0000

The definitions I wrote for the signalling document are:

  CLUE data channel:  A reliable, bidirectional, transport mechanism
      used to convey CLUE messages.  See [I-D.ietf-clue-datachannel] for
      more details.

   CLUE-capable device:  A device that supports the CLUE data channel
      [I-D.ietf-clue-datachannel], the CLUE protocol
      [I-D.presta-clue-protocol] and the principles of CLUE negotiation,
      and wishes to upgrade the call to CLUE-enabled status.

   CLUE-enabled call:  A call in which two CLUE-capable devices have
      successfully negotiated support for a CLUE data channel in SDP.  A
      CLUE-enabled call is not necessarily immediately able to send
      CLUE-controlled media; negotiation of the data channel and of the
      CLUE protocol must complete first.  Calls between two CLUE-capable
      devices which have not yet successfully completed negotiation of
      support for the CLUE data channel in SDP are not considered CLUE-
      enabled.

   Non-CLUE device:  A device that supports standard SIP and SDP, but
      either does not support CLUE, or that does but does not currently
      wish to invoke CLUE capabilities.

   CLUE-controlled media:  A media "m" line that is under CLUE control;
      the capture source that provides the media on this "m" line is
      negotiated in CLUE.  See Section 4 for details of how this control
      is signalled in SDP.  There is a corresponding "non-CLUE-
      controlled" media term.

While these are written in a fairly signalling specific matter, CLUE-capable device and CLUE-enabled call could potentially be broken out for the framework doc, and the signalling document could then include the signalling specific aspects of what they mean.

Rob

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
Sent: 20 October 2014 19:20
To: Paul Kyzivat; [email-masked]
Subject: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17

Hi Paul,

... snip 

Mark

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 21 Oct 2014 07:24:28 -0700

Hi Rob,

The definitions for CLUE-capable device and CLUE-enabled call are already in the framework (as Paul suggested a while ago), identical to the definitions in signaling document.  I think those are high level enough for the framework, and nobody has objected to those definitions in the framework.

I was questioning Paul's suggestion of new definitions for CLUE-aware device, CLUE-disabled device, CLUE-enabled device.  Maybe these would be useful in the signaling document, but I think they are not needed for the framework.

Mark

> From: Robert Hansen (rohanse2) [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2014 5:18 AM
> To: Duckworth, Mark; Paul Kyzivat; [email-masked]
> Subject: RE: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in
> framework-17
> 
> While these are written in a fairly signalling specific matter, CLUE-capable
> device and CLUE-enabled call could potentially be broken out for the
> framework doc, and the signalling document could then include the signalling
> specific aspects of what they mean.
> 
> Rob
> 
> [Duckworth, Mark] These definitions make sense, but seems to me they get
> too much into signaling detail for the framework document.  I still like the
> definitions of MC and MP given above.  Do you think a change is really
> necessary?  If so, how about something like "a CLUE-capable device that
> intends to receive Capture Encodings"?
> 
> Mark
>