We are facing an issue where under certain conditions, extensions do not ring when the queue or the Ring Group tries to deliver a call to an extension. In this particular situation, we were using regular queues when the problem started. To check if it was a network issue, we tried various configurations in SIP and PJSIP, TCP and UDP, with and without STUN configured, and VPN, but nothing had any effect. In the end, we recreated the structure using Ring Groups instead of queues, and the problem seemed to be resolved, but it is still occurring. The extensions are online, not in DND, the CDR logs the attempt, but the app does not ring. Could you help us by checking if there is anything in the log that could help identify the problem?
Internal calls don’t seem to be affected. We tried comparing the content of the ‘invites’ from calls that rang with those that didn’t ring, but we didn’t identify any differences.
On this specific client all peers are registered with something like this:
[sip:T52_1004@191.xxx.xxx.139:24075;ob;x-ast-orig-host=192.168.120.182:53259]
As I can Say, the server has the information about public and private IP. But now that you mentioned it, I realize that some peers in other locations do not have this additional information, while others do. However, so far, only one Tenant has reported issues, and it’s not with all the calls – it’s something selective. Could this additional information ‘x-ast-orig-host’ be the cause of the problem? If So, is there anythning we can do internally to solve it?
I’ve run into issues before with similar sounding behavior when using UDP for SIP. I found the SIP packets would get too big partly due to the codecs enabled for the device, the supported codecs would add to the length of the packet. I’d suggest sticking to TCP to eliminate that as an issue.
This also sounds like it could be firewall related, see if you can turn off SIP ALG on that customers router. This is where an SBC becomes helpful to try to fix issues caused by badly behaved firewalls and other NAT traversal issues.
You can also use sngrep on your vitalpbx server to see what’s happening, that should give you some info to track down the issue. I personally use VoipMonitor or you could use Homer which is free and would help to pinpoint the issue.
I tryed to get some info on SNGREP before, but the content of the INVITE looks similar for calls that the extensions rings and when dont.
The client made some changes to their router, and the problem seems to have stopped occurring, at least the reports have ceased. Hopefully, they are convinced that it was caused by their network.