Subject: Re: [SIP] SIP Registration interval

From: William Marshall <[email-masked]>
Date: Wed, 7 Mar 2001 14:53:23 -0500 (EST)

A further question about this interval negotiation...

Henning wrote:
> 
> Baniel Uri-CUB001 wrote:
> > 
> > Bis02 para 6.25 says:
> > 
> > "The server MAY choose a shorter time interval than that requested by the
> > client"
> > What is the rational behind? Is it just for reducing the table size at the
> > registrar? Is it also for getting better control from
> > validation/authentication/services perspective?
> 
> Yes. A server may not appreciate having to store your identity for the
> next 38 years. States time out so that UAs that crash (or whose network
> becomes disconnected for extended periods of time) don't tie up server
> resources forever.
> 

The server may also be concerned about the number of registration messages
it will need to process, and its ability to keep up with the traffic.

If the client requested a shorter interval than desired by the server
(example: server prefers 30 minutes, client request 5 seconds), how can
the server indicate a _lower_ bound for a reasonable interval?  Possibly
ignore the SHOULDNOT in 2543bis section 6.25?  If so, MUST the UAC comply?

Bill Marshall
[email-masked]

_______________________________________________
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: Eric Tremblay <[email-masked]>
Date: Wed, 7 Mar 2001 15:09:27 -0500

Could it be something like this?

SIP/2.0 4xx Expiration too short
...
...
Contact: sip:[email-masked]; expires=600

Where the contact found in the error would be the same contact as in the
request, with the minimum acceptable time?

EricT

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 14:53
> Subject: Re: [SIP] SIP Registration interval
> 
>

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 7 Mar 2001 14:35:58 -0600

Eric

Jonathan said a while ago that it did not make sense to the SIP authors to try "guarantee" well behavior of clients..
I tend to agree w/ him, since even if you control it in the application layer, a vicious client may still attack you with IP packets, which u have nothing to do about.

Also there are (and may be in the future as we go) features (such as remote pick up) that may need to enable a client choose a very small interval.

Let's put it this way, after a client is validated/authenticated we shall trust it to well behave...

===========================================
[email-masked], 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
===========================================

> From: Eric Tremblay [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 2:09 PM
> To: 'William Marshall'; 'Henning G. Schulzrinne'
> Cc: [email-masked]
> Subject: RE: [SIP] SIP Registration interval
> 
> 
>

---

From: Eric Tremblay <[email-masked]>
Date: Wed, 7 Mar 2001 16:11:53 -0500

Baniel, 

I agree with your first point. I was mainly focused on how a friendly UA
could find the minimal expire time that the server would like to
acknowledge.

Regarding the call pick up service, according to the latest SIP Services
examples draft, I don't think it would break anything to do as I suggested.

But first, I think we have to ask ourselves if a UA knowing the "minimum
expiration time" is a must in SIP?

EricT

> From: Baniel Uri-CUB001 [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 15:36
> To: 'Eric Tremblay'; 'William Marshall'; 'Henning G. Schulzrinne'
> Jonathan said a while ago that it did not make sense to the 
> SIP authors to try "guarantee" well behavior of clients..
> I tend to agree w/ him, since even if you control it in the 
> application layer, a vicious client may still attack you with 
> IP packets, which u have nothing to do about.
> 
> Also there are (and may be in the future as we go) features 
> (such as remote pick up) that may need to enable a client 
> choose a very small interval.
> 
> Let's put it this way, after a client is 
> validated/authenticated we shall trust it to well behave...
>

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 7 Mar 2001 15:17:01 -0600

Sure, I agree that this is a very valid question. Lets see what our other friends-2-the-list think about it..

> Sent: Wednesday, March 07, 2001 3:12 PM
> To: 'Baniel Uri-CUB001'; Eric Tremblay; 'William Marshall'; 
> 'Henning G.
> Schulzrinne'

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 7 Mar 2001 15:32:47 -0600

BTW, speaking about limits, I have not seen a limitation for number of
contacts in the spec.(for the registration request only! I am not sure
regarding redirection ) 
If the main reason for limiting the time interval (ceiling limitation) is
for making sure the registrar table is not growing too big, then wouldn't it
make sense to define max number of contacts allowed? 
Also if the registrar provides the contact information to a proxy server, do
we want the proxy server to search for ever?
(I know we can take care of this performance issue, with the timeout
parameters which are in place already)
Am I missing an existing mechanism/parameter, which is already in place?

> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 1:37 PM
> To: Baniel Uri-CUB001
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 7 Mar 2001 15:52:26 -0600

(Last email for today, I promise..)
I understand though that what Henning suggests below is not just concern about the registrar table growing too big, but also (or even somewhat more worried) being out of date, as a result of a client crash

> From: Baniel Uri-CUB001 
> Sent: Wednesday, March 07, 2001 3:33 PM
> To: 'Henning G. Schulzrinne'; Baniel Uri-CUB001
> BTW, speaking about limits, I have not seen a limitation for 
> number of contacts in the spec.(for the registration request 
> only! I am not sure regarding redirection ) 
> If the main reason for limiting the time interval (ceiling 
> limitation) is for making sure the registrar table is not 
> growing too big, then wouldn't it make sense to define max 
> number of contacts allowed? 
> Also if the registrar provides the contact information to a 
> proxy server, do we want the proxy server to search for ever?
> (I know we can take care of this performance issue, with the 
> timeout parameters which are in place already)

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 7 Mar 2001 16:47:57 -0600

> Contact: sip:[email-masked]; expires=600

Using the Contact: address in this fashion is a bit odd.
I would prefer a header along the lines of 

Min-Expiration: ...

A rejection of the REGISTER with multiple Contact:s should
be a rejection of all Contact:s.

> request, with the minimum acceptable time?

/sean

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 7 Mar 2001 16:54:04 -0600

> limitation) is

The main reason for limiting the time interval is to limit the 
rate of incoming REGISTER requests, not to limit the registrar
table size.

Limiting the max. no. of contacts is a good idea as well.
"400 Too Many Contacts" feels about right.

> proxy server, do

The proxy has the same discretionary control that the registrar
has.  The difference between this case and the need to 
specify a lower bound on the expiration time is that the proxy
has direct control. Granted, specifying a minimum expiration time
requires a cooperative UA, but that applies to almost all of SIP.

/sean

---

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 08 Mar 2001 14:30:11 +0000

Ok, now back to the question of imposing a lower bound on the registration
time interval....What are the thoughts?

Tina Iliff

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 8:24 AM
To: Baniel Uri-CUB001
Cc: 'Sean Olson (EUS)'; [email-masked]'
Subject: Re: [SIP] SIP Registration interval

> Sounds like 412 may just do it.. 

No, 412 is definitely the wrong one; this has nothing to do with
preconditions. (SIP doesn't define 412, but any status codes that are
used in HTTP are not redefined with another meaning.)

Generally speaking, this is a server problem, so it should take the 500
blame. The client has done nothing wrong. Except in extreme cases
(hundreds of Contact headers), I would guess that any
industrial-strength server won't have to worry about limiting this,
unless this is used by lots of clients in a concerted denial-of-service
attack. Certainly, anything like eight is far too restrictive.

The more error conditions and restrictions you impose, the more tech
support headaches you incur. My guess is that in most cases, a few
microcents of disk space is the far better trade-off. (Even with a 1000
bytes of Contact, we're talking a storage cost of 0.0005 cents here. You
have to have a lot of long Contact headers before you've made up for one
tech support call.)

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Thu, 8 Mar 2001 09:53:38 -0600

OK. point is taken..

> Sent: Thursday, March 08, 2001 9:50 AM
> To: Baniel Uri-CUB001
> > Yes, it definitely makes sense what you say. perhaps we can 
> just offer it as
> > a recommendation (as opposed to restriction) for the client 
> to limit number
> > of contacts to X (when X = ?). And then it is truly a 
> server fault if it can
> > not handle the contacts, since it was only a recommendation 
> for the client,
> > and thus the 500 range is indeed the right one..
> > 
> 
> Any such recommendations will be taken by server vendors as a 
> license to
> restrict things or not to test values above these arbitrary 
> limits. The
> spec is long enough as is; the last thing we need is more 
> implementation
> details that have no meaning and no reasonable way to decide on these
> constants (My definition of "reasonable" is as valid as anybody
> else's.). If servers should accept more Contact headers, why recommend
> that clients restrict themselves to some arbitrary number that may or
> may not be appropriate for a particular application?
> 
> In general, IETF specs do not take the role of RFI, purchase
> specifications, product manuals or implementation descriptions.
> 
> The fewer arbitrary limitations or magic constants specs have, the
> better.
>

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 14 Mar 2001 13:50:23 -0600

Gee I can swear my daughter told me yesterday that they (Sesame Street)
have taught the letter 'z' already :)
Anyhow, I begin to get the generic idea of letting the spec be as much opened and generic as can be and focusing on increasing the ability of providing things rather than looking for constraining the system..

Thanks!

Uri

> Sent: Wednesday, March 14, 2001 12:56 PM
> To: Baniel Uri-CUB001
> Cc: 'Jonathan Rosenberg'; 'Iliff, Tina'; 'Sean Olson (EUS)';
> [email-masked]'
> > number of Contacts - Basically agree with what you say. 
> have a question
> > though... Would it be silly/redundant/possible of a client 
> to use the
> > OPTIONS request to find out if there is an upper bound 
> limitation on number
> > of contacts it can use with given server? (I think it may 
> be beneficial for
> > a client that serve many users (e.g. multi user host) and 
> have many hits
> > with the same registrar) (I know it may sound like an implementation
> > question..)
> 
> This is another direction I don't think we want to go to. As 
> stated, in
> almost all reasonable cases, clients should never, ever have to worry
> about these things. Otherwise, instead of implementing OPTIONS to say
> "sorry, I only support 7 Contact headers", developer effort is much
> better spent increasing that limit to effectively infinity (which, in
> practice, you have to work hard it not to be). This is a deep 
> rat-hole,
> as the policy restrictions on registrations are endless. Do 
> you want to
> construct a language that says "Sorry, being MSN, I don't accept yahoo
> mail addresses, and by the way, email addresses can only be 25
> characters long and I don't like the letter "Z" since Sesame Street
> hasn't gotten around to that one yet; please also avoid 
> registering tel:
> URLs on Fridays, and certainly don't register any 10288 tel: URL since
> I'm paid by AT&T; also, don't register 
> http://www.whitehouse.com as your
> URL, since it's a porn site."?
> 
> In short: for parameters that have to have reasonable limits and where
> policy comes into play, this is a network management issue. For
> everything else, the old maxim "Computer Science only knows three
> numbers, zero, one and infinity" is a good one.
> 
> --

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Wed, 14 Mar 2001 19:52:47 -0600

Henning

We said there could be all kind of cases in which the client may want to be able to re-register within a short interval.
Remotely pick-up (as you wrote in the 2543 Bis) is an example...

Uri

> Sent: Wednesday, March 14, 2001 2:00 PM
> To: Jonathan Rosenberg
> Cc: Baniel Uri-CUB001; 'Iliff, Tina'; 'Sean Olson (EUS)';
> 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. 
> --

---

From: <[email-masked]>
Date: Thu, 15 Mar 2001 09:45:45 -0000

Hi All,

(Please bear in mind I from a cellular background, and I do (try to)
appreciate that SIP can never be compared too closely with any 'cellular'
protocols)

However, reading this particular discussion, it would appear that some
distinction between the 'type of REGISTER', similar to something we use in
GSM, GPRS and UMTS, might be useful.

One issue is how often the registration should be refreshed, based simply on
network dynamics (e.g. how long does the registrar want to keep a record for
a user, how often is the UAC likely to disappear, how often is the registrar
likely to restart, etc...)

A different issue is where there is a change of registration information
(i.e. a change in where a user wishes to be contacted...)

So, is there any value to be gained by introducing a header in the REGISTER
request to indicate either 'Re-fresh registration' (no change of contact
details) or 'Temporary registration' (change of contact details)?

Now, I wouldn't propose that the registrar has to start keeping two
registration records for each user who happens to send a 'temporary'
registration.  I'd simply use it to indicate the following to the registrar,
in the REGISTER request:

'Re-fresh registration' - If the 'expires:' header contains a value the
registrar doesn't agree with, then this value can be re-assigned by the
registrar in the response.

'Temporary registration' - The 'expires:' header will contain a value,
chosen by the user, indicating the period of time for which the new contact
details are valid.  The registrar SHOULD NOT overrule this.

Obviously there would need to be rules for what to do if the re-fresh timer
expires whilst the temporary timer is still running, but I think that could
be overcome.

This is only a personal opinion and your comments/opinions would be most
welcome.

Duncan MILLS
Vodafone (UK)

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]]
Sent: 15 March 2001 08:45
To: Jonathan Rosenberg; 'Henning Schulzrinne'; Baniel Uri-CUB001
Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]
Subject: RE: [SIP] SIP Registration interval

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

