Nope,

Read carefully section 10.3.1...

- *Provisionnal* responses are retransmitted upon the reception of the
original request.  
- *Final* responses are retransmitted starting at T1 and toping at T2.

EricT


> -----Original Message-----
> From: David Frascone [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 23, 2001 14:44
> To: [EMAIL PROTECTED]
> 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 PROTECTED]]
> > > Sent: Monday, January 22, 2001 12:47
> > > To: [EMAIL PROTECTED]
> > > 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 PROTECTED]> -----
> > > > > 
> > > > > From: "Jo Hornsby" <[EMAIL PROTECTED]>
> > > > > To: "David Frascone" <[EMAIL PROTECTED]>, 
> > > > > <[EMAIL PROTECTED]>
> > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > Message-ID: <000001c0848a$a4281f20$[EMAIL PROTECTED]>
> > > > > 
> > > > > 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 PROTECTED] 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 PROTECTED] 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 PROTECTED] 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 PROTECTED] with
> "subscribe sip-implementors" in the body.
> 
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to