Subject: RE: [SIP] T2 and 182 Queued

From: "Culpepper, Bert" <[email-masked]>
Date: Wed, 24 Jan 2001 12:26:28 -0600

Hi David,

If I understand your issue correctly, you are concerned with 
how long UA2 waits before it gives up on UA1 after sending 
200 OK.  Section 10.5.1 addresses this case, in it final 
responses are sent a total of 7 times with retransmission 
timer starting at T1 and doubling each time.  I understand 
this to mean UA2 waits 28 seconds (plus a little to see if 
the last retransmission gets acknowledged) for the ACK from 
UA1.  If not received, UA2 tears down the call.  Using your 
example, the customer support rep. will wait 28 seconds 
before moving on to the next call.  Not that bad but 28 
seconds of the support rep's time has been non-productive. 
this might encourage the organization to shorten the queue. 
The frequency at which the 182s are sent by UA2 is up to 
UA2.  200 OK is the only message retransmitted.  No big 
waste of transmissions that I see.

I hope this helps,
Bert

> -----Original Message-----
> From: David Frascone [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 11:43 AM
> To: [email-masked]
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> Ok, but let me get this straight.  This call flow looks like 
> it is broken
> with the current RFC.  Let me know if I am wrong.  It seems 
> broken even
> without a proxy.  In the following, I'm assuming a 20-30 
> minute queue wait.
> Not unreasonable if you've ever called customer support about 
> a DSL line :)
> 
> Ok, Here is a good call:
> 
>     UA1                             UA2
>      |                               |
>      |             INVITE            |
>      |------------------------------>|
>      |                               |
>      |      182 Queue Position 20    |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 10    |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 1     |
>      |<------------------------------|
>      |                               |
>      |            200 OK F4          |
>      |<------------------------------|
>      |                               |
>      |               ACK             |
>      |------------------------------>|
>      |                               |
>     UA1                             UA2
> 
> Everything is happy above.  But, what about this:
> 
> 
>     UA1                             UA2
>      |                               |
>      |             INVITE            |
>      |------------------------------>|
>      |                               |
>      |      182 Queue Position 120   |
>      |<------------------------------|
>      |                               |
>    Here, the UA1 pulls the plug on his computer, drives into a tunnel,
>    has a power outage, ISP drops the connection, etc.  No cancel, just
>    vanishes.
> 
>      |      182 Queue Position 110   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 100   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 1     |
>      |<------------------------------|
>      |                               |
>      |            200 OK F4          |
>      |<------------------------------|
>      |                               |
>      |   UA2 Timer FINALLY times out |
>      |                               |
>     UA1                             UA2
> 
> 
> So, the UA keeps him in the queue, spitting out UDP packets for a LONG
> time, without ever knowing that UA1 is no longer on the 
> network.  So, if
> T2 *is* used, the timeout is way too short.  If T2 is NOT 
> used, then there
> is an big waste of retransmissions for queued calls.  Perhaps 
> PRACK should be
> required for long queue times?  There might even be a DOS 
> attack by forging
> tons of INVITES to a full queue.
> 
> Now do you see the problem?  
> 
> 
> 
> On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > David,
> > 
> 
> 
> On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > David,
> > 
> > we found that on top of T1 and T2 there's a need for 
> "transaction timeouts"
> > i.e. a timer that terminates the transaction simply because nothing
> > significant happened for a given period of time. Note that 
> the durations of
> > these timeouts vary based on the current state of the 
> transaction. Without
> > these timeouts some transactions might never die. You can find some
> > references to this matter in RFC 2543-bis02. 
> > 
> >   Itamar 
> > 
> > > -----Original Message-----
> > > From: David Frascone [mailto:[email-masked]]
> > > Sent: Tue, January 23, 2001 9:44 PM
> > > To: [email-masked]
> > > Subject: Re: [SIP] T2 and 182 Queued
> > > 
> > > 
> > > So, a proxy server would just retransmit the 182 
> > > indefinately?  I thought the
> > > proxy retransmission timer was also tied to T2.
> > > 
> > > Hehe, maybe I should just use TCP :)
> > > 
> > > On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > > > David,
> > > > 
> > > > 10.3.1 states that INVITES are retransmitted after T1 
> > > seconds, and this
> > > > value doubles after each retransmission.  Retransmissions 
> > > are stopped when
> > > > receiving any kind of response (provisional or definitive). 
> > >  As soon as a
> > > > UAC receives a 182, it simply stops retransmitting its 
> > > INVITE and waits for
> > > > a final response (which can take a lot of time to come).
> > > > 
> > > > EricT
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: David Frascone [mailto:[email-masked]]
> > > > > Sent: Monday, January 22, 2001 12:47
> > > > > To: [email-masked]
> > > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > > 
> > > > > 
> > > > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > > > can't find 
> > > > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > > > provisional responses
> > > > > are re-sent upon every duplicate request, but it never resets 
> > > > > the T2 timer.
> > > > > 
> > > > > My concern is not retransmissions, but the total call setup 
> > > > > time, which 
> > > > > could take much longer than T2 allows, if the call is queued.
> > > > > 
> > > > > Now, if the timers are just a suggestion, and the user agent 
> > > > > can do whatever
> > > > > it wants, then this is not a problem.  I know that I can set 
> > > > > T1 and T2 to
> > > > > whatever values I want, but I'd prefer to have a queued call 
> > > > > work within
> > > > > the "suggested" parameters of 500ms and 4sec as set 
> by the RFC.
> > > > > 
> > > > > Comments?  Does anyone really care?  Should I ignore this, 
> > > > > and just set my
> > > > > T2 timer really high?
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > > > David Frascone wrote:
> > > > > > > Given this forwarded discussion, this might be an 
> > > error in 02bis.
> > > > > > 
> > > > > > It might be.  But given the fact that section 10.2 
> is entitled:
> > > > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > > > is not. &:)
> > > > > > 
> > > > > > > ----- Forwarded message from Jo Hornsby 
> > > > > <[email-masked]> -----
> > > > > > > 
> > > > > > > From: "Jo Hornsby" <[email-masked]>
> > > > > > > To: "David Frascone" <[email-masked]>, 
> > > > > > > <[email-masked]>
> > > > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > > > Message-ID: 
> <[email-masked]>
> > > > > > > 
> > > > > > > David Frascone wrote:
> > > > > > > >
> > > > > > > > Does anyone know the answer to this?  Should I switch 
> > > > > to the sip list?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> > > Frascone wrote:
> > > > > > > > > From section 10.2.1:
> > > > > > > > >
> > > > > > > > >    Subsequent retransmissions are spaced by T2 
> > > > > seconds. If the client
> > > > > > > > >    receives a provisional response, it continues to 
> > > > > retransmit the
> > > > > > > > >    request, but with an interval of T2 seconds. 
> > > > > Retransmissions cease
> > > > > > > > >    when the client has sent a total of eleven 
> > > > > packets, or receives a
> > > > > > > > >    definitive response. Default values for T1 and 
> > > T2 are 500 
> > > > > > > ms and 4 s,
> > > > > > > > >    respectively. Clients MAY use larger values, but 
> > > > > SHOULDNOT use
> > > > > > > > >    smaller ones. Servers retransmit the response upon 
> > > > > receipt of a
> > > > > > > > >
> > > > > > > > > Which means, the INVITE would be retransmitted 
> > > every 4 seconds
> > > > > > > > > while the caller is waiting in the queue.  And, would 
> > > > > stop after
> > > > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > > > small for
> > > > > > > > > some queues.
> > > > > > > 
> > > > > > > You are correct -- the text you quoted does say this. 
> > >  However,
> > > > > > > if you seek to the beginning of the same 
> paragraph, you find:
> > > > > > > 
> > > > > > >    A SIP client using an unreliable transport 
> > > protocol such as UDP
> > > > > > >    SHOULD retransmit requests other than INVITE 
> or ACK [...]
> > > > > > > 
> > > > > > > Look to section 10.3 for reliability-related behaviour 
> > > > > for INVITEs.
> > > > > > > 
> > > > > > > 
> > > > > > >  - Jo.
> > > > > > > 
> > > > > > > 
> > > > > > > ----- End forwarded message -----
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > This list is for continuing development of the 
> SIP protocol.
> > > > > > > The sip-implementer's list is the place to discuss 
> > > implementation,
> > > > > > > and to receive advice on understanding existing sip.
> > > > > > > To subscribe to it, send mail to 
> > > [email-masked] with
> > > > > > > "subscribe sip-implementors" in the body.
> > > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to 
> [email-masked] with
> > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to [email-masked] with
> > > > "subscribe sip-implementors" in the body.
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to [email-masked] with
> > > "subscribe sip-implementors" in the body.
> > > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to [email-masked] with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 24 Jan 2001 13:40:51 -0500

