Subject: Re: [Sip] Open Issue #282: Timer C needs minimum for proxies

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 01:24:31 -0500

Robert Sparks wrote:

> This is related to the question of how proxies treat
> an Expires header in an INVITE. If we ask a proxy to
> remain aware of that header, it will influence timer C
> and we have to answer what the timer should be if there
> is no Expires header present.

I see the Expires issue as orthogonal. Whether or not proxies
look at expires, we need to have a minimum value for timer C
at proxies.

> 
> If proxies remain aware of the Expires header, I expect
> most of them to have a policy that limits how large 
> timer C can be made (otherwise, they increase their 
> vunerability to state-depletion DoS through lots of
> INVITEs with very long Expires). 
> 
> I propose we recognize this policy and base timer C
> at a proxy on that alone, recommending a reasonably
> long value.

I'm not certain what "that" refers to in the sentence above.

> 
> With this proposal, a proxy would not even need to parse
> the Expires header for an INVITE. If an Expires header
> is present with a shorter value than what the proxy
> uses for timer C one of four things will happen:
> 
> 1) the receiving endpoint with 408 the request - the
>    proxy's client transaction gets to enter
>    the completed state
> 2) the requesting endpoint CANCELs and the receiving
>    endpoint returns a 487 - the proxy's client transaction
>    gets to enter the completed state
> 3) the requesting endpoint CANCELS but the receiving
>    endpoint fails to return a 487 - the proxy's client
>    transaction enters the terminal state after 
>    timer C expires
> 4) both endpoints (or the network infrastructure) are
>    misbehaving - the proxy's client transaction enters
>    the terminal state after timer C expires.

I think this is totally orthogonal. I don't want to sidetrack this 
thread into a discussion on whether proxies should CANCEL when an INVITE 
Expires. I will open an issue on that and post separately.

> 
> If this is acceptable, it still leaves us with the question
> of what value we should recommend. I propose something
> long - order of .5 to 1 hour (remember that calls stay in a 
> provisional state with early media when you are in the queue
> to talk to an AA representative).

Egads, thats a long time! Your point on early media is well taken, 
though. Arguably, if this case happens, 1 hour is not even enough, since 
I have certainly been on hold for durations longer than that. Probably 4 
hours is more reasonable. Once you've set the timer this high, it may as 
well be any finite number as far as the proxy is concerned. The only 
value in having a number at all (as opposed to infinity) is very long 
term garbage collection. You will get NO DoS attack prevention from 
numbers of this magnitude. You really need to be careful, as a proxy, to 
not create transaction state unless the request is authenticated somehow.

-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: "Bob Penfield" <[email-masked]>
Date: Thu, 27 Dec 2001 08:02:39 -0500

> not create transaction state unless the request is authenticated somehow.
I don't think this really applies. I believe that most ACD systems that put
you on hold actually do answer the call. Especially ones that have DTMF
menus since some carriers block the caller to callee connection until it is
answered. Many TDM switches that I have experience with will tear down an
unanswered connection after 1 or 2 minutes. I think a 2 or 3 minute timer
would be adequate.

But, this is not the TDM world. So, if we want to provide for unanswered
calls being queued for long periods of time, maybe we could require the UAS
to send periodic provisional responses and the proxy could reset Timer C.
But that may be getting to complicated.

Service providers who charge for these calls don't want their resources used
for free for such a long period of time.

cheers,
(-:bob