Subject: RE: [Sip] RFC 3261: Setting the expiration interval by Registrar?

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 24 Jan 2006 17:34:58 -0500

True, but I think that negotiation is somewhat rigid. If a client is not
able to honor the Min-Expires period in the 423 response for whatever
reason then it will not be able to register at all. 

A subtle variation could be that the client is given the freedom to
refresh/query registrations as frequently as it wants, even though the
Registrar only needs to track a bigger expiration period. This is
basically stating that given the current mechanisms in RFC 3261, one can
build a client that will honor the Min-Expires reported in 423 and will
then register for the appropriate duration. However, it can then send
registration queries to the Registrar as frequently as it wants. 

It is a problem local to the client that it wants to refresh frequently.
Why should the Registrar be burdened with that and forced to run a
smaller timer than it needs to? The NAT scenario would be an exception
to this because in that case the Registrar would want to run the same
timer that the client is running, so that if the client ever became
inaccessible it can be marked so in the location service. 

-----Original Message-----
From: Bharrat, Shaun [mailto:[email-masked]] 
Sent: Tuesday, January 24, 2006 4:46 PM
To: Jain, Rajnish
Cc: [email-masked]
Subject: RE: [Sip] RFC 3261: Setting the expiration interval by
Registrar?

Maybe I just don't understand your use case but there
is nothing stopping the registrar from controlling the refresh
rate. If it wants a lower value, it just lowers it. If it wants
a higher value, it sends a 423 with a Min-Expires header.

Cheers,
Shaun

Sonus Networks
www.sonusnet.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jain, Rajnish
Sent: Tuesday, January 24, 2006 4:26 PM
To: Jonathan Rosenberg; Mohsen Soroushnejad
Cc: [email-masked]
Subject: RE: [Sip] RFC 3261: Setting the expiration interval by
Registrar?

One way to look at this would be to define the Registrar's behavior in
such a way that it has complete control over the registration period
regardless of the expiration duration clients put in their REGISTER
requests. Just like a Registrar has valid reasons to lower the
registration period, it may have valid reasons to up the registration
period. 

Let's say a Registrar is getting swamped with registration refresh
requests and the resultant read and write operations on the Location
Service database. To combat this, the registrar decides to up the
registration period. While some clients may be able to honor this, some
clients (for good reasons) may not be able to honor this. The clients
that are able to honor this will back off and that will manifest as
reduced load on the Registrar. 
 
If a client, such as one behind a NAT, is not able to honor this it can
still go ahead and refresh bindings as frequently as it deems necessary.
I don't think RFC 3261 disallows the client from refreshing
registrations, for instance, every 60 seconds if the registration
expiration period reported by the Registrar was 3600 seconds. If we want
to somewhat relieve the registrar from frequent read and write
operations into the location service, then the client can issue
registration queries instead, which is a read-only operation.  

I think by giving Registrar a complete control over the registration
period, it helps the Registrar to deal with certain situations and it
also makes it less confusing to describe/implement the registration
period negotiation between the client and the Registrar. 

Just a thought,
Rajnish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Tuesday, January 24, 2006 2:58 PM
To: Mohsen Soroushnejad
Cc: [email-masked]
Subject: Re: [Sip] RFC 3261: Setting the expiration interval by
Registrar?

Mohsen Soroushnejad wrote:

> Can Registrar accepts a REGISTER request (send 200 OK) and set the 
> expiration interval
> to a value greater than one requested in the REGISTER?

No.

> The text in RFC 3261 (Section 10.3) (snippet below) is not explicit on

> on this question.
> It indicates that Registrar MAY reject a REGISTER request with 423 
> response code
> (if the conditions mentioned are met). Does it mean that it is also 
> allowed to accept
> the REGISTER and set the expiration interval to a value greater than 
> requested?

No. There may be reasons why the client wants its registration to expire

in a short time. Its better to play it safe by making the client do 
something active to keep its registration, rather than doing something 
active to remove it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.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

_______________________________________________
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

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Tue, 24 Jan 2006 18:03:51 -0500

On Tue, 2006-01-24 at 17:34 -0500, Jain, Rajnish wrote:
> smaller timer than it needs to?

I don't see what the point of all this is.  If the registrar is getting
overwhelmed, allowing it the luxury of setting longer timers while still
having to cope with the same frequency of REGISTER messages will make
little difference.

As Shaun Bharrat says, SIP provides the 423 response so the registrar
can demand that the UA registers for a longer period, which seems to
solve the problem you stated at the beginning.

If the UA is incapable of registering for longer periods, there is no
solution to the problem.  So the best result is to have the UA not
registered at all, to increase the chance that the user will notice the
problem and take corrective action.

In any case, SIP has clearly defined rules for how registrars and UAs
should behave.  If you'd like to propose an upward-compatible change
that would be an improvement, please do so...

Dale