No audio on VOIP calls after calls transferring

[MAW]

@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.html

Scroll 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?

[MAW]

@wintok Just checking, if when you set up the FreePBX instance on Vultr Cloud, did you leave the "Firewall Group" set to "No Firewall" as recommended during the installation from the ISO Library?

Just in case you missed that and so there is traffic blocked at the Vultr Cloud instance. I have no idea, never used the service, but I just had a look at their Web site. I also read an article about setting up FreePBX on Vultr Cloud and noticed that point was made regarding the firewall.

[MAW]

@wintok I have another important throubleshooting option to your problem!
On your phones, in their configuration options, do you have a facility to set the phone to NAT mode?
This will set the phone to indicate to the remote PBX that your WAN IP address is the extensions IP address. If you don't do this, the phone will indicate it's IP address is it's LAN address to the PBX and that isn't going to work.

[MAW]

@wintok Also note the following FreePBX/Asterisk requirement when a lack of audio is experienced per your set up.............

For a VoIP system comprising of remote off site hosted FreePBX server instance and local IP phones behind a NAT firewall

FreePBX server's sip.conf file important settings.
nat=force_rport,comedia
directmedia=no

Also in rtp.conf file you will see the RTP ports range. By default the settings should be...
rtpstart=10000
rtpend =20000
But you can set the range to whatever you like.
So make sure traffic within the set range can pass end to end within the overall VoIP system. For example, if you have lock down your pfSense appliance's outbound traffic rules with limited and specific traffic rules, add an outbound traffic rule from your phones to your remote FreePBX, for the required rtp port range. Also check if your phones need to be configured to use the FreePBX server's rtp port range. Usually if an IPPBX is able to auto-provision your phones, it will auto configure things like this on your phones. If there is no auto provisioning of your phones, then just check that the rtp port ranges match across server and phones configuration.

Hopefully you now have several things to try help you to resolve your problem. I thought I would provide a few things to inc=vestigate to limit the back and forth which can be more time consuming.

Cheers

[wintok]

@maw said in No audio on VOIP calls after calls transferring:

This is what it looks like

a) A port forward definition under Firewall --> NAT --> Port Forward

and another rule that get auto created based on the above under WAN interface

[wintok]

@maw I leave to No Firewall during my installation

Thanks

[wintok]

@maw

I use handset phone Matrix Sparsh VP110
There is a NAT with only two values : Disable or STUN.

For Softphone I use MicroSIP there are some there I might need to change.

Thanks

[bingo600]

@wintok

One suggestion
I have previously had STUN save my butt, when doing SIP & NAT
On the softphone maybe try one of these , in the STUN field:

https://ourcodeworld.com/articles/read/1536/list-of-free-functional-public-stun-servers-2021

stun.counterpath.com:3478
stun.freeswitch.org:3478
stun.3cx.com:3478

Maybe try the stunserver entry, both with :3478 at the end, and without.

/Bingo

[MAW]

@wintok OK your port forward looks ok

[MAW]

This post is deleted!

[MAW]

@wintok Just to be clear about the situation, is your problem limited to only when transfering calls?

Does the system otherwise work, as in can you make and receive calls with audio, to and from an external phone number?

[MAW]

@wintok "I use handset phone Matrix Sparsh VP110
There is a NAT with only two values : Disable or STUN."

No that is a different feature to what I was thinking of and relates to Bingo's suggestion. I have looked through the manual for your phone and it doesn't have the feature I was thinking of.

[MAW]

@wintok I notice the online Matrix content states that the Sparsh V110 phone became an "EOL" (end of life) product on 4th December 2020

Is your V110 phone then running the latest firmware available, to ensure it has the latest bug fixes, security updates and any updated features?

[wintok]

@maw The problem is with transferring calls only. Registration behind pfsense went smoothly. I like I mentioned earlier dialing from hand-set phone to a software without pfsense was not an issue. The calls went smoothly and the sound was ok.

If both or one them behind pfsense that when the call seems cannot transfer between them. You can hear the ringing from each other only when you pick you can't hear the sound.

Thanks

[MAW]