> Sent: Thursday, March 08, 2001 10:55 AM
> To: Baniel Uri-CUB001
> Cc: 'Iliff, Tina'; 'Sean Olson (EUS)'; [email-masked]'
> 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

---

From: Baniel Uri-CUB001 <[email-masked]>
Date: Thu, 15 Mar 2001 10:17:05 -0600

It sounds very good, Jonathan!
The idea of having a client need to 'implicitly convince/prove' (over time..) why it needs what it requests for, may sound scary at the first place for some servers developers, but it definitely adds more fine tuning capability to the SIP system/network!
We may even leverage your idea to other cases, beyond registrations scenarios... but yes, first thing first...

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 9:27 AM
> To: 'Henning Schulzrinne'; [email-masked]
> Cc: [email-masked]'
> > Sent: Thursday, March 15, 2001 8:31 AM
> > To: [email-masked]
> > Cc: [email-masked]'
> > Stephen Terrill wrote:
> > > 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.
> > 
> > Simple rule:
> > 
> > - Client takes registration interval from registrar.
> > 
> > - Unless something really strange is going on, the registrar uses
> > whatever registration interval the client wants.
> 
> The only issue is how the server can differentiate between small
> registration lifetimes which are useful for some services 
> (and should be
> allowed), and small registration lifetimes that will be used 
> continuously
> (which the server may want to disallow). I would suggest that 
> the two cases
> can be differentiated, if needed, by heuristics at the 
> registrar. When a
> contact is registered with a lifetime below X, its accepted, 
> and the server
> increments a counter for this registration. Everytime that contact is
> refreshed in less than X seconds, the counter is bumped. If 
> it exceeds N,
> the server can return some larger expiration time in the next 
> refresh. 
> 
> This works assuming that short lived registrations for these 
> services are
> "one-shots", which seems to be the case so far.
> 
> -Jonathan R.
> 
> ---

