[asterisk-users] Timer1 RFC and SIP.CONF

[Olle E. Johansson]

4 jul 2012 kl. 13:32 skrev Elliot Murdock:

> Hello,
> 
> I am trying to get clarity with the sip.conf timer configuration.  The
> current configuration states:
> 
> ;--------------------------- SIP timers
> ----------------------------------------------------
> ; These timers are used primarily in INVITE transactions.
> ; The default for Timer T1 is 500 ms or the measured run-trip time between
> ; Asterisk and the device if you have qualify=yes for the device.
> ;
> ;t1min=100                      ; Minimum roundtrip time for messages
> to monitored hosts
>                                ; Defaults to 100 ms
> ;timert1=500                    ; Default T1 timer
>                                ; Defaults to 500 ms or the measured round-trip
>                                ; time to a peer (qualify=yes).
> ;timerb=32000                   ; Call setup timer. If a provisional
> response is not received
>                                ; in this amount of time, the call
> will autocongest
>                                ; Defaults to 64*timert1
> 
> However, according to RFC 3261:
> 
> (EXCERPT 17.1.1.1)
> T1 is an estimate of the round-trip time (RTT), and
>   it defaults to 500 ms.  Nearly all of the transaction timers
>   described here scale with T1, and changing T1 adjusts their values.
>   The request is not retransmitted over reliable transports.  After
>   receiving a 1xx response, any retransmissions cease altogether, and
>   the client waits for further responses.  The server transaction can
>   send additional 1xx responses, which are not transmitted reliably by
>   the server transaction.  Eventually, the server transaction decides
>   to send a final response.
> 
> (EXCERPT 13.2.2.4 2xx Responses)
> The UAC core considers the INVITE transaction completed 64*T1 seconds
>   after the reception of the first 2xx response.
> 
> According to the RFC, the 64*t1 timeout is not for provisional
> responses, but for final responses.  This seems to be in contradiction
> to what is stated in the sip.conf file.

Unless you have PRACK support, which Asterisk not yet has, there's
no timeout in the SIP protocol for provisional responses more than
the need to update your provisional response at least every minute
not to hit a 3 minute timeout in the SIP transaction state in a proxy.

Now, the timerb is used to get ANY response from a server out there,
including provisional responses. If we don't get ANY response within
TIMERB, the SIP transaction dies and in a UA with a transaction
layer we generate a local 408 timeout. In Asterisk, we congest the call.

So the 64*T1 is for any response, including final response. It's there
to decide whether or not you have intelligent SIP life forms handling
your SIP request in the network universe.

I hope this clears up your confusion.

Regards,
/Olle