RingCentral Office@Hand from AT&T

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

Back to product page

Office@Hand: Network Requirements and Recommendations
Article #4364

TABLE OF CONTENTS

  1. Introduction
  2. Reading Guidelines
  3. Acronyms
  4. Unified Communications Reference Architecture
  5. End-to-end Quality of Service Network Requirements
  6. Network Readiness Assessment
  7. Office@Hand Supernets
  8. Required and Recommended Devices and Configurations
    1. DNS
    2. Tested Routers
    3. Traffic Prioritization
    4. Bandwidth Management
    5. VLANs and Subnets
    6. Unsupported Devices and Configurations
    7. Office@Hand Soft-Client Endpoints
  9. Bandwidth and LAN/WAN Link Capacity Determination
    1. VoIP Traffic Bandwidth
    2. Video Traffic Bandwidth
    3. Data Traffic Bandwidth
    4. Total Required Bandwidth
    5. LAN and WAN Link Capacity
  10. Firewall Access Control and Network Address Translation
    1. Network Address Translation
    2. Firewall TCP/IP Ports
    3. Whitelisting of Domains and Hostnames / IP Addresses
  11. References

1. Introduction

The purpose of this document is to provide Office@Hand customers with network requirements and recommendations to ensure that the Office@Hand Unified Communication services operate properly. For the successful implementation of
Office@Hand services, the network requirements are to be followed without reservation. Recommendations are advised to be followed.

These requirements include constraints for network capacity, quality of service, firewall configuration, and unsupported devices and configurations. Section 4 introduces the Office@Hand Unified Communications Reference Architecture. This
architecture can be used to understand the context of the end-to-end Quality of Service requirements (Section 5) and the network specific requirements and recommendations to meet the end-to-end requirements (Section 7 through Section 10). Section 6 describes the need to perform Network Readiness Assessment to verify and ensure that the network meets the stated network requirements.

 

2. Reading Guidelines

The following reading guidelines can be used to traverse the material:

  • For quick reading, Sections 3 through 6 can be skipped since these sections provide contextual and background information.
  • For some SMB environment routers the Configuration Guides under the link provided in Section 8.2 on the Tested Routers can be used to configure QoS settings.
  • For Enterprise and SMB environments, the network requirements and recommendations are stated in Sections 7 through 10. Section 7 specifies the Office@Hand IP Supernets which can be used to configure QoS, firewall rules,
    and selective disabling of layer 7 functions. Sections 8 through 9 provide QoS specific requirements. Section 10 captures firewall requirements.

3. Acronyms

The following acronyms are used in this document.

ACRONYMS

ACL Access Control List IPS Intrusion Prevention Protocol
ALG Application Layer Gateway ISP Internet Service Provider
ARP Address Resolution Protocol ISP-WAN-CAP Capacity required on the ISP WAN link for data plus VoIP traffic
BLA Busy Lamp Appearance ICMP Internet Control Message Protocol
BW Bandwidth ITSP Internet Telephony Service Provider
BWH-Data Headroom bandwidth for data traffic LAN Local Area Network
BWH-Video Headroom bandwidth for data traffic M-Video Expected maximum number of video calls
BWH-VoIP Headroom bandwidth for VoIP traffic M-VoIP Expected maximum number of VoIP calls
BWM-Data Maximum bandwidth needed for data traffic ms Milliseconds
BWM-Video Maximum bandwidth needed for video traffic NAT Network Address Translation
BWM-VoIP Maximum bandwidth needed for VoIP
traffic
NTP Network Time Protocol
BWR-Data Bandwidth required for date traffic plus
headroom for future growth
PoE Power over Ethernet
BWR-Total The aggregate bandwidth required for
VoIP, video, and data traffic
PSTN Public Switched Telephone Network
BWR-Video Bandwidth required for video traffic plus
headroom for future growth
QoS Quality of Service
BWR-VoIP Bandwidth required for VoIP traffic plus
headroom for future growth
RTP Real-time Protocol
DHCP Dynamic Host Configuration Protocol SBC Session Border Controller
DMZ Demilitarized Zone SIP Session Initiation Protocol
DPI Deep Packet Inspection SMB Small and Medium-sized Business
DSCP Differentiated Services Code Point SPI Stateful Packet Inspection
DSL Digital Subscriber Line TCP Transport Control Protocol
EF Expedited Forwarding UDP User Datagram Protocol
GW Gateway VLAN Virtual LAN
HD High Definition VoIP Voice over IP
HQ High Quality VQ Voice Quality
IDS Intrusion Detection System WAN Wide-Area Network
IP Internet Protocol WiFi Set of standards for wireless
communication

