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

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Jan 2002 11:33:49 -0500

3 minutes seems a reasonable compromise. That will allow all but one of the
ringtime
applications I am aware of work. I will begrudgingly accept it.
 
What this means is that any application that has a ringtime component can
only
count on the overall system providing a maximum of 3 minutes of ringtime
(since
some proxy in the path may have chosen to set Timer C to its 3 minute
minimum).
 
It also means that until we do some other kind of work, we preclude access
to
american airlines telephone service from the SIP world. (I _have_ stayed in
the queue
on their system for significantly longer than 5 minutes from multiple
residential, wireless,
and PBX phones, so something besides the timers discussed below is in play).
So, since the consensus is that really long timer C's are not the way to
address this
problem, what's the alternative? Pretending the problem doesn't exist is
unacceptable.
 
RjS

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 9:38 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Default value for Timer C (was #282)

When I worked on the DMS several years ago, the timer was configurable, the
company set it for 2 minutes.  I'm hearing a general concensus the timer
should be in the 1-5 minute range.  Perhaps 3 minutes would be agreeable to
most.  Haven't heard anyone new pipe up for very long times...
 
John Hearty
Level3

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 8:10 AM
To: 'William Marshall'; [email-masked]
Subject: RE: [Sip] Default value for Timer C (was #282)

A long time since I looked at that code, but I seem to recall a timeout
after three minutes of ringing on the DMS. 

-----Original Message----- 
From: William Marshall [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, January 07, 2002 10:12 PM 
To: [email-masked] 
Subject: Re: [Sip] Default value for Timer C (was #282) 

In the circuit switch world, the equivalent of "Timer C" exists. 
On a 5ESS, ringback turns to fast busy after 3 minutes.  On a 4ESS, 
it happens after 90 seconds.  (Both figures were as of a few years 
ago, but I doubt they have changed).  Perhaps someone from Nortel 
could speak of the DMS switches.  Also as of a few years ago, 
business customers paid for ring time, so if still true, it is not 
clear why AA is "cheating". 

So a timeout value of a couple of minutes (like 4) would work 
just fine for calls into the PSTN, and would only get hit for 
a high-and-dry type of defect. 

Bill Marshall 
[email-masked] 

-----original message----- 
From: [email-masked] 
Subject: RE: [Sip] Default value for Timer C (was #282) 
Date: Mon, 7 Jan 2002 15:56:14 -0700 

 I agree with Bob.  AA is apparently cheating here, doing all their IVR 
functions without returning answer.  I vote for the alternative, choosing a 
value on the order of minutes (not more than maybey three or four). 

John Hearty 
Level3 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, January 07, 2002 3:33 PM 
To: Bob Penfield 
Cc: Henry Sinnreich; 'Robert Sparks'; [email-masked] 
Subject: Re: [Sip] Default value for Timer C (was #282) 

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]
<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]
<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
<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
<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 <http://www.jdrosen.net>                   PH:  (973)
952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  

_______________________________________________ 
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
<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
<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
<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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 11:59:35 -0500

Robert Sparks wrote:

> It also means that until we do some other kind of work, we preclude
> access to
> american airlines telephone service from the SIP world. (I _have_ stayed
> in the queue

Actually, its not clear to me that things won't work with timer C at 3m. 
Lets say you've called AA, and after 3m, the proxies give up. Let us say 
that the DONT CANCEL, but just discard all state. The terminating GW 
doesnt' give up, since it knows there is media in progress. Same with 
your calling UAC. Now, after 30m, the call is answered. A 200 OK is sent 
by the terminating GW. This 200 OK will be properly routed back to the 
UAC even without transaction state in any proxies. The ACK will be 
routed based on the route set, and should get there as well.

If the call is rejected, a 4xx will be sent by the terminating GW. The 
previous hop proxy will statelessly forward it as well, and the behavior 
will effectively look like the 2xx/ACK case, with the 4xx being 
retransmitted by UAS, and the ACK by the UAC. The ACK for the non-2xx 
case won't have route headers, so it may or may not get delivered to the 
terminating gateway, but the odds are actually good.

This is a fine example of the benefits of stateless operation.

Things will break in the case of a forking proxy. If timer C expires and 
it doesn't cancel, the UAC may end up getting multiple non-2xx 
responses. There are a few possible solutions to this one:

    a. the proxy cancels all but one branch (the one that returned the 
1xx), and then drops its state. This allows that one branch to continue
    b. so what if the uac gets multiple non-2xx. It accepts the first, 
drops the rest.

Comments?

-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

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 8 Jan 2002 12:21:33 -0500

> to american airlines telephone service 
> from the SIP world. (I _have_ stayed in 
> the queue on their system for 
> significantly longer than 5 minutes from 
> multiple residential, wireless, and PBX 
> phones, so something besides the timers 
> discussed below is in play). So, since 
> the consensus is that really long timer 
> C's are not the way to address this
> problem, what's the alternative?

It is the gateway's decision.  It can
send a 200 prior to expiration or a
408 upon expiration.  Such a choice
would be based upon associated billing
and resource usage policies and 
regulations.

And added option could be for the UAC
or it's proxy to include something to
indicate its willingness to accept
billing charges associated with long
call setup times.  However since SIP
doesn't deal with billing, I guess
SIPPING can identify a mechanism or
need to communicate such a thing.

---

From: [email-masked]
Date: Tue, 8 Jan 2002 11:19:40 -0600

I know I'm entering this thread late (I'm a bit behind on the list),
but I just *need* to object.

In particular, if we accept Robert's concession, this consensus makes
the 182 status code almost completely worthless.

This *isn't* a TDM architecture, and treating it as such is ridiculous.
I was under the impression that everyone here understood that billing
based on SIP signaling is a rather ridiculous proposition; given that,
it should be obvious that remaining in a pre-answer state isn't any sort
of an attempt to "cheat." It's obviously someone using the basic building
blocks of SIP in a way that you may not have conceived in order to
provide some service -- and I thought that's what the protocol was all
about.

Staying in a pre-answer state has several legitimate uses. Sending of
182 messages is one of the most obvious ("SIP/2.0 182 Call is queued;
approximate wait is 13 minutes"), since it is endorsed by the
specification itself. Robert has pointed out another real-world
application (which happens to involve legacy systems).

So, there's the theoretical problem to satisfy the purists, and
the actual "someone you know has personally been inconvenienced
by this" problem to satisfy those swayed by anecdotes: an arbitrary
short limit on pre-answer states creates a real problem.

There have already been proposals about how to work around this (e.g.
re-sending provisional responses periodically), so I don't believe the
impasse is technical in nature.

That means we have a philosophical difference here. Everyone please
inhale deeply, exhale slowly, and repeat to yourself: "This is not
the PSTN. This is not the PSTN. This is not the PSTN." Then examine
the problem from a SIP perspective. Keep the whole "generality" thing
in mind, and consider whether you want to limit the number of services
and the ways they can be implemented.

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 08 Jan 2002 12:36:04 -0600

> Everyone please
> the PSTN. This is not the PSTN. This is not the PSTN."

Yesss!!!

Henry Sinnreich
WorldCom

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, January 08, 2002 11:20 AM
> To: 'Robert Sparks'; [email-masked];
[email-masked];
> [email-masked]; [email-masked]

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 8 Jan 2002 13:56:00 -0500

OK ... This is not the PSTN. This is not the PSTN. This is not the PSTN.

I do think it is not wise to have an extremely large default Timer C value.
I'm thinking 3 minutes is about right.

There needs to be some mechanism that allows a UAS that is putting a call in
queue to tell the intervening proxies that it will take longer than the
default Timer C to answer the call. The UAC has no way of knowing how long
the UAS will take to answer, so I don't think using the Expires value in the
INVITE to affect Timer C will help much. Two ways of doing this come to
mind:

1) Modify the FSMs to restart Timer C for every 1xx response and then have
the UAS send a 1xx periodically to maintain the transactions in the proxies.

2) Include the "expected time" the UAS will take to answer the call in the
1xx response and the proxies would set their Timer C accordingly. This would
still require the UAS to retransmit the 1xx response if the call was not
answered in time, but the proxies would only have to reset the timer when
they saw the "expected time" value.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: <[email-masked]>
To: "'Robert Sparks'" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 08, 2002 12:19 PM
Subject: RE: [Sip] Default value for Timer C (was #282)

---

From: [email-masked]
Date: Tue, 8 Jan 2002 13:34:28 -0600

> they saw the "expected time" value.

I like both of these solutions (it was the first one to
which I was referring in my previous mail), and have no
preference between them.

/a

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Jan 2002 03:43:32 +0100

>Actually, its not clear to me that things won't work with timer C at 3m. Lets say you've called AA, and after 3m, the proxies give up. Let us say that the DONT CANCEL, but just discard all state. The terminating GW doesnt' give up, since it knows there is media in progress. Same with your calling UAC. Now, after 30m, the call is answered. A 200 OK is sent by the terminating GW. This 200 OK will be properly routed back to the UAC even without transaction state in any proxies. The ACK will be routed based on the route set, and should get there as well.
>
>If the call is rejected, a 4xx will be sent by the terminating GW. The previous hop proxy will statelessly forward it as well, and the behavior will effectively look like the 2xx/ACK case, with the 4xx being retransmitted by UAS, and the ACK by the UAC. The ACK for the non-2xx case won't have route headers, so it may or may not get delivered to the terminating gateway, but the odds are actually good.
>
>Things will break in the case of a forking proxy. If timer C expires and it doesn't cancel, the UAC may end up getting multiple non-2xx responses. There are a few possible solutions to this one:
>
>   a. the proxy cancels all but one branch (the one that returned the 1xx), and then drops its state. This allows that one branch to continue
>   b. so what if the uac gets multiple non-2xx. It accepts the first, drops the rest.

ad b) Note that quite interesting call flows may happen. Proxy forks a reqeust from A to 
X and Z. Both reply with 183 (interesting media issue for A). Timer C hits the proxy
which goes stateless silently. X establishes the call using the stateless proxy.
The call is BYE-ed, it no more exists. Z sends a final response. No ACK comes from A
so Z keeps retransmitting its final response for some time.

More detailed arguing follows separately. The major point is C can be very low too and
silent transaction dropping for non-forking is good. With forking, it may take
longer C and explicit cancellation.

-Jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Jan 2002 03:44:08 +0100

Summary: C-timer required to be as huge as 3 minutes
eats proxy memory badly while providing questionnable benefits
-> please, don't do that and allow C to be small for
economical proxies; real size of C and handling of C timer can vary
depending on functionality. I think it can be quite
low (4sec?). Sometimes, it must be longer to meet user
expectations (forking ... 32 sec). Special cases
(forking to multiple AA "183 next agent will serve you"
destinations) may ask for even longer C. C in phones
can even be infinite. C may be in hands of users
too (CPL: forward-on-busy with user-driven timeout).

-Jiri

--------

In order to be robust, I really want to remove transaction 
context asap. This has been nicely hard-wired in protocol 
and proxy "randez-vous" concept from SIP's beginning. Who doesn't 
agree and wants to make a storage server out of a proxy may 
try putting it under heavy load. You'll see that running out 
of memory will happen *very* soon (unless you have
terrabytes of fast memory and kilobits of bandwidth).
Making a proxy call-stateful by keeping state during
5-minutes-long 183 replies is simply too heavy.

From this point of view, I would recommend against REQUIRING
C to be long (long: > 32 sec). I think it can be frequently
very short (like 4 sec) without any harm. Specifically, 
if the use of state in proxy is retransmission  (good if 
for example upstream client is on a wireless link and I want 
the proxy to deal with retransmissions on its behalf). Then,
- short C timer hurts neither for 2xx (2xx are always relayed 
  even by stateful proxies) nor for 3xx-6xx which are
  mostly automated and come back  very quickly
- and if C hits (like with loooong 183), the proxy may discard transaction 
  state silently (no CANCEL, no 408) -- upstream and downstream
  willing to wait for each other will finish the transaction with 
  stateless proxy; the great thing is there is no evil intermediary 
  proxy stopping parties from waiting for each other too early

It's trickier, if the purpose of state is different 
(i.e., if the proxy does more than cleaning transaction 
state when C timer hits or a final response comes).
All kinds of forking are a terrifying example. Because we do not want 
to put the forking burden on upstream client unexpectedly, 
the proxy cannot release transaction context silently
(->CANCEL, 408). And because we do not want to hurt users by 
early cancellation, C cannot be too low. 32 sec would be 
perhaps enough. Dedicated waiters may push the redial button.

That's still quite nice, however troubles multiply in special
case of forking to multiple 1xx destinations. What do you do 
after C hits (be it 3 minutes), two AA agents keep feeding 
you with early media and you are still ready to wait for
a human representative? (I mean from signaling perspective. 
I am open to discussion of mixing early media, though  ;-) 
Cancelling is unhappy in this case -- the caller is still
willing to wait. Silent state releasing is not possible because 
that would put forking burden upstream. 

I argue forking to multiple destinations which will return 1xx for
long time and caller will keep waiting is a special case.
So special that whoever configures the proxy to do so will be 
aware of how special it is, rise C and buy enough RAM.
Implementers of call distribution by forking might do so, 
for (PSTN-free) example. Implementors of standard proxies
might cancel all but one branch before going stateless
if they fear 32 sec is not good enough.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jan 2002 01:03:26 -0500

After a private discussion between myself, Jiri, and Robert, we 
concluded on the following proposal:

1. If you are a proxy which can act statelessly (ie., you didn't fork, 
no tcp, and so on), if you are stateful anyway, you can drop to 
stateless at any time without sending a CANCEL or anything else. We 
relax whatever constraints are needed for this.

2. If you can't go stateless, there is a minimum timer C of 3m. A 
minimum of this size is needed (as opposed to recommended), since 
otherwise, the UAS won't know how frequently to send 1xx (see below).

3. If a uas needs an extension on timer C, it sends a 1xx. A proxy 
resets timer C on receipt of a 101-199. The UAS will need to send 1xx at 
least as frequently as once every 3m.

This seems to give us everything we need, and its fairly simple.

Agreement?

-Jonathan R.

---

From: [email-masked]
Date: Wed, 9 Jan 2002 11:01:51 -0600

I agree with Jonathan's three-part proposal, as updated by Bill's "transmit
once a minute" amendment.

/a