VOIP issues
-
If you enable SIP OPTIONS keep-alives and STUN you wouldnt have to increase the UDP timeout. Most UACs/sip phones support this capability. You could also use TCP as a transport instead of UDP for SIP traffic as well.
Edit: Increasing the UDP timeout can also have undesirable effects for other applications. Your state table will fill up faster.
-
Have you tried the siproxd package?
Ive never had to utilize port forwarding of any kind whether or not I use Siproxd. But incoming firewall rules are important at least in all my cases.
-
This sounds like it has nothing to do with the network or pfSense.
"Insufficient Resources" is not even a VOIP related thing. What handsets are you using? Is the firmware up to date?
Install X-Lite softphone on one of your desktops and see if it exhibits the same symptoms…
Out of the box pfSense works just fine for SIP, no "fine tuning" is needed in my experience.
-
Hi you. I'm using FreePBX and having problems like you. The reason is that the blocking signal Pfsense returned from the server. Fix by visiting the Advance => Firewall & NAT => State Timeouts => Fist + UDP UDP Multiple Single + UDP to 3600 values.
Thanks, I'll have to try that just to see if it fixes my problem, so you mean the following 3 settings?
UDP First
UDP Single
UDP MultipleIf you enable SIP OPTIONS keep-alives and STUN you wouldnt have to increase the UDP timeout. Most UACs/sip phones support this capability. You could also use TCP as a transport instead of UDP for SIP traffic as well.
Edit: Increasing the UDP timeout can also have undesirable effects for other applications. Your state table will fill up faster.
Unfortunately my povider does not support STUN, SIP OPTIONS keep-alives are already set.
We've tried using TCP as a transport and that didn't solve the issue either, even tried using TCP over 5061 (provider supports this).Have you tried the siproxd package?
Ive never had to utilize port forwarding of any kind whether or not I use Siproxd. But incoming firewall rules are important at least in all my cases.
No, I haven't because I couln't find clear documentation on how to configure it exactly, or how to configure my handsets to register on the pfSense :-/
This sounds like it has nothing to do with the network or pfSense.
"Insufficient Resources" is not even a VOIP related thing. What handsets are you using? Is the firmware up to date?
Install X-Lite softphone on one of your desktops and see if it exhibits the same symptoms…
Out of the box pfSense works just fine for SIP, no "fine tuning" is needed in my experience.
It does have everything to do with pfSense because if I hook up the base station directly to WAN the problems are gone.
They are RTX 8630 handsets and yes, we've tried a number of different firmware versions up to the very latest.
I'll have to try softphones, that might give us some insight, thanks! -
No, I haven't because I couln't find clear documentation on how to configure it exactly, or how to configure my handsets to register on the pfSense :-/
I like using Siproxd where I have multiple devices behind the firewall.
-
On your phones you might have a "Proxy" entry. Make that your LAN gateway.
Whether or not I use the proxy Ive had to make firewall rules. Might be because the service I use does not always proxy the audio from the same server as does SIP.
Firewall states and rules below are from a customer of mine that does not use siproxd. Notice the rules for both SIP and RTP. You might need to do this based on what you have.
If you use Siproxd- point the WAN rules at your WAN address. If you don't then point the rules at the device LAN address. (see why I like siproxd for many devices now??) You could make a rule to point at a "network" of devices.
Last picture is my PAP2 device behind siproxd telling it to use the proxy.
-
Hi,
I got a similar siproxd setup as you have, however, I never had so setup any firewall rules to handle the SIP or RTP traffic.
Only difference to your siproxd setup, I have a stun server setup (stunserver.org).
I use voip.ms as provider.
Just my 2cents.
-
Yep- stun is why you don't need the firewall rules. For some of us stun is not an option and can actually add some latency to your voip conversations.
-
Thank you all of you that pitched in!
In the end the problem was in the Base Stations.
Apparantly this is a bug in the upgrade process of the firmware, too much stuff gets left behind.
The fix was that after upgrading a Base Station you should perform a factory reset on both the Base Station and the Handsets registered to it.
Then configure them both again and all is well.For the people reading this thread that are in a similar postition these concern the XRS/RTX/Snom Base Stations and Handsets (all manufactured by RTX).
-
This post is deleted!
