Subject: RE: [SIP] SIP Registration interval

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2001 11:00:31 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 10:55 AM
> To: Baniel Uri-CUB001
> Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]'
> Subject: Re: [SIP] SIP Registration interval
> 
> 
> I suspect many clients already simply take the refresh 
> interval from the
> server, rather than doing a min(client,server) operation. Maybe it
> wouldn't hurt to put that into the spec, as it doesn't seem 
> to cause any
> backwards-compatibility problems. (At worst, clients refresh more
> frequently than they have to.) I'm against imposing any 
> arbitrary fixed
> lower value, for the same reasons that I outlined with regards to the
> number of Contact entries.

I agree with Henning. I believe we should change the wording such that the
client should use the refresh interval as specified in the 2XX registration
response, whatever the value. We would then strike the rule that the
registrars SHOULD NOT increase the value. I don't even recall why we put
this directionality constraint in there (can only decrease, not increase).
Henning, do you recall?

As per number of Contacts, I also agree that the spec should remain silent
on this. In general, a server may decide not to service a request for many
reasons. It may not want to support multiple contacts, or it may allow users
to register only specific contacts. Rather than define specific headers for
each of these cases (which, in many cases, there is nothing the client can
do anyway), the server can simply respond with a 500 class response, and
include something textual in the reason phrase. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 14 Mar 2001 14:59:33 -0500

There having been no objections to my original proposal, I modified the
draft accordingly.

I don't remember the motivation for the min(client_wants,
registrar_wants) rule. About the only reason I can think of is the
"client knows that it's going to be suddenly disappearing, so it wants
short refreshes" case, but this seems contrived. 
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 14 Mar 2001 18:45:24 -0500

> short refreshes" case, but this seems contrived. 

I always assumed the reason not to increase 
the expiration was to allow for a temporary 
override of a location preference.  This 
symbolized something like temporary forwarding 
(or temporary first try location).  Allowing 
the Registrar to increase the time interval 
would prevent such a service from acting as 
it was intended without the UA specially 
deregistering the location after the original 
expiration time.

From the Registrar's perspective, the only 
reason to increase the expiration time would 
be as means to hopefully reduce the number 
periodic REGISTERs from the UA.

I think that it would be beneficial to include 
something in Register response that indicates 
the preferred refresh rate without extending a 
contacts expiration time.  The specification 
could suggest that the UA use the suggested 
refresh rate when formulating the expires 
field of the next registration.

The same header could be used by the Session 
Timer draft so that a proxy or destination UA 
can ask the originator to not refresh 
so often without increasing the session 
expiration time associated with the current 
INVITE.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 15 Mar 2001 10:44:49 +0200

I don't think it's appropriate for a registrar to increase the registration
period for a client.  If I register for half an hour and I really only want
to be registered at that location for half an hour, I don't think the
registrar should override that and register me for 1 hour. It only means
that I have to remember to deregister, an extra transaction that could be
avoided.

The decrease is appropriate here so that clients for register for 100 years,
for example.

Regards,
Hisham Khartabil
Hotsip Finland
www.hotsip.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jonathan Rosenberg
Sent: Wednesday, 14 March 2001 6:01 PM
To: 'Henning Schulzrinne'; Baniel Uri-CUB001
Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]'
Subject: RE: [SIP] SIP Registration interval

-Jonathan R.
---

---

From: Stephen Terrill <[email-masked]>
Date: Thu, 15 Mar 2001 14:17:11 +0100

Hi Henning,

Can you clarify the proposal - is it that the client takes the registration time from the refresh rate in a 2xx registration response?  In this case, does this allow the registrar to increase the registration time if the original time requested by the client was considered to low.

If so, then this would seem appropriate.

..//Steve

---

From: Stephen Terrill <[email-masked]>
Date: Thu, 15 Mar 2001 14:22:14 +0100

Hi,

well - there are scenarios where the client may register with a shorter interval than would make sence in such an enviorment.  I am thinking of a case where there are a large number low powered terminals sharing a common signalling transport.  In this case, it would be better if the registrar requested the Ue to increase the registration timers in order to avoid unecessary use of the signalling transport.

I don't have a stronge opionion on how this is achieved, however I do feel that it is very useful in these scenarios.

..//Steve

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Mar 2001 08:30:54 -0500

> Can you clarify the proposal - is it that the client takes the registration time from the refresh rate in a 2xx registration response?  In this case, does this allow the registrar to increase the r…

Simple rule:

- Client takes registration interval from registrar.

- Unless something really strange is going on, the registrar uses
whatever registration interval the client wants.

Thus, the server decides, but in almost all cases, the client gets its
wishes. Exceptions were noted (100 year registrations).

I just don't see the value of further complicating this. The only reason
offered so far for a server to lengthen the registration interval was to
limit the refresh rate.

If there's a real need here, I had suggested a Require header to
indicate "strictly observe or fail".

---

From: "Hisham Khartabil" <[email-masked]>
Date: Thu, 15 Mar 2001 15:42:22 +0200

Hi,

You can probably fail with 403 "the server understood the request, but is
refusing to fulfil it".

Regards,
Hisham

-----Original Message-----
From: Stephen Terrill [mailto:[email-masked]]
Sent: Thursday, 15 March 2001 3:22 PM
To: Hisham Khartabil
Cc: [email-masked]
Subject: Re: [SIP] SIP Registration interval

Hi,

well - there are scenarios where the client may register with a shorter
interval than would make sence in such an enviorment.  I am thinking of a
case where there are a large number low powered terminals sharing a common
signalling transport.  In this case, it would be better if the registrar
requested the Ue to increase the registration timers in order to avoid
unecessary use of the signalling transport.

I don't have a stronge opionion on how this is achieved, however I do feel
that it is very useful in these scenarios.

..//Steve