AT&T Office@Hand

Learn how to use features from AT&T Office@Hand. Access our self-help options to set up and use this application to communicate with customers.

Back to product page

Network – Requirements and Recommendations | AT&T Office@Hand
Article #4364

How do I set up my network to get the best VoIP experience with AT&T Office@Hand?


  1. Introduction
  2. Reading Guidelines
  3. Acronyms
  4. End-to-End Quality of Service Network Requirements
  5. AT&T Office@Hand Supernets
  6. Networks
    1. VLANs
    2. SMB/SoHo Networks
    3. WiFi Networks
    4. Wide-Area Networks (WANs)
  7. Network Components and Services
    1. Enterprise Class Routers and Tested Routers
    2. Unsupported Devices and Configurations
    3. AT&T Office@Hand Soft-Client Endpoints
    4. DNS
    5. NAT
    6. Firewall Control
      1. Firewall Types
      2. TCP/IP Ports
      3. Whitelisting of Domains, IP Addresses, and Ports
  8. QoS Classification and Traffic Treatment Policies
    1. Traffic Classification
    2. Practical Constraints
    3. Traffic Classification Methods
    4. Endpoint and Internet DSCP Traffic Marking Constraints
    5. DSCP Marking Policy
    6. Bandwidth Management Policy
    7. Layer 2 WAN Interconnect Policy
  9. Bandwidth and LAN/WAN Link Capacity Determination
    1. Endpoint Bandwidths
    2. VoIP Endpoint Bandwidth
    3. AT&T Office@Hand Meetings Bandwidths

Appendix A – VLANs Configuration of Polycom Phones
Appendix B – TCP/IP Port Tables
Appendix C – CloudFront IP Address Range for Phone Firmware Upgrades References

1. Introduction

The purpose of this document is to provide AT&T Office@Hand customers with network requirements and recommendations to ensure that the AT&T Office@Hand cloud-based unified communication services operate properly. For the successful implementation of AT&T Office@Hand services, the network requirements are to be followed without reservation, while recommendations are advised to be followed.

This document states constraints on network capacity, quality of service, firewall configuration, and unsupported devices and configurations.

back to Table of Contents

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 5 specifies the AT&T Office@Hand IP Supernets, which can be used to configure QoS policies, firewall rules, and disable layer 7 functions.
    • Section 6 specifies requirements and recommendations for specific types of enterprise and wide-area networks.
    • Section 7 specifies QoS requirements.
    • Section 8 provides network specific NAT and firewall requirements.
    • Section 9 provides the guidelines on how to calculate your bandwidth requirement to adequately utilize AT&T Office@Hand features on different endpoints.
    • The appendices contain detailed information, such as VLAN configuration of Polycom phones, TCP/IP port tables, and IP Address Range for Phone Firmware upgrades.

3. Acronyms


ACL Access Control List Mbps Megabit per second
ALG Application Layer Gateway ms Milliseconds
AP Access Point NAT Network Address Translation
ARP Address Resolution Protocol NTP Network Time Protocol
BLA Bridged Line Appearance QoS Quality of Service
BW Bandwidth RTP Real-time Protocol
CoS Class of Service SBC Session Border Controller
DPI Deep Packet Inspection SIP Session Initiation Protocol
DSCP Differentiated Services Code Point SMB Small and Medium-sized business
DSL Digital Subscriber Line SoHo Small office – Home office
EF Expedited Forwarding SPI Stateful Packet Inspection
HD High Definition SRTP Secure Real-time Transport Protocol
HQ High Quality SUF Simultaneous Use Factor
IDS Intrusion Detection System TCP Transport Control Protocol
UDP User Datagram Protocol TS-DATA-BW Total data traffic bandwidth for a given site
IP Internet Protocol TS-RC-BW Total AT&T Office@Hand traffic bandwidth for a given site
IPS Intrusion Prevention System VLAN Virtual Local Area Network
ISP Internet Service Provider VoIP Voice over IP
Kbps Kbps Kilobit per second 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 below need to be satisfied for VoIP media traffic to get optimal call quality between AT&T Office@Hand endpoints. The same requirements hold for Video over IP when using the AT&T Office@Hand Meetings application since voice is embedded in the video signal.

Table 2. Quality of Service Network Requirements
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 (Section 9)
Delay < 150 ms (of one way latency)*
Packet Loss < 1%
Jitter < 30 ms

*, Appendix II

back to Table of Contents

5. AT&T Office@Hand Supernets

The following supernets (concatenated subnets) are owned and used by AT&T Office@Hand for unified communication:

AT&T Office@Hand Supernets

AT&T Office@hand 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 AT&T Office@Hand 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 7.2) for UDP traffic to/from AT&T Office@Hand.
  • Firewall TCP/IP Ports (Section 7.6.2).
  • IP Layer DCSP packet markings (Section 8.5).

back to Table of Contents

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

6.1 VLANs

Virtual LANs (VLANs) can be used as follows with AT&T Office@Hand 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 AT&T Office@Hand 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 AT&T Office@Hand 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 AT&T Office@Hand cloud-based services.
  • The way Polycom phones can leverage VLANs is described in Appendix A.

6.2 SMB/SoHo Networks

Small Medium Business 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 more difficult to manage the end-to-end QoS for cloud communication services. However, to maximize the QoS, it is recommended to:

  • Closely follow the AT&T Office@Hand network requirements in this document, including the WiFi network requirements in Section 6.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.

6.3 WiFi Networks

The achievable QoS over a WiFi network depends on many factors. Chief among them are:

  • The capabilities, settings, and physcial 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.

AT&T Office@Hand soft-endpoints such as desktop softphones, mobile phone applications, and AT&T Office@hand Meetings 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:

  1. The wired network meets the AT&T Office@Hand network requirements.
  2. 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.
  3. 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.

6.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 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 8.5)

7. Network Components and Services

To ensure high-quality communication service delivery, AT&T Office@Hand requires that network devices and endpoints support the feature requirements and follow the recommendations stated in this section.

7.1 Enterprise Class Routers and Tested Routers

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

7.2 Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended in an AT&T Office@Hand 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 AT&T Office@Hand 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 AT&T Office@Hand supernets listed in Section 5 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to AT&T Office@Hand.

Table 4. Functions to be Disabled for UDP Traffic to/from AT&T Office@Hand
Layer Function
  • 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
  • Port filtering
  • Packet-by-packet load balancing across multiple service providers links
IP & Data Link
  • Auto-QoS, when used in combination with Polycom phones
  • Dynamic ARP inspection
  • 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 the AT&T Office@Hand 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 between enterprise and AT&T Office@Hand 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.

7.3 AT&T Office@Hand Soft-Client Endpoints

Computer endpoints used for AT&T Office@Hand 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 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.

7.4 DNS

AT&T Office@Hand endpoints use several cloud-based support services:

  • Provisioning and firmware updated 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, AT&T Office@Hand endpoints rely on a DNS service to resolve the call server domain name (e.g., 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 are 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 AT&T Office@Hand Cloud regions will, in general, connect to IP addresses in different supernets.

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

NAT is a frequently implemented as part of a firewall functionality, but can also be implemented stand-alone.

For proper operation of the AT&T Office@Hand 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 AT&T Office@Hand phones.

7.6 Firewall Control

For security purposes, usually, a firewall is present at the border of an enterprise network. For proper operation of the AT&T Office@Hand 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 7.6.3) to allow inbound and outbound traffic transfer for supporting AT&T Office@Hand 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
  • AT&T Office@Hand APIs
  • Call control (SIP signaling)
  • RTP media
  • Auxiliary services: Network Time Service and Directory Services
  • Telephone provisioning and registration

7.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 port 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 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 AT&T Office@Hand Unified Communication Services.

The high-level firewall Access Control Configuration rules indicated in Table 5 can be used in conjunction with AT&T Office@Hand supernets (Section 5) and port tables (Appendix B).

Table 5. Additional Access Control Policies
Type of Firewall Outbound Direction Inbound Direction
Stateful Firewall Allow traffic as indicated in the port tables to all AT&T Office@Hand supernets. No configuration required
Stateless Firewall Allows all traffic as indicated in the port tables to all AT&T Office@Hand supernets

Allow all traffic as indicated in the port tables in Section 7.6.2 from all supernets according to the following rules:

  • Destination ports must be replaced by source ports.
  • Source ports must be replaced by destination ports.

7.6.2 TCP/IP Ports

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

7.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 AT&T Office@Hand supernet IP address.
  • The Firmware Update service is located in the Amazon cloud.
  • Softphones and mobile phones use pubnub for presence status notifications.
  • AT&T Office@Hand Premium and Enterprise plans provide the ability to archive softphone messages (text, fax, and voicemail) and call recordings (automatic and on-demand) to the Google Drive, Dropbox, Box cloud ( or to an sftp server.
Table 6. Whitelisting of Domains and IP Addresses
  Cloud Service Domain/IP Address and Ports to be whitelisted
Domain/IP Address Ports
NOTE: AT&T Office@Hand URLs will be migrated to .biz, but in the meantime, include BOTH the .com AND .biz (ex. AND domains on your whitelist.
AT&T Office@Hand Service Web AT&T Office@Hand Account Configuration Portal 443

AT&T Office@Hand Live Reports

AT&T Office@Hand Analytics Portal
IP address
Polycom Desk Phones and Conference Phones Provisioning

Firmware Update
Cisco Desk Phones Provisioning

Firmware Update
Yealink Desk Phones Provisioning

Firmware Update
Desktop, Softphone Application & Mobile Application Presence, Call Log Notifications, and Voice Mail notifications *
80 or 443
Softphone Archiver Box It is assumed that the enterprise has already whitelisted the appropriate domains to allow access to Box. 443
sftp IP address of the enterprise sftp server 22
Google Chrome Extension Google Account 443
Chrome for APIs for plugins
Google Chrome Extension Fonts used by Google Chrome 443
AT&T Office@Hand Meetings     443
RingCentral Meetings

• #sjc51-c04-sfu01
• #sjc51-c04-sfu02
• #sjc51-c04-sfu03
• #iad51-c04-sfu01
• #iad51-c04-sfu02
• #iad51-c04-sfu03
* (for firmware and software

Telephony Client Application using the RingCentral Connect Platform API Production API
Mobile and Desktop applications Updates and configurations
80 and 443
AT&T Office@Hand API Production API
AT&T Analytics Analytics
AT&T Live Reports Live Reports
AT&T managed IP

**See Appendix C: CloudFront IP Addresses Range for Phone Firmware Upgrades

back to Table of Contents

8. QoS Classification and Traffic Treatment Policies

AT&T Office@Hand 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 AT&T Office@Hand 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 re-transmitted 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, AT&T Office@Hand communication services traffic should be classified and treated. In practice, it may only be possible to partially follow the  AT&T Office@Hand 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.

8.1 Traffic Classification

The left side of Table 7 indicates the traffic classes that are distinguished for AT&T Office@Hand 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.

Table 7. Traffic Types and Classifications
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


  • 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: 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.

8.2 Practical Constraints

Ideally, the COS tagging and DSCP marking values indicated in Table 7 are used across the entire network between AT&T Office@Hand 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 8.7.   
  • Some AT&T Office@Hand endpoint types do not mark COS/DCSP value yet (Section 8.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.

back to table of Contents

8.3 Traffic Classification Methods

Depending on the QoS capabilities of the local network devices, one of two traffic classification methods can be implemented to support AT&T Office@Hand communication services:   

  • Multi-Band Classification  – Traffic to and from AT&T Office@Hand cloud servers is mapped according to Table 7.  
  • Dual-­Band Classification – Real-time voice and video UDP traffic and SIP TCP traffic originating from or destined to AT&T Office@Hand 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 AT&T Office@Hand traffic (e.g. media, SIP, phone provisioning, and firmware update) is classified as DSCP 46.

Table 8. Traffic Types and Classification
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


  • 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

back to Table of Contents

8.4 Endpoint and Internet DSCP Traffic Marking Constraints

The following types of DSCP marking are applied by AT&T Office@Hand endpoints, cloud media server, and Internet Service Providers:  

  • AT&T Office@Hand Endpoints
    • AT&T Office@Hand 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.   
    • AT&T Office@Hand soft endpoints (softphones, AT&T Office@Hand Meetings, and Google Chrome clients) 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 8.5).
  • AT&T Office@Hand Media Servers ­ – AT&T Office@Hand cloud media servers mark UDP traffic as DSCP 46.   
  • AT&T  Office@Hand 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 AT&T Office@Hand 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. 

8.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  AT&T Office@Hand endpoints and cloud­based servers, which accommodate the DSCP marking constraints listed in Section 8.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­to­end QoS requirements are maintained (Section 8.7).

The AT&T Office@Hand supernets (Section 5) 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 AT&T Office@Hand supernets must be used in the QoS policy definition.

back to Table of Contents

8.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 AT&T Office@Hand traffic to the number obtained from Section 9. If the traffic classification and policies are configured according to the recommendations and requirements stated in prior sections and the AT&T Office@Hand traffic exceeds the configured bandwidth, AT&T Office@Hand traffic may still get prioritized over regular data traffic although bandwidth may not be guaranteed for all calls (depends on the router and setting). 

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

back to Table of Contents

9. Bandwidth and LAN / WAN Link Capacity Determination

Table 9.1 provides an example of a bandwidth calculation for a single enterprise site. Other scenarios are considered in section 4. Two methods can be used to obtain data for the table. One method is to determine the number of deployed endpoints, their type, and the peak traffic load from logs or network data extracted from a still deployed legacy voice/video system. Alternatively, information can be extracted from the AT&T Office@Hand service web portal administration site. This data can be entered into the table columns. The table must be used as follows:

  • Normally, users utilize one endpoint (phone or app) at a time. Such endpoints should not be double-counted in the Number of Endpoints column.
  • The Headroom for Growth column indicates how many extra endpoints may be activated after the initial deployment of AT&T Office@Hand unified communication services. It is useful to take this number into account in the calculation to ensure that network capacity is available to accommodate business growth or company mergers.
  • The Simultaneous Use Factor (SUF), a number between 0 and 1, indicates the maximum number of simultaneously used endpoints. In voice contact center deployment, this number must be set to 1 for the endpoints involved, which may be a subset of the entire enterprise site endpoint population. As a consequence, extra table rows may be needed to accommodate different endpoint use cases.
  • Since the bandwidth used for video calls is much higher than for phone calls, the SUF must be carefully selected so that, in all use cases, sufficient local and wide-area network link capacity is ensured. As an example, the SUF for video must be set to 1 for enterprises with a small number of users, where the total produced bandwidth is primarily determined by video calls.
  • The Bandwidth per Endpoint Type is obtained from bandwidth tables (Section 5) and are stated in Mbps (instead of Kbps). For voice and video calls, codecs are dynamically selected based on priority, endpoint negotiation, and call scenario. For voice calls, always the maximum bandwidth of 0.1 Mbps is entered into the table ensure that capacity needs are properly budgeted for signaling and all voice codec types that may be used. For video calls, maximum bandwidth is entered if transmit and receive bandwidth numbers are different.
  • The Endpoint Type Total Bandwidth (ETTBW) in the last column is calculated from the combination of the numbers on each row.
  • The Endpoint Type Total Bandwidth (ETT-RC-BW) for video calls, is calculated as:
    ETT-RC-BW = [(Number of Endpoints) + (Headroom for Growth)] x (Simultaneous Use Factor) x (Bandwidth per Endpoint)
  • The Total Site Bandwidth produced by AT&T Office@Hand traffic, TS-RC-BW is calculated as the sum of all Endpoint Type Total Bandwidth numbers.
  • The calculated TS-RC-BW (Mbps) must be guaranteed in each traffic direction to/from the enterprise, both in the local enterprise site network and in the wide-area network connecting to the AT&T Office@Hand unified communication services.

An enterprise WAN link may be shared for AT&T Office@Hand and Data Traffic. In that case, the bandwidth for data traffic, TS-DATA-BW, needs to be added to the TS-RC-BW number to get the total bandwidth for the site. The TS-DATA-BW must be determined during a busy time and include headroom for data spikes and growth.

The following capacity condition must be met to ensure that the WAN link capacity is sufficient to transport AT&T Office@Hand Unified Communication traffic:

(TS-RC-BW + TS-DATA-BW) < (Enterprise Site Provisioned WAN link Capacity)

If this condition is not met, then the WAN link capacity needs to be increased. The provisioned capacity is the capacity available on the WAN link connected to the enterprise site. This may be different from the physical link capacity. As an example, a 1 Gbps fiber WAN link may be connecting to the enterprise but a port capacity of only 100 Mbps may actually be provisioned.

To avoid quality of service issues, it is good practice to track the bandwidth used on each network connection at each enterprise site.

Table 9.1 Transmit and Receive Bandwidth for Single Enterprise Site
Endpoint Category Use Case Number of Endpoints Headroom for Growth Simultaneous Use Factor Bandwidth per Endpoint Type (Mbps) Endpoint Type Total Bandwidth (MBPS)
Desk and Soft Phones Hard phone 100 0 0.5 0.1 5
Hard phone – video 2 0 1 0.65 1.3
Speaker phone 5 0 0.25 0.1 0.125
Softphone 20 0 1 0.1 2
Mobile phone on WiFi 3 0 1 0.1 3
AT&T Office@Hand Meetings Group HQ video call 5 0 1 2 10
Two-party HD video call 10 0 1 2 20
Two-party HD video call 10 0 1 0.6 6
Group audio conference 4 0 0.1 0.1 0.04
  TS-RC-BW (Mbps)=47.465

9.1  Endpoint Bandwidths

The next sections summarize bandwidths produced and consumed by each of the AT&T Office@Hand endpoint types. The bandwidth numbers can be used to calculate the capacity needed for the LAN links and ISP WAN link. 

back to Table of Contents

9.2.1 VoIP Endpoint Bandwidth

Table 9.2  states the bandwidth numbers for both the receive and transmit traffic of hard and softphones. As indicated, the numbers depend on the endpoints and the administrative codec settings enabled in the AT&T Office@Hand cloud. The numbers include packetization and Ethernet framing.

Table 9.2 Transmit and Receive Bandwidth for Hard Phones and Soft Phones and Use Cases
Endpoint Codec Transmit and Receive Bandwidth (Kbps)
Desk phone and IP Conference phone G.711 87
G.729 31
G.722 87
Opus 60-80
Video* 616
Softphone Opus 60-80
Mobile phone Opus 60-80

*For some account tiers, 2-­party extension­-to-extension video calls for Polycom VVX 601/600 and 501/500 with detachable cameras are supported. This is an on­-demand feature, which must be enabled by RingCentral Administration. A video call can be activated one­-way or in both call directions.

9.2.2 AT&T Office@Hand Meetings Bandwidth

Table 9.3  states the bandwidth numbers for both the receive and transmit traffic of AT&T Office@Hand Meetings.  As indicated, the numbers depend on the use case. 

Table 9.3 ­ Per Endpoint Transmit and Receive Bandwidth for AT&T Office@Hand Meetings Use Cases
Use Case Meetings Login Panel and Login Panel Setting Transmit Bandwidth (Kbps) Receive Bandwidth (Kbps)
Group HQ video call Settings, Video, Capture HD video not checked 600 2000
Two-party HD video call Settings, Video, Capture HD video checked 2000 2000
Two-party HQ video call Settings, Video, Capture HD video not checked 600 600
Group audio conference Start without video on AT&T Office@Hand Meeting 60-80 60-80

If a user does not join the audio portion of AT&T Office@Hand Meetings session on a computer but calls in via a separate phone connection, then no audio is transferred (transmitted/received) on the user’ s computer but video is still transferred to the computer.

As indicated in Table 9.4, AT&T Office@Hand Office Editions offer different audio and video capacities for AT&T Office@Hand Meetings sessions.

Table 9.4 ­ AT&T Office@Hand Office Editions vs AT&T Office@Hand Meetings Audio and Video Capacities
AT&T Office@Head Office Edition Max. Number of Audio Participants Max Number of Video Participants
Standard 999 4
Premium 999 100
Ultimate 999 100


back to Table of Contents

Appendix A. VLANs Configuration of Polycom Phones

General Phone Request Process for VLAN and IP Information

A Polycom IP phone can operate on a separate Voice tagged VLAN. The Ethernet Switch connected to the phone must be configured properly to use VLANs. A phone can retrieve its Voice VLAN information by four different methods:   

  • LLDP – Link Layer Discovery Protocol  
  • CDP – Cisco Discovery Protocol
  • DHCP – Dynamic Host Configuration Protocol  
  • Statically configured on the phone  

The following process is executed by Polycom phones to receive Voice VLAN information:

  1. When the phone boots, it first sends an LLDP message to the Ethernet switch requesting a VLAN ID with the Voice VLAN ID
  2. If LLDP responds with the VLAN ID, then a DHCP request for IP address and 160 Option  is sent  on the tagged Voice VLAN ID
  3. If no LLDP response occurs, then a CDP message is sent to the switch requesting Voice VLAN ID
  4. If CDP from the switch responds with V oice VLAN, a DHCP request for IP address and 160 Option is sent  on the tagged Voice VLAN
  5. If no CDP response is received, a DHCP request is sent on the Data VLAN for the Voice VLAN DHCP Option and IP information   

DHCP Server Voice VLAN Provisioning

To configure a Voice VLAN the following items need to be provisioned on the DHCP server:

  1. LLDP/CDP must be disabled on the Ethernet Switch port when using DHCP to configure the Voice VLAN.
  2. DHCP Options required by the phone that must be defined in the Data  VLAN Scope of the DHCP server (click to view the wireshark file) are:
    • 1 Subnet Mask  
    • 3 Router (Default Gateway) IP Address  
    • 6 Domain Name Server (DNS) IP address
  3. Optionally, four different DHCP options can be used to configure a Data VLAN in the DHCP Data scope.
    • One of the following options may be used (sometimes an option does not work and a different one has to be selected): Options 128, 144, 157 or 191
  4. The VLAN must be configured as VLAN­-A=x ­­–where VLAN and A must be in CAPS, x = Voice VLAN number and the semicolon behind x must be present.
    • Example: VLAN-­A=10; —  ­sets Voice VLAN to 10
  5. Define a Voice VLAN Scope with the proper IP and Options 1, 3 and 6.
  6. Optionally, the following provisioning service can be configured in Option 160 in the DHCP Voice Scope:
    • https://pp-­

Phone Voice VLAN DHCP Request-­Response Process

The VLAN request­response process including reboots is as follows:

  1. IP Phone performs DHCP request on the Data VLAN (No VLAN tagging)
  2. DHCP server responds with option to set VLAN (Example: VLAN­A=10; –sets Voice VLAN to 10)
  3. IP Phone releases previous DHCP Data VLAN IP address
  4. IP Phone reboots after receiving VLAN option
  5. IP Phone requests Voice VLAN DHCP scope (with VLAN Tagged to 10)
  6. DHCP Responds with new IP address for the V oice VLAN  
  7. Optional ­- Use Option 160 with Provisioning Service URL https://pp­
  8. Phone continues boot process  
  9. Phone contacts Provisioning Server on the Voice VLAN   

DHCP Option for Connecting to the Provisioning Service

To use any IP phone, it must be provisioned in the AT&T Office@Hand Service Portal identifying the phone’ s MAC Address. Polycom phones can be obtained in two ways:

  • Polycom phones purchased from AT&T Office@Hand are already configured with the link pointing to the AT&T Office@Hand Provisioning service. After receiving the IP address via DHCP, the phone will connect to the AT&T Office@Hand Provisioning server and provision the phone appropriately.
  • If the Polycom phone is not purchased from AT&T Office@Hand and reused from a previous VoIP deployment, then it does not have the provisioning server configured. In that case DHCP can be used to provide the AT&T Office@Hand provisioning service:
  • Create DHCP Option 160 on the DHCP Server for the IP Address scope servicing the IP Phone
  • Set DHCP Option 160 to an ASCII string equal to: https://pp­
  • Perform a factory reset of the Polycom phone via the phone display   

Polycom Boot Process – Summary

The phone boot process is summarized as:

  • LLDP to configure Voice VLAN – See switch manufacturer documentation on how to configure LLDP  for the Voice VLAN
  • CDP to configure Voice VLAN – See switch manufacturer documentation on how to configure CDP
  • DHCP Option 128, 144, 157, 191 to configure Voice VLAN
  •  VLAN­-A=10 –­­ to set Voice VLAN to 10, must be in CAPS and must end with a semi­colon, no white spaces
  • Place option in the Data DHCP Scope
  • DHCP Option 160 to configure AT&T Office@Hand Provisioning Service: https://pp­
  • Place option in the Voice DHCP scope  
  • More information can be found in the PolyCom UC Software Administration Guide   

Wireshark Trace of the DHCP Discovery Process

  • Frame 1 – IP Phone DHCP Discover: Parameter request asking for Options 191,157,144, 128 and 160  
  • Frame 2 – DHCP Offer: Option 160 (Provisioning Server) and 144 (VLAN Info) being returned  
  • Frame 5 – IP Phone sending DHCP Release: Release of old IP address on Data VLAN  
  • Frame 6 – IP Phone DHCP Discover on V oice VLAN: New Discover on the Voice VLAN requesting option 160.  
  • Frame 7 – DHCP Of fer: Option 160 for the Provisioning server   

file:  polycom dhcp boot process with vlan­2.pcapng

Appendix B: 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 AT&T Office@Hand 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.4 on Google Chrome Extensions has been refined and corrected to indicate traffic types more explicitly.
  • Table B.5 and Table B.6 cover RC Meetings Desktop and Web Clients. The previous version contained a combined table for these clients.
  • 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 8.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.
  • Table rows indicating Signaling/Media­-Secured can be ignored when the customer account is not configured by AT&T Office@Hand Provisioning for ‘ secured signaling and media’
  • 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.
  • Media in AT&T Office@Hand Meetings and Rooms indicate real-time video with embedded voice.
  • The designation ‘ random’ in the source port column indicates that the port number is randomly selected by the AT&T Office@Hand endpoint.
  • No separate ports are specified for Bridged Line Appearance (BLA) since it uses the signaling ports and standard SIP NOTIFY packets.
Table B.1  Desk Phone
Traffic Type Protocols Source Port Number Destination Port
Media RTP/UDP random 20000-64999
Media – Secured SRTP/UDP random 20000-64999
Signaling SIP/UDP random 5090
Signaling SIP/TCP random 5090, 5099**
Signaling – Secured SIP/TLS/TCP random 5096 and 5097
Network Time Service NTP/UDP random 123
LDAP Directory Service LDAP/(TLS/SSL)/TCP random 636
Provisioning HTTP/TCP and HTTPS/TCP random 443

**TCP port 5099 only needs to be opened when line sharing is used.


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


Table B.3 iOS and Android Mobile Phone Application (on Wi-Fi Network)
The following is the specific ports usage, but it’s recommended to open the port range 5090-­5099 for UDP/TCP/TLS because  new ports may be added and some ports configuration may be changed within this range.
Traffic Type Protocols Source Port Number Destination Port Number
Media RTP/UDP 4000-5000, 20000-60000 20000-64999
Media – Secured SRTP/UDP 4000-5000, 20000-60000 20000-64999
Signaling SIP/UDP and SIP/TCP 5060 or random 5090 and 5091
Signaling (IPv6 client) SIP/TCP/TLS random 5093 and 5094
Signaling – Secured SIP/TLS/TCP random 5096 and 5097
Mobile App Data Sync with
AT&T Office@Hand backend
(e.g., call log info,
presence, and voicemails)
HTTPS random 443
LDAP Directory Service LDAP/TCP random 636
Provisioning and Presence Status HTTP/TCP and HTTPS/TCP 80 AND 443 80 and 443


Table B.4 Google Chrome Extension
Traffic Type Protocols Source Port Numbers Destination Port Number
Media UDP 10000-65535 20000-64999
Signaling TCP random 8083
LDAP Directory Service LDAP/TLS/TCP random 636 and 3269
Presence Status TCP random 6182
Access Control STUN/UDP random 19302


Table B.5 AT&T Office@Hand Meetings – Desktop Client
Traffic Type Protocols Destination Port Numbers
Media  RTP/UDP and
 8801 and 8802
Media – Secured
Signaling – Secured
Access Control  STUN/UDP
3478 and 3479


Table B.6 AT&T Office@Hand Video Meetings – Desktop Client and Chrome Browser
Traffic Type Protocols Destination Port Number
Media – Secured SRTP/UDP (default) 8801-8802
Media – Secured SRTP/TLS/TCP if UDP is not available 443
Signaling – Secured WSS/HTTPS/TLS/TCP 443


back to Table of Contents

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

CloudFront Global IP List CloudFront Regional Edge IP List  
13.1 13.203.0/24