No Audio on PJSIP SIP Servers after power off/on

We have multiple FreePBX 13 servers on a network, 3 that were upgraded from FreePBX 12 using all CHAN_SIP and 2 that were fresh installs using all PJSIP. These were all powered down to do some server maintenance, then powered back on. The 3 CHAN_SIP servers are working fine, but the 2 PJSIP servers both now have the same problem, which is, any calls inbound, outbound or Ext to Ext, all have no audio. The phones will dial out or receive calls as usual, but as soon as you or the remote person answers, neither party can hear the other. Even if one extension dials another, and does not answer, but goes to voicemail, you cannot hear the voicemail greeting.

Just curious if anyone has deployed a brand new FreePBX 13 server using PJ_SIP as the only trunk and extension type, and has no problems with extensions being disconnected when changes are made to the server.

A guess would be RTP port block on your firewall, voice packets goes through different port than your signalling (SIP). So you can send and receive calls but audio is dropping by the firewall.

I just confirmed with a packet trace on all UDP traffic coming into my servers public IP, that nothing was dropped. Also, there is no traffic coming in other than 5060. I have made and received calls using 2 different vendors SIP trunks, confirmed with CDR’s, and still no audio. I’m not sure if the FreePBX server decides what port to use for the call or if the carrier that you are connecting to decides that. With no changes to the firewall configuration for almost 2 years, and was working in production until today, the only thing we did was power down the server for maintenance and then power back on. Each of these servers that no longer work are on two different firewall zones, different subnet’s and a different set of firewall rules. The only thing they have in common are they both are 100% PJSIP. One of these in particular has about 15 or so extensions for phones and some ATA’s. Any time I apply updates or make changes to the extensions, when I go back to the Dashboard page, it looks like an EKG machine with several extenstions randomly disconnecting. If I leave the server alone for about 20 minutes or so, then all extensions come back online. None of my CHANSIP servers do this.

Those statements are contradictory. A SIP call, by definition, has traffic on port 5060 (signaling) and a random port between 10000 and 20000 (RTP Voice Traffic). If you are not getting both, then something, somewhere, is getting dropped.

If the data is not being delivered to your external address, there’s a misconfiguration in the sending phone/server’s sending config. In cases like this, the usual culprit is in the NAT settings for the system.

My firewall is set to allow 5060 and 10000 to 20000. I was just saying that no traffic has entered in through the 10000-20000 range, even after trying to make and receive calls. There is absolutely nothing wrong on our end or either of our two SIP vendors. Something internally with the FreePBX server is not right. I have already moved all voice and fax extensions to another server (CHANSIP), which is on the same subnet, with the same firewall rules and everything is working fine. At this point, I will be creating another FreePBX 13 server, but this time I will use CHANSIP instead of PJSIP.

Smart move. I’m sure their are thousands of installs using pjsip successfully, I personally would never use it in production at this time. OMHO

As far as using Chan-SIP goes - good idea.

Your statement above has me a little perplexed, and it’s probably just because I’m reading too much into it.

When you set up the firewall, your forward all incoming UDP traffic from 10000-20000 to forward to one of your internal servers. Your description makes it sound like you have two in the same subnet. I’m pretty sure that doesn’t work. Having said that, keep in mind that I may also be misreading you.

When I set up systems where there is more than one server behind the firewall, I ‘carve out’ ranges in the 10000-20000 zone for each and tell the sending system to limit RTP to that zone. Note also that if your machine is telling the remote server to send to a non-routable address (the NAT settings on both of the SIP Settings tabs need to be right), the remote system will do what the system says and your audio will be delivered to a convenient non-routable bit bucket at the sender’s end.

Having said all of that, I support your decision to change this connection back to Chan-SIP. While PJ-SIP is the way of the future, that future isn’t reliably here yet for anything but phones. I’ve seen a spate of recent reports about PJ-SIP not playing nice on the trunk side of things.

Sorry, here is a little more clarification. I have a private subnet with multiple servers, but each server has their own private and public IP address. I also do hosting, so each server I host or use, has it’s own public IP and each IP has NAT rules to forward all traffic coming into that public IP, to it’s corresponding private IP. All outgoing traffic from a given servers private IP is translated back to the public IP when it goes out on the Internet. I know for sure that the focus here should be on the server itself and not anything related to the firewall or networking.

OK then, the problem has GOT to be in the NAT configuration of the SIP Settings under the Advanced Tab. Either that, or you’ve wandered up and stubbed your toe on a PJ-SIP bug.

Try the set it up with Chan-SIP and see of the problem continues. Note that the same Advanced Settings issues may exist. If you still have problems there, let us know the configuration of your Advanced SIP Settings and we can try to steer you in the right direction.

Update: As I was preparing to deploy a brand new server, I decided to take the testing extension that I have been using with PJSIP and switch it over to a CHAN_SIP extension. I did have to change the port to 5160 on my phone to make it connect, but I can now make calls and hear the audio. The firewall already had this 5160 port open, so no changes were made here.

Maybe you had 5160 open instead of 5060 on your firewalls before. PJSIP an CHANSIP ports are different in default configs as you know.

Both ports have been open all along. I’ve made no changes to the firewall.

Final Update on PJSIP problem: I ended up changing the server over to all CHAN_SIP on 5060. Then I tried to convert an existing PJSIP extension to CHAN_SIP. Now, instead of no audio, I had one-way audio from the IP Phone to the remote party, but I could not hear the phone dialing and no audio coming back from the remote party.

Two things completely fixed this ‘no audio’ problem. I ended up deleting all PJSIP Trunks and recreating them as CHAN_SIP. I also had to delete every PJSIP extension and even the one extension I had converted from PJSIP to CHAN_SIP. I then recreated every extension as CHAN_SIP (my only choice now), and everything is back to working perfectly.

No firewall rules, NAT rules or changes to the Asterisk SIP Settings in FreePBX, were necessary. I hope this helps someone else that may be having similar issues using PJSIP. Thank you to those who replied.