4. Unified Communications Reference Architecture 

The image below provides the Unified Communications Reference Architecture for Office@Hand. The top of the diagram indicates the call control function, a media server function, and carrier telephony interfaces. This functionality is
implemented in two data centers. No details are provided of this functionality, because they are not important for the customer-site requirements stated in this document. The figure provides representative sample designs of customer sites.
In terms of traffic flow, the notions of inbound and outbound are defined relative to the local customer network.

The functionality in the Reference Architecture is color-coded as follows:

  • Office@Hand provided functionality including call controller, voice and video media servers, and carrier interfaces are illustrated in orange. Note that customers sometimes retain existing desk phones, in which case it cannot be designated as Office@Hand provided.
  • Customer functionality is blue.

Firewall

Supports inbound and outbound packet filtering and network interfaces that can be of Ethernet, DSL, or cable modem type.

Router

Performs routing and packet forwarding, and may support other functions such as layer 3 bandwidth management and ICMP related functions.

Ethernet Switch

Supports frame switching and may support additional functions such as VLANs, layer 2 port control and filtering, Power over Ethernet (PoE), and Green Ethernet.

Desktop Telephone

The phones perform two main functions:

  • Call Control: Phone registration and call handling, (setup, forwarding, teardown, call progress indication, etc.)
  • Voice Signal Processing: Analog-to-digital and digital-to-analog conversion, sidetone injection, voice framing, jitter buffering, echo cancellation, speaker and microphone functionality.

Computer

A computer running Office@Hand softphone or collaboration applications (Office@Hand Meetings or Glip) may be connected directly to an Ethernet switch or WiFi network. In case a wired network is used, the computer may also be connected in series with a desk phone which, in turn, is connected to an Ethernet switch.

Unified Communications reference architecture

In general, customer network implementations are site dependent. For example, large offices will have a more advanced firewalling, routing, and switching architecture than small branch-office sites. Also, the number and type of phone is more likely to vary at larger sites. Implementation variations at customer sites include the following:

  • One or multiple ISP WAN links may be present. In the latter case, one dedicated link could be used for VoIP service and another link for data services. Failover may be implemented between both links.
  • Multiple firewalls may be present, e.g., to demarcate a DMZ.
  • The Wide Area Network interface, firewall, router, and switch may be implemented as separate functions or combinations of functions. In larger deployments, functions are often implemented as individual devices. In SMB
    environments, functions are often combined into fewer devices. An example is an all-in-one modem or cable modem which combines the WAN interface, firewall, router and switch functions. An all-in-one modem may also be
    configured to operate in bypass mode. In bypass mode, a separate firewall and router located behind the modem may be deployed to provide more advanced firewalling and routing capabilities.
  • Multiple sites may be connected into a hub-and-spoke architecture where traffic between sites always traverses the central hub. Traffic to/from the Internet may also have to pass the central hub. For redundancy purposes, the
    remote spokes may have a local Internet connection.
  • Several levels of routers or Ethernet switches may be present. This is typically the case at large enterprise site which have core switches connecting to access switches.
  • Sites may have desk phones and softphones, or a combination thereof depending on user needs.

Voice and video calls can be made between phones at a single customer site, between phones at different customer sites, or calls may connect to an ITSP or a PSTN gateway. The Call Controller registers the phones and handles call orchestration between various components. To support all these types of calls, both call control connectivity must exist between the customer network and the Office@Hand Call Controller. In addition, media path connectivity must exist between the customer network and the Office@Hand Media Server.

5. End-to-end Quality of Service Network Requirements

The requirements stated in Table 1 need to be satisfied for VoIP media traffic to get satisfactory voice quality between Office@Hand endpoints. The same requirements hold for Video over IP when using the Office@Hand Meetings application since voice is embedded in the video signal.

Table 1. Quality of Service Network Requirements
Network Property Requirement
Link Capacity Each link in the end-to-end path must have a capacity in both directions that is larger than the maximum number of simultaneous calls plus capacity added for other types of non-real-time traffic and growth  (see Section 10 for a calculation)
Delay < 150 msec (in both call directions)
Packet Loss < 1%
Jitter < 30 msec

6. Network Readiness Assessment

The end-to-end quality of service requirements stated in Section 5 can be validated by performing a network readiness assessment which determines the quality of the local customer network and the Service Provider network. Two types as network readiness assessments can be performed to assess the ability of the network to support Office@Hand communication services:

  • Snapshot Network Readiness Assessment – This assessment leverages the Capacity Test and VoIP Quality Test tools at: Knowledge Article 3080 – Office@Hand: Broadband Capacity Test Tool and Quality Test Tool. These
    tools provide an impression of network capacity and quality in the outbound direction of a customer site to the Office@Hand cloud over a time interval of a few minutes.
  • Comprehensive Network Readiness Assessment – In this case a probe is installed at the customer site. By running this probe over a longer time interval (e.g. a full business week) a much better impression is obtained of the end-to-end quality and intermediate network hop quality in both directions of the call. Targeted network improvement recommendations can be provided based on this type of assessment.

The first type of assessment can be performed by the customer but provides minimal insights into the end-to-end QoS over time. The second type of network assessment, which is recommended to minimize the likelihood of user-perceived QoS issues, requires involvement of Office@Hand Professional Services.

The requirements stated in the next sections must be implemented before a final network assessment is performed so that any major network issues are already addressed.

7. Office@Hand Supernets

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

Table 2. Office@Hand Supernets
Region Supernet
USA 104.245.56.0/21
192.209.24.0/21
199.68.212.0/22
199.255.120.0/22
208.87.40.0/22

 

Office@Hand announces these networks globally so it is highly recommended to permit all these networks at all customer locations.

The Office@Hand supernets can be used to control the following features in local customer network devices (see next section):

  • IP Layer DSCP packet markings (Section 8.3).
  • Selectively disable layer 7 device functions such as Deep Packet Inspection (Section 8.6) for UDP traffic to/from Office@Hand.
  • Firewall TCP/IP Ports (Section 10.2).

8. Required and Recommended Devices and Configurations

Office@Hand requires and recommends that a customer network and soft-client computers support a minimal set of features to ensure high-quality VoIP service. For this purpose, recommendations are provided for DNS and routers, traffic prioritization, bandwidth management, and VLAN. Unsupported or non recommended configurations are also stated.

8.1 DNS

After boot up, Office@Hand endpoints rely on a DNS server to resolve the call server domain name it obtained from the provisioning server (e.g. sip3.ringcentral.com) to its corresponding call server address.

It is important that the domain name of the call server gets resolved to an IP address within one of the supernets that is geographically close to the physical location of endpoints. Use of a single corporate DNS (e.g. country-wide or even a single global DNS) instead of a distributed DNS which resolves domains names to local IP addresses may result in longer routes to media servers which adversely impact voice quality.

Endpoints at different customer sites may be connecting to IP addresses in different supernets.

8.2 Tested Routers

In general, Enterprise class routers support most of the QoS capabilities and configuration options described in this section.

For smaller enterprises, a set of SMB class WAN routers have been validated to work properly with the Office@Hand VoIP service. The list of routers that have been tested can be found at Office@Hand Router Configuration Guide. 

8.3 Traffic Prioritization

Office@Hand desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding – EF) marking for UDP media packets. In this way, routers in a customer network can prioritize VoIP media traffic over best effort data traffic. Office@Hand soft endpoints (soft phones, Office@Hand Meetings, and Google Chrome clients) mark UDP media packets as DSCP 0. Office@Hand cloud media servers mark UDP traffic as DSCP 46.

To ensure high-priority transport of UDP media traffic by the local network to and from all types of Office@Hand endpoints (desk phones and soft clients), the following QoS configuration settings must be applied to all layer 3 devices (layer 3
switches, IP routers, and network firewalls) in the media path:

  • Outbound Direction – UDP packets sent to Office@Hand cloud servers must be marked as DSCP 46 by the layer 3 device in the private network that is closest to the Office@Hand endpoints. Subsequent layer 3 devices in the local network must maintain this marking.
  • Inbound Direction – UDP packets from Office@Hand must be remarked to DSCP 46 at the inbound edge of the network
    firewall. Subsequent layer 3 devices in the local network inbound path must maintain this marking. This is necessary because Service Providers frequently remark DSCP priority values to a non DSCP 46 value.
  • Honoring DSCP Markings – All layer 3 devices in the inbound and outbound media path must classify and forward UDP packets in accordance with their DSCP marking as high-priority traffic within the internal customer network.

