Link to home
Start Free TrialLog in
Avatar of it_saige
it_saigeFlag for United States of America

asked on

pfSense, NEC SV8100 and DT700 IP Phone

Hey Guys,

I'm a little stumped right now.  We recently had a new NEC SV8100 installed along with all the internal hard phones, internal SIP clients (UC Desktop Suite) and external DT700's.

Everything is working except.  Every 30minutes the external DT700's lose their connection, jump to a network busy message and then reconnect after they finish their reboot.

It appears to be linked to the keep-alive timeout period of the DT700's but I cannot seem to locate the right setting to resolve the issue.

On my pfSense firewall, I have the outbound NAT set to static port mapping.  I have the inbound rules in place for UDP (5080 - 5081 &  10020 - 10083).  I had originally set the Firewall Optimizations Options to Conservative under System -> Advanced -> Firewall and NAT, but "Normal" seems to work the same way.  I changed it when I read on the pfSense forums that you should change the keep-alive time on the SIP configuration.

With that in mind I jumped on my SV8100 and set the H.323/SIP Phone KeepAlive Setup options:

84-15-02 [KeepAlive Message Interval] = 1
84-15-03 [KeepAlive Message Timeout] = 10
84-15-04 [KeepAlive Timeout] = 5

And applied them.  Unfortunately, these did not seem to help the problem.  So then I figured, well let me configure my traffic shaping to prioritize VoIP packets.  Again no dice.

What am I missing.  I've been searching high and low for answers.  But I feel that I'm starting to get muddled under a bunch of settings that after changing them, I may end up finding the answer but not knowing how the issue was resolved.  As, it stands, the keep alive settings are currently as specified and the traffic shaping is still enabled.  The only other setting that I have changed on the NEC SV8100 is 10-12-06 NAPT Router - Enabled.

Thanks for any assistance.

-saige-
Avatar of Mohammed Hamada
Mohammed Hamada
Flag of Portugal image

Check your PBX regarding VoIP behind NAT. if that's supported and if you need to change anything in the configuration in order for it to work.

Make sure that you setup your PBX's NIC Gateway IP address to point to Pfsense's LAN IP  in order for traffic to be routed successfully.

and one last thing keep your Pfsense Firewall/NAT (Firewall Optimization Options) setting to Conservative.

Some PBXes don't even support static NATting, I tried the same thing with Snom ONE PBX and wasn't able to use Pfsense, Untangle or any other firewall's static NAT with it. the only option it would work is direct connection.

hope you get it working though.
Avatar of it_saige

ASKER

Thanks for your response.  We did check all of the settings with regards to VoIP behind NAT.  And based upon those we made the changes to pfSense for it to work in the state that is now.  The settings changes involved:

1.  Firewall Optimization Option setting to Conservative.
2.  Manual outbound NAT with static port enabled.  (Since we have 5 IP's, we used one of the virtual unassinged ones in the CARP).
3.  Inbound NAT Rules for UDP (5080 - 5081 &  10020 - 10083) translated to the IP of the PBX.

With those settings out of the box, everything connects, it's just that the external IP Phones (DT700's) would all fall off with a Network Busy message and basically restart/reinitialize.  When they did, they would connect fine for about 30 minutes and then do it again.

However, after posting my question we did some further searching and found a setting on the PBX that might be the key:

In the DT700 Basic Setup - 84-23-02 [Subscribe Expiry Time] = 3600.  Last night we changed this setting to 180 and so far it does not look like we have had any further drops.  We will now more later today.

-saige-
Glad you went that far. hope things stay stable.
ASKER CERTIFIED SOLUTION
Avatar of it_saige
it_saige
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Great, so you may close the question since you have solved it then.
We were able to identify the solution internally.