PJSIP set timer_t1 and timer_b

Asterisk Asterisk SIP
1

HI,

In my Asterisk 13.16.0, I’ve changed the value of timer_t1 and timer_b in [system] -> ‘pjsip.conf’ after restarting asterisk, these parameters keeps their default value:

[root@asterisk1 asterisk]# asterisk -V
Asterisk 13.16.0
[root@asterisk1 asterisk]# egrep -A3 -i "\[system\]" pjsip.conf
[system]
timer_t1 = 200
timer_b = 5000

[root@asterisk1 asterisk]# systemctl restart asterisk
[root@asterisk1 asterisk]# asterisk -rx "pjsip show settings"|egrep -A11 -i "System Settings"
System Settings:

 ParameterName             : ParameterValue
 ==========================================
 compact_headers           : false
 disable_tcp_switch        : true
 threadpool_auto_increment : 5
 threadpool_idle_timeout   : 60
 threadpool_initial_size   : 0
 threadpool_max_size       : 50
 timer_b                   : 32000
 timer_t1                  : 500

How can I change the default timer B from 32s to 15s in pjsip.conf and can I specify different timers by endpoints ? concerned

Thanks in advance for any help
Ouss

2

You need to add a “type=system” line to the “[system]” entry. Without it the section is ignored as being unknown.

3

Thanks :slight_smile:

[root@asterisk1 asterisk]# asterisk -rx "pjsip show settings"|egrep -A11 -i "System Settings"
System Settings:

 ParameterName             : ParameterValue
 ==========================================
 compact_headers           : false
 disable_tcp_switch        : true
 threadpool_auto_increment : 5
 threadpool_idle_timeout   : 60
 threadpool_initial_size   : 0
 threadpool_max_size       : 50
 timer_b                   : 12800
 timer_t1                  : 200
4

I made the same changes but was not applied. Tried to restart with pjsip reload.

Any suggestion ?

5

worked with full reload. thanks

6

timer_t1 an timer_b refers about time for OPTIONS requests or only for INVITE ?

My question is because I have some troubles with extensions becoming REACHABLE and immediatelly UNREACHABLE some times in a day in a environment behind NAT over the Internet in a non reliable connection.

I changed timer_t1 to 1000 to test if will have any improvement. Can anyone give any tip?

7

The timers are defined in RFC 3261 and both affect any request that produces an acknowledgment, which I think means any request. I haven’t checked, but I think it also applies to final responses.

B is the absolute amount of time allowed to obtain a response, and t1 is the starting time between retransmissions, which subsequently escalates.

1 Like
8

In the case of the OPTIONS the qualify_timeout also controls this. You’d need to see how long it takes things to respond and adjust accordingly.

9

Good replies, thanks. And in the cases that lost packets in a non reliable network, that are becoming UNREACHABLE the extensions.

How many attempts the Asterisk sends the OPTIONS request before to put it as UNREACHABLE? Is it possible increase the time of attempts?

10

The qualify_timeout option controls the time at which the AOR is considered unreachable and the qualify_frequency option controls how often the OPTIONS is sent.

1 Like
11

My environment are using qualify_timeout=10 and qualify_frequency=60 (60 times is already too much I think).

Any Idea what I can do to solve this question of UNREACHABLE?

12

The qualify_frequency is in seconds. A value of 60 means every minute. Your only choice is to either continue adjusting values, or to not qualify.

13

Understand, but how many times the Asterisk will test each OPTIONS packet until become the extension UNREACHABLE?

For example, its sends packets each 60 seconds to test the connections, but if the packet of OPTIONS is lost in the transmission, how many times Asterisk will resend to try again? Or is just one send and doesn’t allow to lost packets

14

It will resend the packet depending on the timers, however qualify_timeout is how long (in seconds) before it considers it unreachable.