The timeout value will keep refreshed back to the default value when traffics is sent via the sessions.Sessions will only being drop/remove when no activity for the session after the timeout value and normally this will happen if the sessions is no longer being used.
Regarding to the VOIP phone issue, i strongly believe the issue is more to the PBX/SIP/VoiP phone configuration issue whereby most of the system should defined with NAT keepalive to refresh the standard session timeouts more than changing the NAT timeout for the NAT devices. You can find some of the related info using the URL below:
The thing is, when the client make no more calls in 120s after the
Register with a NAT port, in the time that need an incoming call, the nat
port is closed, and the call cannot be complete.
When we change the router, no more issue happends.
The same think happends on Juniper that have his default on 60s Nat
timeout UDP, but is possible to change, Peplink no.
I realize this topic is coming up on two years old, but, as of the recent release of firmware revision 8 on the Balance series, it doesn’t appear to have been addressed.
We’ve recently been hitting brick walls with using Asterisk IP solutions (cloud-based) with Balance series devices. This is due to the same inabilities of the appliance to handle some basic configurations.
It appears that Peplink software has a hard-coded default value of 30 seconds per UDP session, 180 seconds on the UDP established/streaming session, and 3600 seconds per SIP 5060 session. The main issue is that the SIP 5060 session needs to be able to have its default value changed to 180 seconds.
This is a significant issue for us as a reseller of Balance (and other Peplink) products as we have more and more clients moving to Asterisk/FreePBX IP voice systems. Just in the last week I’ve had to send a tech to swap out a Balance One Core with a competitor’s unit (one of which was in place for less than a week). I’m not a big player in the Peplink world, but we have roughly 60 units in play at client locations now, and I really don’t like the idea of having to start pulling Balance units out and putting FortiGate units in.
It was recommended to me that I post to this thread to see if we can get software engineering to at least look into addressing this so that I can make an intelligent decision on whether we need to start pulling Balance units (and stop recommending them altogether).
Thank you for the response. Permit me to be clearer here. By line item, these are the specifics required for optimal functionality with Asterisk:
UDP Session: 30 Seconds
UDP Established/Streaming Session: 180 Seconds
UDP SIP 5060 Session: 3600 Seconds
I think I may have had this goofed up previously. But the SIP 5060 session setting for UDP is what is causing the bulk of the problem and requiring multiple scheduled reboots daily for clients on Balance units.
Actually, I had to have a tech pull that Balance One device to get the client’s phone system going (replaced with a FortiGate 60E). They were getting pretty fussy, and I couldn’t work around it with the Balance settings.
Those numbers above are what we’d need the ability to set on the Balance in order to satisfy the Asterisk’s neediness.