Subject: [Sip] SIP instance identifiers

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 15 Feb 2004 20:47:47 -0500

Folks,

We have three drafts this round that all propose a way to define an 
instance identifier for a UA:

http://www.jdrosen.net/papers/draft-ietf-sip-gruu-01.txt
http://www.ietf.org/internet-drafts/draft-jennings-sipping-instance-id-00.txt
http://www.ietf.org/internet-drafts/draft-stucker-sip-guid-00.txt

all three are similar. Mine uses a contact header field parameter, and 
uses the callee capabilities framework to enable caller preferences 
routing based on instance iDs. Cullen also uses a contact parameter, but 
not within the callee caps framework. Brian defines a header field.

I think we generally understand the requirement here, though it would 
probably be good to obtain use cases to be sure. The design choice is 
where to include this parameter, and this represents the difference 
between the three approaches.

I tend to prefer a Contact URI parameter over a header. My main reason 
for that is REGISTER requests. If a register request has multiple 
contacts, which contact does the instance identifier apply to? As a 
header field, it would be hard to know. If you make it a contact header 
field parameter, its no problem. Those header field parameters could 
also then be used in the Contact in INVITE/200 SUB/NOT, etc.

Then, the question is whether to use a regular Contact header field 
parameter as Cullen has done, or a callee cap parameter as I have done? 
The callee cap approach allows for caller preferences to be applied to 
routing to a specific instance. Now, a good question is whether such a 
thing is needed or even a good idea, if we have GRUU as the ideal way to 
route to a UA instance. I can go either way, but welcome thoughts on the 
topic.

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: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 17:28:34 -0500

Jonathan,

I like using a callee-cap feature tag in a registration. OTOH, I can see 
validity in Brian's desire to have it in a header of its own, 
potentially in any message. I don't see those usages as conflicting.

The only potential conflict would be in REGISTER, but that isn't a real 
conflict - a Guid header would describe the entity sending the REGISTER 
message, while the +sip.instance tag on a contact would describe the 
endpoint being registered. Often they would be the same, but not 
necessarily.

Regarding the form of guids, I don't think any single scheme works in 
all cases. My preference is to:

- represent the instance id as a URI

- make it the responsibility of the endpoint to select a URI
   that is unique

- Recommend that a URN be used.

- Define a couple of new URN namespaces that are especially
   suitable for this purpose. (I have in mind urn:mac:xxx for
   mac addresses, and possibly urn:random:xxx for random numbers
   in some large range.)

A couple of other comments:

Section 7.1 says:

    The combination of a UA instance ID and an AOR is referred to as an
    instance ID/AOR pair. There is a one-to-one mapping between such a
    pair and a GRUU; ...

And figure 2 shows the corresponding 1:1 relationship. But it isn't 
necessarily 1:1. It should be 1:0..1 because it is possible to have an 
instance ID/AOR Pair that doesn't have a GRUU. (Instance IDs are 
valuable in their own right.)

This 1:0..1 relationship imposes another error condition on registrars. 
If an attempt is made to register a contact with an instance id in use 
by some other contact of the same AOR, the registrar will have to refuse 
it. This needs to be spelled out somewhere, and a suitable error 
identified. (I don't know if any of the existing responses works for 
this. At the least, a new Reason code is likely to be needed.)

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Feb 2004 23:31:46 -0500

> potentially in any message. I don't see those usages as conflicting.

No, but it represents additional work.

> endpoint being registered. Often they would be the same, but not 

This makes sense.

>   mac addresses, and possibly urn:random:xxx for random numbers

This is a well trod area, and I think it would behoove us to look at 
work in other groups. Dean has mentioned HIP as one obvious candidate; 
generally speaking this exact issue - of endpoint identifiers that work 
better than IP address, is the subject of much other work at this 
moment, including MAST. I'm not familiar enough with it to know if its 
relevant... its on my reading list for this ietf.

> valuable in their own right.)

OK, I'll update the diagram.

> it. 

Well, thats one option.

This needs to be spelled out somewhere, and a suitable error
> this. At the least, a new Reason code is likely to be needed.)

Here is the use case for this. The use case is when a UA crashes, 
recovers, obtains a new IP, and re-registers. In this case, several 
things could possibly happen:

1. The registrar accepts the second registration, as per normal 
registration procedures. An INVITE to the gruu bound to that id/aor pair 
gets translated into BOTH contacts, causing the request to fork. There 
is never any response from the old IP. Within one refresh interval, the 
old contact is removed and all is well.

2. The registrar accepts the second registration, and automatically 
deletes the old one. I believe Brian proposed this behavior.

3. The registrar returns an error. The client fetches the current list 
of contacts, finds the old one listed, and unregisters it.

Approach 1 is problematic, as it will introduce herfp; any non-2xx from 
the new contact will wait for the 2nd branch to timeout. Its not clear 
to me whether 2 or 3 is more right. It depends a lot on who owns the 
policy for how to resolve the conflict - is it the server or the client?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Feb 2004 00:36:54 -0500

Just to be clear, I am not *advocating* that we need these identifiers 
any other place. I'm just saying that if there are other uses for a 
device id, that it won't hurt to use the same id elsewhere.

For the purpose we are discussing, it is important that the id be 
associated with a registered contact, and since REGISTER permits 
multiple contacts, it really needs to be a parameter on each contact.

That is really an entirely different application from identifying which 
device originated a particular message. If there is a need for that, 
then it needs to be in some header that can be in any message. I don't 
recommend we do that until we have a need for it.

	Paul

Cullen Jennings wrote:
> On 2/17/04 2:28 PM, "Paul Kyzivat" <[email-masked]> wrote:
> 
> 
>>I can see 
> Just to be clear, I don't want it to have multiple possible place it could
> be in a SIP message and I have to go traipsing around the message trying
> here then there unless it is a FOO message where you look over here. A
> header would work or caller pref but I don't see an argument for doing both.
> I want it just one place.
> 
> The case with PUBLISH not having contact header had concerned me (actually I
> think this was a mistake) but seems what happens in PIDF bodies could be
> different.
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2004 18:00:57 -0800