182 can be sent for days, if desired, without any connection to T2. How
long this is done is up to the sender of the 182, obviously (and any
intervening proxies). But the proxy will likely be in the called
organization, so as long as the proxy plays along, proxy timeout is not
an issue.

A somewhat related question is whether it makes sense to extend the
session timer mechanism to this case. I haven't thought through all the
consequences (depending on how CSeq is handled, this is either an
overlapping transaction or not), but it would allow consenting parties
to prevent this and still signal in the appropriate way (i.e., without
audio).

I suspect that in many cases, SUBSCRIBE/NOTIFY may be the more
appropriate mechanism for ACD-like systems in the future.

Dumb PSTN gateways are never an excuse for falling back to silly audio
signaling, with all its attendant problems.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: David Frascone <[email-masked]>
Date: Wed, 24 Jan 2001 12:57:34 -0600

It started with a couple of things:

First: If a caller is queued, and a UA uses the timers, then he can
only be on hold for 28 secs, as you mentioned.  This is WAY shorter
than most queue times.

Second: If you ignore the timers, then the caller can be on hold 
indeffinitely, even if he is no longer even on the 'net.  (Assuming
UDP transport, of course)

-Dave

---

From: David Frascone <[email-masked]>
Date: Wed, 24 Jan 2001 12:58:39 -0600

