One way audio on VOIP, but why?
-
Hi
Before anyone asks, I have read through the forum and guides and have so far tried the following:
Static port on Nat oubound
Disable Scrubbing
Changed Firewall Optimization Options to Conservative
Ticked/Unticked, messed around with so many other settings.However, I still continue to get one way audio - the other side can hear me, but I can't hear them.
I have a few servers in a DC and have been gradually moving my home lab setup over there, I have a /23 public ip range, and I have pfsense sitting on one of those, with a private NAT range behind it.
home IP range 192.168.0.0/24
DC IP range 192.168.200.0/24And there is an IPsec tunnel running between my home and the DC.
This works great, I can access the servers on the 200 ip range… no problems (that I know about!).
Now, where it gets complicated... On my public IP range, I have a VOIP server. This has always worked great over the internet without any issues, however I don't use secure SIP/RTP at the moment (I don't use it outside the house), however, being a smart ass, I thought it would be cool to also push this over the encrypted IPSEC tunnel.
I established the tunnel and created a NAT outbound rule for it (I chose the hybrid option), and, I can access the entire range that goes over the tunnel fine - it all goes as expected, other than one way audio on the phones.
I've tried to packet capture (without much luck) and the diagnostic logs on the VOIP server look fine, so, after reading through many posts over the last week, I feel like I am out of options and I was wondering if anyone knows what is happening here and what I can do?
Thanks
-
What have you set up for firewall rules on the WAN for your RTP? If your SIP and RTP come from different sources the firewall will see RTP as unsolicited traffic.
-
At the moment I was just trying to get it all working, so, I simply have Ipsec and outbound set to allow all, along with inbound allow all from the IP of the VOIP server.
-
Make a call and see if there are any blocked connections in the firewall logs from an unknown server to your RTP port range. Check your states and see if your phone or ata is connected out to that same server during the call.
My guess is that your SIP server you connect out to does not handle the audio as my SIP servers I connect to from here do not. Some VOIP providers do handle both SIP and RTP with the same server. You might call your provider and ask.
In my case I have 3 different IP ranges that I had to allow connection inbound to my devices here. You don't need inbound NAT. Just firewall rules on your WAN to allow to your RTP port range to your internal SIP device IP (range).
-
Hi,
I can't see anything coming up in the logs - this doesn't involve any third party as I get this even when I just try to ring voicemail.
I don't suppose you have any other suggestions?
Thanks
-
Just for future reference, I had to read 3/4 of the way through your paragraph just to find out what you meant by "VOIP". Next time, please say what protocol you're talking about near the top. "VOIP" is not a protocol, just a classification of protocols.
-
Where did I say VOIP is a protocol? I'm mentioning the VOIP server is sending one way audio…
If people don't know the difference, I doubt they would be able to help with this anyway :/
-
@wil:
I established the tunnel and created a NAT outbound rule for it (I chose the hybrid option), and, I can access the entire range that goes over the tunnel fine - it all goes as expected, other than one way audio on the phones.
I've tried to packet capture (without much luck) and the diagnostic logs on the VOIP server look fine, so, after reading through many posts over the last week, I feel like I am out of options and I was wondering if anyone knows what is happening here and what I can do?
Thanks
I remember this has come up before… I cannot remember what the outcome was nor can I find the posts during a search. Is there any form of outbound gateway setting in the server? It may be expecting to still send out the audio over the primary internet connection at the DC instead of down the VPN...
Do you have a public or private IP on the server primary interface?
-
The VOIP server uses a public IP address, there are no gateway settings that I can find.
When there is usually a NAT issue or similar, I can see errors in the logs stating RTP didn't establish, but, there just isn't anything.
-
In my experience if you are getting one way audio with voip it is a codec issue between endpoints.
Try hardcoding your endpoints to use ulaw or alaw which is typically supported by all endpoints and voip servers to see if that clears it up.
-
I just tried changing codecs, but, unfortunately there is no difference.
-
Can the SIP server ping ping anything on your home LAN?
-
Hi,
No it can't, but, that is expected.
The server is on a public IP, the pfsense box is on another public IP (in the same subnet) and it then IPSECs the traffic back to my LAN.
Any machine on my LAN can ping and access the server (or anything else with a public IP on the other side of the tunnel), it works as expected. This one way audio seems to be the only issue I am seeing.
-
RTP initiates from the RTP server (in this case your SIP server.) If a client on that side cannot initiate a ping to reach your ATA's/Phones then that could be the source of your problem.
Your SIP device sends instructions to the SIP server to initiate the call. But then the SIP server then instructs RTP server (whatever that may be) to take over and initiate the streams. Im oversimplifying it here but without the ability for the server to act like a client and your ATA/phone like a server your inbound streams will not make it.
-
I get you, however, without the IPSEC tunnel, the server wasn't able to contact the phones either as NAT was done on the other end as well… Which leads me back to thinking there is something going on with the outbound NAT on the PFSense box.
-
Ever consider trying an OpenVPN tunnel to see if you have the same issue? ;)
Im not familiar enough with IPsec to go further on that subject. I imagine though there is a way to tell IPsec about the opposite network that the local network needs to reach. Id have to go re-watch the "hangout" (gold member access) that the guys did on IPsec and pay more attention.
-
One end is an Edgerouter and I haven't really used OpenVPN cross manufacturer before.
I'll try to give it a shot, but, I have a feeling this won't do anything as the IP traffic itself is fine (I can ping/connect from LAN to ipsec routed ips)
-
I run RASPBX behind NAT (pfsense) and am able to connect both laptops and mobile phones remotely.
If you are able to connect to other applications over the IPSEC tunnel then you be good to go.
Here is what I did.
1. Port forwarded 5060 to RASPBX IP for SIP messaging.
2. Port forwarded a RTP port range for the audio traffic. The size of the port range is dependent on the number of users you have. In my case I forward a range of ports starting at 10000.
3. pfsense auto created the firewall rules for the above.
4. Ensured that the remote clients were programmed to use the ports in #1&2. Don't assume that they are. my BRIA mobile sip app was using some other ports and had to be reconfigured.
5. Set up an IPSEC VPN same as the OP.
6. Confirmed that I can connect with Android and IPAD versions of Bria and a Mac application called Telephone.
7. Just for kicks I also tested allowing SIP requests from my cellphone IP address directly through the firewall to the RASPBX. (No VPN). Also work fine, with caveat that my cell data plan provider always assigns the same IP address no matter where I am.
I suggest that you get access to the SIP logs on the server to see if there are any transcoding errors or mismatched RTP port ranges.
