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

From: [email-masked]
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]]
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]] 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

_______________________________________________
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: William Marshall <[email-masked]>
Date: Mon, 7 Jan 2002 22:11:36 -0500 (EST)

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 

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [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)

Further inputs?

-Jonathan R.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 8 Jan 2002 10:10:13 -0500

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]]
Sent: Monday, January 07, 2002 10:12 PM
To: [email-masked]
Subject: Re: [Sip] Default value for Timer C (was #282)

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 

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [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)

Further inputs?

-Jonathan R.

---

From: [email-masked]
Date: Tue, 8 Jan 2002 08:37:31 -0700

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

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 

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) 

Further inputs? 

-Jonathan R. 

Bob Penfield wrote: 

>>>From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of 
>>>>From: Bob Penfield [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>>>>for free for such a long period of time. 
<http://www1.ietf.org/mailman/listinfo/sip>  
>>>>Use [email-masked] for new developments on the application of 
<http://www1.ietf.org/mailman/listinfo/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>  

<http://www1.ietf.org/mailman/listinfo/sip>  

<http://www1.ietf.org/mailman/listinfo/sip>  

<http://www1.ietf.org/mailman/listinfo/sip>

---

From: [email-masked]
Date: Tue, 8 Jan 2002 14:59:17 -0700

Comments inline.  Note that this is not one of the major issues, but has
been getting alot of attention.  We should try to choose a solution quickly.
My vote is below.

> Sent: Tuesday, January 08, 2002 2:27 PM
> To: Robert Sparks
> Cc: Hearty, John; [email-masked]'; [email-masked]';
> [email-masked]'
> Robert Sparks wrote:
> > We only need to specify a minimum if use of the protocol 
> with a smaller
> > value will cause really
> > bad things to happen to the network (this is the motivation for the
> > minimum
> > values for T1 yes?).
> > This is different metric than having really bad things happen to
> > applications running on the
> > network.
> 
> 
> No, we need to define minimums in order to guarantee 
> interoperability. 
> Relying on "if its wrong, the market pressures will make you crank it 
> up", is not the right answer. That could be applied, in theory, to 
> almost any aspect of the spec (for example, having 
> max-forwards never be 
> greater than three, which means a max of three hops. Its good for the 
> network (less traffic), but bad for apps. I would rather not 
> field these 
> customer support questions. It should work.).
> 
> Bob has proposed some interesting ways to signal for more time:
> 
> 
> > 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.
> 
> 
> This one is nice, since it has the effect of requring insertion of 
> traffic to refresh state. This helps make it immmune from DoS 
> attacks, 
> which your second proposal below is.
> 

 This solution currently gets my vote (is this a democracy?).  The problems
prompting some to want the timer to be long would be solved by the user that
needs it to be long, the UAS.  The minimum could then be some small value
such as 32s as originally proposed.

> 
> > 
> > 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.
> 
> 
> Well, a malicious UAS could set the value to infinity and 
> blow out the 
> state in proxies.
> 
> Another approach is the one I had proposed - do nothing. Let 
> the proxies 
> discard state, and I think it still works OK. Any comments on that?

I was hoping Robert Sparks would comment on what you discussed ealier today,
the points sounded interesting.  If the stateless forwarding of responses
and Routing of ACKs would hold the call up, I'm not clear why Robert and
Henry are having their calls dropped after a minute, unless it's really a
PSTN switch they are ultimately interworking with that is dropping the call.
If the points made are ultimately valid, then this approach would seem the
best and my vote would change to this, as it would remove a requirement of
UAS's to retransmit provisionals and proxies to reset timers.  Again, a
minimum would still need to be chosen here such as the originally proposed
32s.

John Hearty
Level3

---

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

At 12:19 AM 1/9/2002, Bob Penfield wrote:
>----- Original Message -----
>From: "Jonathan Rosenberg" <[email-masked]>
><snip>
>> Another approach is the one I had proposed - do nothing. Let the proxies
>Maybe I am missing something, but my reading of Section 16 requires that a
>stateful proxy send a final response when all of the client transactions
>have been terminated. This would result in a non-2xx final response being
>sent to the UAC (namely 408).
>
>If this is correct, there needs to be a way to retain the state in the
>proxy.

I read it the same way but do not see how changing it will harm
interoperability. There are other protols which were designed for
state storage and do that job better than SIP does.

-Jiri

---

From: [email-masked]
Date: Wed, 9 Jan 2002 16:55:24 +0530

"Jo Hornsby" <[email-masked]> on 01/09/2002 04:31:29 PM

To:   "Jonathan Rosenberg" <[email-masked]>, "Jiri Kuthan"
      <[email-masked]>
cc:   [email-masked] (bcc: K Binu/HSSBLR)

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

>Yes, and to be paranoidsafe a good few seconds short
>of 3min, right?

For this to work reliably over UDP, the 1xx responses used to extend
the timer should be sent reliably using 100-rel.

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 09 Jan 2002 15:25:53 +0100

At 12:01 PM 1/9/2002, Jo Hornsby wrote:
>But if INVITE, shouldn't there be some additional
>requirement that you can't drop to stateless
>before you've seen a 1xx?  Otherwise I can
>see a request just suddenly disappearing into
>the ether....

I might be overcoffeinized but I think we're discussing
timer C which is started in "proceeding" state, which
is entered after 1xx was received.

Timer B (which is started before 1xx appears, default
value 64*T1=32s) is IMHO long enough. The B-timer handler
may be different (it may generate SIP messages) from that 
for C-timer (which is silent, unless forking or something
else very stateful is used).

-Jiri

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Jan 2002 15:14:51 -0500

I just realized I had fallen a little too deeply into the minimum value =
only deployed value
trap. 
 
Timer C needs to exist - a proxy element can't be expected to hold state
forever, it has
to have some point where it knows it can safely discard. If we don't discuss
that in the
specification, implementations will address it with local policy,
potentially to the ruin
of interoperation.
 
Elements in real networks will tune this value (the spec should clearly
point out that this MUST
be configurable). So, a provider could set up a system that would let you
work with AA
for 45 minutes (or even all day) if they wanted to (at least the proxies
wouldn't break the service).
Market pressures will eventually drive them providers to use values that
enable the applications
that people are willing to pay for.
 
So, I have to come back to the very starting point for this thread. Why do
we need a minimum
value? I think the 3 minutes we've negotiated so far has really been in the
spirit of a recommended
value, not a minimum.
 
We only need to specify a minimum if use of the protocol with a smaller
value will cause really
bad things to happen to the network (this is the motivation for the minimum
values for T1 yes?).
This is different metric than having really bad things happen to
applications running on the
network.
 
If the value is set to, say 32 seconds, bad things don't happen to the
network. There may be some
domains of control where its known that calls will complete fast or not at
all, and its perfectly
reasonable for intermediaries to discard state after 32s. If we make 3
minutes a minimum, we force
them to keep state longer than they need it, or be noncompliant, neither of
which makes much
sense given that they are satisfying the needs of their application.
 
So, I propose that we take what we've learned from the discussion so far and
state the following:
* Timer C must be configurable
* A recommended value for Timer C is 3 minutes
* A minimum value for Timer C is ? 
 
We haven't really been working to answer that last question - we've been
focusing on when
applications break, not when the protocol breaks the network. So, is a
normative minimum
really necessary? If somebody sets Timer C to zero, an INVITE transaction
will never complete,
which clearly breaks the protocol, so a minimum is needed. If the timer is
around the transmission
delay, the transaction can complete (though a race condition exists). So,
some value larger than
the transition delay is necessary. How much bigger? Probably not much.
Jonathan's originally
suggested 32 seconds. I think it could be much shorter - remember the metric
- what breaks the
network, not what breaks the applications. I propose the minimum be an RTT.
 
RjS
 
 -----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 10:34 AM
To: [email-masked]'; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] Default value for Timer C (was #282)

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)

John Hearty
Level3

-----Original Message----- 

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 

John Hearty 
Level3 

-----Original Message----- 

Further inputs? 

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jan 2002 19:05:28 -0500

And, of course, this was the post that got caught in the
moderator queue finally popping out. Disregard it please.

RjS

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Tuesday, January 08, 2002 2:15 PM
To: Robert Sparks; [email-masked]'; [email-masked];

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip