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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Aug 2003 14:11:58 -0400

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.

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

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 14 Aug 2003 01:39:16 -0400

As I indicated at the WG meeting in Vienna, I have a fairly strong 
preference for pitching the current scheme in favor of having a "Device-id" 
or "instance-id" parameter. I have no strong preference as to the exact 
name, but tend to agree with Jonathan that "instance-id" is more neutral 
than "device-id" and less likely to be over-interpreted by implementers.

I'll comment later on the exact uses I have in mind, since that requires 
quite a bit more effort and it's 2AM here.

Dave.

--On Wednesday, August 13, 2003 2:11 PM -0400 Jonathan Rosenberg 
<[email-masked]> 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.
>
> 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.
>
> 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.
> --

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Aug 2003 23:10:11 -0700

I think device-id is a useful idea but we do need to have a practical way to
generate this instance-id for a softphone running on a PC behind a NAT. A
sufficiently large random number seems like a possibility. It does have
privacy concerns that make when and where it can be removed complicated.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Aug 2003 10:27:41 -0400

This relates to a fundamental question we need to answer: what is the 
scope of uniqueness of this ID? During the meeting, I had proposed 
that it was very long lived. For a hard-phone, it was effectively 
burned into firmware, and would be consistent across any reboots of 
the device.

Thats a little ill-defined for a piece of software. I suppose that it 
would need to be unique for each distinct installation of the 
software. A random number selected at install time, and stored on 
disk, would work. It wouldnt survive a reinstall or an HD crash, but I 
suspect thats fine.

However, the question is whether this level of uniqueness is needed? 
Its not for the original application that drove uri-user and 
uri-domain. THis is why I'd like some use cases from folks to make 
that determination.

Here is one use case to start with:

1. single login: yahoo only allows one device to be registered at a 
time. Feature or bug? Well, whichever it is, we'd like it to be 
possible to allow this. It is possible to implement this without any 
callee caps, but a device ID would make it easy to disambiguate a 
registration from a device which crashed or changed its IP for some 
reason, from one where a second device is registering against the same 
AOR.

This one only requires the device ID to have a long lived duration.

-Jonathan R.

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 15 Aug 2003 11:43:15 -0400

--On Friday, August 15, 2003 10:27 AM -0400 Jonathan Rosenberg 
<[email-masked]> wrote:

> scope of uniqueness of this ID? During the meeting, I had proposed that
> it was very long lived. For a hard-phone, it was effectively burned into
> firmware, and would be consistent across any reboots of the device.
>
Yes.

> That's a little ill-defined for a piece of software. I suppose that it
> would need to be unique for each distinct installation of the software. A
> random number selected at install time, and stored on disk, would work.
> It wouldnt survive a reinstall or an HD crash, but I suspect thats fine.
>
Sounds good.

> However, the question is whether this level of uniqueness is needed? Its
> not for the original application that drove uri-user and uri-domain. THis
> is why I'd like some use cases from folks to make that determination.
>
For most of the uses I have in mind, it needs persistence equal to the 
administrative persistence of the things which enroll devices (as opposed 
to users) into a domain. So, I'd advocate not changing it even after a 
re-install of a softphone as long as there is a residual configuration from 
a prior installation left on the disk (a common practice for PC software).

> 1. single login: yahoo only allows one device to be registered at a time.
> Feature or bug? Well, whichever it is, we'd like it to be possible to
> allow this.
I'd call it a misfeature, but giving people a handle for this bad policy is 
not an argument against having the hook.

> It is possible to implement this without any callee caps, but
> a device ID would make it easy to disambiguate a registration from a
> device which crashed or changed its IP for some reason, from one where a
> second device is registering against the same AOR.
>
That seems at least moderately useful.

Dave.

>> I think device-id is a useful idea but we do need to have a practical
>> way to generate this instance-id for a softphone running on a PC behind
>> a NAT. A sufficiently large random number seems like a possibility. It
>> does have privacy concerns that make when and where it can be removed
>> complicated.
>>

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 20 Aug 2003 11:15:52 -0700

> 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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 20 Aug 2003 11:36:52 -0700

Hi,

A lot of the uses of a device ID that I've heard so far, I have been 
able to get the desired effect by giving the UA (in many cases a SIP 
phone) a separate AOR.  Not sure which requirements of other folks this 
solves or not since I have not seen any requirements yet. ;-)

Lets say I want to identify two otherwise identical devices so I can 
direct SIP messages to a specific one, even if the network topology 
changes.  I have a phone at my desk, and one in the nearby lab.  For 
example, I'd like to send a REFER to one of them from my PC to do 
click-to-dial.

I suggest that in addition to my AOR which is REGISTERed on each phone 
(sip:[email-masked]), that each of my phones has an AOR as well.  
These phones should REGISTER themselves to this AOR, they can do a 
third-party registration when they REGISTER with my AOR, and they can 
use this AOR when they SUBSCRIBE to their configuration information.

By default this "device" AOR can be produced using "burned-in" 
information such as a serial number or a mac address, but this 
information can be rewritten by an administrator to be an arbitrary 
string (with the caveat that you can always tell a burned-in derived 
address from a configured one so you can't cause duplicates with 
someone's burned-in address).

sip:com.cisco.7960.sn8923173;burnedin=[email-masked]
sip:com.cisco.7960.sn9213483;burnedin=[email-masked]

my administrator may decide to make AORs for my phones based on 
location, administrative boundary or something, so that I have:

sip:[email-masked]
sip:[email-masked]

eventually my administrator might assign my phones fixed names in DNS, 
then the device AORs become:

sip:rmahy-office-phone.example.org
sip:rmahy-lab-phone.example.org

I think this allows a lot of useful and interesting behavior.  Whether 
this covers none, some, or all of the device-id requirements I do not 
know.

thanks,
-rohan

On Friday, August 15, 2003, at 07:27 AM, Jonathan Rosenberg wrote:

>> way to