1. Introduction

The purpose of this document is to offer guidelines to End Users on how the LAN & WAN environment should be configured in order to be able to run the Horizon service successfully their site.
Horizon is designed to work using public IP addressing for access and as such this provides more than just the provision of speech and signalling protocols; it also provides access to other publicly available services which Horizon requires to function correctly.
If an end user wish to utilise their access solution (WAN), they need to ensure that the solution can meet the requirements and functionality set out in this document. Failure to meet these requirements will result in quality and setup/support issues.

2. DNS / Firewall Configuration

DNS must resolve to the below IP addresses /ports open on the customer firewall.

2.1 Voice and Video Traffic

Voice and video traffic from all Horizon IP phones and soft-clients route via Horizon Access SBCs as defined below. Occasionally new Horizon Access SBCs will be added to the list and the change will be communicated via regular channels.

3. SBC Discovery

DNS SRV records are used to provide high availability service for Horizon IP phones and soft-clients. DNS SRV records resolve to two or more DNS A-records, which in turn resolve to IP addresses of Horizon Access SBCs. This mechanism provides each Horizon device with multiple SBCs to send or receive calls.

4. UDP Fragmentation during Horizon communications.

In some instances, the size of the UDP packets transmitted between the Horizon platform and customer handsets will exceed the default 1500-byte payload, when this happens packet fragmentation will occur. It is the responsibility of the Channel Partner and/or End User to ensure that any in path CPE is able to support UDP fragmentation. It is also advised that a check is made to confirm that any further applications/functions running on the CPE do not interfere with the reassembly of fragmented UDP packets.

If UDP fragmentation is not allowed on CPE network devices the following features may not function correctly.

• BLF (Busy Lamp Field)
• Feature Synchronisation (DND, Call Forward Busy, Call Forward Always & Call Forward Unreachable/No Answer)
• Incoming calls to Horizon devices after a series of call forwards within the same Horizon Company

5. SIP ALG

SIP Application Layer Gateway (ALG) is common in many of today’s routers and in most cases enabled by default on enterprise, business and home broadband routers.  Its primary use is to prevent problems associated to the router’s firewalls by inspecting VOIP traffic packets, and if necessary, modifying them to allow connection to the required protocols or ports.

On many business and home class routers Active SIP ALG will cause a mixture of problems by adjusting or terminating Horizon traffic packets in such a manner that they are corrupted and cause issues with the service, manifesting in a range of intermittent issues such as; one-way audio, dropped calls, problems transferring calls, handset dropping registration and making or receiving internal calls.

SIP ALGs should be disabled on all CPE routers, we will not accept any faults or issues raised against Horizon if a SIP ALG is enabled.

For instructions on disabling this feature please refer to the specific router user guide. We have a limited selection of instructions for completing this via telnet which are available on the knowledge base under technical support > misc.

5.1 Desktop client SIP ALG bypass

Summary
For deployments featuring Horizon Desktop Client, on Windows and Mac OS, please ensure that firewalls allow access to Gamma SBCs on TCP port 5080. TCP 5080 is a non-standard port for SIP traffic so SIP ALGs will not inspect and alter the traffic.

Detail

Prior to January 2019 all Horizon Desktop clients used standard SIP protocol and port UDP 5060 to communicate with Horizon SBCs.

Due to its portability Horizon Desktop Client is often used in remote access situations, at home or on public internet connections where SIP ALG may be present and it is outside the user’s control to disable it.

From January 2019 Horizon Desktop client used new DNS SRV records as defined in the SBC Discovery section of this document. These records route SIP traffic to the Horizon Access SBCs via TCP 5080 first choice. TCP 5080 is a non-standard port for SIP traffic so SIP ALGs will not inspect and alter the traffic.

Between January 2019 and August 2019 Horizon Desktop client used DNS records to provide a fallback to UDP 5060 if TCP 5080 was blocked on the customer firewall. This is being phased out due to compatibility issues with the Desktop client.

From August 2019 the Horizon Desktop client will only send SIP signalling to the Horizon SBCs on TCP 5080.

6. Keep ALives

Handsets are pre-configured to send UDP keep-alive messages towards the Horizon platform every 45 seconds using the SIP port. These messages keep the firewall pin-holes open which ensures the success of incoming calls.

7. UDP NAT Timeout

Set UDP NAT Timeout > 572 seconds.

Some routers have been reported to close NAT pinholes despite Horizon phones sending keep-alives every 45 seconds. To protect against this occurring, it is recommended that UDP NAT Timeout on the router is set higher than the SIP registration refresh interval for Horizon phones. That is higher than 572 seconds.

8. NAT Port Translation

For Horizon handsets to register correctly, if using a router that requires setting up Dynamic Port Address Translation – Port Multiplexing option must be selected..

9. DNS

A public DNS service must be available to the Horizon handsets so that the domain names can be resolved to the associated IP addresses. SRV and A record types are used by the Horizon service. As best practice resilience of DNS needs to be considered hence both a primary and secondary DNS service should be configured as part of any deployment.

10. Handsets (Clients on customer network)

• The phones require a DHCP address, hence must have access to a DHCP server.
• (Fixed static IP’s are not supported).

NAT must be used and enabled for DHCP pool supplied to phones

 11. Support for Vlans

Both Cisco and Polycom phones provided as part of the Horizon service have CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discover Protocol) enabled as default on delivery. Yealink Dect supports LLDP only . These protocols, CDP (Cisco proprietary), and LLDP including LLDP-MED (vendor neutral), are link layer protocols used by network devices for advertising their identities and capabilities in order to assist with management of the local area network environment, specifically VLAN segregation.

If you wish to support either of these functions for VLAN configuration/selection on the customer LAN, then you should enable the desired function on the customer’s network equipment and disable the alternative option. For example, if you wish to support CDP for a particular end user you should make sure LLDP is not configured as a live option on their network equipment and that CDP is enabled as a live option.

When using LLDP or CDP the Horizon phones will support and use any VLAN ID configured on the customer switching infrastructure (as part of the LLDP and CDP configuration) for both Voice and Data. If the customer wishes to daisy chain laptops or PC’s using the switch port on the Horizon phones, any traffic from this port will be entered into the data VLAN.

Example VLAN set up (using CDP/LLP)

Example Data VLAN: 20

Example Voice VLAN: 30

What we don’t support:

• Fixed VLAN ID’s
• Static VLAN assignment either directly from the phone or from the core network.
• We cannot enable only one of the VLAN options (either CDP or LLDP). Both will always be enabled on Horizon phones and it is the customer’s responsibility to enable/disable the required function on their network.

Please be aware the Softphone Clients & ATA’s do not currently support VLAN .

12. Phon RTP Port Ranges

Horizon phones will send/receive RTP from the following port ranges: