I had an inbound route where the caller ID was set to a priority route to an extension. It’s worked for years. A month ago I changed the destination to an announcement which then sent the call to the extension. That worked. This week I changed the route back to the original setting directly to the extension instead of the announcement. It routes the call to the extension, however there’s no audio when it’s answered.
I’ve tried everything including deleting the Priority route and recreating it. Nothing works. Except… now if I set the Priority route to again point to the announcement, it plays the announcement then transfers to the extenaion, and there’s audio.
What else can I try? I tried to paste in the log file but it says it’s too many characters. What can I try?
If the PBX is behind a NAT (either cloud or onsite) and the extension is not at the PBX site, confirm that the UDP port range for RTP is properly forwarded (in your router or cloud firewall) to the PBX. Also check in Asterisk SIP Settings that External Address and Local Networks are correctly set. Restart Asterisk if you change these.
If you don’t want to troubleshoot the problem or it’s too hard to fix, set the Priority Route to a ring group containing just the one extension. Set up hold “music” that consists of your announcement followed by ringback tone. That way, the announcement won’t delay ringing the extension.
If you don’t need an announcement anymore, another workaround is to set Inband Progress for the trunk.
The extension is local to the PBX, and it’s worked for years until the change mentioned above.
I just changed it back to the extension and it worked fine. I placed a second test call, having made NO changes, and it failed.
I’m confused about several things. Is the call in question supposed to be encrypted on the trunk side? On the extension side? (based on SRTP errors in earlier log)
Is ‘indent preformatted text’ actually in your log, or is it an artifact of the forum?
The log shows you calling out and back in via the same trunk. With some providers, that’s problematic or requires special setup at the PBX end. Do you get the same failure when calling in e.g. from your mobile?
The log shows routing to a ring group that forks to extension 202 and an external number. Does the simpler case of routing directly to the extension fail the same way?
The encryption is the Sangoma and SipStation encryption so trunk side? Never had a problem with it in the past, and still don’t if I go to an announcement first then the extension.
‘indent preformatted text’ was added when I clicked the preformatted text button when submitting the logs. I thought it would indent it to make it easier to read but clearly it didn’t.
I’m not sure what you mean that I’m calling out and back in? The call comes in. It is ringing both an external number and my extension. Same as it’s been for years. And no, I don’t get a failure when calling in from my mobile.
The call isn’t routed to a ring group that I can recall. It’s just inbound priority route to extension (with follow-me to cell). Which fails. Or…inbound priority route to announcement then my extension (with follow-me to cell) which works.
Sorry for the confusion. You hadn’t mentioned follow-me until your last post, so I had assumed that the call was ringing just one extension. The follow-me feature shares logic with ring groups so the log looks similar.
I suspect that the problem is related to decryption (see log lines 861 to 863), though SRTCP doesn’t directly affect the SRTP audio. Unless it’s related to libsrtp version (see
and the link in that thread), I don’t know enough to understand specifically what’s wrong.
Now I’m more confused. I thought that from the FreePBX system under discussion, you made an outbound call to your own DID for this test. For several reasons, this may behave differently than a one from an outside caller. Who is the intended caller for the failing priority route (a user on your system, a user in your organization on a different system, a customer or vendor who happens to be using SIPStation, etc.) It’s indeed interesting that calling from your mobile doesn’t fail (I assume that for this test the Priority route included your mobile number). Have you tested from a landline or other outside source?
Yes. I set an internal extension to use the caller ID of the Inbound route, which is a customers’s cell phone number. I placed test calls and they worked, correctly routing the call and showing the correct CID (the customer’s CID). Then the real caller called from their cell with that CID and it failed. It routed, but there was no audio. I went back to the same internal extension that had worked before, and now it fails as well. I’d made no changes since the first test.
If I modify the Inbound route to send to an announcement first and then the same end extension as used before, it all works fine.
And yes, the end destination extension has a follow-me set up which includes itself and an outside cell phone.
It’s a common complaint, inbound calls that get forwarded to the PSTN off the system have zero way audio. As with most audio issues it’s NAT config, I suspect you don’t have the RTP port range forwarded to the PBX at the router. Setting progressinband (search the forum) will sometimes resolve this, answering the call and sending audio before forwarding call always resolves this.
This inbound route has literally worked for years. I modified it to send it to an announcement (a “mission impossible announcement” for this one customer as a joke. And then after he’d heard it, I switched it back to the extension instead. That’s literally the only change I made that took it from a long-time working inbound route, to a broken one. The end extension is internal. The cell phone in the follow-me of course is not. But that follow-me was never modified during any of this.
Initially, I didn’t think it was a NAT problem, because the OP hadn’t mentioned follow-me at all, and because (paraphrased) “it used to work but doesn’t anymore”.
When the detailed log was posted, the forked call was answered on ‘local’ extension 202, so I assumed that no forwarding was involved. Indeed, 202 was picked up within 3 seconds of when the outbound call to the mobile started (timestamps 2 seconds apart), so it’s unlikely that the outcome was affected by any action on that call.
However, if the OP has a pfSense or similar finicky firewall, this may indeed still be a NAT problem and that’s worth checking. Also, I assume that the OP has confirmed that this isn’t a libsrtp version issue.
If progressinband doesn’t help, try setting Force Answer for the priority Inbound Route.
Questions for the OP: Is extension 202 on the same LAN subnet as the PBX? If not, describe relevant networking. Is the extension using SRTP? Hardware router/firewall make/model? Does the PBX have a NIC with a public IP address? Does the router have a public IP address on its WAN interface? If not, provide details (e.g. ISP-supplied gateway).
The PBX firewall is connected to a WAN directly to the fiber. I have PfSense in pass through mode on other IPs but this IP isn’t connected to PfSense because we had issues. This IP totally bypasses pfsense at the fiber switch. So one port on the PBX is directly connected to a public WAN.
One port on the PBX connects to our internal router in trusted mode. All the internal extensions are on that network. They are all on the same subnet. Asus RT-AC66W router behind pfSense in pass through mode so the router also has a public WAN.
I’m sure Igaetz looks at way too many systems to remember mine, but he checked out my system troubleshooting an external extension issue not long ago. He looked at just about everything in the system (THANK YOU!) to make sure everything was good. No issues. And at that time, this particular route was working the way it was supposed to as well.
I haven’t made any changes to the progressinband settings. So far I’m seeing mixed opinions on it and knowing it was working, I’m hesitant to start changing things that don’t seem related to the change made when it stopped working.
Remember, when I tested it by setting an internal extension to that caller ID it worked. But then a few minutes later it did not work but no changes had been made.
You know, all the clues are there, announcement before sending to recipient fixes issue, answer before sending call to recipient fixes issue (what else?). These are exactly the types of things you test when you suspect it’s an issue of router config when PBX is behind NAT. I can’t help, but would love to know what the final solution is. I’ll wager a doughnut it’s your router somehow.