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

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Jan 2002 15:54:58 -0500

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 2:11 PM
> To: Robert Sparks; Jonathan Rosenberg; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Open Issue #290: Registrar increasing registration
> life time
> 
> 
> My real point is that the "Expires" value
> is not a hard concrete number that will 
> necessarily be obeyed in as precise a manner
> as you seem to want. I understand that it may
> not be feasible to de-register for some applications.
> 
> The real question is how much does it hurt to have
> that (soft)state in the network? How critical
> is it to your service that the registrar purge
> the state at that time?

Potentially alot. (yes, I know the removal time
will be fuzzy, but if I ask for an hour,
having stuff stay around for a week will
break things).

> 
> /sean
> 
> --- Robert Sparks <[email-masked]> wrote:
> > It _used to be_ negotiation and it still should be!
> > 
> > The point you miss below is being able to turn it
> > off.
> > By allowing a registrar to extend the registration
> > interval,
> > you add a burden for the endpoint to actually be
> > around to
> > unregister itself instead of having the state just
> > go away.
> > This clobbers a whole class of applications where
> > registration
> > and use of the registered information is highly
> > decoupled.
> > (3rd party registrations for example).
> > 
> > RjS
> > 
> > > -----Original Message-----
> > > From: Sean Olson [mailto:[email-masked]]
> > > Sent: Thursday, January 10, 2002 1:44 PM
> > > To: Robert Sparks; Jonathan Rosenberg;
> > [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Sip] Open Issue #290: Registrar
> > increasing registration
> > > life time
> > > 
> > > 
> > > 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:
> > > > 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
> > 
> === message truncated ===
> 
> 
> =====
> --
> Sean Olson <[email-masked]>
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 16:20:25 -0500

Robert Sparks wrote:

> having stuff stay around for a week will

I don't feel all that strongly here, as I see points on
both sides. I think much of the issue depends on whether
or not registration times are really used to drive services
or not.

Robert, I would ask that more specific
examples be provided to assist in resolving the issue.
Also, I'd welcome thoughts on some of the other points
Brett raised, specifically, the fact that there is a backwards
compatibility issue with sending an error response if the interval
is too short.

-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