Subject: Re: [Sip] Default value for Timer C (was #282)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jan 2002 17:32:57 -0500

This thread has stalled, and I think it requires some further input 
before we can resolve it.

The issue was this: what minimum timer do we mandate for a proxy to hang 
onto invite transaction state after receiving 1xx? The issue is that 
some PSTN systems (american airlines in particular), appear to use early 
media while a user is on hold waiting, or using the DTMF based IVR 
system. The result is that a call from a PC to a PSTN number could, in 
theory go legitimately unanswered for hours, perhaps. This would require 
that Timer C in proxies be on the order of hours, which is quite large.

An alternative is to not consider this case, and choose a smaller value, 
on the order of minutes.

Both can result in DoS attacks, although in this case, the proxy 
shouldn't be storing transaction state for unauthenticated requests.

Determining whether or not to go with a large value depends a lot on how 
common such systems are in the PSTN, and what the expectation is for 
them to be properly supported.

Further inputs?

-Jonathan R.

Bob Penfield wrote:

>>>I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>
> 
> The same problem occurs using old-world TDM equipment. If I use my
> calling
> card account to call AA, it hangs up after about a minute because the
> calling card platform has a 60 second answer timer. AA is trying to save
> money by having their ACD not return an answer and thus they don't have
> to
> pay for the 800 call.
> 
> BTW, all billing is based on answer (2xx for SIP) being returned by the
> called party. Some systems (usually in hotels) do use a timer when
> answer
> cannot be determined reliably (or they don't care).
> 
> I'm curious as to whether this was isolated to a proxy or is it possible
> the
> TDM side of the gateway is dropping the call? If gateways have answer
> timers
> on this order of magnitude, having a really long timer in the proxy
> won't
> help.
> 
> In any event, do we really need to support these cheaters in SIP and
> open
> ourselves to DOS attacks?
> 
> 
>>I have exactly the same experience.
>>As for:
>>
>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing,
>>>
>>I don't know how to tweak to and I don't ever want to know.
>>
>>Is there a better approach to fix the timer value or am I missing
>>something?
>>
>>Thanks, Henry
>>
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>
>>Robert
>>
>>>Sparks
>>>Sent: Thursday, December 27, 2001 9:57 AM
>>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks
>>>Cc: [email-masked]
>>>Subject: [Sip] Default value for Timer C (was #282)
>>>
>>>I'm talking about a _real problem_ that I have
>>>_right now_ with the UAs on my desk and the gateways
>>>I have access to. I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>Try it - call +18004337300 - my environment drops the unanswered
>>>call about 58 seconds into the first menu (yes, the first menu
>>>is over a minute long).
>>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing, I could
>>>work around it. But what about my tweak-phobic aquaintances
>>>and relatives?
>>>
>>>In this case, the endpoints are dropping the call, but if I had
>>>otherwise behaving endpoints, and a proxy in the middle with a
>>>_default_ Timer C value that is too small, I am left with
>>>at least one well-known service that just doesn't work.
>>>
>>>Now, we could get into a discussion about whether or not a service
>>>_should_ run a whole bunch of time in an early media state, but
>>>that's rather moot - we've worked really hard to make the system
>>>allow it, and it will be used. We're here on purpose, not by
>>>misfortune of oversight.
>>>
>>>As for your last paragraph - who says early media has to be free?
>>>
>>>RjS
>>>
>>>
>>>
>>>>From: Bob Penfield [mailto:[email-masked]]
>>>>
>>>>>>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.
>>>>
>>>>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
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>>>
>>
> 

-- 
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: "Brett Tate" <[email-masked]>
Date: Mon, 7 Jan 2002 19:36:10 -0500

> them to be properly supported.

Using a reasonable Expires header allows 
a value to be communicated to the UAS 
to send a final response within Expires time.  
Proxies can shorten the value if desired.

Thus a UAS can allow an infinite setup 
time when nobody cares.  And a UAS is
forced to switch from a setup state to
final response when a device within the
dialogue refuses to allow indefinite setup
times because of resource/billing issues.

Concerning the 'hold waiting' scenario, 
it forces the gateway to switch to a
200 prior to expiration or send 408 upon 
expiration.

I think the recommended default time should 
be around 3-5 minutes.  However for backward 
compatibility, the UAC/proxy might want to 
add an Expires header since the lack of it 
currently indicates infinity.