Subject: [Sip] GRUU Issue 1: Registration conflicts

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Mar 2004 16:36:31 -0500

Folks,

During the IETF meeting last week, I went over several open issues in 
the gruu spec. We had closure on some, and not on others. I'd like to 
confirm consensus on those we closed on, and obtain consensus on the 
others, as soon as possible. To that extent, I am sending a few notes on 
specific issues to be resolved. THis is the first.

Consider the following situation. User agent A has instance ID 1 and IP 
address IP1. It registers IP1, indicates that its associated with 
instance ID 1, and gets a GRUU for it. UA A crashes and reboots. It 
obtains a new IP, IP2. Its instance ID is unchanged. It registers once 
more. This registration indicates that IP2 is associated with instance 
ID 1. Now, the registrar has a problem. It has two contacts (IP1 and 
IP2) both seemingly bound to the same instance ID. What does it do?

Here are the only options I can see:

1. It binds the GRUU to *both* IP addresses. Subequent requests sent to 
the GRUU would fork to both addresses.

2. The registrar rejects the registration. Its up to the client to 
correct the situation by unregistering the old contact first.

3. The registrar accepts the new registration and deletes the old one.

Option 1 is clearly unacceptable, since it violates a fundamental gruu 
property.

The difference between option 2 and option 3 is in who makes the 
decision on how to resolve the conflict. In option 2, the client 
decices. In option 3, the server decides, and always applies a fixed 
policy - delete the older registration.

I think option 2 is better, since it puts control in the hands of the 
client. Their could be cases where the right behavior is to keep the old 
registration; I could think of one, but who knows down the road....

So, my proposal was to accept option 2, and add text to the 
specification detailing this behavior. I also proposed using a specific 
response code for this case, so that the client could take the 
appropriate actions.

I believe there was agreement at the meeting to take this path. Does 
anyone object?

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: Alex Audu <[email-masked]>
Date: Mon, 15 Mar 2004 10:33:55 -0600

Option 2 is reasonable. We assume of course that the client will be 
given all the neccessary
information it needs to unregister the old contact, since it may have 
lost all knowledge of
that information due to the crash.

Regards,
Alex.

Jonathan Rosenberg wrote:

> others, as soon as possible. To that extent, I am sending a few notes 
> on specific issues to be resolved. THis is the first.
>
> Consider the following situation. User agent A has instance ID 1 and 
> IP address IP1. It registers IP1, indicates that its associated with 
> 1. It binds the GRUU to *both* IP addresses. Subequent requests sent 
> to the GRUU would fork to both addresses.
>
> client. Their could be cases where the right behavior is to keep the 
> old registration; I could think of one, but who knows down the road....
>
> specification detailing this behavior. I also proposed using a 
> specific response code for this case, so that the client could take 
> the appropriate actions.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Mar 2004 02:23:10 -0500

> that information due to the crash.

Yes. Upon failure, it could query the registrar by sending a REGISTER 
with no Contacts. The 200 OK includes the currently registered contacts, 
including the "old" one with the existing instance id. The UA can then 
delete this registration by sending another REGISTER request, including 
that Contact with ;expires=0, and the new one as well.

We probably need to say that the registrar should make sure to process 
deletions (with expires 0) before checking for conflicts. Otherwise it 
would take two requests - one to delete the old contact, and another to 
add the new one.

Chris Boulton writes:
> [Chris Boulton] No objection here.  It would be useful for both (>1)
> GRUU values to be represented in the NEW response.  Maybe also some
> definition of original + updated address (although the client will know
> it's own current IP so probably not necessary).

My proposal above was to just use a subsequent REGISTER to obtain the 
old contact. I'm a bit reluctant to include the Contact in an error 
response, since this would be another meaning of Contact.

-Jonathan R.