@wintok Please read the posts in this thread at the FReePBX forum, in particular the response from avayax. The OP is also using the Vultr Cloud FreePBX setup. The content is essentially agreeing with what I suggested earlier that your phone/s are telling the FreePBX server that their IP address is the LAN address instead of the WAN address.

https://community.freepbx.org/t/no-audio-at-all/60932

I think your solution is heading towards Bingo's suggestion, considering your overall system setup.

In summary, it is looking like your issue is not being generated by pfSense. Your problem is a common NAT problem. When, as you have said, you have experimented with other networks/routers/firewalls and your VoIP system has worked as expected, I would suggest SIP ALG has been available/active on those alternatives.

But if you read up on the SIP ALG feature, you will find VoIP service and hosting providers consistently recommending you disable it, because of the erratic problems it can cause with packet delivery and call quality.

I am certainly no VoIP system expert. But I can say that pfSense handles VoIP traffic really really well and I say this from experience setting up pfSense to work with a few VoIP systems. All of these set ups however have been where the PBX has been locally hosted at the business premises. So the very specific NAT issue you appear to be experiencing with a remotely hosted PBX, did not have to be considered.

[MAW]

@wintok Thanks for confirming the specifics of the problem.

To simplify things in summary, remember that phone registration is initiated by the phone outbound through the firewall to the remote PBX. Calling and features like call transfer are intiated by the phone outbound through the firewall to the remote PBX and all things being configured correctly will always succeed. That is a very simplistic summary of how it works

However once you intiate a call transfer between two local phones and the remote PBX processes the request, the PBX will need to intiate communications with the remote phones involved. The audio component of the call transfer can fail if the NAT process delivers the local phone IP addresses to the PBX instead of the firewall's WAN IP address. This is why I asked if your phones have the feature that includes the WAN IP in the SIP signaling of the local phone.

[stephenw10]

You shouldn't need any port forwards there. There's no way to add them to more than one internal phone anyway.

This is almost certainly a problem with RTP connetion setup details the PBX is sending to the phones. The best way to diagnose it is to take a pcap of the SIP session where it's setup and lool to see what the PBX is sending.

But, guessing, the PBX is probably sending the external public IP to both phones to use as the destination for the RTP session. Since they are both behind the same public IP at the same location that fails.
For a direct RTP session the phones would need to use their internal IPs or they would need to use RTP sessions via the PBX in both dircetions.

That assumes that the only problem you see here is between phones behind the same pfSense instance?

Steve

[MAW]

@wintok Just looking laterally at your situation..............

Maybe a dumb question, but just in case, does you Internet service provider support IPv6?

Your VoIP system components.....
pfSense supports IPv6
Vultr VPS supports IPv6
FreePBX supports IPv6
Matrix Sparsh VP110 phone supports IPv6
Looks like MicroSIP may not support IPv6, although the open source LinPhone as an alternative for example, does support IPv6

Here is some additional info that might be needed to set up IPv6 on FreePBX
https://bpg.id.au/2020/10/14/setting-up-freepbx-with-ipv6/

If you are willing to consider going down the IPv6 path as a solution, then NAT complications are taken out of the scenario and things should just work.

[stephenw10]

Re-reading this it appears the problem still exists even when only one phone is behind pfSense?

In that situation outbound audio will almost always work. Inbound audio can fail if the phone is passing its internal IP to use as the destination for RTP. That's rare though, usually only an issue for a PBX behind the firewall.

I'd still recommend running pcap of the SIP call setup and checking the IPs being sent.

Steve

[MAW]

@stephenw10 said in No audio on VOIP calls after calls transferring:

Re-reading this it appears the problem still exists even when only one phone is behind pfSense?
In that situation outbound audio will almost always work. Inbound audio can fail if the phone is passing its internal IP to use as the destination for RTP. That's rare though, usually only an issue for a PBX behind the firewall.

You were right on the money earlier about this sort of thing. It comes down to maintaining states in pfSense with VoIP systems and correct SIP session parameters between the end points. Also as you correctly pointed out, any port forwarding should not be needed at all in normal day to day use.

From my experience, pfSense does VoIP traffic really well, with no audio problems at all. People often blame pfSense for VoIP problems, but it is nearly always without exception because they don't understand how a stateful firewall works and how some VoIP/SIP parameters need to be set up to work with a stateful firewall.