I have a brand new FreePBX 14.0.13.4 running in a HyperV VM. I am using Sangoma s505 phones and auto provisioning and that is all working. I am also using SIPStation trunks as well as a VoIP.MS trunk. The trunks and the phones all register fine. I am getting a random one way audio condition not only for external calls but also internal calls, and it’s all random. Extension to extension one way audio I haven’t been able to track down at all as the phones are in the same office on the same network, no VLAN or anything like that. The rest of the office network is functioning fine so I don’t think it’s a network issue. The phones never loose registration either. I am about to have to scrap this whole project because I can’t get this figured out. I’m not a Linux person at all really but I’ve been using FreePBX for a few years and never had this issue. This office was using a hosted FreePBX (Cyberlynk) until we decided to bring on prem to save the monthly cost and we didn’t have any issues. We were using Cisco SPA525G2 phones with that, the Sangoma phones are all new. I am willing to pay someone for some one on one support but the prices demanded by most of the go to support people, like Sangoma, are more than we can do right now. It must be something simple that I’m missing but I’ve rebuilt the server twice and still have same issues. I used PJSIP extensions the first time I built the VM and those wouldn’t stay registered so I converted them to SIP. When I had the one way audio issues, I figured it was something with changing the SIP driver so I rebuilt it using SIP extensions right off the bat.
I know this is a lot to read. Any help would be greatly appreciated. I can provide more info if needed.
Some more info… I am using TLS for the phone transport and SRTP for media encryption. I have a LetsEncrypt certificate that I am using for all this. TLS traffic is set for port 5161 and the RTP port range is 10001-20000. Port 10000 is for Webmin so that’s why it’s excluded from the range.
Since one-way audio is almost always a NAT issue, we’re going to need to you look at your Extension module settings and make sure your NAT settings are correct. In addition, you’ll need to check the Advanced Settings tab and look for the NAT settings in both the Chan-SIP and PJ-SIP configurations.
With your phones and server in the same premise, there’s little advantage to the complications that adding TLS is going to add, especially since now you are working with the “non-routable” addresses that may or may not be associated with your server.
If I was debugging your system, I’d turn all of the SSL stuff off for now and configure everything so that it “just works”. After you get that going, reevaluate your security requirements and decide it SSL in the LAN is really something that you need. Not saying I believe you do or don’t - that’s your call.
My suspicion is that everything is trying to get to your external routable LAN interface (for the TLS) and the router is trying to figure out how the h*ll you expect this traffic to be routed and just giving up. The voice of experience says “Uh, no, that isn’t gonna happen.”
Ok, I will give that a try. I do have some external extensions that will be being used later so that’s why I preemptively enabled TLS. If I set the transport back to UDP, can I leave the SRTP enabled or should I also disable that? It’s a medical office so we felt that at least the voice traffic should be encrypted since there will be HIPAA and PCI information being exchanged on the calls.
As far as the extension settings… I have the transport set currently to TLS only with SRTP enabled. NAT is set to no, port is 5060 (TLS is using 5161). All the other settings are stock. As far as the Advanced SIP settings… External address field shows my static external IP, the local subnet is listed Local Networks field. RTP port range is 10001-20000 and the next settings are Yes, Yes, 30, 300, 0. ChanSIP settings are: NAT=no, static IP showing my external IP. Currently TLS is enabled, using the LetsEncrypt cert, set to TLSv1, don’t verify server=yes. Registration settings are 20, 0, 60, 3600, 120. Advanced general settings… bind address=0.0.0.0, bind port=5160, TLS bin address=[::], TLS bind port=5161.
I will disable all the TLS stuff for now and see what happens. Thanks for the help so far. If any of my settings look incorrect, let me know. I will update if the problem persists.
I set all the extensions to UDP only, disabled SRTP and turned off TLS in the SIP settings. I guess time will tell at this point if that resolved the issue. All of the phones downloaded their new configurations from EndPoint Manager and registered with the new settings. The internal phones to have the LAN IP as the primary SIP server and the one external phone I have is using the external DNS name as they should.
NAT is set fo no on the SIP settings page for ChanSIP. I haven’t gotten anymore complaints since setting everything to UDP but it was also late in the day and the office was closing so I should know more tomorrow. Also. I did notice that the port on the SIP settings page defaults to 5160 and the port on the extension defaults to 5060. Not sure why these would be different or why things would work intermittently if that was in fact an issue at all.
The extension port is the port where the extension listens for incoming SIP requests.
The SIP port on the SIP settings page is where the server listens for incoming SIP requests. They might be the same but they don’t need to be.
To use TLS on the internal LAN, you are required to have working DNS resolution to the internal address of the system, or proper hairpin routing setup and working for the IP in question. It sounds like you did neither.
So far everything has been working this morning since moving everything to UDP. As far as the TLS for the LAN… I have an Active Directory server setup and serving DNS. I created a new forward lookup zone in AD and created an A record for the external FQDN of the FreePBX to point to the internal IP of the PBX. That seems to be working normally because when I ping the FQDN from a workstation on the LAN, I get a reply from the internal IP of the PBX. I would think this would satisfy the TLS DNS requirements. Assuming everything continues to work with UDP, what would be my next steps to try to get everything back to TLS/SRTP? I am using Endpoint Manager and the auto provisioning service provided by the Sangoma phones and that all seems to be working properly. I have different templates for internal LAN connected phone versus an external phone. When the phone is internal, it gets the LAN IP and port for the PBX as the SIP server on the phone settings. When a phone is external, it get the internet FQDN and port for the SIP server settings on the phone. Both internal and external register properly and seem to be working on UDP.
I keep debating on leaving it the way it is but ultimately I’d like to understand why it isn’t working with TLS/SRTP and understand and resolve that issue. If I need to do something else with my DNS and/or router (I’m using a WatchGuard and no SIP-ALG enabled), let me know and I’ll try it out. I appreciate all the help so far, this support is one of the reasons I really like FreePBX. The community is very engaged and helpful most of the time.
First of all, you setup is non-standard since you have CHAN_SIP on 5060. FreePBX 14 defaults to PJSIP on 5060 last I knew. Though, maybe I set it so automatically that my brain doesn’t register that I changed it.
Sine it looks like you did have DNS setup, then it is down the rabbit hole with sip debug and packet captures running until you get a broken sample captured.
To start, SIP over TLS and SRTP are two completely separate things.
TLS on SIP is pretty much irrelevant. There is nothing in that traffic that should matter.
So change that but leave the SRTP configured off. Assuming that you do not have problems again, then you know your signalling is not a problem. At that point you can then enable SRTP and see what happens.
I will re-enable TLS this weekend and push the settings to the phones. I will leave the SRTP disabled for now. Should I be using the default certificate that is in the system or the LetsEncrypt certificate for this? I’ve been using the LetsEncrypt certificate for everything but this is the first system I’ve setup using that at all. I’ve always just used the built in cert. Is there any way that using the LetsEncrypt cert could cause any of these issues? I don’t believe that’s the case but figured I would ask.
I haven’t looked into that really but the thought has crossed my mind. I might end up doing that but I would still like to understand why the SRTP isn’t working in case I am deploying non Sangoma phones or any case where a VPN isn’t feasible for whatever reason. I’m assuming it’s the SRTP causing the issues at this point. I will find out more tomorrow once the office is open again. I put them back on TLS but left SRTP off.
So I did get confirmation from the office that everything is still working as it should. So my issue definitely had something to do with SRTP bring enabled. What is the least disruptive way to troubleshoot this issue? Honestly, I’m not really sure where to even start on troubleshooting the issue. I assume I’ll have to enable SRTP and then run packet captures. I have attempted this already but couldn’t really tell what or even if the issue was captured even though the capture was running when the issue happened. It’s entirely possible I just don’t know how to read the results in Wireshark. Any next steps I should take would be greatly appreciated. Thanks in advance.
On a normal call from A to B, encrypted or not, a capture at the PBX will see 4 RTP streams:
A -> PBX
PBX -> B
B -> PBX
PBX -> A
If any of these are missing you need to find out why; there may be a clue in the Asterisk logs, or something wrong with the SDP.
It’s also possible that RTP is flowing but is indecipherable. If Asterisk can’t decipher it, there should be a message in the log. If the phone can’t decipher it, it may have a syslog or other debug feature that will tell you what’s wrong.
Also, you could try recording the call. If B can’t hear A but A’s voice is on the recording, you’ll know that it’s the PBX -> B path that’s failing.
So I went back to some troubleshooting I was doing with a Sangoma engineer when I was attempting to move to a cloud PBXact account. I was attempting to go the cloud route but ran into the whole one way audio thing so that’s why I ended up back with an on premise server instead. When I had the same issue with the on premise and ended up finding out it’s something with the SRTP causing the issues thanks to the help I’ve received on this forum, I emailed the engineer back I was working with to update him. He went back to the logs from the cloud instance I had and found this:
[2019-08-15 08:14:01] VERBOSE[9755][C-00003e2b] res_srtp.c: SRTP unprotect failed because of authentication failure 160
[2019-08-15 08:14:03] VERBOSE[9723][C-00003e28] res_srtp.c: SRTP unprotect failed because of authentication failure 160
[2019-08-15 08:14:04] VERBOSE[9755][C-00003e2b] res_srtp.c: SRTP unprotect failed because of authentication failure 160
[2019-08-15 08:14:06] VERBOSE[9723][C-00003e28] res_srtp.c: SRTP unprotect failed because of authentication failure 160
[2019-08-15 08:14:07] VERBOSE[9723][C-00003e28] res_srtp.c: SRTCP unprotect failed because of unable to perform desired validation
[2019-08-15 12:12:23] ERROR[18031] chan_sip.c: ‘UDP’ is not a valid transport fo
r ‘1000’. we only use ‘TLS’! ending call.
He is starting to think it might be a big somewhere. Honestly these logs done mean much to me other than it now makes sense on why we were getting the one way audio issue. Has anyone run into these types of errors before or know what could be causing them assuming it isn’t a software bug somewhere?
I haven’t re-enabled SRTP on the new server yet at this point. Again, I appreciate all the help so far.
Any other ideas what would cause those errors? I still haven’t been able to re-enable SRTP mostly because there is never a good time to purposefully break the phones to try to diagnose the issue. We only have 6 phones total and since the issue is intermittent, it’s hard to catch it if I were to just enable SRTP for 2 extensions and keep calling back and forth.
@dfd1125 This is where a question like, why do you need TLS for the phones when they are all on the same local network? What is TLS actually providing you for this? Because it sounds like you’re messing around with something that is unneeded for this setup.
We have plans to add some remote phones and/or something like Zopier on an iPhone that can be used anywhere, even overseas. This is for a medical office and the doctor wants to be able to stay connected even when he is traveling. That’s why I am trying to preemptively get everything setup with TLS and SRTP. While it isn’t really needed at this moment, it could become very important quickly in the near future.