One way audio on VOIP, but why?
-
@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.
