Avaya Cloud Office Networking Requirements and Recommendations

 

Table of Contents

1.  Introduction

2.  Reading Guidelines

3.  Acronyms

4.  End-to-End Quality of Service Network Requirements

5. Network Readiness Assessment

6.  Avaya Cloud Office Supernets

7.  Networks

7.1. VLANs
7.2. SMB/SoHo Networks
7.3. WiFi Networks
7.4. Wide-Area Networks (WANs)

8.  Network Components and Services

8.1. Enterprise Class and Tested Routers
8.2. Unsupported Devices and Configurations
8.3.  Avaya Cloud Office Soft-Client Endpoints
8.4. DNS
8.5. NAT
8.6. Firewall Control
    8.6.1. Firewall Types
    8.6.2. TCP/IP Ports
    8.6.3. Whitelisting of Domains, IP Addresses, and Ports

9.  QoS Classification and Traffic Treatment Policies

9.1. Traffic Classification
9.2. Practical Constraints
9.3. Traffic Classification Methods
9.4. Endpoint and Internet DSCP Traffic Marking Constraints
9.5. DSCP Marking Policy
9.6. Bandwidth Management Policy
9.7. Layer 2 WAN Interconnect Policy

10.      Bandwidth and LAN / WAN Link Capacity Determination

 

Appendix A. TCP/IP Port Tables

Appendix B. Amazon Cloud Front IP Address Range for Phone Firmware Upgrades References

 

1.  Introduction

The purpose of this document is to provide Avaya Cloud Office customers with network requirements and recommendations to ensure that Avaya Cloud Office cloud-based unified communication services operate properly. For the successful implementation of Avaya Cloud Office 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. The Avaya Cloud Office UC Reference Architecture can be used to understand the context of the end-to-end Quality of Service requirements (Section 4) and the network specific requirements and recommendations (Section 6 through Section 9). Section 5 describes the need to perform Network Readiness Assessment to verify and ensure that the network meets the stated requirements.

 

2.  Reading Guidelines

The following reading guidelines can be used:

· For Enterprise and SMB/SoHo environments, the network requirements and recommendations are stated in Sections 6 through 9.

· Section 6 specifies the Avaya Cloud Office IP Supernets, which can be used to configure QoS policies, firewall rules, and disable layer 7 functions.

· Section 7 specifies requirements and recommendations for specific types of enterprise and wide- area networks.

· Section 8 provides network specific NAT and firewall requirements.

· Section 9 specifies QoS requirements.

· Section 10 contains a description for LAN / WAN bandwidth and capacity requirements.

· The appendices contain detailed information, such TCP/IP port tables, and IP Address Range for Phone Firmware upgrades.

· For some SMB environment routers, the Configuration Guides under the link provided in Section 8.1 on Enterprise Class and Tested Routers can be used to configure QoS settings.

 

3. Acronyms

 Table 1 summarizes the acronyms used in this document:

Table 1. Acronyms
ACL	Access Control List	ms	Milliseconds
ALG	Application Layer Gateway	NAT	Network Address Translation
AP	Access Point	NTP	Network Time Protocol
ARP	Address Resolution Protocol	QoS	Quality of Service
BLA	Busy Lamp Appearance	RTP	Real-time Protocol
BW	Bandwidth	SBC	Session Border Controller
CoS	Class of Service	SIP	Session Initiation Protocol
DPI	Deep Packet Inspection	SMB	Small and Medium-sized Business
DSCP	Differentiated Services Code Point	SoHo	Small office - Home office
DSL	Digital Subscriber Line	SPI	Stateful Packet Inspection
EF	Expedited Forwarding	SRTP	Secure Real-time Transport Protocol
FQDN	Fully Qualified Domain Name	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

 

4.  End-to-End Quality of Service Network Requirements

The requirements stated in Table 2 need to be satisfied for VoIP media traffic to get optimal call quality between Avaya Cloud Office endpoints.

 

*https://www.itu.int/rec/T-REC-G.114-200305-I/en, Appendix II.

5.  Network Readiness Assessment

The end-to-end quality of service requirements stated in Section 4 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 Avaya Cloud Office communication services:

 

·       Snapshot Network Readiness Assessment - This assessment leverages the Capacity Test (https://www.ringcentral.com/support/capacity.html) and VoIP Quality Test (https://www.ringcentral.com/support/qos.html). These tools provide an impression of network capacity and quality in the outbound direction of an enterprise site to the Avaya Cloud Office services 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 Avaya Professional Services.

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.

6.  Avaya Cloud Office Supernets

The following supernets (concatenated subnets) are owned and used by Avaya for unified communication:

 

Avaya Cloud Office uses these networks 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 for the specific regions.

The Avaya Cloud Office supernets can be used to control the following features in local enterprise network devices (see next section):

·      Selectively disable layer 7 device functions such as Deep Packet Inspection (Section 8.2)
for UDP traffic to/from Avaya.

·      Firewall TCP/IP Ports (Section 8.6.2).

·      IP Layer DSCP packet markings (Section 9.5). 

 

7.  Networks

This section covers high-level requirements and recommendations for specific types of enterprise and wide-area networks. More details are provided in the subsequent sections for network components, QoS handling, and bandwidth estimation.

 

7.1. VLAN's 

Virtual LANs (VLANs) can be used as follows with Avaya Cloud Office 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 Avaya Cloud Office soft-clients 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:

·        The Avaya Cloud Office 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 Avaya
cloud-based services.

·        The way Polycom phones can leverage VLANs is described in Appendix A.

 

7.2. 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 Avaya Cloud Office network requirements in this document, including the WiFi network requirements in Section 7.3.

·        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.

 

7.3. 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.

Avaya Cloud Office soft-endpoints such as desktop softphones and mobile phone applications 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 Avaya Cloud Office 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.

 

7.4. Wide-Area Networks (WANs) 

Many technologies exist to implement WANs, including internet, Ethernet Virtual Private Line, MPLS, and SD-WAN. Each type of network technology has its own way of supporting QoS.
To ensure that the end-to-end QoS requirements and recommendations are met, it is required that:

·        Every traversed WAN network segment must have sufficient quality.

·        Proper mapping of prioritization tags is performed between LAN and WAN networks (Section 9.5).

8. Network Components and Services

To ensure high-quality communication service delivery, Avaya Cloud Office requires that network devices and endpoints support the feature requirements and follow the recommendations stated in this section.

 

8.1. Wide-Area Networks (WANs)

In general, enterprise class routers support most of the QoS capabilities and configuration options described in the remainder of this document.

A set of SMB class WAN routers have been validated to work properly with the Avaya Cloud Office VoIP service. The list of routers that have been tested can be found here: List of Avaya Cloud Office Recommended SoHo Routers.

 

8.2. Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended in a Avaya Cloud Office 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 Avaya Cloud Office Unified Communications services, the functions listed in Table 4 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 Avaya Cloud Office supernets listed in Section 6 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to Avaya Cloud Office.

 

 

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 the Avaya Cloud Office. 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 Avaya Cloud Office equipment.

·        Use of Auto-QoS may cause voice quality issues (such as distortions or incorrect volume levels) with older Polycom 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.

 

8.3. Avaya Cloud Office Soft-Client Endpoint

Computer endpoints used for Avaya Cloud Office 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.
See https://superuser.com/questions/708716/setlan-to-take-network-priority-before-wi-fi-on-windows-7 for more background.

 

Security Software

Cloud-based security client software may need to be disabled when this interferes with
soft-client operation or presence status updates.

 

8.4. DNS

Avaya Cloud Office 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, Avaya Cloud Office endpoints rely on a DNS service to resolve the call server domain name e.g., sip3.ringcentral.com) 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 Avaya Cloud Office regions will, in general, connect to IP addresses in different supernets.

 

8.5. NAT

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 to Avaya Cloud Office.

NAT is frequently implemented as part of a firewall functionality but can also be implemented standalone.

For proper operation of the Avaya Cloud Office 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 phones every 5 minutes. As a consequence:

·        NAT entry expiration timeout must be set to greater than 5 minutes to cover all Avaya Cloud Office phones.

 

8.6. Firewall Control

For security purposes, usually, a firewall is present at the border of an enterprise network (Avaya Cloud Office UC Reference Architecture). For proper operation of the Avaya Cloud Office endpoints:

·        A set of inbound and outbound TCP/IP firewall ports must be opened (Appendix B. TCP/IP Port Tables).

·        Domains need to be whitelisted (Section 8.6.3) to allow inbound and outbound traffic transfer for supporting Avaya Cloud Office 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

·        Avaya APIs

·        Call control (SIP signaling)

·        RTP media

·        Auxiliary services: Network Time Service and Directory Services

·        Telephone provisioning and registration

 

8.6.1. Firewall Types

Two main types of firewall operation can be distinguished

•      Stateful Firewall – In a stateful firewall, the associated inbound TCP/IP port is automatically opened upon initiating a TCP or UDP session in the outbound direction from the private network side.

•      Stateless Firewall – Session state is not maintained in the firewall, each packet transferred through the firewall is considered unrelated to any other packets that are part of the same session. This implies that, before allowing a TCP/IP session between the private and public network, the appropriate ports need to be opened first, both in the inbound and outbound direction.

 

Both types of firewall operation may be configurable within the same physical firewall device.

Compared to stateful firewall operation, a stateless firewall generally requires more firewall

administration work and may be less secure because it is more prone to administration errors. It is therefore recommended to use a stateful firewall to support Avaya Cloud Office Unified Communication Services.

The high-level firewall Access Control Configuration rules indicated in Table 5 can be used in

conjunction with Avaya Cloud Office supernets (Section 6) and port tables (Appendix B).

 

 

8.6.2.  TCP/IP Ports

When using a stateless firewall, use the tables in Appendix B to control TCP/IP ports.

 

8.6.3.  Whitelisting of Domains, IP Addresses and Ports

To allow the devices and applications indicated in Table 6 to access supporting cloud services, Fully Qualified Domains Names (FQDNs), IP addresses, and associated ports must be whitelisted:

•      The Polycom, Cisco, and Yealink provisioning services are located in the Avaya Cloud Office supernet IP address.

•      The Firmware Update service is located in the Amazon cloud.

•      Softphones and mobile phones use pubnub for presence status notifications.

•      Avaya Cloud Office Premium and Ultimate plans provide the ability to archive softphone messages (text, fax, and voice mail) and call recordings (automatic and on-demand) to the Box cloud (www.box.com) or to an sftp server.

 

 

 **See Appendix B. CloudFront IP Address Range for Phone Firmware Upgrades

 

9. QoS Classification and Traffic Treatment Policies

Avaya Cloud Office 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 Avaya 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, Avaya Cloud Office communication services traffic should be

classified and treated. In practice, it may only be possible to partially follow the Avaya Cloud Office 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.

•      outbound is away from the enterprise site or in the direction of the service provider network.

•      inbound is to the enterprise site or from the service provider network into the local enterprise network.

 

9.1.  Traffic Classification

The left side of Table 7 indicates the traffic classes that are distinguished for Avaya Cloud Office

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.

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: End-to-end 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.

 

9.2.    Practical Constraints

Ideally, the COS tagging and DSCP marking values indicated in Table 7 are used across the entire network between Avaya Cloud Office 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 in Table 7. More details are provided in (Section 9.7).

•      Some Avaya Cloud Office endpoint types do not mark COS/DCSP value yet (Section 9.4).

 

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.

9.3.    Practical Constraints

Depending on the QoS capabilities of the local network devices, one of two traffic classification methods can be implemented to support Avaya Cloud Office communication services:

•      Multi-Band Classification – Traffic to and from Avaya Cloud Office cloud servers is mapped according to Table 7.

•      Dual-Band Classification – Realtime voice and video UDP traffic and SIP TCP traffic originating from or destined to Avaya 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 Table 8.

 

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 Table 8, where all Avaya Cloud Office traffic (e.g. media, SIP, phone provisioning, and firmware update) is classified as DSCP 46.

 

9.4.    Endpoint and Internet DSCP Traffic Marking Constraints

The following types of DSCP marking are applied by Avaya Cloud Office endpoints, cloud media server, and Internet Service Providers:

       Avaya Cloud Office Endpoints

•      Avaya Cloud Office 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.

•      Avaya Cloud Office soft endpoints 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 (Section 9.5).

•      Avaya Cloud Office Media Servers - Avaya cloud media servers mark UDP traffic as DSCP 46.

•      Avaya Cloud Office Mobile Applications have the capability to mark traffic with a DSCP value as indicated in Table 6.

•      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 the Avaya Cloud Office 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.

9.5.  DSCP Marking Policy

This section describes traffic treatment policies for (re-)marking DSCP values in enterprise networks. The following DSCP marking and honoring (i.e. keeping the assigned DSCP value and forwarding it according to the priority of the assigned value) policy must be implemented in switches, routers, and firewalls in the end-to-end communication path between Avaya Cloud Office endpoints and cloud-based servers, which accommodate the DSCP marking constraints listed in (Section 9.4):

1. Outbound Direction - Remark traffic to the correct DSCP value in Table 7 or Table 8
as close as possible to the endpoint if the endpoint does not mark the correct value.
The remarking may occur in network devices like Access Points, access switches, router,
and firewalls.

2. Inbound Direction - Remark traffic to the correct DSCP value as soon as it enters the enterprise network via a carrier WAN link or WiFi Access Point.

3. Inside the Local Network - Honor the DSCP markings throughout the enterprise network in both the inbound and outbound direction.

4. WAN Network - Any mapping from DCSP to COS and back needs to be performed so that end-toend QoS requirements are maintained (Section 9.7).

The Avaya Cloud Office supernets (Section 6) and port tables TCP/IP port tables (Appendix B) must be used in the inbound and outbound ACLs to define the stated QoS policies. Local subnet address ranges should not be used to define QoS policies because any subnet changes would require modification of the policy. 

Some firewall manufacturers do not support re-marking of DSCP, but may support prioritization of packet forwarding based on source IP addresses and IP address ranges, which also requires that the Avaya Cloud Office supernets must be used in the QoS policy definition.

 

9.6.  Bandwidth Management Policy

Some routers support bandwidth management, which can be used to guarantee the capacity for certain types of traffic even under saturation conditions. If routers support bandwidth management, then it is advised to enable this feature and set the bandwidth for Avaya Cloud Office traffic to the number obtained from (Section 10). If the traffic classification and policies are configured according to the recommendations and requirements stated in prior sections and the Avaya Cloud Office traffic exceeds the configured bandwidth, Avaya Cloud Office traffic may still get prioritized over regular data traffic although bandwidth may not be guaranteed for all calls (depends on the router and setting).

 

9.7.   Layer 2 WAN Interconnect Policy

Large enterprise networks frequently rely on layer 2 MPLS or Metro-Ethernet WAN networks to interconnect layer 3 networks. To ensure that the End-to-End Quality of Service Network Requirements (Section 4) are adhered to, several conditions must be met at the ingress and egress border of these networks:

•      Traffic Class and Priority Matching – Ensure that the number of traffic classes and COS values in the Wide-Area Network align as much as possible with Table 7 or Table 8 (depending on the selected classification method).

•      Bandwidth Matching – Ensure that the assigned average capacity for each layer 2 traffic class is larger than the maximum bandwidth for each type of traffic in the layer 3 network.

•      Traffic Shaping – Ensure that the maximum Layer 3 network bandwidth produced for each traffic class does not exceed the WAN link capacity. This can be accomplished by traffic shaping provided that the average bandwidth does not exceed the provisioned WAN capacity.

 

If the Traffic Class and Priority Matching condition cannot be met, then some layer 3 DSCP values must be mapped to a higher COS value. The bandwidth matching condition must be followed because otherwise, QoS issues of the following types may occur. Suppose that the produced voice bandwidth in the layer 3 network is 10 Mbit/s and the voice traffic capacity allocated in the WAN network is 200 kbit/s. Then, the voice quality will be very much degraded when more than a few calls are made, in case voice traffic gets a higher priority assigned than data traffic.

 

10. Bandwidth and LAN / WAN Link Capacity Determination

Two methods can be used to determine the bandwidth produced by Avaya Cloud Office traffic on LAN and WAN links and their capacity required to carry Avaya Cloud Office unified communication traffic.

The preferred and most accurate method is to determine the peak traffic load from logs or network data extracted from a still deployed legacy voice/video system. Alternatively, a bandwidth and capacity calculation procedure can be used (Avaya Cloud Office Bandwidth and LAN WAN Link Capacity Determination).

 

 

Appendix A: TCP/IP Port Tables

Port tables 1 through 9 summarize the TCP/IP source and destination port numbers that are used by traffic generated by the Avaya Cloud Office endpoints. The following general properties hold for the port tables:

•      Table B.1, B.2, B.3, and B.5: Media and Media-Secured traffic port ranges have been expanded to 20000-64999

•      Table B.5 on Google Chrome Extensions and Desktop App Telephony has been refined and corrected to indicate traffic types more explicitly.

•    Table B.6 covers video desktop clients and Chrome browser 

•    The port tables are more or less organized from top to bottom according to QoS traffic prioritization, with media requiring highest priority and supporting data service traffic at the lowest priority (Section 9.1).

•      Table rows indicating Signaling/Media (without the Secured modifier) can be ignored when the customer account is configured for ‘secured signaling and media.’ Note that blocking non-secured traffic may require a longer time to troubleshoot voice quality issues.

•      Some 3rd party devices, such as the Polycom IP7000 speakerphone, do not support signaling or media encryption. They should be avoided in a deployment requiring full security.

•      No separate ports are specified for Busy Lamp Appearance (BLA) since it uses the signaling ports and standard SIP NOTIFY packets.

 

Table B.1 -  Desk Phone
Traffic Type	Protocols	Destination Port Number
Media	RTP/UDP	20000-64999
Media - Secured	SRTP/UDP	20000-64999
Signaling	SIP/UDP	5090
Signaling	SIP/TCP	5090, 5099*
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	443

*TCP port 5099 only needs to be opened when line sharing is used
**Implemented on all systems from November 2021

 

Table B.2 - Desktop Softphone Application
Traffic Type	Protocols	Destination Port Number
Media	RTP/UDP	20000-64999
Media - Secured	STRP/UDP	20000-64999
Signaling	SIP/TCP	5091
Signaling - Secured	SIP/TLS/TCP	5097
LDAP Directory Service	LDAP/(TLS/SSL)/TCP	636
Provisioning and Presence Status	HTTP/TCP and HTTPS/TCP	80 and 443

 

 
 

 

 

 

  

Appendix B. Amazon CloudFront IP Address Range for Phone Firmware Upgrades