No audio on some PJSIP endpoints

We have a system that is having a weird issue with PJSIP extensions.

The issue is a lack of audio on PJSIP extensions on internal calls when connected from some public IP addresses. It started on 5/21/24 with no known changes to the PBX or ISP. The PBX has a public IP address and is one of many within the same data center and is the only system having an issue.
Here is what hours of testing determined. The problem is only present on PJSIP extensions connecting from some public IP addresses. In other words, calls between 2 PJSIP extensions in location A will work fine but between A and B there is no audio but the call will complete. If either is a CHANSIP extension there is no problem. The issue on exists on internal calls. External, using a trunk, are fine. If I enable call recording on an extension the audio is present on the call. I restarted Asterisk and rebooted the server with no affect.

The only way to get the audio to work was to disable direct media on the affected extensions. The issue seems to be related to the public IP address of the endpoint. When looking at packet captures there was no RTP stream or the port was in the 3xxx range.

This system was installed 3 years ago and this just started.

If the affected extensions are connecting via T-Mobile home or business internet, they made a gateway change two days ago, which might be your issue. See

Audio is present on the recording (but the parties still can’t hear each other), or does recording cause the call to start working? If the latter, try setting Direct Media for the extensions to No.

The affected ISP’s are at least Verizon Wireless and Altice. Frontier works fine. I suspect it is something within an external route.

Yes, the recording also has the audio. When recording is enabled there are no problems and everything works perfectly.

If Direct Media for the extensions was set to Yes, try setting to No and test.

If it was already No, or setting No doesn’t help, report whether enabling recording causes different codec selection or other media flow changes (encryption, packetization, etc.)

I had to turn off Direct Media to fix this.

OK, so there are (at least) three possibilities:

  1. A change in Asterisk or pjsip resulted in a new bug, causing direct media to be inappropriately invoked. I’m guessing that the LAN subnets at both locations (A and B) are the same (for example 192.168.1.0/24), but Asterisk is no longer taking into account that direct media won’t work if the public IPs are different.

  2. The bug has been there all along, but a change at one of the locations, e.g., new ISP, new router, firmware upgrade caused the LAN subnets to match.

  3. Both A and B have a SIP ALG enabled, which pretends (to Asterisk) that the endpoint is on a public IP. Asterisk assumes that the two public IPs can communicate directly and enables direct media. In this case, it’s necessary to manually turn it off.

Speaking from an Asterisk perspective, that code hasn’t really been touched in… a long time. The “don’t do direct media if behind NAT” is a separate option in PJSIP disabled by default, and it looks at whether the IP address and port defined in the SDP is different than the source IP address and port of the media.

Regarding chan_sip, the OP may will have copy and paste coded the configuration and used canreinvite=no, without realising it is an obsolete name for directmedia=no. They may have thought they hadn’t set directmedia off, for chan_sip, when, in fact, they had.

I am using Asterisk 18.9 and have for a long time. This started suddenly on Tuesday without any changes being done. It seems it seems like the "don’t do direct behind NAT stopped working and needs to be explicitly enabled. The weird thing is that the is doesn’t happen with every connection. It seems ISP related.

Part of the problem here is that for chan_pjsip the extension configuration defaults to having Direct Media enabled in FreePBX. That would mean any of your internal calls would have both endpoints trying to use Direct Media with each other and yes that can be impacted by the Internet connection they are using and other networking factors involved.

Direct Media is automatically disabled if the following are used on the call, Confbidge, MixMonitor (Monitor too for legacy), ChanSpy and various others found here Asterisk PJSIP Troubleshooting Guide - Asterisk Documentation

So when you enabled call recording you immediately forced Direct Media out of the call and that is why there is audio on those calls.

I understand that direct media is the cause of the issue as well as the fix and that call recording disabled direct media. That’s why external calls work as well as as calls when recording was enabled. There were no changes made prior to this issue starting.

I am trying to determine two things.

  1. Why this started suddenly on Tuesday
  2. Why it only only occurs with certain public IP addresses. The issue is not happening on all calls.

