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

From: Robert Sparks <[email-masked]>
Date: Sun, 9 Dec 2001 12:33:54 -0500

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

RjS

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 4:49 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip] Open Issue #282: Timer C needs minimum for proxies
> 
> 
> 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:
> > 
> > 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
> > 
> 
> _______________________________________________
> 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

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 10 Dec 2001 14:36:45 -0600

Responses inline.

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
> 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
> 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
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184