Running FreePBX 16 and having an annoying issue with inbound calls using my Voip.MS trunks. The calls will randomly not go through, but then be fine minutes later. The registration continues to show as active even when calls are failing, but nonetheless, calls fail.
Here’s a pastebin containing the asterisk logfiles for a recent example of an inbound call hitting the PBX but failing. NOTE: I have changed the DID to 0000000000 for privacy reasons - it was properly displaying the DID in the logs.
kindly can you give asterisk logs for more detail about this error then i will try to solve out it. otherwise it is difficult to sort out issue.
Best regard
Danish Hafeez | QA Assistant
ICTInnovations
The immediate cause of the failure is apparently the error return from sangomacrm.agi, but the underlying cause is hidden. For example, see
With luck, if you temporarily disable the CRM module and/or turn on pjsip logger, you’ll be able to see the trouble (or paste a new log).
BTW, I recommend using pastebin.com ; pastes (by default) last forever, so future readers of the thread can follow along. That used to also be true at pastebin.freepbx.org but someone at Sangoma recently changed it (IMO a bad idea).
Thanks to you both for the replies. I turned on logging and have a (hopefully) helpful new pastebin here.
I also disabled the CRM module before getting these logs, and the calls are still failing.
Once again, DIDs, Voip.MS IDs, and IPs have been altered in the pastebin, so no need to worry about that being a potential issue.
(Good to know about FPBX’s pastebin - thanks!)
Wow, there was noINVITE (incoming call attempt) shown at all, only OPTIONS (qualify) requests going out and good replies coming back.
But your other example did show an INVITE being processed, so either it’s failing in (at least) two different ways, or the 09:44:50 to 09:45:27 didn’t include the time the INVITE came in.
However,
493 Via: SIP/2.0/UDP 192.168.1.123:5060;rport;branch=z9hG4bKPje07ac140-ae6d-4195-84fb-d88be9db9138
494 From: <sip:[email protected]>;tag=24e272dc-5d0b-40dc-a6b8-c2db03d10d7d
495 To: <sip:[email protected]>
496 Contact: <sip:[email protected]:5060>
This is weird. Normally, Asterisk would substitute its public IP address in the Via and Contact headers. If this is a redacted public IP value, why did you put a private IP here? If this is the actual value, confirm that in Asterisk SIP Settings, Local Networks and External Address are correctly set. If you change these, after Submit and Apply Config, restart Asterisk.
If this is the actual local address, it looks like Asterisk has both 192.168.1.123 and 192.168.86.128? If so, explain the network setup.
Sorry, I should have clarified. 192.168.1.123 is what I replaced the external IP with for privacy reasons, so that is where the external IP is in the actual logs.
I realize I should have probably replaced it with some more obvious generic external IP. Sorry about that!
OK, so did your paste show the wrong time range, or was there really no INVITE? If the latter, is there any clue logged at VoIP.ms? Or, can you capture traffic on the WAN interface to see whether your firewall blocked it (seems unlikely, given that the OPTIONS replies got through)?
Nope, the paste should be right with the time range. I didn’t change anything besides the external IP. So whatever’s there is what I got back.
What, if anything, did VoIP.ms log for the call? If you made the call yourself, e.g., from your mobile, what did you hear? Was there a long delay (expected if VoIP.ms was repeatedly sending INVITE retries) before your phone showed an error? Do you have any failover set up at VoIP.ms?
Voip.MS logged the call as successful because, in their eyes, it hit the PBX. On my end, it sat there for about 20 seconds, then returned the “call failed” screen.
Well, if FreePBX Firewall somehow blocked the INVITE, you should be able to see it by running sngrep. Or, if your hardware firewall blocked it, a capture on its WAN interface should show it. Otherwise, maybe open a ticket with them asking what address/port the INVITEs went to and what responses, if any, they received. Is there possibly another device on your LAN that is sending competing / conflicting registrations?
There shouldn’t be anything else on the network that would interfere. I’ll take a look at the firewall when I get home tonight.
Ok, so as I suspected, there is nothing that would be interfering. I added the POP server IPs into the firewall and fail2ban so that they are explicitly mentioned, and so far, it seems to be working, save for one or two times I still couldn’t get through. Will update if this is still an issue over the weekend.
After 5 years of random trunk drops between our PBX’s and voip.ms we determined with their support the missing information.
Here are core requirements for their PJSIP Trunk setup requirements that are not declared.
Authentication and stable operations requires. VOIP.ms subaccount to be listed in A. Username, B. Auth Username and C. (under Advanced) "From User "
Without the VOIP.ms subaccount name being in “From User” we have found that calls are not processed randomly and without visible notification, just operational issues. Once we added step C. our trunks with VOIP.ms have been stable.
Call forward, ring groups, Follow-me calling not working - unless you at a minimum enable “Send RPID/PAI” or enable “Both.”
We have spent hours to get our FreepBX trunks and SMS to work and it all seems very stable now with these changes.
Cheers
We have a Freepbx-VoIP.ms setup and have not noticed random trunk drops in the past 3? years. I find nothing entered in this setup’s pjsip settings for Auth Username, nothing in From User. The only difference I can tell (I’m sure there is more) is that this setup is not using a VoIP.ms sub-account, but the main account. We sometimes use the sub-accounts for a sort of backup registration and not any of those are PBX-type device configuration.
I’m not going to say you don’t need those entries, @rwise, but I am just curious that we don’t need them.
I have seen @dsirota similar “conditions” when the PBX was behind an edge router that was not configured for NAT port forwarding/mapping. No calls in, but I suspect firewall state tables temporarily allowed the incoming routing just after making an outbound call. Seemed we could get inbound calls for awhile after placing an outbound call.
I never proved all this because I configured the port forwarding and all has been fine since.
They should not be recording it as successful unless and until they receive a 200 OK, in which case Asterisk would have logged an INVITE.
They can’t claim it even hit the PBX unless they have a response, and, again, that would mean an INVITE would have been logged.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.