Network Requirements | AT&T Office@Hand
Article #91404

TABLE OF CONTENTS

1. Introduction
2. IP supernets
3. Whitelisting of domains, IP addresses, and ports
     3.1 Common cloud services
     3.2 Endpoints
          3.2.1 AT&T Office@Hand desktop, web, and mobile app
          3.2.2 AT&T Office@Hand Video mobile, desktop, and web application
          3.2.3 AT&T Office@Hand Webinar
          3.2.4 AT&T Office@Hand Video Rooms
          3.2.5 AT&T Office@Hand Video with Room Connector
          3.2.6 AT&T Office@Hand desk, conference, and cordless phones
          3.2.7 AT&T Office@Hand desktop softphone application
          3.2.8 AT&T Office@Hand mobile softphone application
     3.3 AT&T Office@Hand Archiver
     3.4 SIP trunks
     3.5 Communication integration services
4. Domain Name Service (DNS)
5. Network Address Translation (NAT)
6. Security software
7. Quality of Service guidelines
8. VLAN configuration guidelines

1. Introduction

The purpose of this document is to inform enterprises of the network requirements for firewall and web proxy configuration for cloud-based Office@Hand Unified Communication Services to operate correctly.

2. IP supernets

The supernets (concatenated subnets) in Table 2.1 are advertised by the AT&T Office@Hand cloud using the BGP routing protocol to support Unified Communication Services over the internet. These networks can be used to connect to the AT&T Office@Hand cloud over the internet.

Additional requirements apply for enterprises with private connections to the AT&T Office@Hand cloud. Please contact AT&T Office@Hand Support for more information.

To ensure that Office@Hand services operate properly, your enterprise network must accept the supernets at all locations where unified communication services are used.

These supernets must be used by the enterprise network for:

• Configuring firewall rules for signaling and media ports.
• Configuring DSCP markings in IP packet headers according to the Quality of Service Guidelines (Section 7).
• Selectively disabling Layer 7 device functions, such as Deep Packet Inspection for UDP traffic to and from the unified communication cloud (Section 7).

3. Whitelisting of domains, IP addresses, and ports

3.1 Common cloud services

You may need to whitelist the destination ports in Table 3.1.1 for all of your enterprise firewalls and web proxies. Whitelisting these ports allows devices and applications to access supporting cloud services, domain names, and IP addresses.

You should whitelist only the set of services that you need. For example, if you don’t use the Live Reports portal, you need not whitelist the live-officeathand.att.com domain.

You must always whitelist the following domains:

• The AT&T Office@Hand company website, which provides general information about AT&T and its products, and does not require login.
• The AT&T Office@Hand Administrator/User Account portal, which authenticates admin and user access to underlying communication and administration services.
• AT&T Office@Hand discovery service API, which:
  • Allows client applications to dynamically discover the correct .com and .biz API domains before a user logs in.
  • Points to the Login Process service. After the Login service authenticates an admin or user, the Discovery service API uses configured account data to determine the appropriate API domain.
• Service web portal, which provides access to administration and unified communication services.
• The Analytics portals, which provide account admins with unified communication service data about the AT&T Office@Hand system. This data can help admins understand the current state of the system, and to troubleshoot certain issues.
• The Live Reports portals, which provide access to real-time call center performance data.

Note: The Analytics and Live Reports portals may be country-specific to comply with data-locality requirements. If you only access these portals for Canadian accounts, for example, then you need only whitelist these portals’ Canadian domain names.

3.2 Endpoints

This section provides endpoint-specific tables for domain names, supernets, and a range of cloud destination ports for various types of communication services traffic, including media, signaling, and registration traffic.

The AT&T Office@Hand cloud does not initiate any session toward customer endpoints. All sessions are initiated from an endpoint toward AT&T Office@Hand’s cloud communication services.

Please note the following endpoint table guidelines for firewall and web proxy configuration:

• • The endpoint tables do not specify cloud destination ports, since port range is operating-system-dependent, and ports are dynamically selected by the operating system.
  • The tables provide modular sets of requirements for firewall control to support different mixes of AT&T Office@Hand endpoint deployments. They do not necessarily match 1:1 with AT&T Office@Hand product definitions since, for example, AT&T Office@Hand Video can be used with AT&T Office@Hand as well as a stand-alone product. For this reason, a separate table, Table 3.2.2, lists the endpoints for AT&T Office@Hand Video mobile, desktop, and web. This table factors out the specific firewall requirements for video service.
  • In creating your firewall configurations, you need only refer to the tables for the endpoints that you actually use. For example, if you don’t use hardphones, you may ignore the hardphone table.
  • Rows in the port table are generally ordered from highest QoS traffic priority (media) to lowest QoS traffic priority (supporting data service).
  • Different endpoint tables may contain the same domain names or port ranges when they are shared. As well, these duplications in different tables ensure that each endpoint can be deployed independent of other endpoint types. If you deploy multiple endpoints that require the same domain and associated ports to be whitelisted, then you need configure only one whitelist or access rule instance in the firewall.

• You may use the AT&T Office@Hand mobile app on a mobile operator network or a WiFi network.
  • On a mobile operator network on which traffic only traverses the internet to AT&T Office@Hand communication services, firewall configuration is irrelevant.
• On an enterprise WiFi network on which you’re configuring a firewall for the Office@Hand mobile app, refer to Table 3.2.1.

3.2.1 AT&T Office@Hand desktop, web, and mobile app

3.2.2 AT&T Office@Hand Video mobile, desktop, and web application

Note:

• AT&T Office@Hand Video uses the Connect platform API for user authentication and communication session control.
• The Statistics collector publishes detailed statistics about calls. The Analytics Portal (Table 3.1.1) uses a subset of the data extracted by the statistics collector.
• You don’t need to whitelist the Office@Hand video web client application if you’re only using the desktop and mobile version of the Office@Hand video app.
• You should whitelist the network connectivity test application to allow video app users to test their network connections.

3.2.3 AT&T Office@Hand Webinar

AT&T Office@Hand Webinar relies on two clients:

• Webinar host client: Used by a webinar session’s host, cohosts, and panelists.
• Webinar attendee client: Used only by webinar attendees.

For both clients, apply the whitelistings from Table 3.2.3 when configuring your enterprise firewall.

Note:

• AT&T Office@Hand Webinar is based on AT&T Office@Hand Video.
• If you’ve already whitelisted Cloudfront for the AT&T Office@Hand mobile, desktop, and web application (Section 3.2.1), then you need not whitelist it again.

3.2.4 AT&T Office@Hand Video Rooms

3.2.5 AT&T Office@Hand Video with Room Connector

You must whitelist the relevant region-independent domain name. Domain names need only be whitelisted when a Room Connector is used in the indicated region.

* Customer video devices determine whether connectivity is secured or unsecured.

3.2.6 AT&T Office@Hand desk, conference, and cordless phones

• Some third-party devices, such as the Poly IP7000 speakerphone, do not support signaling or media encryption. Such devices should be avoided in a deployment that requires complete security.
• No separate ports are specified for Busy Lamp Appearance (BLA), since BLA uses the signaling ports and standard SIP NOTIFY packets.

**Ports 5098 and 5099 should be opened for Busy Lamp Appearance only when you’re using line sharing.

3.2.7 AT&T Office@Hand desktop softphone application

3.2.8 AT&T Office@Hand mobile softphone application

Table 3.2.8 pertains to the use of the AT&T Office@Hand mobile softphone app on a WiFi network.
one Application (on Wi-Fi Network)

3.3 AT&T Office@Hand Archiver

AT&T Office@Hand Archiver is a cloud-side integration that allows administrators to copy call content to a long-term, enterprise-owned repository. Copied content includes recordings, voicemail, fax, and text messages. Archiver ensures that data is retained over a long period of time, and that it meets local data residency and regulatory retention requirements.

3.4 SIP trunks

3.5 Communication integration services

Enterprises can use Office@Hand communication integration services to develop soft-endpoint communication clients.

Table 3.5.1 summarizes the programmatic communication integration services that allow enterprises to build their own soft endpoint clients.

Note:

• You only need to whitelist the set of services that you use. For example, if you don’t use integration services, you need not whitelist that domain.
• You must whitelist the Integration service API, which is the foundation API on which all communication integration services rely.
• You must whitelist the endpoint registration service, which registers all integration services (WebRTC) endpoints with the Office@Hand Cloud Communication Service.
• The Office@Hand video scheduling service is used to create and manage video meetings.
• The Microsoft Teams (Slack) integration service integrates Office@Hand services into Teams (Slack).
• The platform APIs can be used to develop stand-alone applications (such as an outbound dialer), or applications that are embedded into existing business applications.
• You should whitelist the Stand-alone platform API and Embeddable platform API only if you actually implement applications based on these APIs.

4. Domain Name Service (DNS)

To function properly, all endpoints and services require internet-based DNS. For instance, endpoints rely on a DNS service to resolve the provisioning service domain name (e.g., pp.ringcentral.biz).

If you use private DNS, it must perform forward-lookups to internet-based DNS.

5. Network Address Translation (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 the collision of IP address spaces.

You must configure a minimum NAT timeout to ensure proper operation of hardphones:

• Cisco phones send a follow-up REGISTER refresh message every four minutes.
• Poly phones re-register every five minutes. For these phones, you must set NAT entry expiration timeout to greater than five minutes.

6. Security software

You may need to configure your cloud-based security software (network firewalls and web proxies) to whitelist the domains listed in this document’s tables.

7. Quality of Service guidelines

You must follow the Quality of Service guidelines to ensure the proper prioritization of your traffic. Otherwise, either or both parties may experience intermittent issues with call control or media quality.

8. VLAN configuration guidelines

You must follow VLAN configuration guidelines to ensure that VLANs are properly configured for hardphones (section 3.2.6).

Was this page helpful? Yes No