Calls from internal extensions to DIDs on PBX result in no audio

Hello

I am running FreePBX 14 on Asterisk 13.22.0 that is hosted in the cloud.

I have a really odd issue where calls to DIDs on the box that originate from a local extension on the phone system result in no audio both ways.

However, if I place a call to a DID on the box that originates from an external number, audio is there.

As this is a hosted solution, all phones are remote.

Seems like a NAT issue… but I’ve verified that my public IP is configured correctly under Settings > Asterisk SIP Settings. The NAT setting for the extensions are configured to yes, etc…

Anyone have any ideas?

Here is an sngrep output… it is showing RTP?

SIP flow is below…

https://wiki.freepbx.org/display/SUP/Providing+Great+Debug#ProvidingGreatDebug-AsteriskLogs

Post a full log of a failed call.

Here you go: https://pastebin.freepbx.org/view/0a2857e8

Does that give any insight?

UPDATE: When dialing a DID that resides on the PBX as an inbound route from a local extension, there is no audio in either direction and the call terminates at exactly 30 seconds – the default RTP timeout in FreePBX… so apparently no RTP is being sent in this scenario.

Anyone have any idea why RTP wouldn’t be sent in this scenario but local extensions can dial out to external numbers just fine and there is two way audio? Additionally, incoming calls from the outside world to the PBX have two way audio as well.

Reasonably and economically you need a loopback trunk to route those calls.

1 Like

Hi dicko

Can you elaborate?

I realize it’s not best practice for an internal extension to dial an inbound route to reach another extension… they should just be dialing the extension number… but… users.

Can you elaborate a bit more on what I need to do to make this scenario work?

There is a search spyglass at the top of this page, regurgitation is not necessary :slight_smile: @lgaetz has oft posted his howto

That took care of it, thanks Lorne.

I set my loop back trunk to play the congestion message instead… don’t really like the idea of encouraging incorrect behavior to users :slight_smile:

1 Like

there is nothing incorrect about the users behavior, it is up to you to provide a robust route. hanging up is incorrect on your behalf

Hi Dicko-

I took your advice, I have it working as it should – thank you.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.