Subject: RE: [SIP] T2 and 182 Queued

From: David Frascone <[email-masked]>
Date: Mon, 22 Jan 2001 11:27:19 -0600

Given this forwarded discussion, this might be an error in 02bis.

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 22 Jan 2001 17:29:45 -0000

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

---

From: David Frascone <[email-masked]>
Date: Mon, 22 Jan 2001 11:47:03 -0600

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?