Subject: [Sip] Open Issue #290: Registrar increasing registration lifetime

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 12:30:41 -0500

The spec now says that the registrar can increase the registration 
interval.
This is done to protect the registrar from clients that want to refresh too
frequently. However, this introduces interesting complications:

   a. it can't really increase Expires: 0, since we do need a way to 
terminate a
registration, so we would need to special case 0
   b. the client may choose to register an interval because they want the
information to die at a specific time (husband registering his phone at his
mistresses number for a brief period, REALLY wants it unregistered when 
he asks)

So, do we really want to allow the registrar to increase the interval?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: [email-masked] (Henning Schulzrinne)
Date: Thu, 27 Dec 2001 18:52:36 +0100

I agree that this is of limited usefulness. If a client wants to pester
the registrars with frequent renewals, it doesn't need a lower refresh
interval for that.

If cooperative clients that are too eager need to be advised, one should
probably introduce some 5xx error code "Registration interval too
short". Designing a registrar installation that can't handle the nominal
1 hour interval for its user population seems ill-advised.

Banner headline in Washington Times: IETF changes Internet to accomodate
depravity - congressional hearing soon

---

From: Vijay Gurbani <[email-masked]>
Date: Thu, 27 Dec 2001 13:23:02 -0600

Jonathan Rosenberg wrote:
> interval.  This is done to protect the registrar from clients that want to 
> refresh  too frequently. However, this introduces interesting 
> complications:
> 
> terminate a registration, so we would need to special case 0
> information to die at a specific time (husband registering his phone at 
> his mistresses number for a brief period, REALLY wants it unregistered 
> when he asks)
> 

Yes, I would think so; although there is nothing stopping a trigger happy
(or paranoid) UA from sending REGISTERs every second.  

As for (b), the husband should really not be using his SIP phone at such an 
compromising location :-).  Assuming he did, he can de-register within what-
ever small time interval he needs by sending another REGISTER, Expires:0 
which should be honored, as per (a).

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: Ben Campbell <[email-masked]>
Date: 28 Dec 2001 12:54:17 -0600

Actually, I really hate letting a registrar increase the interval, for a
few reasons:

1) As you mention, Expires:0 would then require special case processing.

2) The registering device should be the "owner" of its registration. It
is the only thing that has any hope to know the lifetime that its
registration is meaningful. If it sends a short Expires header, one must
assume to some degree it knows what it's doing. If it's choice of
Expires violates network _policy_, then a better solution would be to
send some sort of error response, perhaps containing the minimum allowed
expiration. If the device is willing to play by the local rules, it
registers again. If not, it takes its user and goes home.

3) Since there is no way to enforce that a client does not re-register
well before the expiration time, forcing a larger expiration is a fairly
weak solution to registration rate problems. Since older implementations
had a reasonable expectation that the Expires value would not increase,
they may not check for the condition.