It is highly recommended that you do not put your phones on public IP addresses or map any public addressable ports to phones on the internal network.
Router configuration settings can be found here.
Firewalls must allow Jive Voice handsets to send and receive all IP traffic to and from the phones on the local network to Jive’s IP ranges. Jive provisioned phones work correctly behind all NAT types (full cone, address/port restricted cone, and symmetric) and do not need port mappings to be created. It is strongly recommended that you only have one device handling NAT as it pertains to phones.
Jive Voice handsets must have unfiltered access to Jive’s network ranges. These IPv4 and IPv6 ranges are listed below and are also available in a automatically parsable (and updated) form at https://static.jive.com/meta/networks.txt.
Jive IP Blocks
|Jive Block 1||220.127.116.11/22||255.255.252.0||0.0.3.255|
|Jive Block 2||18.104.22.168/22||255.255.252.0||0.0.3.255|
|Jive Block 3||22.214.171.124/22||255.255.252.0||0.0.3.255|
|Jive Block 4||126.96.36.199/21||255.255.248.0||0.0.7.255|
|Jive Block 5||188.8.131.52/20||255.255.240.0||0.0.15.255|
Our recommendation is to create explicit rules that allow traffic to and from Jive’s IP blocks (LAN→ WAN and WAN→ LAN) and set high in priority — even if this is implicitly stated in another access rules down the list.
Note: Be sure that the phones are using a reliable DNS server as a DNS failure can delay or prevent call setup. We strongly recommend using Google’s DNS, 184.108.40.206 and 220.127.116.11.
Jive Voice handsets initiate connections with Jive Cloud infrastructure and uses NAT keep-alives to keep the binding open. If your firewall drops these NAT keep-alives or ‘prunes’ NAT connections more aggressively than every 300 seconds, the handsets will not function properly. They will be able to call out, but will not receive inbound calls (inbound calls will go straight to voicemail). The following settings are recommended:
Increase UDP Timeouts
UDP sessions are typically given shorter timeout intervals on firewalls. The default for most is 30 seconds, which is too aggressive for an application like SIP. Increase UDP timeouts to a minimum of 90 seconds, however our recommendation would be 300 seconds or longer.
Note: You can specify that SIP sessions have increased timeouts rather than all UDP sessions, if your firewall allows for that specific delineation. Just make sure to set that for UDP ports 5060 and 5061 for at least 300 seconds, as those are the standard SIP ports Jive uses and most user agents (phones) do as well.
Enable Consistent/Persistent NAT
In much the same way that ensuring the NAT binding does not get dropped or pruned — ensuring that the NAT binding (public IP and UDP port) remains the same for each phone’s internal private IP address and port pairing will help with an application like VoIP. If that binding were to change suddenly, there will be a discrepancy between the IP and port to which the VoIP server thinks it should be sending requests and what the phones’ current binding is in the firewall.
For example, a phone can make calls because NAT is working, but can’t receive calls because the VoIP server hasn’t received a new REGISTER request from that phone since that binding changed and is sending it to the old IP and port pairing.
Note: Most of the other settings are generic, whereas this one is more vendor specific (Sonicwall and Juniper for example). It is a recommended setting if your firewall has it available, but unlike the other settings it is not usually an issue if it cannot be configured.
The phones use SIP as their signalling protocol. Many routers and firewalls have SIP specific settings that manipulate how SIP traffic is handled. This Application Layer Gateway’s intention is to help alleviate traditional issues that applications with specific addressing requirements like SIP have with NAT traversal. This can have other names (SIP Helper, SIP Inspection, SIP Transformations, etc.), but ultimately they all perform a similar function — identifying SIP packets and manipulating them. These settings almost always need to be turned off as they (somewhat ironically) will almost always break SIP.
Disable SIP ALG
If your firewall/router does not have an option to disable SIP ALG, that does not mean that it is not running; it just means you cannot disable it. The only way to truly confirm this would be to verify with the vendor if a SIP application is running on the device and how (and if) that can be disabled. If it is running and cannot be disabled, that device should not be used with Jive.
It is recommended to keep the vendor firmware current as these updates fix known issues, include upgrades, and can even provide access to settings that were previously unavailable (i.e. SIP ALG). There is no need to be an early adopter, but it is a good idea to check the vendor’s support site periodically to ensure that you are not running outdated firmware.
Tip: Be sure to read any release notes and verify that you have the capacity to roll back as there is the chance a firmware update will fix one issue, only to cause another.