So a new thing started happening recently on a couple of new PBX installations.
When somebody calls out from a SIP phone that’s going through the PBX (Polycom with Vitelity as the trunk) if they reach the VM greeting of the person they are calling they are intermittently not able to leave a VM. The greeting plays for them but then they never hear the beep and then the call hangs up on them after a few seconds of silence.
This does not happen every time, end users estimate about half the time but they might be overestimating.
Thus far I am unable to get anything from the asterisk CLI as they are unable to replicate the issue for every call.
So I posted this in the other thread but thought maybe I’ll get some more traction here. Here is the response I received from Vitelity:
show this call timed out. I show we did not receive an ACK from you in response to our 200 OK, and then your system sent a cancel:
Jul 16 9:14:23.460 AM 63.227.68.191 > 64.2.142.109 INVITE sip:[email protected] SIP/2.0
Jul 16 9:14:23.461 AM < SIP/2.0 100 Trying
Jul 16 9:14:25.512 AM < SIP/2.0 180 Ringing
Jul 16 9:14:25.513 AM < SIP/2.0 183 Session Progress
Jul 16 9:15:01.702 AM < SIP/2.0 200 OK
Jul 16 9:15:02.701 AM < SIP/2.0 200 OK
Jul 16 9:15:03.702 AM < SIP/2.0 200 OK
Jul 16 9:15:05.703 AM < SIP/2.0 200 OK
Jul 16 9:15:28.207 AM > CANCEL sip:[email protected] SIP/2.0
So according to them, they are sending packets that my phone system isn’t responding to? It can’t be the firewall/connectivity since it specifically only happens when we call out and try to leave a VM, everything else works fine.
You first need to identify whether you are using chan_pjsip or chan_sip on your connection to Vitelity, then you need to capture the SIP packets going between your PBX and your carrier. that would be diagnostic.
Vitelity does not support pjsip as of now so it’s chan_sip that’s being used for the trunk.
I am having trouble capturing packets as it’s not that easy to replicate the issue (I’ve been dealing with the problem for about a week). It happens intermittently and not on all calls.
I will try and figure out how to capture packets continuously and analyze/narrow down the problem after the fact. Is there a good article that you could point me to that could help me with doing this well?
Huh, that’s interesting. Last time I attempted to use pjsip for trunk registration with Vitelity I wasn’t able to make it work because of how they wanted to have me register against the account.
Now this was a couple of years ago and granted I probably didn’t know enough to get it setup properly or troubleshoot.
In any case chan_sip worked well enough for the trunk that I never spent the time to actually figure out how to make pjsip work with a Vitelity trunk.
I’ll give it another shot for for the next system that we are slated to install.
In the mean time I’ll try to troubleshoot the current configuration and report back with the findings.
Evantually chan_pjsip will in fact fully effectively replace chan_sip as it is without doubt a better stack, but at the risk of opening old wounds, there are aspects of SIP protocol that are yet not fully implementable in FreePBX , yes this is anecdotal as ever, but that just means there are stories of where it doesn’t yet fully work. When all these stories are laid to rest then we can all proceed confidently with pjsip
So I do need further assistance. I capered the SIP packets for an outgoing call that wasn’t answered and then hung up on during VM playback (didn’t hear the beep). My end never seems to see the 200 OK packets that the Vitelity end shows on their packet capture.
Jul 17 7:50:35.440 AM PBX > Vitelity INVITE sip:[email protected] SIP/2.0
Jul 17 7:50:35.441 AM PBX < Vitelity SIP/2.0 407 Proxy Authentication Required
Jul 17 7:50:35.474 AM PBX > Vitelity ACK sip:[email protected] SIP/2.0
Jul 17 7:50:35.476 AM PBX > Vitelity INVITE sip:[email protected] SIP/2.0
Jul 17 7:50:35.476 AM PBX < Vitelity SIP/2.0 100 Trying
Jul 17 7:50:38.128 AM PBX < Vitelity SIP/2.0 180 Ringing
Jul 17 7:50:38.128 AM PBX < Vitelity SIP/2.0 183 Session Progress
Jul 17 7:51:08.761 AM PBX < Vitelity SIP/2.0 200 OK
Jul 17 7:51:09.762 AM PBX < Vitelity SIP/2.0 200 OK
Jul 17 7:51:10.761 AM PBX < Vitelity SIP/2.0 200 OK
Jul 17 7:51:12.780 AM PBX < Vitelity SIP/2.0 200 OK
Jul 17 7:51:40.829 AM PBX > Vitelity CANCEL sip:[email protected] SIP/2.0
Jul 17 7:51:40.829 AM PBX < Vitelity SIP/2.0 481 Call leg/transaction does not exist
So it’s clear from these that they think they are sending 200 OK packets but my end never sees it. I have no idea how to even start troubleshooting this one. Why doesn’t it just see those 4 packets but everything else is passing as it should? Why does it only happen when it reaches the VM on a Verizon number?
I understand you guys probably don’t have an answer to the questions above but I am a bit at a loss here.
I’m fairly sure that the failure to receive the 200 OK is caused by a short timeout in your router or firewall.
It likely is not related to VZ or voicemail but to a call answered after a relatively long time. You can confirm this by calling a number that does not have voicemail or an answering machine enabled. Ask the remote party to wait 45 seconds (eight rings) before answering. I suspect that after he answers, the call will drop 32 seconds later.
A possible workaround: For the trunk in question, set qualify=yes qualifyfreq=20
then try some test calls.
If that works, the proper fix is to increase the UDP timeout in your router or firewall.
If you still have trouble, please provide details of your network setup (make/model of relevant equipment, port forwarding and firewall rules, etc.)
Giving this a shot as I didn’t have that enabled on the trunk prior. Vitality also did state that they “don’t support qualify settings on trunks” whatever that may mean.
The firewalls that we have implemented are the Unify Security Gateways 3P at the two locations that are experiencing the issue. Not sure if it’s those as that’s the same equipment we have implemented at other locations that aren’t experiencing the problem and we don’t have any special configurations or settings at these two locations that I can think of.
I don’t know if this is related to your issue, but I found a credible post about UDP associations being prematurely destroyed. See https://community.ubnt.com/t5/UniFi-Routing-Switching/USG-UDP-connections-destroyed-before-default-180-second-stream/td-p/2142633 . If the log shows this happening to you, Ubiquiti support may be able to help. Forwarding the port would likely be a workaround, but it’s a security risk, unless you limit it to the proper Vitelity addresses. If you are already forwarding the port, you’ll probably need to log traffic on the WAN side to see what is going wrong.
Saw those articles as well and checked. SIP ALG on these USGs is off by default (and I’ve checked to make sure that they were indeed off on these devices). UDP stream timeout is 180 by default, I actually bumped it up to 240 to see if that’ll make any difference.
I wasn’t able to troubleshoot much more then this as there seem to be some major outage going on so we’ll get back to it once things are back to normal.
So a quick update for everyone now that around 24 hours has passed. Adding the qualify flag options to the trunk settings seems to have resolved the issue. I’ll post an update if I find out anything else but that seems to have made a difference!
Edit 09/11/2018: Another quick update. I managed to get pjsip trunks working with Vitelity as well and now days it seems like a much simpler setup then even doing a chan_sip trunk. They have worked great and we haven’t run into any major problems since switching to pjsip for trunk configurations.
