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

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

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

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?

/sean

> > > > Jonathan D. Rosenberg, Ph.D.            72
=== message truncated ===

=====