Did you trunk also have Direct Media enabled? Direct Media only works when both endpoints configured in Asterisk have it enabled. If one has it disabled, it doesn’t work.

No idea, we haven’t seen any real troubleshooting data from the system.

It doesn’t occur with certain IP addresses, it occurs with certain networks. Again, we haven’t seen anything that tells us any real details. But one possible answer to this question is, Phone A calls Phone B over the Internet via the PBX with Direct Media on. Phone A has RFC1918 (private) IPs listed in its Contact or SDP information, possible Phone B does as well. You can’t send media over the public Internet if the destination is 192.168.1.124 (or any private space).

So depending on the devices involved and the network they are on (which will be NAT’d) some of them can be sending private IPs in the SIP packet when there should be public IPs and since there is nothing in between to repair said NAT issues, they become NAT issues at either side.

Turning Direct Media off or using certain features of Asterisk makes Asterisk stay in the media path which then allows Asterisk to fix all the broken NAT your devices use.

I know I have not provided every detail needed to figure this out but I have provided a lot of information.

Yes, the issue is likely present on certain “networks”. I don’t have the ability to test with multiple addresses with an ISP’s network so I stated an exact problem. I do have the ability to test using my home network and a cellular connection and can reproduce the issue. Using the exact same phones and networks, connecting to two different severs in the same data center that use the same routes and firewalls, gives two different outcomes. One server results in no audio while another server has no issues, Same routes, same phones, same networks. I use the same SIP settings. Trunk calls have no problem so I did not look at direct media but it is not allowed. NAT is enabled and always has been.

I fixed this, but I would like to understand what is causing the issue to happen.

Trying to do Direct Media between two endpoints that are behind NAT causes this problem. It is random because depending on the router, firewall and other factors it can change how the SIP packets are handled. If the network doesn’t handle NAT problem and is sending a private IP in the SDP/media information then the other phone is trying to send media over the public Internet to a non-public IP which is going to fail and give you the issues you were having.

I understand what you are saying and agree with it. I figured that out before posting. My question is what changed last week to make this start happening on just this system? Yes, I know there is a NAT issue so I made changes to address it.

Since NAT is enabled in the SIP setting direct media should be disabled. This is evident in the fact that this system has been working without issue for over three years.

I am trying to determine what changed to make this start happening. I did not enable direct media last week. I made no changes to the system at all. The only changes were to disable direct media when making the correction.

I am working under the theory that there was a module update that caused this. The system is version 15 with Asterisk 18. I will update to 16 and see if the issue is resolved.

The only thing a module would do is either turn it on in Asterisk, or change Asterisk configuration to allow direct media to occur where it didn’t occur before.

Since Asterisk hasn’t changed, those are the only two things I can think of from a FreePBX/Asterisk perspective.

Direct Media is enabled by default, in FreePBX, for chan_pjsip extensions. You have to actively turn it off.

I agree that something changed in FreePBX but I don’t know what.

I didn’t say something changed in FreePBX. I said those are the two things I can come up with. That doesn’t mean something did change.

Why do you care? If your system doesn’t benefit from direct media, I suggest that you turn it off for all extensions and call it a day. If you have some other reason for troubleshooting (to help the community, to use in a future system, whatever), paste a log of a failing call with pjsip logger turned on and explain how that differs from expected behavior.

If your system does benefit, explain whether the failing calls were expected to have direct media but it didn’t work, or whether direct media was inappropriate but Asterisk tried to invoke it anyway. Paste a log showing what happened.

Not true. Except for those on the same LAN as an on-site PBX, nearly all user endpoints (IP phones, softphones, SIP apps) are behind a NAT. For example, internal calls on a cloud PBX have lower latency with direct media, as do calls within a branch office via a PBX at headquarters. When the users are (at least somewhat) also within earshot, the direct sound is a “pre-echo” of what’s heard over the phone and this can be quite annoying when the delay is significant.

So Asterisk has to be smart about when direct media is used. Unfortunately, SIP ALGs, firewall misconfiguration and other problems may make it impossible for Asterisk to reliably determine whether direct media should be used, which is why the administrator can disable it.