Subject: [Sip] GRUU issue 2: providing a gruu to the server

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 May 2004 02:36:28 -0400

I received a private email suggesting a feature be added to the gruu 
spec, which I believe requires discussion.

The suggestion is that it should be possible for the client to suggest a 
gruu to the server in a contact. The motivation that was given was to 
deal with failures in a proxy server - the client could effectively help 
in persistence of the gruu across failures.

We have, in fact, discussed this in the past, and decided NOT to do it. 
It introduces a lot of complexity. What happens if the suggested gruu 
exists in the server? Can there be race conditions where different 
servers in a cluster receive registrations for the same instance ID but 
different gruu (I believe this can happen)?

I think its really fundamental that a gruu be generated and provided by 
the server only.

In the case of a proxy failure, if you don't compute the gruu 
algorithmically, you will be required to store the instance ID to gruu 
mapping. This mapping would need to be replicated to backup servers for 
availability purposes. I dont see that as a big deal. Many of the 
carrier grade SIP servers I know of already replicate registration data, 
and so this isnt introducing any new burden on the server.

As such, I would like to keep what we have today.

Comments?

-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: Avshalom Houri <[email-masked]>
Date: Wed, 12 May 2004 15:18:15 +0300

Agree that is should remain in the server only. It is too complex to 
enable clients to suggest a gruu.
In addition to the issues that you mention how can the server verify that 
the gruu belongs to the claiming client?

Avshalom

Jonathan Rosenberg <[email-masked]> 
Sent by: [email-masked]
12/05/2004 09:36 AM

To
[email-masked]
cc

Subject
[Sip] GRUU issue 2: providing a gruu to the server

Comments?

-Jonathan R.

---

From: Alex Audu <[email-masked]>
Date: Wed, 12 May 2004 14:57:49 -0500

I agree with leaving things the way they currently are. There are better 
and well known ways
of having a server survive an outage ( including redundancy, and  
persisting  critical data).

Regards,
Alex.

Jonathan Rosenberg wrote:

> The suggestion is that it should be possible for the client to suggest 
> a gruu to the server in a contact. The motivation that was given was 
> to deal with failures in a proxy server - the client could effectively 
> help in persistence of the gruu across failures.
>
> We have, in fact, discussed this in the past, and decided NOT to do 
> it. It introduces a lot of complexity. What happens if the suggested 
> gruu exists in the server? Can there be race conditions where 
> different servers in a cluster receive registrations for the same 
> instance ID but different gruu (I believe this can happen)?
>
> I think its really fundamental that a gruu be generated and provided 
> by the server only.
>
> mapping. This mapping would need to be replicated to backup servers 
> for availability purposes. I dont see that as a big deal. Many of the 
> carrier grade SIP servers I know of already replicate registration 
> data, and so this isnt introducing any new burden on the server.
>