By implementing a QoS policy, these UDP traffic handling behaviors has to applied to all UDP traffic originating from or destined to the Office@Hand Supernets (Section 7).

NOTE: The remote Office@Hand supernets should be used in the QoS policies and not local subnets. The latter is undesirable because desk phones and computers with soft-clients reside on different VLAN subnets (Section 8.5). Every change in the number of local subnets with Office@Hand endpoints would require a modification of the QoS policy.

NOTE: Some firewall manufacturers do not support re-marking of DSCP, but may support prioritization of packet forwarding based on source and destination IP addresses and IP address ranges.

Many (MPLS and Metro-Ethernet network service providers will provide varying levels of service (SLA). To take advantage of the higher levels of service, IP packets may have to be re-marked based to/from the service providers requirements.

8.4 Bandwidth Management

Some routers support bandwidth management which can be enabled 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 Office@Hand traffic to the number obtained from the calculation procedure provided in Section 9. If the traffic prioritization is configured according to Section 8.3 and the Office@Hand traffic exceeds the configured
bandwidth, the traffic still gets prioritized over regular data traffic although bandwidth is not guaranteed for all calls.

8.5 VLANs and Subnets

VLANs can be used as follows in combination with 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 separate from other data traffic and reduces broadcast domains. This also simplifies management of these endpoints because their IP addresses are clearly distinguishable from other device addresses.
  • Soft-Clients – Computers running Office@Hand soft-clients will usually run other applications as well. For this reason, the computer is normally connected to the default VLAN. Therefore, it is not possible to put VoIP and Video traffic for soft-clients on a dedicated VLAN.

For all types of Office@Hand endpoints and independent of their VLAN assignments, UDP traffic must be prioritized on the local network according to the rules provided in Section 8.3.

The Office@Hand VoIP solution must be put on a different subnet than an already deployed VoIP solution from a different vendor. Otherwise the network routing of the existing VoIP solution may inhibit the Office@Hand phone to reach out to the provisioning server and call servers.

8.6 Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended by the Office@Hand
Unified Communications Solution, as they are known to cause continuous or intermittent voice quality issues (contributing
to high latency, packet loss or severe jitter).

The following configurations are not supported or recommended for a Office@Hand Communications Solution:

  • Not Supported – Packet-by-packet load balancers used to route outbound VoIP traffic simultaneously across multiple WAN links.
  • Not Recommended – Satellite network connections.

Load balancers are not supported because they can cause out-of-order packet arrival at the media processors in the Office@Hand cloud. This can result in intermittent or continuous voice quality issues. such as interruption of audio and SIP messaging in Session Border Controllers (SBC). It can also result in inconsistent NAT TCP session states between customer and Office@Hand equipment.

Satellite connections introduce delays much exceeding 150 msec 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.

For proper support of the Office@Hand Unified Communications services, the functions listed in Table 3 may need to be disabled on IP devices (layer 3 switches, routers, firewalls), and Ethernet switches. Disabling the mentioned functionality
for the IP and higher layers can be limited to the Office@Hand Supernets listed in Section 7 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to Office@Hand.

Table 3. Functions to be disabled for UDP Traffic to/from Office@Hand
Layer Function
Application • Session Initiation Protocol Application Layer Gateway (SIP ALG), also referred to as
SIP Transformations
• Deep Packet Inspection (DPI)
• Application Layer Access Control
• Stateful Packet Inspection (SPI), also called Dynamic Packet Filtering
• Intrusion Detection/Intrusion Prevention System (IDS/IPS)
• WAN Acceleration
Transport • Port filtering
IP • Packet-by-packet load balancing across multiple Service Providers links
IP & Data Link • Auto-QoS, when used in combination with Polycom phones
• Dynamic ARP Inspection
Physical • Green Ethernet

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

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 an advanced
networking devices but may be substantial for SMB and SoHo devices.

  • Any of the Application layer functions may cause signaling or UDP media quality issues. For example, IDS/IPS 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 (see e.g. https://support.sonicwall.com/kb/sw10399).
  • Packet-by-packet load balancing may cause increased jitter and out-of-order packet arrival at the receiving media processor in the Office@Hand cloud. This may result in increased packet loss.
  • 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.

8.7 Office@Hand Soft-Client Endpoints

Computers used for Office@Hand soft-clients are recommended to be configured as follows:

Runtime Priority

The Office@Hand Desktop app’s runtime priority is set to Normal at installation time. In case of computer attributable voice quality issues, the runtime priority can be increased as follows in Windows 8.1 and Windows 10. Note that this setting does not get retained upon execution of a computer reboot.

  1. On your Windows computer, press Alt+Ctrl+Del and select Task Manager.
  2. Select Processes.
  3. Select on Office@Hand.
  4. Right click and select Go to details.
  5. Select Softphone.exe
  6. Right click on Softphone.exe
  7. Select Set Priority.
  8. Change selection to Realtime.

LAN Interface Metric

The interface metric plus the route table metric of the wired network should be higher than for the wireless network, so that only one network at a time is selected. If the total metric is identical for both types of network interfaces, this may result in load-balancing across both interfaces and voice quality issues.

From MS Windows, the metrics can be viewed by opening a command prompt window (CMD) and entering netstat -rn. The Interface List indicates metrics in the left-hand column. The IPv4 Route Table shows the metric in the right-hand column. See https://superuser.com/questions/708716/set-lan-to-take-network-priority-before-wi-fion- windows-7 for more background.

Security Software

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

9. Bandwidth and LAN / WAN Link Capacity Determination

Several artifacts need to be collected to be able to calculate the bandwidth needed for VoIP, Video over IP, and data traffic at a given customer site. The results of the calculation can be used to determine the capacity needed for the LAN links and the ISP WAN link.

9.1 VoIP Traffic Bandwidth

The following procedure can be used to determine the required VoIP bandwidth across the ISP WAN link and LAN links:

  1. Determine the maximum number of simultaneous calls, M-VoIP, at the customer site. This number may be smaller than the number of telephones deployed at the customer site. Solutions used with call centers will result in a higher maximum number of simultaneous calls compared to remote office operation and may be equal to the number of deployed telephones phones. The M-VoIP number can be obtained in various ways depending on whether the VoIP solution superseded a previous (non-)VoIP solution and on the specific use of the solution:
    • Calculate the bandwidth for each call direction, BWM-VoIP, based on the maximum number of simultaneous calls as:
    • Completely New VoIP Solution: In this case, no history information is available to determine the number of voice calls that will be made from/to the site and the Office@Hand solution has not been operational long
      enough to determine the maximum number of simultaneous calls. Determine the number or hard/soft phones that will be deployed at the site or by obtaining the information from the Network Information spreadsheet filled out by the Office@Hand Account Administrator. A representative percentage of this number should give the expected maximum number of simultaneous calls that will be made to/from the site.
    • Operational Office@Hand Solution: In this case, the Office@Hand VoIP solution has been operational (ideally) for several weeks. Determine from the Office@Hand User Web Interface call log the maximum number of simultaneous calls BWM-VoIP that occur at the site by examining the call logs over a representative number of business days.
  2. Instead of or in conjunction with desk phones, Office@Hand Desktop softphone applications and mobile phone applications may be used. Normally, a single user uses only one communication endpoint at a time so that the impact on bandwidth needs to be counted only one time. Mobile apps can be used in two ways:
  3. Calculate the bandwidth for each call direction, BWM-VoIP, based on the maximum number of simultaneous calls as:
    BWM-VoIP = M-VoIP x 100 kbit/s
    NOTE: The 100 kbit/s bandwidth includes signaling and media traffic. The actual bandwidth depends on the codec used and depends on the applied administrative settings in service-officeathand.att.com. As a consequence, the
    signaling plus media traffic bandwidth varies between 35 kbit/s and 100 kbit/s. A bandwidth of 100 kbit/s can be used to simplify the calculations.
  4. Accommodate future growth of the user population at the customer site by adding some headroom (BWH-VoIP) for VoIP calls. It is useful to configure some headroom to prevent frequent changes in either Bandwidth Management or the ISP interface capacity required. Use a factor of 10% of the number of simultaneous calls in cases where the expected growth is unknown.
  5. Calculate the required bandwidth in each direction, BWR-VoIP, to carry VoIP traffic on each LAN link and the WAN link on the customer network as:
    BWR-VoIP = BWM-VoIP + BWH-VoIP

9.2 Video Traffic Bandwidth

Office@Hand Meetings users may use different communication options:

  • Two-party sessions or group sessions involving at least three parties.
  • If a user does not join the audio portion of a Office@Hand Meetings session but calls in via a separate phone connection, then no audio is transferred (transmitted/received) on the user’s PC. However, video is still transferred.

The bandwidth used for the Office@Hand Mettings application depends on the communication mode:

  • The total audio bandwidth used is similar for a phone (100 kbit/s) or PC joining (60 kbit/s) a Office@Hand Meeting session. The differences are due to the used audio codecs. For bandwidth calculations, 100 kbit/s should be used for transmit and received direction (see also group audio conferencing below).
  • Group audio conferencing:
    • Transmit: 100 kbit/s
    • Receive: 100 kbit/s
  • Two-party HQ video calls:
    • Transmit: 600kbit/s
    • Receive: 600kbit/s
  • Two-party HD video calls:
    • Transmit: 2 Mbit/s
    • Receive: 2 Mbit/s
  • Group HQ video calls:
    • Transmit: 600kbit/s
    • Receive: 2 Mbit/s

The following procedure can be used to determine the required Video over IP bandwidth across the ISP WAN link:

  1. Determine the maximum number of simultaneous video calls, M-Video, at the customer site. This number may be smaller than the number of users at the User site.
  2. Calculate the bandwidth for each call direction, BWM-Video, based on the maximum number of simultaneous calls as:
    BWM-Video = M-Video x 2.1 Mbit/s
    NOTE: The 2.1 Mbit/s bandwidth used in the calculation assumes that all users used HD video and that a separate audio connection is used for audio.
  3. Accommodate future growth of the user population at the customer site by adding some headroom (BWH-Video) for video calls. Use a factor of 10% of the number of simultaneous calls in cases where the expected growth is unknown.
  4. Calculate the required bandwidth, BWR-Video, in each direction to carry video traffic on each LAN link and the WAN link on the customer network as:
    BWR-Video = BWM-Video + BWH-Video

    Note that the Standard Office@Hand Service Plan supports Office@Hand Meetings with up to 4 users. Enterprise and Premium Office@Hand service plans support RC Meetings with up to 200 users. In both cases, if these plans are used, the calculations need to be adjusted because it has a significant impact on the bandwidth that needs to be supported by both the local network and the Service Provider network.

9.3 Data Traffic Bandwidth

The following procedure can be applied to determine the bandwidth for data traffic on each LAN/WAN link used to carry
VoIP traffic:

  1. Measure the current maximum amount of data traffic bandwidth, BWM-Data, on the physical links that are also traversed by VoIP and video traffic.
  2. Add some extra bandwidth headroom (BWH-Data) to ensure that future growth of data traffic is accommodated.
  3. Calculate the possible data traffic bandwidth on a given LAN/WAN link as:
    BWR-Data = BWM-Data + BWH-Data

9.4 Total Required Bandwidth

The total required bandwidth on LAN links and WAN link is equal to

BWR-Total = BWR-VoIP + BWR-Video = BWR-Data

Note that this number may vary per link.

9.5 LAN and WAN Link Capacity

Using the calculated total bandwidth, BWR-Total, the required capacity, ISP-WAN-CAP on the ISP WAN link at a customer site can be determined. If the required bandwidth for BWR-Total is smaller than the capacity provided by the ISP, then the ISP WAN link capacity must be increased to at least the BWR-Total to provide enough bandwidth to support all traffic.

A similar capacity assessment procedure can be used to determine the required capacity for any LAN link inside the User network which carries VoIP, video and data traffic.

10. Firewall Access Control and Network and Address Translation

For the next considerations, the notions of inbound and outbound are defined relative to the local private network. To protect the private network, it is assumed that a firewall resides at the border between the private local customer network containing the Office@Hand endpoints and the network service provider WAN.

For proper operation of the Office@Hand endpoints, a) in the network firewall a minimum Network Address Translation time out needs to be configured (Section 10.1), b) a set of inbound and outbound TCP/IP ports must be opened (Section
10.2), and c) domains need to be whitelisted (Section 10.3) to allow inbound and outbound traffic transfer for supporting the following functions or media types:

  • Telephone provisioning and registration
  • Call control (SIP signaling)
  • RTP media
  • Auxiliary services (NTP and Directory Services)
  • Office@Hand APIs
  • Google Chrome extensions

