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

This article lists network requirements and recommendations for AT&T Office@Hand.


  1. Introduction
  2. Reading Guidelines
  3. Acronyms
  4. End-to-End Quality of Service Network Requirements
  5. Network Readiness Assessment – Placeholder
  6. AT&T Office@Hand Supernets
  7. Networks
    1. VLANs
    2. SMB/SoHo Networks
    3. WiFi Networks
    4. Wide-Area Networks (WANs)
  8. Network Components and Services
    1. Enterprise Class 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
  9. 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
  10. AT&T Office@Hand Bandwidth and Network Capacity Assessment

Appendix A – VLANs Configuration of Polycom/Poly Phones
Appendix B – TCP/IP Port Tables

1. Introduction

The purpose of this document is to provide AT&T Office@Hand customers with network requirements and recommendations to ensure that cloud-based Unified Communication services operate properly. The network requirements must be followed without reservations, while recommendations are advised to be followed.

This document covers 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 6 specifies the 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 specifies QoS requirements.
    • Section 9 provides network specific NAT and firewall requirements.
    • Section 10 contains a description of LAN/WAN bandwidth and capacity requirements.
    • The appendices contain detailed information, such as VLAN configuration of Polycom/Poly phones, TCP/IP port tables, and IP Address Range for Phone Firmware upgrades.

3. Acronyms

Table 1 summarizes the acronyms used in this document.


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 Network Path Performance Requirements

The requirements stated in Table 2 below need to be satisfied in order to optimize the network path for VoIP and Video media traffic (RTP) when using AT&T Office@Hand services.

Table 2. Quality of Service Network Requirements
Network Property Requirement
Link Capacity Each link in the end-to-end path must have symmetric (bidrectional) capacity which is larger than the maximum number of simultaneous  calls and meetings, in addition to capacity for other types of non-real time traffic and growth (Section 10)
Delay < 150 ms (of one way latency)*. This translates to <300ms round-trip latency.
Packet Loss < 1%
Jitter < 30 ms

*, Appendix II

back to Table of Contents

5. Network Readiness Assessment – Placeholder

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

These networks 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 locations where unified communication services are used.

The 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 the unified communication cloud.
  • Firewall TCP/IP Ports (Section 8.6.2).
  • IP Layer DCSP packet markings (Section 9.5).

back to Table of Contents

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 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 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, meaning 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 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 cloud-based services.
  • Recommended configuration to operate Polycom/Poly phones on VLANs is described in Appendix A.

7.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 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 bridge (also called passthru) mode, and the router is configured according to the requirements in the next sections.

7.3 WiFi Networks

The achievable network performance over a WiFi 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 video applications can be used on WiFi networks provided that network performance and configuration requirements stated in this document are followed. To maximize network performance, it must be ensured that:

  1. The wired network meets the 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 Section 4.
  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.

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 the end-to-end network performance 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, AT&T Office@Hand requires that network devices and endpoints support the feature requirements and follow the recommendations stated in this section.

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

8.2 Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended in a 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 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 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 AT&T Office@Hand.

Table 4. Functions which may impair SIP signaling and/or RTP media traffic
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)
  • Web Proxy operation
  • 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 (Ethernet over microwave) network connections

These items may result in intermittent call connectivity issues (phone registration or call feature operation) and/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 resulting in non- or partially functioning call features and/or one way or no audio.
  • 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. WAN accelerators use header compression to reduce bandwidth consumption. For VoIP traffic, this can result in increased jitter.
  • Web proxies typically do not support QoS so that VoIP and video traffic and may cause an intermittent increase of latency and 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 across multiple internet connections is not supported because signaling and media for a single session must originate from the same IP address.
  • 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.

8.3 Soft-Client Endpoints

Endpoints used for soft-clients are recommended to be configured as follows:

In casse of an endpoint with multiple network connections (wired or wireless) ensure that the traffic uses only one connection.

From MS Windows, the WiFi 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.

8.4 DNS

All endpoints and services require internet-based DNS to function properly. In the case where private DNS is used, it must perform forward-lookups to internet-based DNS.

For example, endpoints rely on a DNS service to resolve the provisioning service domain name.

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

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

For proper operation of hard phones, 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 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.

8.6 Firewall Control

For security purposes, a firewall is usually present at the border of an enterprise network. If no egress filtering is performed in the network path to cloud-based communication services, then the default firewall and NAT configuration for most enterprise-grade firewalls will be sufficient to allow communication services to operate properly. However, if any egress filtering is applied in the network where unified communication services are used from, then it needs to be ensured that access is allowed based on the whitelisting Table 5.

