I’m running the most current SangomaOS distro (12.7.6-1910-1.sng7) with FreePBX 15.0.16.27 and Asterisk 16.6.2. All modules are up to date.
The issue I’m experiencing is that some, but not all, inbound calls will simply hang up on the person when a call comes in. If the user calls back it will usually answer and is fine. Outbound calls have no issues at all.
Handsets are Grandstream GXP2170’s and I have one softphone extension that I’ve been using for testing as well. The issue occurs regardless of endpoint device.
Firewall is pfsense and provider is Skeytel. I’ve got this same combination (firewall and provider… PBX may be slightly older version) at other locations with no issues so I don’t believe it is anything from that end.
I have snippets from call logs for both failed and successful calls which I will post in separate reply to keep things clean. Any guidance of where to look net or what I can try would be greatly appreciated.
…and I can’t post links cause I’m new and the log file is 3500+characters and limit is 3200… sweet. so if you are up for some arts and crafts, here are the links to the call logs.
Yeah, I have no idea what could be causing it because it’s a lot of things. It could be anything from the local network, the itsp, or a configuration issue. So, where I would start is to try and eliminate the network as a possibility, since 90% of VoIP issues always seem to be network related.
First thing I would do is look at the log files in /var/log/asterisk/ and see if that gives you any clue as to what is going on.
Next, I would look at the traffic to and from the FreePBX system and the phones, itsp, etc. and try to reproduce the issue. You can do this with something like tcpdump app, or some other packet capture application. There is a SIP packet call flow, and those packets must lineup or there is a possibility one side will hangup the call.
Thanks for the pointers. I’ll try and capture a call with tcpdump… the trouble is that it may occur with two calls and then be fine for a period and then it will happen again. Typically if a user calls right back it will answer no problem.
The logs in my second post where from the /var/log/asterisk file just filtered down to the specific calls.
ISP is AT&T fiber so I don’t expect too many issues on that front (but I won’t put anything past them). If it is a configuration issues, where could I begin to look to troubleshoot that?
As far as configuration goes? I have no idea, there are many settings and combinations of settings that could be causing it. But it’s unlikely settings.
[2019-12-23 08:24:25] VERBOSE[32687][C-00000001] bridge_channel.c: Channel PJSIP/104-00000001 joined ‘simple_bridge’ basic-bridge <a81c4018-b0ae-42ba-a8eb-49e6a08252d5>
[2019-12-23 08:24:25] VERBOSE[32669][C-00000001] bridge_channel.c: Channel PJSIP/Skyetel_SE-00000000 joined ‘simple_bridge’ basic-bridge <a81c4018-b0ae-42ba-a8eb-49e6a08252d5>
[2019-12-23 08:24:25] VERBOSE[32669][C-00000001] bridge_channel.c: Channel PJSIP/Skyetel_SE-00000000 left ‘simple_bridge’ basic-bridge <a81c4018-b0ae-42ba-a8eb-49e6a08252d5>
So the trunk side dropped the call within the same second after answering. Possibly, a codec issue or a refused re-invite. With luck, a SIP trace may be all we need to diagnose. At the Asterisk command prompt, type: pjsip set logger on
and call in until you get a failure, then post the log. Please don’t use Google Drive or any other service that requires the reader to log in or provide any information. We recommend pastebin.freepbx.org
I believe that you can post links now, but if not, just replace the last dot with %2E for example
pastebin.freepbx%2Eorg
which can be pasted into a browser without editing.
Thank you for the feedback. I opened a ticket with our provider as well and they just responded that the call was “failing on an invite response” which jives with your re-invite hunch. They suspect it is the extension CID responding with internal info and not the DID so I’m exploring that now.
I did see that I can post links now. I’ll use the pastebin in the future but the links I provided where wide open with no authentication needed (cause I hate that stuff too!)
As for the pfsense… I’m more than confident that it is configured properly as it is the same setup as most of my other clients have and they have no issues, even with the same provider.
I’ve double checked that and doubt it is a NAT issue as well since it does work part of the time. That and the fact that all outbound calls work perfectly. Softphone from outside of network works perfectly as well.
Does your pfSense get a public IP address on its WAN interface? If not, the AT&T fiber connection is a “gateway” (configured as router) and it would be my first suspect.
IMO it’s very unlikely that the From User setting is the culprit. This normally overrides the user field of the From header on an outgoing call. For it to affect incoming, the re-invite would have to be initiated by Asterisk. It’s wrong for that to happen at all (and would require several non-default settings for that to occur).
Please post a new log of a failing call with pjsip set logger on
turned on.
I can see how that is confusing. Basically I can put a softphone on the system, call extensions, call outbound… no issues, hence: no issue with NAT/firewall setup.
I was trying to convey that the inbound call issue happens regardless of device used on the extension (thus ruling out the specific handsets
Yes, they send from multiple IP’s and agree that setting multiple IP’s per trunk makes the most sense but the field in FreePBX only implies a single IP can be placed.
The Outbound labeled trunk uses SRV record which overlaps for some of the inbound IP’s but doesn’t include all of the inbound.
How would I go about setting multiple IP’s on a PJSIP trunk in FreePBX 15? On the chan_sip stuff I know they had edit fields that allowed you to do stuff like that but am not certain how to do it with PJSIP.
I disagree that that is “clear”. Sure, it means “allow these IP’s that match” but what do you place on the “General” tab for “SIP Server” then? If I put one IP there… the trunk talks to one IP not the list of IP’s in that advanced tab. If it DOES work that way then no, it is NOT clear that this does that.
