No audio on VOIP calls after calls transferring
-
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:3478Maybe try the stunserver entry, both with :3478 at the end, and without.
/Bingo
-
@wintok OK your port forward looks ok
-
This post is deleted! -
@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?
-
@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.
-
@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?
-
@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
-
@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.
-
@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.
-
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
-
@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 IPv6Here 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.
-
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
-
@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.
-
Yes. Most VoIP issues we see are customers moving from a previous firewall that had a SIP proxy/ALG of some sort. That can hide a misconfigured PBX by correcting the IPs/ports sent on the fly. pfSense doesn't have a SIP ALG so without it those issues are exposed.
Steve
-
Hello there
If anyone interested see wireshark capture when I make call between my handset-phone and a softphone. Still not be able to solve this. Again the these phone made calls behind a pfsense. Still no audio.
Appreicate if someone point me in the right direction.
-
@maw I will try IPv6 first and see if it works
-
@wintok I will state up front that I am not familiar with all the features and set up options in FreePBX itself.
Now regarding your pcap content..........
1/ Since you supply no defining details about the pcap content, I assume the 207. IP is the remote PBX. You can see that it is trying to contact (ICMP) a non routable private IP address. Again I will assume that private IP address is on the LAN side of your pfSense instance. There is no way it can succeed, as you can see ("Destination unreachable"). So the PBX system has a wrong configuration some where. The PBX needs to know that it reaches the 192. IP via your pfSense WAN address. A static route on the PBX system could resolve that for ICMP, for example. BUT, is the ICMP originating from the PBX server OS or the PBX software itself? If it is the FreePBX software sending ICMP, then the question becomes why doesn't FreePBX know that your WAN address is the gateway to the 192. address?
2/ Again continuing the pcap content assumptions.
I am not sure why your 192. LAN address would be sending NetBIOS Name Service calls out over the Internet to the remote FreePBX system. I expect that should not be happening. It also looks like no NetBIOS parameters are supplied with the query. Look for any NetBIOS feature on your phone configuration and turn it off. If a name service should/can be used I would expect the use of DNS and fully qualified domain names.To help you understand what and how the traffic should look............
Here is a very good SIP NAT traversal tutorial from the VoIP Studio Web site for you to adapt to your situation with FreePBX. Transpose your IP addresses and required ports in place of those shown, so you can visualize what should be happening in your system.
https://voipstudio.com/blog/sip-nat-traversal/ -
Hmm, I'm having trouble opening that pcap in Wireshark. What did you create it with?
That ICMP reply though is actually 'port unreachable'. That's probably the firewall on the PBX blocking the port the phone is trying to use at a guess. Which implies something is misconfigured.
That is assuming 207.148.82.147 is the PBX and 192.168.202.99 is a local phone.
And also that the pcap was taken on a the local client behind pfSense. It wasn't taken on the pfSense LAN interface since I'd be able to open it if that was the case.
Steve
-
@stephenw10 It looks like it is a screen capture. Its a png image file actually.
-
Oh. Ha!
Yeah, OK. The actual pcap file here would be much more useful.
And we need to know what the various IP addresses are here and where they are.
What and where is 192.168.0.103?
One of those things is probably incorrectly sending it's internal IP to connect to for RTP because that's almost what's broken with VoIP.
You can see in the screenshot that it appears the phone at 192.168.202.99 starts sending RTP traffic to the PBX before the PBX replies with the port unreachable error.
Steve
