Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Jan 2002 14:08:42 -0500

I still feel strongly that the registrar should only shorten
the lifetime of the registration. The spirit should be
negotiation, not server assignment. With the registrar extending
the expiration, there is no way for the client to object to
an excessive time (requiring it to remember when it really
wanted to "deregister" defeats the whole purpose of softstate).

RjS

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 12:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Open Issue #290: Registrar increasing registration
> life time
> 
> 
> Brett makes some excellent points. Thanks for recapping
> the old discussion.
> 
> Based on this, I would therefore propose to keep what
> we have, and allow the registrar to increase the durations,
> indicating that an exception should be made for 0, and
> document that this means setting registrations with
> expires is not the right way to get call services.
> 
> Let us resolve this issue finally.
> 
> -Jonathan R.
> 
> Brett Tate wrote:
> 
> >>The ONLY thing solved by the increasing-duration 
> >>capability was to handle compliant, but 
> >>"overly zealous" user agents. There is no 
> >>disagreement that it doesn't help with dos 
> >>attacks.
> >>
> >>Perhaps the right solution, then, is to allow 
> >>registrars to only decrease, and to provide an 
> >>error response code to provide a general 
> >>"you're sending too fast, slow down" capability, 
> >>which would also be helpful for SUBSCRIBE, for 
> >>example, which will suffer the same problem.
> >>
> >>Comments?
> >>
> > 
> > All of these same points were raised last summer
> > around the time we were also trying to address 
> > short Session-Expires.
> > (Sorry, I couldn't reach 
> > http://lists.bell-labs.com/pipermail/sip/
> > to link the thread).
> > 
> > At that time, the decision was that the REGISTER
> > was not intend to register services like temporary 
> > call forwarding through the use of the expires
> > header or parameter.  Nobody was overly opposed 
> > to the backward compatibility issue with rfc2543.
> > People didn't really think reallocation of a
> > contact to a different subscriber would really
> > be an issue.
> > 
> > The problem with returning an error response is
> > that non-bis compliant UAC's would reduce the
> > response to 400.  Thus it might actually produce
> > more registrations and restrict the user from 
> > receiving calls until customer support 
> > communicates what the timer should be.
> > 
> > The problem with UAS extending the timer is that
> > non-bis compliant UAC might continue to register
> > based upon original expires.  This isn't that
> > big a deal.  The registrar could kick off an
> > email, auto-call, or begin rejecting the REGISTER
> > to ensure the situation gets corrected.
> > 
> > Ultimately, I don't mind which solution is 
> > chosen, I would just like to see it closed 
> > for good.  If a vote is required, I'd prefer
> > allowing the registrar to modify the 
> > expires however it desires as long as it
> > gets communicated back to the UAC so it knows
> > when to refresh or cancel the registration.
> > This would help avoid the need for user 
> > reconfiguration since the UAC gives the
> > preference and the UAS gives the decision.
> > 
> > 
> 
> 
> -- 
> 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
> 

_______________________________________________
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: Sean Olson <[email-masked]>
Date: Thu, 10 Jan 2002 11:43:46 -0800 (PST)

But this isn't negotiation. The expiration value
defines state/service in the server. Ultimately
it is completely up to the registrar to determine
how long it will maintain state for. If the server
decides to increase the value, the only impact
to the client is that it needs to send a de-REGISTER
if it truly wants a smaller registration period.
I don't think this is significant because the client
will likely have implemented logic to handle 
re-REGISTERs anyways (i.e. the client has a notion
of how long it's registration state is valid for 
and is maintaining a timer of sorts to determine
when to send a re-REGISTER.)

I strongly
agree with the notion of soft-state. I would
go further and say that registration is actually
"fuzzy" state meaning that we are not really
talking about well defined or crisp time boundaries
here. The difference between holding state for
10 seconds or 15 seconds is not significant for
instance. And as Jonathan pointed out, services
should not depend on such crisp values. I don't
believe that having to send a de/re-REGISTER is
a violation of soft state.

--- Robert Sparks <[email-masked]> wrote:
> > Sip mailing list 
> http://www1.ietf.org/mailman/listinfo/sip
> Sip mailing list 
> http://www1.ietf.org/mailman/listinfo/sip

=====
--
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/