---

From: Gordon Ledgard <[email-masked]>
Date: Thu, 15 Mar 2001 14:21:46 -0500

I think the registrar should be allowed to do either. I think
that decision should be left up to the implementer of the
registrar. I don't see that these two options are mutually
exclusive within a network. Or am I missing something?

Gordon Ledgard
IPeria, Inc.
[email-masked]
(781) 993-3540

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 1:58 PM
To: Gordon Ledgard; 'Jonathan Rosenberg'; 'Henning Schulzrinne';
[email-masked]
Cc: [email-masked]
Subject: Re: [SIP] SIP Registration interval

Jonathan's proposal would retain the registrar's ability to increase the
expiration time. Would it be better to not allow the registrar to lengthen
the expiration time, but have the registrar reject the request when it
figured out that the client was doing periodic refreshing too frequently and
suggest a more acceptable refresh rate?

Bob Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Gordon Ledgard" <[email-masked]>
To: "'Jonathan Rosenberg'" <[email-masked]>; "'Henning
Schulzrinne'" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 15, 2001 10:40 AM
Subject: RE: [SIP] SIP Registration interval

>
> I would agree with Jonathan, but extend the statement a bit.
>
> I would expect that registrars should be free to disallow any
> sort of registration based on any sort of algorithm or heuristic
> they wished, including unrealistic subscription times. I
> don't really think the registration mechanism itself (IE the
> SIP transactions rules) ought to be dictating rejection
> algorithms within registrars, except to say how to perform
> the rejection.
>
> Different registrars will have funamentally differing
> capabilities.
>
> Gordon Ledgard
> IPeria, Inc.
> [email-masked]
> (781) 993-3540
>
> Sent: Thursday, March 15, 2001 10:27 AM
> registration lifetimes which are useful for some services (and should be
> allowed), and small registration lifetimes that will be used continuously
> (which the server may want to disallow). I would suggest that the two
cases
> can be differentiated, if needed, by heuristics at the registrar. When a
> contact is registered with a lifetime below X, its accepted, and the
server
> refreshed in less than X seconds, the counter is bumped. If it exceeds N,
> the server can return some larger expiration time in the next refresh.
>
> This works assuming that short lived registrations for these services are