Contact expires after 300 seconds. Change configuration

Hello,
I see that my account gets added with an expiry of 300 seconds and after 300 seconds it gets unreachable and is added again. The log reads:

1	[2022-08-26 00:41:40] VERBOSE[1151] res_pjsip_registrar.c: Added contact 'sip:[email protected]:5060;ob' to AOR '23' with expiration of 300 seconds	
2	[2022-08-26 00:41:41] VERBOSE[1151] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Reachable	
3	[2022-08-26 00:41:41] VERBOSE[1151] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob is now Reachable. RTT: 894.430 msec	
4	[2022-08-26 00:42:13] VERBOSE[1151] res_pjsip/pjsip_options.c: Contact 24/sip:[email protected]:5060;ob is now Reachable. RTT: 923.557 msec	
5	[2022-08-26 00:46:42] VERBOSE[4602] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob has been deleted	
6	[2022-08-26 00:46:42] VERBOSE[4602] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Unreachable	
7	[2022-08-26 00:46:42] VERBOSE[1151] res_pjsip_registrar.c: Added contact 'sip:[email protected]:5060;ob' to AOR '23' with expiration of 300 seconds	
8	[2022-08-26 00:46:43] VERBOSE[1151] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Reachable	
9	[2022-08-26 00:46:43] VERBOSE[1151] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob is now Reachable. RTT: 865.995 msec	
10	[2022-08-26 00:51:44] VERBOSE[5851] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob has been deleted	
11	[2022-08-26 00:51:44] VERBOSE[5851] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Unreachable	
12	[2022-08-26 00:51:44] VERBOSE[1151] res_pjsip_registrar.c: Added contact 'sip:[email protected]:5060;ob' to AOR '23' with expiration of 300 seconds	
13	[2022-08-26 00:51:44] VERBOSE[1151] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Reachable	
14	[2022-08-26 00:51:44] VERBOSE[1151] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob is now Reachable. RTT: 873.161 msec

Is there any possibility to turn this off? Or increase this time? What is its purpose, if I may ask?

For the purpose it’s the way SIP registration works. When an endpoint registers there is a time of how long that registration is valid for. When that time is over, then Asterisk will remove the registration. It’s up to the endpoint to re-register before expiration. This is so contacts don’t stick around indefinitely and pile up.

Thank you for the reply. Is there anyway to increase this time?

There is a minimum and maximum setting on the AOR, but as I don’t work on FreePBX I can’t comment on where those are. As well, your issue may still continue to exist if the endpoint doesn’t re-register early enough which is not something Asterisk can control.

1 Like

Seeing from Wireshark, it appears that the enpoint registers within 300 seconds. Why does the deregistration happen still?

log:

4	[2020-10-06 04:41:29] VERBOSE[5726] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob has been deleted	
5	[2020-10-06 04:41:29] VERBOSE[5726] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Unreachable	
6	[2020-10-06 04:41:29] VERBOSE[24400] res_pjsip_registrar.c: Added contact 'sip:[email protected]:5060;ob' to AOR '23' with expiration of 300 seconds	
7	[2020-10-06 04:41:29] VERBOSE[24400] res_pjsip/pjsip_configuration.c: Endpoint 23 is now Reachable	
8	[2020-10-06 04:41:29] VERBOSE[24400] res_pjsip/pjsip_options.c: Contact 23/sip:[email protected]:5060;ob is now Reachable. RTT: 18.522 msec

According to the Asterisk log and the wireshark, it occurred at pretty much the same time of expiration. The endpoint is supposed to re-register before (for example Asterisk re-registers 10 seconds before expiration). If it re-registers at the exact moment or extremely close to it (1 second or less) there’s no guarantee of overlap and so expiration can occur. Things take time to process.

Whilst it is within the 300 seconds, as seen at the point where the packet capture was done, it is far too close to the brink for good practice. I believe chan_pjsip would start at 290 seconds, but there is advice to start at 150 seconds.

At the 800ms before expiry, seen here, the registration will timeout before the maximum number of resends of the request has been reached, so, even with perfect timing, there is a significant chance of a registration dropping out.

My guess is that Asterisk has an off by one error in the calculation of the expiry point, but with the expected safety margins, that wouldn’t be a problem.