No audio on VOIP calls after calls transferring
-
We have a problem where we get no audio on calls, both ways, once the call is transferred from one phone to another. The PBX is based in the cloud. Our setup is like follows:
PBX > PFsense Firewall/Router > LAN > VOIP Phones
It is a flat network with no VLANs.
If we connect the phones to the cloud based PBX from a completely different/separate networks, it works fine. We are certain it is a problem with the pfsense, but can't quite figure out what.
Does any one have any ideas?
-
Differences like this are usually because the other firewall/routers you might be testing behind have a SIP ALG running.
If the PBX is misconfigured a SIP ALG can mask that by correcting the data in the SIP packets. We quite commonly see that when some other firewall is swapped out for pfSense and you end up with one way audio because a PBX is sending it's internal IP for RTP sessions to connect back to, which of course fails.You will probably need to pcap the SIP traffic sent for the call transfer but something similar to that would be my first guess here.
There is no SIP ALG in pfSense. It's almost never needed and it presents an attack surface.
Steve
-
Hi Steve
Thanks for your response. The network that the phones work from are behind a FortiGate with SIP-ALG disabled. SIP-ALG has to be disabled for this PBX to work.
When I do a TCPDump, everything looks normal until the point the phone call is transferred. Then all I can see, is one way traffic going from the PBX to the customer's network but with nothing coming back.
-
Do you see that traffic blocked in the pfSense firewall log there?
And I assume that's only the audio (RTP)? The SIP sessions remain up and the phones themselves think the call has been transferred?
Steve
-
Firewall log shows that traffic is being allowed.
Spot on, call transfers perfectly fine. It's just the audio/RTP.
Thanks
-
Mmm, OK I'd try to get a pcap of that SIP traffic then and look for IP or port mismatches.
If you get no audio either way I would expect to see the RTP traffic either blocked or going to the wrong place.
You might just see no incoming RTP traffic from the PBX if it tries to use the phones internal IP for example. The phone the call was transferred to should still be sending though.
Steve
-
Hi,
Apologies for the slow response. I can't see any mismatch between IPs and port numbers.
We can see RTP traffic coming from the PBX, we just can't see any RTP traffic going to the phone system from the customer's network once the call is transferred.
-
It's arriving on the WAN but not leaving on the LAN?
And state exists for it?
Is the incoming traffic using the same ports as the outgoing?
It seems likely that it isn't if the reply traffic doesn't pass.You might need to set static source ports somewhere.
Steve
-
This post is deleted! -
I know this is an old post but I hope we can still get replies from people who had the same issues and managed to solve this.
I have the same problem. Recently I deployed my freepbx instance on Vultr cloud. I'm still experimenting with this awesome opensource pbx. I created two extenstions and registered a softphone and a hand-set phone for this setup. Behind my pfsense firewall I can only ring each other but no audio between them. Took these phone to a different network with no pfsense. I could make calls and the audio was loud and clear. Perfect.
I have not been able to solve this.
-
@wintok Sorry to anyone if I am stating the bleeding obvious, but.........
Reading through this thread takes my thinking to the way a stateful firewall works relative to problem.
a) LAN side of pfSense has multiple PBX client VoIP nodes.
b) The PBX is located in the cloud on the WAN side of pfSense.I expect you can do everything without issue when just one LAN side VoIP node is involved for the duration of an external call, either inboud or outbound, correct?
VoIP traffic should always be maintained for the original traffic flow between the PBX and the same LAN VoIP node to succeed. The LAN VoIP node should be able to successfully transfer a call with the PBX, but because the cloud based PBX will, I expect, now intiate a new connection to a different VoIP Client LAN node, pfSense will likley see this as unsolicitied traffic and ignore the traffic as it arrives on the WAN interface.
To test if this is the problem, maybe make some very specific inbound Cloud PBX source FQDN/IP and port traffic forwarding rule/s, to allow inbound traffic from just that specific cloud PBX to the relevant LAN VoIP addresses. This should then allow call traffic to be successfully initiated in either direction. In this instance to transfer the call successfully and completely to a new LAN side VoIP node. The effect being that PfSense would no longer treat the call transfer traffic at the WAN as unsolicitied.
Of course this is if I am reading your problem correctly.
Cheers
-
@maw Correction to my previous post.
"maybe make some very specific inbound Cloud PBX source FQDN/IP and port traffic forwarding rule/s"
Should have read....
maybe make some very specific inbound Cloud PBX source FQDN/IP and destination port traffic forwarding rule/s
-
@maw said in No audio on VOIP calls after calls transferring:
Should have read....
Editing your post is easier to read, the option in behind the three dots
-
@patch Thanks Patch, noted.
-
@maw Reading your suggested solution it seems I need to do port forwarding in pfsense firewall ? which basically means port foward to FreePBX running locally in my LAN ? FreePBX is hosted in the Cloud (Vultr cloud).
-
@stephenw10 it will be great if you show how to do with pfsense, maybe some screen shot.
thanks
-
@wintok "it seems I need to do port forwarding in pfsense firewall" - Correct
" which basically means port foward to FreePBX running locally in my LAN ?" - No
"FreePBX is hosted in the Cloud (Vultr cloud)" - Yes
I am confused why you are referring to two instances of FreePBX. Are there actually two instances involved, one local and one remote? Is this like a multi branch VoIP phone system?If FeePBX was ONLY local, hanging off your LAN, you wouldn't be having the problem, I am sure.
But if this issue only involves a single remote instance of FreePBX then..........
You will need the following for your port forwarding rule/s on the WAN interface.
a) The FQDN or IP address of the remote FreePBX system (as the source in the rule).
b) The destination/target (LAN) port or ports you needs to include in the port forward.
c) The LAN IP addresses on the LAN you require the remote FreeBPX to reach.Since you likely have multiple IP's and ports involved, I suggest you make use of aliases in pfSense to simplify the port forwarding rule construction.
Hope that helps.
To be clear, I am assuming you need your remote FreePBX instance to be able to reach your IP phones/end points on you LAN, when ever IT needs to for any reason. No tailored port forwarding rule/s on the WAN interface then this will not be able to happen.
-
@wintok As another thing for you to keep as an avenue of investigation.
It may be that your phone's cyclic registration period with FreePBX is too long. What can happen is that pfSense drops the inactive state/s associated with the phones and the remote PBX. So then it is possible the PBX cannot access the phone/s that have been inactive for a while. Dropped states due to too long a VoIP registration frequency is not uncommon.
You can troubleshoot this potential cause in two ways.
1/ Reduce the handset/phones registration period to a small frequency, around 30 seconds. This can often be anywhere between 1 to 10 minutes by default.2/ On pfSense go to System --> Advanced --> Firewall NAT and temprarily set "Firewall Optimization Options" to "Conservative.
Item "2/" will cause pfSense to hold onto existing states for a longer period. No need to ultimately leave pfSense in "conservative mode if this resolves your issue. Just experiment with your VoIP phones registration frequency.
This alludes to some of what stephenw10 has mentioned regarding states.
PS: Sometimes you can also configure IP phones to ping an end point as a "keep alive" tool. If you have this facility available on your phones, then set it up to periodically ping the FreePBX IP address (every 20 to 30 seconds). That is another way to keep the relevant pfSense states active.
-
@maw I've configured port forward and I tested it to make calls but still no audio, not sure if this is the correct port-forwarding. To be honest I have not seen this type of port-forward. I've still alot to learn ..
Appreciate your help
-
@wintok Hmm, not sure that looks right.
There is usually two parts to a port forward in pfSense
Please read here on how to add a Port Forward in pfSense.
https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.htmlScroll down to the section "Adding Port Forwards"
In pfSense you add a port forward in Firewall --> NAT --> Port Forward
Once you add the port forward definition and save it, a firewall rule on the relevant interface will be auotmatically implemented using the port forward definition you just created.So when you are finished,you should have......
a) A port forward definition under Firewall --> NAT --> Port Forward.
b) A Firewall rule on the WAN interface that employs the port forward definition you created.Do you currently have that?
