Remote Endpoint Intermittently Not Getting Ring Group Calls

User 7005 has two endpoints. User 7005 is in a Ring Group. One endpoint extension is on local subnet, Second extension is at the end of an IPSEC VPN which is marked as local and trusted in FreePBX 16 Firewall. Sporadically, and confirmed by the logs, without noting why in the logs, the remote second extension for user 7005 is not getting a ring. The local endpoint for 7005 gets a ring, but not the remote second extension. Direct ext to ext dial calls to remote user 7005 always go through. Below is what log is saying:
[2023-07-17 03:15:01] VERBOSE[30966] logger.c: Asterisk Queue Logger restarted
[2023-07-17 03:15:01] VERBOSE[30966] asterisk.c: Remote UNIX connection disconnected
[2023-07-17 03:37:20] VERBOSE[17510] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 has been deleted
[2023-07-17 03:50:44] VERBOSE[20314] res_pjsip_registrar.c: Added contact ‘sip:[email protected]:14260’ to AOR ‘7005’ with expiration of 900 seconds
[2023-07-17 03:50:44] VERBOSE[20314] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 is now Reachable. RTT: 99.905 msec
[2023-07-17 04:27:24] VERBOSE[13658] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 has been deleted
[2023-07-17 04:40:44] VERBOSE[17510] res_pjsip_registrar.c: Added contact ‘sip:[email protected]:14260’ to AOR ‘7005’ with expiration of 900 seconds
[2023-07-17 04:40:44] VERBOSE[23061] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 is now Reachable. RTT: 100.033 msec
[2023-07-17 05:07:15] NOTICE[13658] res_pjsip_exten_state.c: Endpoint ‘7004’ state subscription failed: Extension ‘**’ does not exist in context ‘from-internal’ or has no associated hint
[2023-07-17 05:17:21] VERBOSE[20314] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 has been deleted
[2023-07-17 05:30:44] VERBOSE[23061] res_pjsip_registrar.c: Added contact ‘sip:[email protected]:14260’ to AOR ‘7005’ with expiration of 900 seconds
[2023-07-17 05:30:44] VERBOSE[17510] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 is now Reachable. RTT: 107.592 msec
[2023-07-17 06:07:28] VERBOSE[13658] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 has been deleted
[2023-07-17 06:20:45] VERBOSE[20314] res_pjsip_registrar.c: Added contact ‘sip:[email protected]:14260’ to AOR ‘7005’ with expiration of 900 seconds
[2023-07-17 06:20:45] VERBOSE[13658] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 is now Reachable. RTT: 98.949 msec
[2023-07-17 06:57:18] VERBOSE[13658] res_pjsip/pjsip_options.c: Contact 7005/sip:[email protected]:14260 has been deleted

Many years ago in a galaxy far away on a Fonality asterisk system, I had an end user get lost by asterisk and had to tell asterisk to route to remote endpoint. Maybe something like that needs to be done here, but have no clue how to set a route.

To me it looks like the remote extension is simply losing connectivity back to the phone system. I’d do some monitoring of the ipsec tunnel and see if that simply is sporadically dropping for whatever reason.

Try setting a longer qualify timeout. In /etc/asterisk/pjsip_custom_post.conf add (or put if empty)

[7005](+type=aor)
qualify_timeout=16

Reload Asterisk. At the Asterisk command prompt, type
pjsip show aor 7005
and confirm the new qualify timeout value.

Also, what is Qualify Frequency for the extension? If long, try setting to e.g. 60.

I think this is more than a qualify failure, which won’t remove the contact; I think the registration has expired, or the remote party has de-registered. In the former case, and especially given the marginal round trip time, I would suggest you have an overloaded network.

Well, perhaps all three of you may have a point. In monitoring the router logs at the ipsec vpn endpoint the IP address is under heavy DOS attack. I wonder though if the phone itself may be malfunctioning, because the words “You have a call from __” appear on the phone screen, though the phone does not ring, and there is no call to pickup when handset is lifted. The phone and server must have some connection for a signal to be sent to the screen??? So either the VPN tunnel is breaking down to prevent full connection, or something is wrong with the phone? Or maybe timeout adjustments are needed.

You are correct. I hadn’t noticed that the pattern is completely regular. Registration is regained precisely every 50 minutes and lost (presumably disqualified because the message doesn’t show ‘expiration’) almost precisely 37 minutes later. Something in the network is timing out. As something quick to try, set the registration expiry in the phone to e.g. 120 seconds.

Well the phone was set to expire registry in 15 minute interval. I changed it to 30 minutes to see if that impacts things.

IMO setting 2 minutes will make a timeout less likely.

I tend to agree, but phone setting of 900 seconds is shortest time frame permitted. However, looking at logs AFTER I added a longer qualify timeout to /etc/asterisk/pjsip_custom_post.conf the log for that phone does not show any further deletes. I will watch it for a few days and confer with user on functioning. Perhaps issues is solved? Time will tell.

I have never seen a device with such a limitation. Make/model? Does it offer a keep-alive option that could be used instead to keep the connection open?

Phone is CIP250V2. No keep alive setting. Has setting called “session expiration” that is set to 180 seconds. Another setting is “SIP detect interval” which is set to 15 (no idea if secs or mins). There is a setting called “SRTP mode” which is set to disabled.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.