Best Practice Guidelines
Guidelines on how to improve the uptime/stability of their services by implementing redundant links and failover options.
Last updated
Guidelines on how to improve the uptime/stability of their services by implementing redundant links and failover options.
Last updated
Carrier Level Redirection allows us to redirect calls before they hit the Hosted Network Voice core.
If you’re expecting the customer's site to go offline, or are aware of maintenance we are conducting we strongly recommend that you request us to divert the customer's numbers to a secondary location or to a mobile temporarily.
Our VoIPNow platform supports the use of incoming call rules, these rules allow you to configure a rule that will divert calls to a predefined number in the event that the PBX/Phone becomes unregistered or unreachable.
It’s recommended to divert calls to a mobile or other off-net number that will not be impacted if the site goes offline e.g. due to a failed internet connection.
For customers that require a high level of uptime, we strongly recommend taking advantage of our Inbound Numbering System as it provides several features to ensure uptime of your inbound calls.
Key features for inbound call redundancy include:
Network Queuing will queue calls in the event that your concurrent call limit is hit. For example with a SIP Trunk.
Off-Net Overflow / Failover will allow you to preconfigure off-net failover call flows in the event that the primary destinations are not answering or are unavailable.
Where redundancy is required we recommend leveraging multiple outgoing SIP Servers. In the event of an upstream SIP failure, your PBX should be configured to automatically route calls over the second path. When ordering a SIP Trunk from Hosted Network we will issue you with a primary and secondary SIP server for this reason.
To limit the failure zone you may also consider:
Spreading the inbound DIDs across multiple SIP Trunks
Leveraging our Inbound Number System to failover the inbound call routing between your primary and secondary SIP Trunks.
We strongly recommend that customers have some form of redundancy onsite for their internet access in order to keep them online if/when their primary service goes offline.
Typically this would be an NBN service with a 4G backup, but you can also use a faster (100/40) NBN service and have a slower (25/5) NBN service as a backup. You may even want to consider using an SD-WAN product like Hosted Network’s bonded internet service, as this will allow you to connect multiple WAN services without the displayed public IP changing.
If you use IP based authentication and the service fails over to the secondary connection your PBX/phone may fail to route calls unless you have allowed the secondary connection’s public IP address.
We heavily recommend you ensure that your PBX or phone is configured to only accept traffic from the suitable SIP servers, many PBX or SIP devices will accept the traffic inbound but reject the majority of it due to it not being from a registered device.
If you have a UTM or a firewall capable of source-based rules then we also recommend you configure firewall rules to only allow SIP connections from your carrier trunks.
For VoIP Bundles, and Multi-Tenant PBX you can set the extension within our VoIP platform to only accept inbound/outbound traffic from a list of predefined IP addresses, this is different from IP based authentication but will still restrict registrations and calls from coming from unauthorized IP addresses.
This will prevent your SIP service from being registered by a third party if they manage to get ahold of the SIP password, and then spamming out international calls.
This applies not just to the password used to register your SIP device, but also to the login portal for your SIP handsets themselves.
Setting a complex password will help prevent a third party from getting access to the WebGUI of the SIP device in the event that the device is exposed to the web or by an attacker that is already inside the network.
A lot of SIP/VoIP compromises are caused by the use of insecure passwords or outdated firmware which contains an exploit to bypass authentication.
You should ensure you are regularly updating the firmware for your SIP devices (Handset or PBX) as unpatched systems are most commonly the cause of VoIP Toll Fraud.
Hosted Network takes no responsibility for toll fraud caused by security issues on devices outside of our control such as downstream PBX’s or VoIP handsets. The partner and their end customers are responsible for all charges associated with toll fraud.
You should ensure your SIP Devices are using the TLS transport protocol in addition to the SRTP encryption settings if supported by the device itself.
A lot of issues are mitigated (specifically NAT issues) by setting the phone to use TLS for the transport protocol as opposed to UDP/TCP protocols. The SRTP option will also encrypt traffic between your servers and our SIP servers, keeping everything private in between and decreasing the risk of someone being able to intercept the traffic.
SRTP and TLS do not mean that the call has been encrypted end to end as once it leaves our network it may be routed via any number of carriers to its final destination, all of which Hosted Network have no control over.
For Multi Tenant PBX and VoIP Bundles you should set an upper limit on the number of outbound calls a customer can make to reduce the impact should they be compromised.
You may choose to set this limit to a dollar amount, e.g. $1000 to limit the risk of potential toll fraud.
We also strongly suggest barring outbound calls to international destinations if the customer doesn’t have a need to call internationally. Toll fraud is typically done to international numbers so this is a simple way of reducing risk.
A suitable router should be used when running VoIP. Basic features such as Quality of Service and the ability to turn off SIP ALG are essential.
For non SOHO environments, an enterprise router should always be used.
Routing and switching equipment that honours DSCP markings is also a requirement if you are tagging voice traffic as a priority.
Consider implementing a dedicated internet connection, such as a 25/5Mbps nbn service so that any connectivity issues with your main internet service don’t affect your ability to make or receive phone calls. This also protects all VoIP traffic from being saturated if the primary link is congested and removes the complexities of needing to configure and manage Quality of Service (QoS).
Secondly, look at leveraging an SD-WAN service as opposed to load-balancing. Loud-balancing commonly causes the source IP to change and severely affects or disconnects an active phone call completely. An SD-WAN service allows for seamless movement between internet services should one experience issues.
As with any technology, security should be at the forefront of any deployment and ongoing management. While this section could be a book in itself, here are a few key items that we would recommend at a minimum be implemented.
Dedicated VLAN for voice traffic
Competing network traffic can cause degradation of VoIP traffic. VoIP traffic is extremely susceptible to bandwidth limitations, slowdowns, and other traffic on the same network taking precedence. Separate VoIP traffic into its own VLAN allows for precise controls and ensures that VoIP traffic is independent with the highest priority.
Quality of Service
Quality of service (QoS) allows you to create rules that prioritize your VoIP traffic across all of your network devices. A quality router and managed switches should include QoS settings that will allow you to accomplish this with ease. This may not be feasible for smaller deployments but where possible we recommend implementing it.
Depending on your configuration, SIP ALG can be the difference between a good user experience and intermittent issues that make the service seem unusable.
Unless your handsets are set up to specifically use TLS, SIP ALG should be disabled on the router.
If possible, we would recommend using SIP TLS as this encrypts the traffic and bypasses the issues experienced with SIP ALG.
