VOIP issues
-
First off, I just wanted to say that this is a great forum which has provided me with answers time and time again without me having to ask anything, thanks for that!
Currently I find myself in a strange situation that I can't seem to figure out.In the LAN are 4 Base Stations that connect to an external PBX.
Each base station has about 4 or 5 handsets, about 18 in total.
Everything works without any real issue apart from 1.
5 of those handsets are part of a group, so when a specific number is called all 5 of those are supposed to ring.
One of them will always fail with 'Insufficient Resources', it is completely random which one of those will fail.
If you remove one of the 5 from the group, the problem is solved.If I bypass pfSense and connect one of the Base Stations to the WAN directly and have the 5 grouped handsets registered to this Base Station the problem is solved as well.
This leads me to the conclusion that pfSense is causing this problem.
The version of pfSense is the latest 2.3.1_1.I've tried disabling Firewall Scrub and set the optimization option to conservative and even rebooted pfSense afterward but it didn't help.
Even tried 1:1 NAT for one of the stations but that also didn't solve it.
Also set an outbound rule for UDP/5060 but that only caused that 3 out of 4 base stations could not register at all.Currently I am at the end of my rope and I'm hoping one of you might have any insights or suggestions that I could try.
Thanks in advance :)
-
Isn't there anyone that can at least point me in the right direction?
-
What do you mean by 'insufficient resources?' This is not a SIP response code I am familiar with. Are there 5 distinct SIP INVITEs sent to the base station when a call is placed? Are all five UACs registered with the PBX when this situation occurs? Is STUN enabled on the base station? What kind of PBX is it? More information is definitely required.
-
"The handset displays "insufficient resources" on the screen when it occurs.
Each handset is individually registered on the base station, then the group number is called all 5 are ringing.
During the ringing and before picking up one of the 5 will display "insufficient resources".
STUN is not enabled on the base station, the PBX is an external provider belcentrale.nl
If you need more information please let me know.
-
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.
-
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!