10.1 Network Address Technician

Network Address Translation/Port Address Translation functionality (generically referred to as NAT) may also be applied at the border between the private network and service provider network. The NAT function translates the 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.

Use of Network Address Translation inside the firewall impacts the firewall configuration rules stated in Section 10.3 since, in the outbound direction, the NAT function replaces addresses and port numbers at the WAN interface.

Cisco phones send a follow-up REGISTER refresh message every 4 minutes, Polycom phones every 5 minutes. NAT entry expiration timeout must be set to greater than 5 minutes to cover all Office@Hand phones.

10.2 Firewall TCP / IP Ports

To reduce configuration complexity, it is recommended to use a stateful firewall. In a stateful firewall an inbound TCP/IP port is automatically opened upon initiating outbound traffic by a Office@Hand endpoint from within the private network.
The TCP/IP port tables indicated below can be ignored when using a stateful firewall provided that all traffic types are handled in a stateful fashion.

In case a stateless firewall is used, a set of inbound and outbound TCP/IP ports must be configured manually on the firewall to allow transfer of traffic from and to Office@Hand endpoints. The next tables indicate the TCP/IP source port and
destination port numbers that are used in traffic generated by each Office@Hand endpoint. The firewall must be configured to allow outbound traffic in accordance with the port numbers provided in the table. In the inbound direction, ports must be opened by replacing destination ports with source ports and source ports with destination ports in the Tables.

