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

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Dec 2001 16:51:05 -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...
> 

Nothing would keep a proxy from doing this as an optimization.
I just don't see it as a requirement.

RjS

_______________________________________________
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 K. Gurbani" <[email-masked]>
Date: Mon, 10 Dec 2001 17:05:17 -0600

Robert Sparks wrote:

> vkg>
> vkg> I agree with Robert's proposal above, but disagree somewhat
> vkg> in that proxies
> vkg> need not parse the Expires header.  I think they should, and
> vkg> here's why.
> vkg>
> vkg> The default value for a proxy's Timer C -- 1/2 to 1 hr --
> vkg> should kick in
> vkg> if the proxy receives a 183 from (one of) the UAS.  If all
> vkg> the proxy got was
> vkg> a 100 or a 180, and the UAC included an Expires header which
> vkg> is much less
> vkg> then the proxy's default Timer C (.5-1hr), I don't think it
> vkg> hurts to have
> vkg> the proxy honor it.  Of course, this means that within the
> vkg> 1xx class of
> vkg> responses, proxies will have to look for 183...
> 

Problem with optimizations are that they may not be immediately 
apparent to the uninitiated implementor.  Maybe putting it in as
a SHOULD...but I will defer it to the authors for a final conclusion.
 
- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software/IN Architecture Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713
0184