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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 17:10:15 -0500

Issue:

The spec says that Timer C is specified by the TU. Timer C defines how long
the 
client invite transaction waits for a final response after a provisional.
Having this 
be entirely defined by the TU makes sense when the TU is a UAC (i.e., how
long you let the phone ring is a matter of local policy). But, for a 
proxy, its a different story. If the proxy transactions give up immediately,

calls will not function properly. Thus, for this to work, proxies need to
have a 
minimum value for timer C. 

Proposal:

The proposal would be to have 32s as the minimum. This value is somewhat
arbitrary.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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: [email-masked]
Date: Thu, 6 Dec 2001 15:49:03 -0700

I agree with the proposal, but wonder if the arbitrary number chosen might
be a bit short.  In the PSTN, 32 seconds typically equates to 5 rings in the
US.  Grandma might not make it to the phone in time...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 3:10 PM
> To: [email-masked]'
> Subject: [Sip] Open Issue #282: Timer C needs minimum for proxies
> 
> 
> Issue:
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Dec 2001 16:57:36 -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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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).
> 
> I agree with Robert's proposal above, but disagree somewhat 
> in that proxies
> need not parse the Expires header.  I think they should, and 
> here's why.
> 
> The default value for a proxy's Timer C -- 1/2 to 1 hr -- 
> should kick in
> if the proxy receives a 183 from (one of) the UAS.  If all 
> the proxy got was
> a 100 or a 180, and the UAC included an Expires header which 
> is much less
> then the proxy's default Timer C (.5-1hr), I don't think it 
> hurts to have 
> the proxy honor it.  Of course, this means that within the 
> 1xx class of 
> responses, proxies will have to look for 183...
> 
> - vijay

(hit send too soon)
As I said before, nothing would keep a proxy from looking
at the Expires header as an optimization - I just don't
see it being a requirement.

If a proxy _does_ look at the Expires header, I would have
it wait a bit to see if either endpoint bails out of the
transaction - the way we have things written now, its a
race to see whether the endpoints or one or more proxies
in the chain start trying to tear the transaction down
first.

RjS

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 10 Dec 2001 16:01:50 -0800

I completely agree John: having an arbitrary *proxy* dictate the maximum
ring time for an endpoint is totally unacceptable in my opinion - this
should be decided by the user-agents alone. I understand the problems this
causes when trying to return final response when forking but that is still
not a justification for a *proxy* to terminate a *ringing* phone simply so
it can return a failure cause?!?!?!? Timer C must be _at least_ an order of
magnitude larger than 32secs (10 minutes?) - large enough not stop a phone
ringing in a reasonable time but short enough to protect itself. 

Robert.

> From: [email-masked] [mailto:[email-masked]]
> Sent: 06 December 2001 22:49
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] Open Issue #282: Timer C needs minimum for proxies
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Dec 2001 10:14:22 -0500

inline

> > 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
> 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.

Agree - we need a minimum value. I was interpreting minimum
to be default which led me down this path. Expires _definitely_
should override a default.

> > 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
> > 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.
that == "this policy" (described in the paragraph above).
> > 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
> >    endpoint returns a 487 - the proxy's client transaction
> >    gets to enter the completed state
> >    endpoint fails to return a 487 - the proxy's client
> >    transaction enters the terminal state after 
> >    timer C expires
> >    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.
> 
> 
> > 
> > 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
> http://www.jdrosen.net                  PH:  (973) 952-5000