Subject: [clue] CLUE signaling document queation

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Dec 2014 21:12:40 +0200

Hi,

During the framework WGLC we had a discussion about what is an endpoint that
supports CLUE. The conclusion was to defer it to the signaling document.

Both the framework and the signaling have the following term

CLUE-capable device: A device that supports the CLUE data channel
[I-D.ietf-clue-datachannel
<https://tools.ietf.org/html/draft-ietf-clue-framework-19#ref-I-D.ietf-clue-
datachannel> ], the CLUE protocol [I-D.ietf-clue-protocol] and the
principles of CLUE negotiation, and wishes to  upgrade the call to
CLUE-enabled status.

Yet we also have the media feature tag - sip.clue that according to section
3 of the signaling draft indicates support for CLUE. It also says "Presence
of the media feature tag in the contact field of a request or response can
be used to determine that the far end supports CLUE."

So if an endpoint gets an invite with the feature tag and no CLUE data
channel is this a CLUE capable endpoint.

The interesting case is if the INVITE included the feature tag and the CLUE
data channel and the response rejected the channel but had the feature tag,
is the remote end point CLUE capable, is it allowed to reject the data
channel but have the feature tag?

My view is that it is enough to have the feature tag to call an endpoint
CLUE capable, other views?

Thanks

Roni

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2014 00:15:00 -0500

On 12/16/14 2:12 PM, Roni Even wrote:
> Hi,
>
> During the framework WGLC we had a discussion about what is an endpoint
> that supports CLUE. The conclusion was to defer it to the signaling
> document.
>
> CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel  <https://tools.ietf.org/html/draft-ietf-clue-framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I-D.ietf-clue-protocol] and the principles of CLUE negotiation, and wishes to  upgrade the call to CLUE-enabled status.
>
> Yet we also have the media feature tag – sip.clue that according to section 3 of the signaling draft indicates support for CLUE. It also says “Presence of the media feature tag in the contact field of a request or response can be used to determine that the far end supports CLUE.”
>
> The interesting case is if the INVITE included the feature tag and the
> CLUE data channel and the response rejected the channel but had the
> feature tag, is the remote end point CLUE capable, is it allowed to
> reject the data channel but have the feature tag?
>

My take is that that the feature tag indicates that the endpoint 
*understands* CLUE, and is capable of using CLUE if it wishes. But it 
doesn't necessarily mean that it always wants to use CLUE - it may 
choose not to in some cases. For instance a mobile endpoint might choose 
not to use CLUE when it has a poor wireless connection.

	Thanks,
	Paul

---

From: "Xiaojing (Lennard)" <[email-masked]>
Date: Wed, 17 Dec 2014 09:19:19 +0000

Hi Roni,

I agree with you and Paul.
CLUE-capable doesn't necessarily mean CLUE-preferable. 

Best regards,
Lennard

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, December 17, 2014 1:15 PM
> To: [email-masked]
> Subject: Re: [clue] CLUE signaling document queation
> 
> > CLUE-capable device: A device that supports the CLUE data channel [I-
> D.ietf-clue-datachannel  <https://tools.ietf.org/html/draft-ietf-clue-
> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I-
> D.ietf-clue-protocol] and the principles of CLUE negotiation, and
> wishes to  upgrade the call to CLUE-enabled status.
> >
> > Yet we also have the media feature tag - sip.clue that according to
> section 3 of the signaling draft indicates support for CLUE. It also
> says "Presence of the media feature tag in the contact field of a
> request or response can be used to determine that the far end supports
> CLUE."
> >
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Robert Hansen <[email-masked]>
Date: Wed, 17 Dec 2014 15:05:40 +0000

My understanding is that the two views aren't entirely compatible, 
unless there's something I've not understood.

I agree with Paul, that the feature tag should indicate that an 
understanding of CLUE, but not necessarily a desire to do it, and hence 
isn't sufficient to define a device as CLUE-capable.

Rob

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2014 12:17:35 -0500

> isn't sufficient to define a device as CLUE-capable.

This highlights the terminology issues. We have described 'sip.clue' as 
a feature tag, which is indeed one name for it. But in RFC3840/3841 is 
called a callee *capability* (in contrast to a caller preference). Using 
that terminology something that includes sip.clue is clearly *capable* 
of clue, though it may not always be willing.

Offering to negotiate the clue channel indicates that it is also 
*willing* to use clue.

	Thanks,
	Paul

---

From: Robert Hansen <[email-masked]>
Date: Wed, 17 Dec 2014 18:12:15 +0000

So maybe what we need to change is the "CLUE-capable" definition (which 
currently means "capable and willing", which I agree isn't intuitive) to 
something like "CLUE-supporting"?

Rob

On 17/12/14 17:17, Paul Kyzivat wrote:
> This highlights the terminology issues. We have described 'sip.clue' 
> as a feature tag, which is indeed one name for it. But in RFC3840/3841 
> is called a callee *capability* (in contrast to a caller preference). 
> Using that terminology something that includes sip.clue is clearly 
> *capable* of clue, though it may not always be willing.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Dec 2014 19:31:37 +0000

Hi,

First, it depends on what the scope of the media feature tag is.

If a device indicates support for a feature in an INVITE request/response, my understanding is that it applies to that given session (at least that is what it means for feature capability indicators).

But, still, even if the answerer e.g. rejects the data channel, it may still indicate support for CLUE. Because, it may be willing to do CLUE later in the session, e.g. if the coverage gets better.

So, I think it's perfectly ok to indicate support of CLUE, even if you don't accept the data channel at a given point - as long as you MAY be willing to do CLUE later during the session.

If you KNOW that you won't do CLUE during the session, then I don't think you should indicate support of CLUE for that session either.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Robert Hansen
Sent: 17 December 2014 20:12
To: [email-masked]
Subject: Re: [clue] CLUE signaling document queation

So maybe what we need to change is the "CLUE-capable" definition (which currently means "capable and willing", which I agree isn't intuitive) to something like "CLUE-supporting"?

Rob

On 17/12/14 17:17, Paul Kyzivat wrote:
>> understanding of CLUE, but not necessarily a desire to do it, and 
>> hence isn't sufficient to define a device as CLUE-capable.
>
>>>>> that supports CLUE. The conclusion was to defer it to the 
>>>>> signaling document.
>>>>>
>>>> <https://tools.ietf.org/html/draft-ietf-clue-
>>>> section 3 of the signaling draft indicates support for CLUE. It 
>>>> also says "Presence of the media feature tag in the contact field 
>>>> of a request or response can be used to determine that the far end 
>>>> supports CLUE."
>>>>> CLUE data channel and the response rejected the channel but had 
>>>>> the feature tag, is the remote end point CLUE capable, is it 
>>>>> allowed to reject the data channel but have the feature tag?
>>>>>
>>>> *understands* CLUE, and is capable of using CLUE if it wishes. But 
>>>> it doesn't necessarily mean that it always wants to use CLUE - it 
>>>> may choose not to in some cases. For instance a mobile endpoint 
>>>> might choose not to use CLUE when it has a poor wireless 
>>>> connection.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>

---

From: "Roni Even" <[email-masked]>
Date: Fri, 19 Dec 2014 08:52:45 +0200

Hi,
I started this discussion based on a comment I made on the framework draft.
So it seems like we need to update the definition of CLUE capable device in
the framework and the signaling document (they should be the same). There is
also some text in the framework at the end of section  5 about discovering
if the remote endpoint is CLUE capable that will need to be fixed
Roni

> From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 18 December, 2014 9:32 PM
> To: Robert Hansen; [email-masked]
> If a device indicates support for a feature in an INVITE request/response,
my
> understanding is that it applies to that given session (at least that is
what it
> means for feature capability indicators).
> 
> But, still, even if the answerer e.g. rejects the data channel, it may
still indicate
> support for CLUE. Because, it may be willing to do CLUE later in the
session,
> e.g. if the coverage gets better.
> 
> So, I think it's perfectly ok to indicate support of CLUE, even if you
don't accept
> the data channel at a given point - as long as you MAY be willing to do
CLUE
> later during the session.
> 
> If you KNOW that you won't do CLUE during the session, then I don't think
you
> should indicate support of CLUE for that session either.
> 
> Regards,
> 
> Christer
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Dec 2014 13:19:45 +0000

Hi,

In general, I don't think we should have the same definition in two places. Put it in the framework draft, and reference it from other drafts.

Regards,

Christer

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: 19. joulukuuta 2014 8:53
To: Christer Holmberg; 'Robert Hansen'; [email-masked]
Subject: RE: [clue] CLUE signaling document queation

Hi,
I started this discussion based on a comment I made on the framework draft.
So it seems like we need to update the definition of CLUE capable device in the framework and the signaling document (they should be the same). There is also some text in the framework at the end of section  5 about discovering if the remote endpoint is CLUE capable that will need to be fixed Roni

my
what it
still indicate
session,
don't accept
CLUE
you
> So maybe what we need to change is the "CLUE-capable" definition 
> (which currently means "capable and willing", which I agree isn't 
> intuitive) to something like "CLUE-supporting"?
> 
> Rob
> 
> > as a feature tag, which is indeed one name for it. But in 
> > RFC3840/3841 is called a callee *capability* (in contrast to a caller preference).
> >>>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol 
> >>>> [I- D.ietf-clue-protocol] and the principles of CLUE negotiation, 
> >>>> and wishes to  upgrade the call to CLUE-enabled status.
> >>>> of a request or response can be used to determine that the far 
> >>>> end supports CLUE."
> >>>>> So if an endpoint gets an invite with the feature tag and no 
> >>>>> CLUE
> >>>> data
> >>>>> The interesting case is if the INVITE included the feature tag 
> >>>>> and
> >>>> the
> >>>> *understands* CLUE, and is capable of using CLUE if it wishes. 
> >>>> But it doesn't necessarily mean that it always wants to use CLUE 
> >>>> - it may choose not to in some cases. For instance a mobile 
> >>>> endpoint might choose not to use CLUE when it has a poor wireless 
> >>>> connection.
> >>>>
> >>>>     Thanks,
> >>>>     Paul
> >>>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 19 Dec 2014 06:40:28 -0800

Is there a need for two definitions, then?
CLUE-capable - understands CLUE, uses the feature tag, but not necessarily wanting to use CLUE at the moment.
CLUE-supporting - CLUE-capable and currently desiring to use CLUE (this is the current definition of CLUE-capable in the signaling draft)

Or did I get them backwards from Rob's suggestion?

I agree with Christer's suggestion to put the definition in just one document, and reference it from others.  Keeping these in the framework is okay with me.

Mark

> Sent: Wednesday, December 17, 2014 1:12 PM
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Dec 2014 11:31:54 -0500

> Or did I get them backwards from Rob's suggestion?

We had a discussion about this a couple of months ago.
Here is a link to it:

http://mailarchive.ietf.org/arch/msg/clue/5NAMhg2HUfISUvGpBQogRtpAiR8

I made the following proposal there:

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

	Thanks,
	Paul