(Section 8.6.3) and tables in 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 5 to access supporting cloud services, Fully Qualified Domains Names (FQDNs), IP addresses, and associated ports must be whitelisted:

  • Firmware updates for hard phones, software updates for soft-clients, and configuration file updates for hard and soft-clients are supported by the CloudFront service is in the Amazon cloud.
  • Softphones and mobile phones use Pubnub for presence status notifications.
  • Premium and Ultimate plans provide the ability to archive softphone messages (text, fax, and voicemail) and call recordings (automatic and on-demand) to the Box cloud ( or to an SFTP server.
  • The port column indicates the port used by the respective unified communication services.
  • It is highly recommended to whitelist the pubnub and CloudFront domain name in the firewall
    configuration instead of configuring IP addresses. As the AT&T Office@Hand cloud platform scales, the set of IP addresses may change over time which makes firewall configurations error-prone.
  • The latest set of CloudFront IP address subnets that may be used by AT&T Office@Hand can be found at Pubnub addresses can be obtained from AT&T Office@Hand upon request.
Table 5. Whitelisting of Domains and IP Addresses
Purpose Page Type /Communication
To be whitelisted
Domain/IP Address Port(s)
AT&T Office@Hand – Website Login page 443

AT&T Office@Hand Service Web

Login page 443

AT&T Office@Hand – Analytics

Login page

AT&T Office@Hand -Live Reports

Login page

Accounts Federation Portal

Login page 443

Multi-application credential portals

Login page 443

This is the express setup page where new users can set up their account (voicemail greeting, etc.)

Login page 443

Analytics portal for data stored in Germany*

Login page 443

Analytics portal for data stored in UK*

Login page 443

Analytics portal for data stored in Canada*

Login page 443

Analytics portal for data stored in US*

Login page 443

Analytics portal for data stored in Australia*

Login page 443

Status website to verify that AT&T Office@Hand service is up

Status Page 443

Web version of the AT&T Office@Hand app

Login page 443

AT&T Office@Hand app – Messaging API

App – Cloud Comm. 443

AT&T Office@Hand app – Messaging API Gateway

App – CLoud GW Comm. 443

AT&T Office@Hand app – Messaging to determine which app instance a user is located in

App – Cloud Comm. 443

AT&T Office@Hand app – Messaging cache

App – Cloud Comm. 443

AT&T Office@Hand – Messaging dump log for troubleshooting

App – Cloud Comm. 443

AT&T Office@Hand app – Messaging web hooks for pushing messages to endpoints

App – Cloud Comm. 443

AT&T Office@Hand app – Messaging gateway handler for syncing data to/from clients

App – Cloud Comm. 443

AT&T Office@Hand app – downloading files

App – Cloud Comm. 443

Office App – Secure download of files shared in messaging*

App – Cloud Comm. 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 AT&T Office@Hand cloud need to be whitelisted.

Any of these IP addresses may dynamically be selected by the AT&T Office@Hand SFTP client to connect to an enterprise SFTP server.


Telephony Client Application using the AT&T Office@Hand Connect Platform API


Production API
Development API 443

AT&T Office@Hand App (Glip)

Glip * 443

AT&T Office@Hand Video


Login Page 443
Media Servers * 443

Desktop Softphone Application & Mobile Application

Presence status, call log notifications, and voicemail notifications *
* (for newer endpoint versions)

Google Chrome Extension



Login page 443
Chrome API for plugin 443
Fonts used by Google Chrome 443
Polycom/Poly Desk Phones and Conference Phones Provisioning

Firmware Update
Cisco Desk Phones Provisioning

Firmware Update
Yealink Desk Phones Provisioning

Firmware Update

In the Purpose column:

*Not active yet

back to Table of Contents

9. 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 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, communication services traffic should be classified and treated in the contect of the enterprise network and WAN. In practice, it may only be possible to partially follow the 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 are provided 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 6 indicates the traffic classes that are distinguished for unified 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 6. 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: 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.

9.2 Practical Constraints

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

back to table of Contents

9.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 unified communication services:   

  • Multi-Band Classification  – Traffic to and from AT&T Office@Hand cloud servers is mapped according to Table 6.  
  • Dual-­Band Classification – Real-time voice and video UDP traffic and SIP TCP traffic originating from or destined to 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 7.

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 7, where 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

9.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
    • Desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding ­ EF) marking for UDP media (RTP) packets. In this way, routers in an enterprise network can prioritize VoIP media traffic over best effort data traffic.   
    • Soft endpoints (softphones, video clients, Glip, 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 9.5).
  • Media Servers ­ – Cloud media servers mark UDP traffic as DSCP 46.   
  • 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. 

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  AT&T Office@Hand 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­to­end QoS requirements are maintained (Section 8.7).

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

back to Table of Contents

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 AT&T Office@Hand 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 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). 

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 network path performance (Section 4) is 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 6 or Table 7 (depending on the selected classification method).   
  • 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.

back to Table of Contents

10. Bandwidth and Network Capacity Determination

Two methods can be used to determine the bandwidth produced by traffic on LAN and WAN links and their capacity required to carry 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.

back to Table of Contents

Appendix A. VLANs Configuration of Polycom/Poly Phones

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. When a phone boots it attempts to dynamically discover the voice VLAN by using the following (discovery) protocols in order:

  • LLDP – Link Layer Discovery Protocol  
  • CDP – Cisco Discovery Protocol
  • DHCP – Dynamic Host Configuration Protocol  
  • Statically configuration on the phone (not covered below)

Once the VLAN is determined, the phone sends out a DHCP requests on the VLAN using Option 160.

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

  1. When the phone boots, it requests a VLAN ID with an LLDP broadcast into the local network.
  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 broadcast requesting voice VLAN ID
  4. If CDP responds with Voice VLAN ID, 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. When using DHCP to configure the voice VLAN, it needs to be ensured that LLDP/CDP is not used in the same broadvast domain.
  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.
    • Options 128, 144, 157 or 191. Sometimes an option does not work and a different one has to be selected.
  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:

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 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 Voice VLAN  
  7. Optional ­- Use Option 160 with the RingCentral Provisioning Service URL https://pp­ /pp
  8. Phone continues boot process  
  9. Phone attempts to contact a provisioning server on the voice VLAN   

DHCP Option for assigning a 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/Poly phones can be obtained in two ways:

  • Polycom/Poly phones purchased from AT&T Office@Hand are already configured with the FQDN pointing to the AT&T Office@Hand Provisioning service. After receiving the IP and DNS server addresses via DHCP, the phone will connect to the AT&T Office@Hand Provisioning server and provision the phone appropriately.
  • If the Polycom/Poly phone is not purchased from AT&T Office@Hand, then it will not have the appropriate 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 scope servicing the IP Phone
  • Set DHCP Option 160 to an ASCII string equal to: https://pp­
  • Perform a factory reset of the Polycom/Poly phone via the phone display   

Polycom/Poly 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/Poly 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 Voice VLAN: New Discover on the Voice VLAN requesting option 160.  
  • Frame 7 – DHCP Offer: 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.6 on covers AT&T Office@Hand Video Desktop Clients and Chrome browser.
  • Table B.7 and Table B.8 cover AT&T Office@Hand Meetings Desktop and Web 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 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/Poly 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 AT&T Office@Hand Meetings Rooms indicate real-time video with embedded voice.
  • LDAP Directory Service traffic is not destined to AT&T Office@Hand. THe LDAP port must be opened on the firewall when the traffic traverses the public internet and a directory server resides at a different enterprise site.
  • 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, Conference and Cordless Phone
Traffic Type Protocols Destination Port
Media RTP/UDP 20000-64999
Media – Secured SRTP/UDP 20000-64999
Signaling SIP/TCP, SIP/UDP 5090, 5099**
Signaling – Secured SIP/TLS/TCP 5096 and 5098**
Network Time Service NTP/UDP 123
LDAP Directory Service LDAP/(TLS/SSL)/TCP 636
Provisioning HTTP/TCP and HTTPS/TCP 443

**Ports 5098 and 5099 only need to be opened for Busy Lamp Appearance when line sharing is used.


 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


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 Destination Port Number
Media RTP/UDP 20000-64999
Media – Secured SRTP/UDP 20000-64999
Signaling SIP/UDP and SIP/TCP 5091
Signaling (IPv6 client) SIP/TCP/TLS 5091-5098
Signaling – Secured SIP/TLS/TCP 5097
Mobile App Data Sync with
AT&T Office@Hand backend
(e.g., call log info,
presence, and voicemails)
LDAP Directory Service LDAP/TCP 636
Provisioning and Presence Status HTTP/TCP and HTTPS/TCP 80 and 443


Table B.4 Glip Mobile Application
Traffic Type Protocols Destination Port Number
Media and Signaling HTTP/TCP and HTTPS/TCP
80 and 443


Table B.5 WebRTC Telephony (Chrome Extension, AT&T Office@Hand App (Glip))
Traffic Type Protocols Destination Port Numbers
Media  UDP  20000-64999
Signaling TCP

LDAP Directory Service LDAP/TLS/TCP 636 and 3269
Presence Status TCP 6182
Access Control STUN/UDP



Table B.6 AT&T Office@Hand Video – 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


Table B.7 AT&T Office@Hand Video – Desktop Client
Traffic Type Protocols Destination Port Number

Media – Secured Signaling – Secured HTTPS/TLS/TCP
Access Control STUN/UDP
3478 and 3479


Table B.8 AT&T Office@Hand Video – Web Client
Traffic Type Protocols Destination Port Number
Media – Secured Signaling – Secured TCP/TLS


back to Table of Contents