Most incoming calls hang up when answered... but not all

I’m running the most current SangomaOS distro (12.7.6-1910-1.sng7) with FreePBX 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.

Failed: driveDOTgoogleDOTcom/open?id=1A-JuzgjGf3i7Sx7OfPhFIz6JO9nuNo2y

Success: driveDOTgoogleDOTcom/open?id=1lz45SpubLH7DeMPJO96lujpSpKR616M5

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.

Link to tcpdump instructions:

1 Like

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

I believe that you can post links now, but if not, just replace the last dot with %2E for example
which can be pasted into a browser without editing.

Also, check

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.

Try with setting the parameter fromuser

Where would I set this? Phone? Extension? Trunk?

Trunk, but the value must be provided by your provider, in case they require it they should be able to tell you how to configure the trunk.

Their documentation didn’t have anything in there about that. I’ve got them setup on several other clients with same config and don’t have this issue.

Also, I’m using PJSIP so not sure where you set the fromuser setting in freepbx (if you even can)

If it is indeed configured exactly like all others, maybe you have a NAT issue.

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’m confused about your last post.

This implies that inbound calls directed to the softphone often fail.

But that implies that inbound calls directed to the softphone work properly.

Which is it?

In either case, confirm that Direct Media for the trunk is set to No.

I just noticed what may be wrong. The failing call shows Skyetel_SE as the matched trunk; the working call shows Skyetel_Outbound.

So it appears that Skyetel sends calls from more than one IP address (that’s normal) but that one or more don’t match the intended trunk.

Why do you have two (or more) Skyetel trunks in the first place? How do their settings differ?

Normally, you would use just one trunk, but set the Match (Permit) field to include all addresses from which the provider can send calls.

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.

Here is their instructions that I’ve followed (and use at other locations with no issue):

The tool tip for Match (Permit) in the Advanced PJSIP Settings is pretty clear:

In your outbound trunk, just put in all the addresses from which Skyetel sends calls and you should be good to go.

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.