The designation ‘random’ means that the source port is randomly selected by the host. A summary port table is provided at the end. No separate ports need to be opened for Busy Lamp Appearance (BLA) since it uses the signaling ports and
standard SIP NOTIFY packets.

When a stateless firewall is used, the following rules can be applied:

  • The table rows indicating secured signaling/media can be ignored when the customer account is configured for no secured signaling and media.
  • Conversely, table rows indicating non-secured signaling/media can be ignored when the customer account is configured for secured signaling and media. However, blocking non-secured traffic may require a longer time to troubleshoot.

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

Table 4. Desk Phone
Traffic Type Protocols Source Port Number Destination Port
Provisioning HTTP/TCP and
HTTPS/TCP
random

443

Signaling SIP/UDP

5060-6000

5090
Signaling SIP/TCP 5060-6000 5090
Signaling – Secured SIP/TLS/TCP 5060-6000 5096
Media RTP/UDP 16384-16482 20000-39999
Media – Secured SRTP/UDP 16384-16482 40000-49999
Network Time Service NTP/UDP random 123
LDAP Directory Service LDAP-SSL/TCP random 636

 

 Table 5. Office@Hand Desktop Softphone Application
 Traffic Type Protocols Source Port Number Destination Port Number
 Provisioning  HTTP/TCP and
HTTPS/TCP
 random  80 and 443
Signaling   SIP/TCP random  5091 
Signaling – Secured   SIP/TLS/TCP random  5097 
Media   RTP/UDP 8000-8200  50000-59999 
Media – Secured   STRP/UDP 4000-5000, 20000-60000  60000-64999 
LDAP Directory Service  LDAP-SSL/TCP random  636

 

Table 6. Google Chrome Extensions
Traffic Type Protocols Source Port Number Destination Port
Signaling and (secured)
Media
(WebRTC & STUN)
HTTP/TLS/TCP,
STUN/UDP
5060, 6182, 8080, 8083 5060, 6182, 8080, 8083

 

Table 7.
Traffic Type Protocols Source Port Number Destination Port
Provisioning  HTTP/TCP and
HTTPS/TCP
80 and 443 80 and 443
Signaling SIP/UDP 5060 5090
Signaling SIP/TCP random 5090-5091
Signaling – Secured SIP/TLS/TCP random 5097
Media RTP/UDP 4000-5000, 20000-60000 50000-59999
Media – Secured SRTP/UDP 4000-5000, 20000-60000 60000-64999
Mobile App Data Sync with
Office@Hand backend
(e.g., call log info,
presence, and voicemails)
HTTPS random 443
LDAP Directory Service LDAP/TCP random 636

 

