Subject: RE: [Sip] GRUU Issue 1: Registration conflicts

From: "Chris Boulton" <[email-masked]>
Date: Mon, 15 Mar 2004 09:55:39 -0000

<<in-line>>

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: 12 March 2004 21:37
>To: [email-masked]
>Subject: [Sip] GRUU Issue 1: Registration conflicts
>
>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?

[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).

Chris.

>
>
>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

This message has been scanned for viruses by MailControl - www.mailcontrol.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