Hmmm, I hadn't considered session timers.  I was leaning more towards
manditory PRACK's.

---

From: Rick Dean <[email-masked]>
Date: Wed, 24 Jan 2001 13:45:26 -0600

An algorithm I am familiar with and is allowable
by the standard, is the UAC retransmits
an INVITE (same cSeq) ~30 seconds after a 
provisional response is received to see if the 
far end is still alive.  Because non-response to 
a single INVITE is not conclusive,  the UAC
restarts the 0.5, 1, 2, 4, 4,... sequence at
this time.  If no response after N INVITES
(where N <= 7 allowable in the spec) plus some
time for the far end to do a sequence, the 
call is considered dead.  This algorithm allows 
the UAC to decide how frequently he wants to 
check on the far end.  In the normal case
each check costs two packets.

Any clever ACD queueing system will probably
want to send 200 OK instead to take control
from a possible forking proxy, and to give
the user choices "press 1 to leave a voicemail".  
Nevermind that it already has to implement an audible 
progress alternative for the PSTN gateways.  I
doubt 182 will get much use.

--
Rick

---

From: Billy Biggs <[email-masked]>
Date: Wed, 24 Jan 2001 16:55:48 -0500

> signaling, with all its attendant problems.

  If a PSTN gateway receives a 182 Queued at Work (tag=5) and a 180
Ringing Home Phone (tag=8), what should it play to the user?  Can it
possibly generate audio to convey this information?

  It's important that all call states maps to machine-readable status
codes with error messages for many cool features.  However, in order to
personalize service, and for guarenteed compatibility with display-less
phones (PSTN), you need an audio stream: call queues need to play music,
ads, or explain how much they appreciate your call, and some find-me
services may wish to explain their progress as they locate your party.

  Using SIP, an audio stream is only established when a call is
successfully established.  Pre-call is a multi-party unconnected tree,
and no media is established on call failure.  I therefore suspect that
many systems in practice will connect the call as soon as possible to
allow for enhanced verbage in the audio stream.  Some find-me services
will using a back-to-back SIP UA instead of a pure forking proxy.

  Maybe a helpful technique would be to have a mid-call status code,
sent in a header in a re-INVITE, or some description language sent in
the body of a CALLSTATE message.  This may be useful to indicate a call
state change while still establishing a point-to-point connection and
allowing for media.  This way, gateways which need to send pre-connect
media may still be able to send back status updates if such information
becomes available, and back-to-back UAs can propagate back information
in the signalling domain.

  This isn't to say that informative 100-class responses, or even
informative 400-class responses are useless: only that for many
applications they will not be appropriate.

  One hint is how many websites use HTTP authentication, and how many do
their own nice-looking web page with text boxes.  Personalization of
service is important.

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 24 Jan 2001 17:49:38 -0500

We should design mechanisms that give people reasons to move away from
legacy PSTN systems rather than assume that all future VoIP will be
limited to whatever limitations the current steam telephones have.

However, this seems like a caller preferences item, where the caller can
indicate whether it wants audio feedback or something more semantically
meaningful. Indeed, the caller preferences draft already contains this
feature:

    queue-feature: If the called party is temporarily unreachable,
             e.g., because it is in another call, the caller can
             indicate that it wants to have its call queued rather than
             rejected immediately. If the call is queued, the server
             returns "182 Queued".  A pending call be terminated by a
             SIP CANCEL or BYE request.

We may want to rephrase/add a third option, as in "queue, but connect to
elevator music and being forced to listen to advertisements".
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs