Subject: Re: [Sip] Calle capabilities device ID: take 2

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Oct 2003 15:48:31 -0400

About to rev callee-caps, and wanted to conclude on this point.

Rohan makes a good point. Since we all agree we need GRUU for 
transfer, the use cases for device ID are not clear, and we can 
certainly add a device ID later on if we want. So, I will not include 
device-id, uri-user or uri-domain in the next rev of callee-caps.

Thanks,
Jonathan R.

Rohan Mahy wrote:

> 
> On Wednesday, August 13, 2003, at 11:11 AM, Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> I posted a note on this about a month back, with no responses. This is 
>> a big remaining open issue in callee caps and we want to resolve it. 
>> So, please take a look and respond.
>>
>> One of the issues I raised today during the meeting was on the utility 
>> of the uri-user and uri-domain parameters in 
>> draft-ietf-sip-callee-caps. The primary purpose that these serve is a 
>> means of identifying a UA instance. In order to accomplish 
>> applicaitons like assisted call transfer, a UA would send INVITE to 
>> the AOR of the transfer target, and include an Accept-Contact with the 
>> uri-user and uri-domain equal to those of the UA instance.
>>
>> Now, it turns out that uri-user and uri-domain are not very helpful 
>> when used this way. GRUU is a better approach. However, thats almost a 
>> secondary issue.
>>
>> The primary issue is that uri-user and uri-domain are ugly, and they 
>> repeat information already in the registration. The suggestion, made 
>> by Paul, was to instead define a device-id attribute. This ID would be 
>> long lived - burned into firmware of a device, perhaps. It would be 
>> included in a registration as a unique ID for the device or software 
>> instance, as the case may be.
>>
>> You could use this callee capability attribute for the assisted 
>> transfer just as you could use uri-user and uri-domain. It has the 
>> same problems that still make GRUU a better solution. However, during 
>> the meeting, folks like the idea of a device-id attribute as something 
>> useful for lots of other applications.
> 
> 
> I agree that a device ID would be useful for lots of things, but not for 
> transfer. I think you really need to use a GRUU for that.
> 
> This identified for me that we may all have some very different ideas 
> about what problems we'd like to solve with a device ID.  So, lets get 
> some requirements on the list (a few sentences each).  If we come to 
> consensus on what we need a device ID for, lets include it.  Otherwise, 
> we can add the appropriate capability or capabilities later.  Lots of 
> stuff depends on callerprefs and callee-caps.  Lets finish them everyone.
> 
> thanks,
> -rohan
> 
> 
>> So, I would like to invite comment and discussion on (1) whether you 
>> like the idea of replacing the uri-user and uri-domain attributes with 
>> device-id (a better name may be needed, like instance-id), (2) what 
>> kind of usages you had in mind for it, for good or for evil.
>>
>> Thanks,
>> Jonathan R.
>> -- 
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> [email-masked]                     FAX:   (973) 952-5050
>> http://www.jdrosen.net                      PHONE: (973) 952-5000
>> http://www.dynamicsoft.com
>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip