Subject: RE: [SIP] T2 and 182 Queued

From: Itamar Gilad <[email-masked]>
Date: Wed, 24 Jan 2001 11:35:47 +0200

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.

---

From: David Frascone <[email-masked]>
Date: Wed, 24 Jan 2001 10:42:30 -0600

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?