Table 8. Office@Hand Meetings and RC Room Connector
Traffic Type Protocols Source Port Numbers Destination Port
Signaling SIP/TCP and SIP/UDP random 3000-4000
5060 and 5061
8801
Signaling SIP/TCP random 1720
Signaling – Secured SIP/TLS/TCP random 443
Media – RC Meetings RTP/UDP random 9000-10000
Media – RC Room Connector RTP/UDP random 5090-5099

 

Table 9. Summary of all Office@Hand Endpoints
Traffic Type Protocols Source Port Numbers Destination Port
Provisioning  HTTP/TCP and
HTTPS/TCP
random  80 and 433
Signaling  SIP/UDP

5060-6000

 3000-4000
5060 and 5061
8801
Signaling  SIP/TCP  5060-6000, random  1720
3000-4000
5060 and 5061
5090 and 5091
5096, 5097
8801
Signaling – Secured  SIP/TLS/TCP  5060-6000, random  443
5096 and 5097
Media  RTP/UDP  4000-5000, 8000-8200,
16384-16482, 20000-60000,
random
 5090-5099
9000-10000
20000-39999
50000-59999
Media – Secured  SRTP/UDP  4000-5000
16484-16482
20000-60000
 40000-49999
60000-64999
Signaling and Media for Chrome Extensions  HTTP/TLS/TCP,
STUN/UDP
 5060, 6182, 8080, 8083*  5060, 6182, 8080, 8083
 Network Time Service  NTP/UDP  random  123
Mobile App Data Sync  HTTPS  random  443 
LDAP Directory Service  LDAP-SSL/TCP  random  636 

*Already in Media Port range

Depending on the type of firewall, additional configuration settings must be applied per Table 10 when a deny all policy is applied on inbound or outbound traffic.

Table 10. Additional Access Control Policies
Direction Stateful Firewall Stateless Firewall
Outbound Allow all traffic to Office@Hand supernets Allow all traffic to Office@Hand supernets
Inbound No Configuration Allow all traffic from Office@Hand supernets

10.3 Whitelisting of Domains and Hostnames / IP Addresses

The following additional Access Control List (ACL) rules must be applied to control traffic from and to Office@Hand endpoints beyond the ones indicated in the tables in Section 10.2.

The following Fully Qualified Domains Names (FQDNs) and hostnames/IP addresses must be whitelisted for the indicated Office@Hand devices, applications and services, unless not used:

  • Desk Phone Provisioning Server:
    • pp.ringcentral.com
  • Desktop Softphone Application:
    • Presence status
      The next domains need to be whitelisted in the network firewall to ensure that presence status is correctly
      updated on the Office@Hand Desktop app (Softphone) Head-Up Display (HUD):

      • *.pubnub.com
      • *.pubnub.net
      • *.pndsn.com
    • Archiver
      Office Enterprise and Premium Office@Hand service plans provide the ability to archive softphone messages (text, fax, and voice mail) and call recordings (automatic and on-demand) to the Box cloud (www.box.com) or to an sftp server:

      • Box archive: it is assumed that the customer has already opened up the firewall to allow access to Box.
      • sftp server: 54.208.102.73 needs to be whitelisted
  • Office@Hand Meetings:
    • 104.245.60.128/25
    •  199.68.212.128/25
    • 199.255.120.128/25
    • 199.255.122.128/25
    • 199.255.121.0/24
    • 208.87.43.0/24
    • 185.23.248.128/25
    • 185.23.248.0/25
    • 185.23.250.128/25
    • 185.23.250.0/25
      These subnets are all located within the Office@Hand supernets
  • Office@Hand Telephony APIs for Enterprise Application Integrations:
    • api.ringcentral.com
  • Google Chrome Plugins:
    • Login to Google account: account.google.com
    • Chrome APIs for Google Chrome plugins: apis.google.com
    • Fonts used by Google Chrome: fonts.gstatic.com

NOTE: Office@Hand endpoints leverage cloud services which rely on geo-location. As a consequence a DNS lookup resolves a domain name to an IP address which depends on the geographic location and the Service Provider used to perform the lookup.

11. References

For more information on the Office@Hand Unified Communications Solutions, go to Office@Hand Advanced Solutions page.

NOTE: A PDF version of this document can be created by clicking the Printable View link at the top of this document and then saving it to a PDF file.