Re: [clue] Ben Campbell's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

[Ben Campbell <[e-mail]>]

> On Nov 20, 2018, at 1:34 PM, Paul Kyzivat <[e-mail]> wrote:
> 
> On 11/20/18 1:26 PM, Ben Campbell wrote:
> 
>> §4.5.1:
>> - What sort of user experience is expected when a CLUE device talks to a
>> non-CLUE device? Is this a realistic use case? (I'm not saying it's not; I'm
>> just asking.)
> 
> If the non-clue device is audio-only then you will get an audio call. If it is an audio/video device then you will get a basic audio/video call.
> 
> This can be entirely reasonable. For instance, if you have a clue-capable device on your desktop, you can use it for all of your calls. If the call is being originated from a clue-based conference room, inviting multiple clients, somebody in their car can be included in the call.

Okay, that makes sense. I wasn’t thinking about “desktop” CLUE devices, I guess.

> 
>> - "If the device has evidence that the receiver is also CLUE-capable,
>> for instance due to receiving an initial INVITE with no SDP but
>> including a "sip.clue" media feature tag,"
>>  Is it reasonable to remember CLUE support from previous sessions? I suspect
>>  the answer is  "no", due to SIP forking issues, but I think it's worth
>>  guidance one way or the other.)
> 
> This doesn't have to be from a prior session. The initial call may be an offerless invite (e.g., from a 3pcc controller). If the caller indicates support for clue then the callee can respond with an offer of a clue session.
> 

To be clear, I was wondering if remembering past sessions was an _additional_ way to “know” a peer is clue capable. In particular, if it’s not a good idea it would be worth mentioning that, because I suspect implementors might get creative in that particular direction.

Thanks!

Ben.