Introduction
The purpose of this document is to provide customers with network requirements and recommendations to ensure that cloud-based unified communication services operate properly. For the successful implementation of services, the network requirements must be followed without reservations, while recommendations are advised to be followed.
This document states constraints on network capacity, quality of service, firewall configuration, and unsupported devices and configurations.
Acronyms
Table 1 summarizes the acronyms used in this document:
| ACL | Access Control List | NAT | Network Address Translation |
| ALG | Application Layer Gateway | NTP | Network Time Protocol |
| AP | Access Point | QoS | Quality of Service |
| ARP | Address Resolution Protocol | RTP | Real-time Protocol |
| BLA | Busy Lamp Appearance | SBC | Session Border Controller |
| BW | Bandwidth | SIP | Session Initiation Protocol |
| CoS | Class of Service | SMB | Small and Medium-sized Business |
| DPI | Deep Packet Inspection | SoHo | Small office – Home office |
| DSCP | Differentiated Services Code Point | SPI | Stateful Packet Inspection |
| DSL | Digital Subscriber Line | SRTP | Secure Real-time Transport Protocol |
| EF | Expedited Forwarding | TCP | Transport Control Protocol |
| IDS | Intrusion Detection System | UDP | User Datagram Protocol |
| IP | Internet Protocol | VLAN | Virtual Local Area Network |
| IPS | Intrusion Prevention System | VoIP | Voice over IP |
| ISP | Internet Service Provider | WAN | Wide-Area Network |
| LAN | Local Area Network | WiFi | Set of standards for wireless communication |
| ms | Milliseconds |
End-to-End Quality of Service Network Requirements
The requirements stated in the table below need to be satisfied for VoIP media traffic to get optimal call quality between endpoints. The same requirements hold for Video over IP when applications since voice is embedded in the video signal.
| Network Property | Requirement |
|---|---|
| Link Capacity | Each link in the end-to-end path must have a capacity in each direction that is larger than the maximum number of simultaneous calls plus capacity added for other types of non-real-time traffic and growth |
| Delay | < 150 ms (of one way latency)* |
| Packet Loss | < 1% |
| Jitter | < 30 ms |
Network Readiness Assessment
The end-to-end quality of service requirements stated above can be validated by performing a network readiness assessment, which determines the quality of the local enterprise network and the Service Provider network. Two types as network readiness assessments can be performed to assess the ability of the network to support our communication services:
• Snapshot Network Readiness Assessment – This assessment leverages the Capacity Test and VoIP Quality Test tools. These tools provide an impression of network capacity and quality in the outbound direction of an enterprise site to the cloud over a time interval of a few minutes.
• Comprehensive Network Readiness Assessment – In this case, a probe is installed at the enterprise site. By running this probe over a longer time interval (e.g. a full business week), a much better impression is obtained of the end-to-end quality and intermediate network hop quality in both directions of the call. Targeted network improvement recommendations can be provided based on this type of assessment.
The first type of assessment can be performed by the enterprise but provides minimal insights into the end-to-end QoS over time. The second type of network assessment, which is recommended to minimize the likelihood of user-perceived QoS issues, requires the involvement of our Professional Services Team. To setup a Professional Services engagement, please contact your commercial management team.
The requirements stated in the next sections must be implemented before a network assessment is performed so that any major network issues are already addressed.
Approved Subnets
| Approved Subnets |
|---|
| 45.40.112.0/24 45.40.113.0/24 45.40.114.0/24 45.40.115.0/24 |
| Decommissioned Subnets as of Nov. 10th, 2022 |
|---|
| 23.92.190.96/27 173.231.184.43/32 206.191.152.160/28 107.6.72.160/27 107.6.77.240/28 |
These subnets are used globally for call servers, media services, route announcements, and auxiliary services, like telephone provisioning and network time. It is highly recommended to permit all these networks at all enterprise locations.
We have two IP addresses which are used for all Device Level SIP Traffic. Those addresses are:
45.40.112.100 and 45.40.113.100, on ports UDP/TCP 5060,5061 and 7000.
VLANs
Virtual LANs (VLANs) can be used as follows with endpoints:
• Desk Phones and IP Speaker Phones – If VLANs are supported by network switches, then it is recommended to define a VLAN specifically for desk phones and IP speakerphones. This will keep VoIP traffic of these types of endpoints logically separate from data traffic and reduces broadcast domains. It also simplifies the management of these endpoints because their IP addresses are VLAN specific.
• Soft-Clients – Computers running soft-clients such as the Bria Enterprise Softphone will usually run other applications as well. For this reason, the computer is normally connected to the default VLAN so that VoIP and Video traffic for soft-clients does not reside on a dedicated VLAN.
The following recommendations and requirements should be followed for VLAN implementations:
• Our VoIP solution must be put on a different VLAN and subnet than an already deployed VoIP solution from a different vendor. Otherwise, the network routing of the existing VoIP solution may inhibit VoIP phones from reaching out to our cloud-based services.
SMB/SoHo Networks
Small-Medium Businesses and Small Office – Home Office (SMB/SoHo) networks are mostly connected to cable provider or Digital Subscriber Line (DSL) ISP networks. These local networks may have lower quality equipment (such as all-in-one modems) than enterprise networks. Frequently, the users on such networks also use WiFi. The combination of these factors makes it more difficult to manage the end-to-end QoS for cloud communications services. However, to maximize QoS, it is recommended to:
• Closely follow the network requirements in this document, including the WiFi network requirements.
• If an ISP provided modem is used with a separate router, the modem is configured in passthru (also called bridge) mode, and the router is configured according to the requirements in the next sections.
WiFi Networks
The achievable QoS over a WiFi network depends on many factors. Chief among them are:
• The capabilities, settings, and physical location of WiFi Access Points (APs)
• The location of users relative to APs
• The number of users connecting to an AP
• Environmental conditions such as location, addition, and migration of objects and furniture
These factors may contribute to lower quality compared to wired network implementations.
Soft-endpoints such as desktop softphones, mobile phone applications, and can be used on WiFi networks provided that QoS and configuration requirements stated in this document are followed. To maximize QoS, it must be ensured that:
a. The wired network meets the above network requirements
b. The wired network plus the WiFi leg attached to the wired network also meets the end-to-end requirements as stated in the next sections
c. The 5GHz band is used instead of the 2.4 Hz band since the former offers higher bandwidth and less interference from other equipment due to non-overlapping channels.
Unsupported Devices and Configurations
Some types of devices, device settings, and network configurations are not supported/recommended in our Unified Communications Solution as they are known to cause continuous or intermittent voice quality issues (contributing to high latency, packet loss, or jitter).
For proper support of our Unified Communications services, the functions listed in the table below may need to be disabled on IP devices (layer 3 switches, routers, firewalls), and Ethernet switches, or be avoided. Disabling the mentioned functionality for the IP and higher layers can be limited to the before stated approved supernets listed by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP & TCP traffic originating and destined to our network.
| Layer | Function |
|---|---|
| Application | • Session Initiation Protocol Application Layer Gateway (SIP ALG), also referred to as SIP Transformations • Deep Packet Inspection (DPI) • Application Layer Access Control • Stateful Packet Inspection (SPI), also called Dynamic Packet Filtering • Intrusion Detection/Intrusion Prevention System (IDS/IPS) • WAN Acceleration |
| Transport | • Port filtering |
| IP | • Packet-by-packet load balancing across multiple Service Providers links |
| IP & Data Link | • Auto-QoS, when used in combination with Polycom / Poly phones • Dynamic ARP Inspection |
| Physical | • Energy Efficient Ethernet (a.k.a. Green Ethernet) • Satellite network connections |
Enabling these functions may result in intermittent call connectivity issues (phone registration or call feature operation) or excessive voice quality impairments (increased latency and jitter), specifically:
• For some of the functionality mentioned under Application Layer Functions, packet content may traverse a separate processing engine, which may result in the mentioned impairments. The impact may be minimal when using advanced networking devices but could be substantial for SMB and SoHo devices.
• Enabling SIP ALG may cause signaling issues when desk phones and softphones are used simultaneously.
• IDS/IPS functions may limit packet streams to a certain bandwidth causing intermittent audio issues across multiple calls when the number of calls exceeds a certain volume. To reduce bandwidth, WAN accelerators use header compression to reduce traffic. For VoIP traffic, this can result in increased jitter.
• Port filtering, such as UDP flood protection, may limit bandwidth thereby causing intermittent voice quality issues when many simultaneous calls occur.
• Packet-by-packet load balancing may cause increased jitter and out-of-order packet arrival at the receiving media processor in our communications cloud. This may result in packet loss and intermittent or continuous voice quality issues, such as interruption of audio and SIP messaging in Session Border Controllers (SBC). It can also result in inconsistent NAT TCP session states between enterprise and our equipment.
• Use of Auto-QoS may cause voice quality issues (such as distortions or incorrect volume levels) with older Polycom / Poly speakerphones and older versions of desk phones.
• Green Ethernet is used on switch ports to save energy by automatically turning them into low power mode after they have not passed traffic for some time. This may also cause intermittent signaling and media traffic issues.
• Satellite connections introduce delays much exceeding 150 ms in each direction and, depending on the quality of the satellite connection, may also cause excessive jitter and packet loss. It depends on end-user expectations whether this is acceptable.
Soft-Client Endpoints
Computer endpoints used for soft-clients are recommended to be configured as follows:
LAN Interface Metric
The interface metric plus the route table metric of the wired network should be higher than for the wireless network so that only one network at a time is selected. If the total metric is identical for both types of network interfaces, this may result in load-balancing across both interfaces and voice quality issues.
From MS Windows, the metrics can be viewed by opening a command prompt window (CMD) and entering netstat -rn. The Interface List indicates metrics in the left-hand column. The IPv4 Route Table shows the metric in the right-hand column.
Security Software
Cloud-based security client software may need to be disabled when this interferes with soft-client operation or presence status updates.
DNS – Domain Name Services
Our endpoints use several cloud-based support services:
Provisioning and firmware update services for desk and conference phones.
• Call servers.
• Presence status.
Endpoints access these services via DNS lookup to resolve a domain name into an IP address.
For example, endpoints rely on a DNS service to resolve the call server domain name (e.g., sip1.flex.avpnet.us) obtained from the provisioning service to its corresponding call server address.
It is important that the domain name of the call server gets resolved to an IP address within one of the supernets that is geographically close to the physical location of endpoints. Use of a single corporate DNS (e.g., country-wide or even a single global DNS) instead of a distributed DNS to resolve domain names to local IP addresses may result in longer paths to media servers, which adversely affects voice quality.
Note that endpoints located in different Cloud regions will, in general, connect to IP addresses in different supernets.
NAT – Network Address Translation
Network Address Translation/Port Address Translation functionality (generically referred to as NAT) is applied at the border between two networks to translate between address spaces or to prevent collision of IP address spaces. More specifically, a NAT function translates a source (IP address, port number) pair of outbound packets into a public source (IP address, port number) pair and maintains table entries corresponding to this translation to allow inbound response traffic to return to the proper host in the private network. This is required, for example, when connecting: a) an enterprise IP network to the public Internet, or b) an enterprise network via a Layer 2 network.
NAT is frequently implemented as part of a firewall functionality, but can also be implemented stand-alone.
For proper operation of our endpoints, a minimum Network Address Translation time out needs to be configured. Cisco phones send a follow-up REGISTER refresh message every 4 minutes, Polycom / Poly as well as Yealink phones every 5 minutes. As a consequence:
• NAT entry expiration timeout must be set to greater than 5 minutes to cover all IP Phones.
Firewall Control
For security purposes, usually, a firewall is present at the border of an enterprise network. For proper operation of our endpoints please see below:
• A set of inbound and outbound TCP/IP firewall ports must be opened
• Domains need to be whitelisted to allow inbound and outbound traffic transfer for supporting our cloud services.
The ports that need to be opened and the domains that need to be whitelisted pertain to the following types of traffic and functionality:
• Presence status indication
• Google Chrome extensions
• Call control (SIP signaling)
• RTP media
• Auxiliary services: Network Time Service and Directory Services
• Telephone provisioning and registration
Whitelisting of Domains, IP Addresses, and Ports
To allow the devices and applications indicated below to access supporting cloud services, Fully Qualified Domains Names (FQDNs), IP addresses, and associated ports must be whitelisted:• The Firmware Update service is located in the Amazon cloud.
• Softphones and mobile phones use pubnub for presence status notifications.
• The port column indicates the port used after resolution of the domain name to an IP address.
| Domain / IP Address | Ports | ||
| Website | Login Page | login.flexuc.io flex.avalonetworks.com uc.rscom.ca | 80/443 |
| Support Services | Login Page | torque.rscombusiness.com | 80/443 |
| Insight Analytics | Login Page | insight.flexuc.io | 80/443 |
| Softphone Archiver | Box | It is assumed that the enterprise has already whitelisted the appropriate domains to allow access to Box | 443 |
| Secure File Transfer | For archiving to an enterprise SFTP server, the following SFTP client IP addresses in the cloud need to be whitelisted: 34.225.218.68 34.226.29.169 34.234.210.244 34.236.210.8 34.239.13.99 35.172.123.110 52.87.7.127 54.80.51.95 Any of these IP addresses may dynamically be selected by the our SFTP client to connect to an enterprise SFTP server. | 22 | |
| Telephony Client Application using the Platform API | Production API | api.flex.avpnet.us | 8000/16000 |
| Desktop Softphone Application & Mobile Application | Presence Status, Call Log Notifications, and Voice Mail notifications | *.softphone.com *.flexuc.io *.rscom.ca *.rscombusiness.com *.avpnet.us | 80 or 443 |
| Google Chrome Extension | Login Page | account.google.com | 443 |
| Chrome APIs for plugin | apis.google.com | ||
| Fonts used by Google Chrome | fonts.gstatic.com | ||
| Hard Phone | Cloudfront Firmware Update** | *.cloudfront.net | 443 |
| Polycom / Poly Desk Phones and Conference Phones | Provisioning | pf.avpnet.us p3.zswitch.net p.flexuc.io | 80/443 |
| Cisco Desk Phones | Provisioning | pf.avpnet.us p3.zswitch.net p.flexuc.io | 80/443 |
| Yealink Desk Phones | Provisioning | pf.avpnet.us p3.zswitch.net p.flexuc.io | 443 |
QoS Classification and Traffic Treatment Policies
traffic needs to be classified and treated properly in enterprise and service provider networks to ensure that end-to-end QoS requirements are met for our Cloud-based communications services. In terms of QoS, VoIP and video impose the most severe constraints on the network because delay, packet loss, and jitter QoS requirements requirement need to be met. Signaling traffic has lower QoS requirements since real-time requirements do not apply and packets can be retransmitted when lost. Other types of service traffic, such as messaging and directory services, can be treated more like data traffic.
The next sections indicate how, ideally, our communication services traffic should be classified and treated. In practice, it may only be possible to partially follow the our QoS traffic class and treatment requirements due to the limitation of endpoints, network devices, and ISP and carrier networks. Recommendations are provided to handle these sub-optimal cases as well.
Traffic Classification
The left side of the table below indicates the traffic classes that are distinguished for our communication services, where the class requiring the highest priority treatment (VoIP Media) is indicated at the top. At Layer 2, Class of Service (COS) frame header tagging is indicated, while DSCP packet marking is available in the IP header in Layer 3. In the next considerations, tagging at Layer 2 and marking at Layer 2 is generically called marking.
| Traffic Class | COS Decimal Value | DSCP Decimal Value | Name | Drop Probability |
| VoIP Media – Real Time | 5 | 46 | EF | N/A |
| Video Media – Real Time | 4 | 34 | AF41 | Low |
| SIP | 3 | 26 | AF31 | Low |
| Transactional: • Network Time Service • Mobile App Data Sync • LDAP Directory Service | 2 | 18 | AF21 | Low |
| Best Effort: Phone Provisioning and firmware update | 0 | 0 | BE | Undetermined |
| Layer 2 | Layer 3 |
COS is a 3-bit field in the Ethernet frame header with possible values ranging from 0 to 7. DSCP is a 6-bit field in the IP packer header with possible values ranging from 0 to 63.
NOTE: Comprehensive security is implemented above the IP layer, e.g. secured VoIP media is transported as SRTP/UDP/IP (SRTP is the secure version of RTP) so that security does not affect COS and DSCP values.
Practical Constraints
Ideally, the COS tagging and DSCP marking values indicated in the table above are used across the entire network between our endpoints and cloud-based servers, and traffic is treated according to this classification, which is referred to as honoring the marking. However, in practice this is often not entirely possible because:
• Some network devices do not support sufficient QoS capabilities. Examples are low-end routers.
• COS values are often not managed in small networks.
• ISPs may change DSCP markings along the internet path, e.g. from DSCP 46 to 0.
• In large corporate enterprise networks, with sites connected to an MPLS or Metro-Ethernet network, a DSCP to COS mapping must be performed by the WAN network border devices. This mapping may not exactly maintain the COS-DCSP values indicated.
• Someendpoint types do not mark COS/DCSP value yet.
Practical requirements and recommendations for traffic classification, DSCP marking, and a description of Layer 2 WAN interconnections are provided in the next sections to address these constraints.
Traffic Classification Methods
Depending on the QoS capabilities of the local network devices, one of two traffic classification methods can be implemented to support our communication services:
• Multi-Band Classification – Traffic to and from our cloud servers is mapped according to the table above.
• Dual-Band Classification – Realtime voice and video UDP traffic and SIP TCP traffic originating from or destined to our cloud communication media servers are all classified as DCSP 46. Other traffic is classified as unprioritized data traffic with DSCP and COS value equal to 0. The dual-band classification method is indicated in the table below.
Multi-band classification offers the best way to handle QoS in large corporate networks and whenever the network devices support this. Dual-band classification is relatively simple to implement and works well in most SoHO and corporate environments with devices with limited QoS capabilities. In some cases, when sufficient network capacity exists, some enterprises choose to implement a variant of the dual-band classification illustrated in the table below, where all our traffic (e.g. media, SIP, phone provisioning, and firmware update) is classified as DSCP 46.
| Traffic Class | COS Decimal Value | DSCP Decimal Value | Name | Drop Probability |
| VoIP Media – Real Time Video Media – Real Time SIP | 5 | 46 | EF | N/A |
| Transactional:• Network Time Service • Mobile App Data Sync • LDAP Directory Service • Best Effort: Phone Provisioning and firmware update | 0 | 0 | BE | Undetermined |
| Layer 2 | Layer 3 |
Endpoint and Internet DSCP Traffic Marking Constraints
The following types of DSCP marking are applied by our endpoints, cloud media server, and Internet Service Providers:
• VoIP Endpoints
• Desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding – EF) marking for UDP media packets. In this way, routers in an enterprise network can prioritize VoIP media traffic over best effort data traffic.
• Soft endpoints such as the Bria Enterprise Softphone mark UDP media packets as DSCP 0. Other types of traffic are not marked by the endpoints yet. This implies that network devices like access switches, routers and firewalls need to remark traffic at the proper location in the outbound direction.
• VoIP Media Servers – Our cloud media servers mark UDP traffic as DSCP 46.
• Internet Service Providers – Internet Service providers frequently remark DSCP priority values to different (lower) values, which has the following implications:
• Outbound direction: Traffic often arrives in Our VoIP Communications cloud with improper marking.
• Inbound direction: Internet traffic may arrive to an enterprise site incorrectly marked from the internet and, therefore, needs to be remarked immediately by the enterprise network border device to ensure that it will be forwarded inside the internal network according to the right priority relative to other traffic.
TCP/IP Port Tables
| Traffic Type | Protocols | Destination Port Number |
| Media | RTP/UDP | 10000-64999 |
| Media – Secured | SRTP/UDP | 10000-64999 |
| Signaling | SIP/UDP | 5060, 7000 |
| Signaling | SIP/TCP | 5060, 7000 |
| Signaling – Secured | SIP/TLS/TCP | 5096 |
| Network Time Service | NTP/UDP | 123 |
| LDAP Directory Service | LDAP/(TLS/SSL)/TCP | 636 |
| Provisioning | HTTP/TCP and HTTPS/TCP | 80/443 |
| Traffic Type | Protocols | Destination Port Number |
| Media | RTP/UDP | 10000-64999 |
| Media – Secured | STRP/UDP | 10000-64999 |
| Signaling | SIP/TCP | 5060, 7000 |
| Signaling – Secured | SIP/TLS/TCP | 5061, 7001 |
| LDAP Directory Service | LDAP/(TLS/SSL)/TCP | 636 |
| Provisioning and Presence Status | HTTP/TCP and HTTPS/TCP | 80 and 443 |
| Traffic Type | Protocols | Destination Port Number |
| Media | RTP/UDP | 10000-64999 |
| Media – Secured | SRTP/UDP | 10000-64999 |
| Signaling | SIP/UDP and SIP/TCP | 5060 and 7000 |
| Signaling (IPv6 client) | SIP/TCP/TLS | 5060 and 7000 |
| Signaling – Secured | SIP/TLS/TCP | 5061 and 7001 |
| Mobile App Data Sync (e.g., call log info, presence, and voicemails) | HTTPS | 80 and 443 |
| LDAP Directory service | LDAP/TCP | 636 |
| Provisioning and Presence Status | HTTP/TCP and HTTPS/TCP | 80 and 443 |
Amazon CloudFront IP Address
| CloudFront Global IP List: | CloudFront Regional Edge IP List: |
| 13.32.0.0/15 13.35.0.0/16 52.46.0.0/18 52.84.0.0/15 52.124.128.0/17 52.222.128.0/17 54.182.0.0/16 54.192.0.0/16 54.230.0.0/16 54.239.128.0/18 54.239.192.0/19 54.240.128.0/18 64.252.64.0/18 70.132.0.0/18 71.152.0.0/17 143.204.0.0/16 204.246.164.0/22 204.246.168.0/22 204.246.174.0/23 204.246.176.0/20 205.251.192.0/19 205.251.249.0/24 205.251.250.0/23 205.251.252.0/23 205.251.254.0/24 216.137.32.0/19 | 13.54.63.128/26 13.59.250.0/26 13.113.203.0/24 13.124.199.0/24 13.228.69.0/24 18.216.170.128/25 34.195.252.0/24 34.216.51.0/25 34.226.14.0/24 34.232.163.208/29 35.158.136.0/24 35.162.63.192/26 35.167.191.128/26 52.15.127.128/26 52.47.139.0/24 52.52.191.128/26 52.56.127.0/25 52.57.254.0/24 52.66.194.128/26 52.78.247.128/26 52.199.127.192/26 52.212.248.0/26 52.220.191.0/26 54.233.255.128/26 |