04/15/19 16:22 PM  

Network Requirements and Recommendations | RingCentral

« Go Back

Article

 
Summary
Details

Last Modified: April 2019

The current version of this article incorporates changes to reduce article length and improve readability. Also included in this update are changes to Appendix B, which expand the destination port range for the desk phone, softphone, IOS/Android mobile phone, and Chrome extension to 20000-64999. It is recommended to apply the range changes to the enterprise firewall Access Control Lists and QoS settings if destination port restrictions are applied.

Unified Communications Reference Architecture is now discussed in a separate article.
 
It is very important that you work with your IT to configure your network's settings to ensure continuous and reliable service.

To view the previous version of this document, go to RingCentral Network and Recommendations previous version
 

TABLE OF CONTENTS

 

1. Introduction
The purpose of this document is to provide RingCentral customers with network requirements and recommendations to ensure that RingCentral cloud-based unified communication services operate properly. For the successful implementation of RingCentral services, the network requirements must be followed without reservations, while recommendations are advised to be followed.

This document states constraints on network capacity, quality of service, firewall configuration, and unsupported devices and configurations. The RingCentral Unified Communications Reference Architecture can be used to understand the context of the end-to-end Quality of Service requirements (Section 4) and the network specific requirements and recommendations (Section 6 through Section 9). Section 5 describes the need to perform Network Readiness Assessment to verify and ensure that the network meets the stated requirements.
 

2. Reading Guidelines
The following reading guidelines can be used:

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

•  Section 6 specifies the RingCentral 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 for LAN / WAN bandwidth and capacity requirements. 
•  The appendices contain detailed information, such as VLAN configuration of Polycom phones, TCP/IP port tables, and IP Address Range for Phone Firmware upgrades.


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

3. Acronyms

Table 1 summarizes the acronyms used in this document:

Table 1. Acronyms

ACL

Access Control List

NAT

Network Address Translation

ALG

Application Layer Gateway

NTP

Network Time Protocol

AP

Access Point

QoS

Quality of Service

ARP

Address Resolution Protocol

RTP

Real-time Protocol

BLA

Busy Lamp Appearance

SBC

Session Border Controller

BW

Bandwidth

SIP

Session Initiation Protocol

CoS

Class of Service

SMB

Small and Medium-sized Business

DPI

Deep Packet Inspection

SoHo

Small office - Home office

DSCP

Differentiated Services Code Point

SPI

Stateful Packet Inspection

DSL

Digital Subscriber Line

SRTP

Secure Real-time Transport Protocol

EF

Expedited Forwarding

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

ms

Milliseconds

 

 

 

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

The requirements stated in Table 2 need to be satisfied for VoIP media traffic to get optimal call quality between RingCentral endpoints. The same requirements hold for Video over IP when using the RingCentral Meetings application since voice is embedded in the video signal.
 
Table 2. Quality of Service Network Requirements
Network Property
Requirement
Link Capacity
Each link in the end-to-end path must have a capacity in each direction that is larger than the maximum number of simultaneous calls plus capacity added for other types of non-real-time traffic and growth (Section 10)
Delay
< 150 ms (of one way latency)*
Packet Loss
< 1%
Jitter
< 30 ms

5. Network Readiness Assessment

The end-to-end quality of service requirements stated in Section 4 can be validated by performing a network readiness assessment, which determines the quality of the local enterprise network and the Service Provider network. Two types as network readiness assessments can be performed to assess the ability of the network to support RingCentral communication services:
 
• Snapshot Network Readiness Assessment - This assessment leverages the Capacity Test and VoIP Quality Test tools at Knowledge Article 1162: Testing your Internet Connection for RingCentral Service. These tools provide an impression of network capacity and quality in the outbound direction of an enterprise site to the RingCentral cloud over a time interval of a few minutes.

• Comprehensive Network Readiness Assessment - In this case, a probe is installed at the enterprise site. By running this probe over a longer time interval (e.g. a full business week), a much better impression is obtained of the end-to-end quality and intermediate network hop quality in both directions of the call. Targeted network improvement recommendations can be provided based on this type of assessment.

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

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

6. RingCentral Supernets

The following supernets (concatenated subnets) are owned and used by RingCentral for unified communication:
 
Table 3. RingCentral Supernets
80.81.128.0/20
103.44.68.0/22
104.245.56.0/21
185.23.248.0/22
192.209.24.0/21
199.68.212.0/22
199.255.120.0/22
208.87.40.0/22

RingCentral uses these networks globally for call servers, media services, route announcements, and auxiliary services, like telephone provisioning and network time. It is highly recommended to permit all these networks at all enterprise locations for the specific regions.

The RingCentral 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 RingCentral.
• Firewall TCP/IP Ports (Section 8.6.2).
• IP Layer DSCP packet markings (Section 9.5).
 

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

7.1 VLANs
Virtual LANs (VLANs) can be used as follows with RingCentral 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 RingCentral soft-clients will usually run other applications as well. For this reason, the computer is normally connected to the default VLAN so that VoIP and Video traffic for soft-clients does not reside on a dedicated VLAN. 

The following recommendations and requirements should be followed for VLAN implementations:

• The RingCentral 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 RingCentral cloud-based services.
• The way Polycom phones can leverage VLANs is described in Appendix A.
 

7.2. SMB/SoHo Networks
Small Medium Businesses and Small Office - Home Office (SMB/SoHo) networks are mostly connected to cable provider or Digital Subscriber Line (DSL) ISP networks. These local networks may have lower quality equipment (such as all-in-one modems) than enterprise networks. Frequently, the users on such networks also use WiFi. The combination of these factors makes it more difficult to manage the end-to-end QoS for cloud communications services. However, to maximize QoS, it is recommended to:

• Closely follow the RingCentral network requirements in this document, including the WiFi network requirements in Section 7.3.
• If an ISP provided modem is used with a separate router, the modem is configured in passthru (also called bridge) mode, and the router is configured according to the requirements in the next sections.


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

• The capabilities, settings, and physical location of WiFi Access Points (APs)
• The location of users relative to APs
• The number of users connecting to an AP
• Environmental conditions such as location, addition, and migration of objects and furniture

These factors may contribute to lower quality compared to wired network implementations.

RingCentral soft-endpoints such as desktop softphones, mobile phone applications, and RingCentral Meetings applications can be used on WiFi networks provided that QoS and configuration requirements stated in this document are followed. To maximize QoS, it must be ensured that:

a. The wired network meets the RingCentral network requirements
b. The wired network plus the WiFi leg attached to the wired network also meets the end-to-end requirements as stated in the next sections
c. The 5GHz band is used instead of the 2.4 Hz band since the former offers higher bandwidth and less interference from other equipment due to non-overlapping channels. 


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

• Every traversed WAN network segment must have sufficient quality.
• Proper mapping of prioritization tags is performed between LAN and WAN networks (Section 9.5).

8. Network Components and Services
To ensure high-quality communication service delivery, RingCentral 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.

A set of SMB class WAN routers have been validated to work properly with the RingCentral VoIP service. The list of routers that have been tested can be found at ringcentral.com/support/qos-router.html.

8.2 - Unsupported Devices and Configurations
Some types of devices, device settings, and network configurations are not supported/recommended in a RingCentral 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 RingCentral 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 RingCentral 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 RingCentral.
 

Table 4. Functions to be Disabled for UDP Traffic to/from RingCentral
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
• Energy Efficient Ethernet (a.k.a. Green Ethernet)
• Satellite network connections

Enabling these functions may result in intermittent call connectivity issues (phone registration or call feature operation) or excessive voice quality impairments (increased latency and jitter), specifically:
 
• For some of the functionality mentioned under Application Layer Functions, packet content may traverse a separate processing engine, which may result in the mentioned impairments. The impact may be minimal when using advanced networking devices but could be substantial for SMB and SoHo devices.

• Enabling SIP ALG may cause signaling issues when desk phones and softphones are used simultaneously.

• IDS/IPS functions may limit packet streams to a certain bandwidth causing intermittent audio issues across multiple calls when the number of calls exceeds a certain volume. To reduce bandwidth, WAN accelerators use header compression to reduce traffic. For VoIP traffic, this can result in increased jitter.

• Port filtering, such as UDP flood protection, may limit bandwidth thereby causing intermittent voice quality issues when many simultaneous calls occur.

• Packet-by-packet load balancing may cause increased jitter and out-of-order packet arrival at the receiving media processor in the RingCentral cloud. This may result in packet loss and intermittent or continuous voice quality issues, such as interruption of audio and SIP messaging in Session Border Controllers (SBC). It can also result in inconsistent NAT TCP session states between enterprise and RingCentral equipment.

• Use of Auto-QoS may cause voice quality issues (such as distortions or incorrect volume levels) with older Polycom speakerphones and older versions of desk phones.

• Green Ethernet is used on switch ports to save energy by automatically turning them into low power mode after they have not passed traffic for some time. This may also cause intermittent signaling and media traffic issues.

• Satellite connections introduce delays much exceeding 150 ms in each direction and, depending on the quality of the satellite connection, may also cause excessive jitter and packet loss. It depends on end-user expectations whether this is acceptable.
 

8.3 - RingCentral Soft-Client Endpoints

Computer endpoints used for RingCentral soft-clients are recommended to be configured as follows:

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

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

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

8.4 - DNS

RingCentral endpoints use several cloud-based support services:
 
• Provisioning and firmware update services for desk and conference phones.
• Call servers.
• Presence status.
 
Endpoints access these services via DNS lookup to resolve a domain name into an IP address.

For example, RingCentral endpoints rely on a DNS service to resolve the call server domain name (e.g., sip3.ringcentral.com) obtained from the provisioning service to its corresponding call server address.

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

Note that endpoints located in different RingCentral Cloud regions will, in general, connect to IP addresses in different supernets.

8.5 - NAT
Network Address Translation/Port Address Translation functionality (generically referred to as NAT) is applied at the border between two networks to translate between address spaces or to prevent collision of IP address spaces. More specifically, a NAT function translates a source (IP address, port number) pair of outbound packets into a public source (IP address, port number) pair and maintains table entries corresponding to this translation to allow inbound response traffic to return to the proper host in the private network. This is required, for example, when connecting: a) an enterprise IP network to the public Internet, or b) an enterprise network via a Layer 2 network to RingCentral via CloudConnect (RingCentral Unified Communications Reference Architecture).

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

For proper operation of the RingCentral endpoints, a minimum Network Address Translation time out needs to be configured. Cisco phones send a follow-up REGISTER refresh message every 4 minutes, Polycom phones every 5 minutes. As a consequence:
• NAT entry expiration timeout must be set to greater than 5 minutes to cover all RingCentral phones.
 
8.6 - Firewall Control
For security purposes, usually, a firewall is present at the border of an enterprise network (RingCentral Unified Communications Reference Architecture). For proper operation of the RingCentral endpoints:

• A set of inbound and outbound TCP/IP firewall ports must be opened (Appendix B. TCP/IP Port Tables).
• Domains need to be whitelisted (Section 8.6.3) to allow inbound and outbound traffic transfer for supporting RingCentral cloud services.

The ports that need to be opened and the domains that need to be whitelisted pertain to the following types of traffic and functionality:
 
• Presence status indication
• Google Chrome extensions
• RingCentral APIs
• Call control (SIP signaling)
• RTP media
• Auxiliary services: Network Time Service and Directory Services
• Telephone provisioning and registration
 

8.6.1 - Firewall Types

Two main types of firewall operation can be distinguished:
Stateful Firewall – In a stateful firewall, the associated inbound TCP/IP port is automatically opened upon initiating a TCP or UDP session in the outbound direction from the private network side.
Stateless Firewall – Session state is not maintained in the firewall, each packet transferred through the firewall is considered unrelated to any other packets that are part of the same session. This implies that, before allowing a TCP/IP session between the private and public network, the appropriate ports need to be opened first, both in the inbound and outbound direction.

Both types of firewall operation may be configurable within the same physical firewall device. Compared to stateful firewall operation, a stateless firewall generally requires more firewall administration work and may be less secure because it is more prone to administration errors. It is therefore recommended to use a stateful firewall to support RingCentral Unified Communication Services.

The high-level firewall Access Control Configuration rules indicated in Table 5 can be used in conjunction with RingCentral supernets (Section 6) and port tables (Appendix B).
 
Table 5. Additional Access Control Policies
Type of Firewall
Outbound Direction
Inbound Direction
Stateful Firewall
Allow all traffic as indicated in the port tables to all RingCentral supernets
No configuration required
Stateless Firewall
Allow all traffic as indicated in the port tables to all RingCentral supernets
Allow all traffic as indicated in the port tables in Section 8.6.2 from all supernets according to the following rules:
 
• Destination ports must be replaced by source ports.

• Source ports must be replaced by destination ports.

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

8.6.3 - Whitelisting of Domains, IP Addresses, and Ports
To allow the devices and applications indicated in Table 6 to access supporting cloud services, Fully Qualified Domains Names (FQDNs), IP addresses, and associated ports must be whitelisted:
 
• The Polycom, Cisco, and Yealink provisioning services are located in the RingCentral supernet IP address.

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

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

• RingCentral Office Premium and Ultimate plans provide the ability to archive softphone messages (text, fax, and voice mail) and call recordings (automatic and on-demand) to the Box cloud (www.box.com) or to an sftp server.
 
Table 6. Whitelisting of Domains and IP Addresses
 
Cloud Service
Domain / IP Address and Ports to be whitelisted
Domain / IP Address
Ports
RingCentral WebsiteRingCentral Web Portalwww.ringcentral.com443
RingCentral Service WebRingCentral Account Configuration Portalservice.ringcentral.com443
Polycom Desk Phones and Conference Phones
Provisioning
pp.ringcentral.com
443
Firmware Update
pp.s3.ringcentral.com
Cisco Desk Phones
Provisioning
cp.ringcentral.com
Firmware Update
cp.s3.ringcentral.com
Yealink Desk Phones
Provisioning
yp.ringcentral.com
Firmware Update
yp.s3.ringcentral.com
Desktop Softphone Application & Mobile Application
Presence, Call Log Notifications, and Voice Mail notifications
*.pubnub.com
*.pubnub.net
*.pndsn.com
80 or 443
Softphone Archiver
Box
It is assumed that the enterprise has already whitelisted the appropriate domains to allow access to Box
443
sftp
IP address of the enterprise sftp server
22
RingCentral app (Glip)Glip*.glip.com443
Google Chrome Extension
Google Account
account.google.com
443
Chrome APIs for plugins
apis.google.com
Fonts used by Google Chrome
fonts.gstatic.com
RingCentral MeetingsRingCentral Meetingsmeetings.ringcentral.com
webinar.ringcentral.com
*.zoom.us
*.cloudfront.net (for firmware software updates)**
443
Telephony Client Application using the RingCentral Connect Platform APIProduction APIplatform.ringcentral.com443
Development APIplatform.devtest.ringcentral.com

9. QoS Classification and Traffic Treatment Policies

RingCentral 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 RingCentral Cloud-based communications services. In terms of QoS, VoIP and video impose the most severe constraints on the network because delay, packet loss, and jitter QoS requirements requirement need to be met. Signaling traffic has lower QoS requirements since real-time requirements do not apply and packets can be retransmitted when lost. Other types of service traffic, such as messaging and directory services, can be treated more like data traffic.

The next sections indicate how, ideally, RingCentral communication services traffic should be classified and treated. In practice, it may only be possible to partially follow the RingCentral QoS traffic class and treatment requirements due to the limitation of endpoints, network devices, and ISP and carrier networks. Recommendations are provided to handle these sub-optimal cases as well.

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

9.1 - Traffic Classification

The left side of Table 7 indicates the traffic classes that are distinguished for RingCentral communication services, where the class requiring the highest priority treatment (VoIP Media) is indicated at the top. At Layer 2, Class of Service (COS) frame header tagging is indicated, while DSCP packet marking is available in the IP header in Layer 3. In the next considerations, tagging at Layer 2 and marking at Layer 2 is generically called marking.
 
Table 7. Traffic Types and Classification
Traffic ClassCOS
Decimal Value
DSCP
Decimal Value
NameDrop Probability
VoIP Media - Real Time546EFN/A
Video Media - Real Time434AF41Low
SIP326AF31Low
Transactional:
• Network Time Service
• Mobile App Data Sync
• LDAP Directory Service
218AF21Low
Best Effort: Phone Provisioning and firmware update00BEUndetermined
 Layer 2Layer 3

COS is a 3-bit field in the Ethernet frame header with possible values ranging from 0 to 7. DSCP is a 6-bit field in the IP packer header with possible values ranging from 0 to 63.

NOTE: End-to-end security is implemented above the IP layer, e.g. secured VoIP media is transported as SRTP/UDP/IP (SRTP is the secure version of RTP) so that security does not affect COS and DSCP values.
 

9.2 - Practical Constraints

Ideally, the COS tagging and DSCP marking values indicated in Table 7 are used across the entire network between RingCentral endpoints and cloud-based servers, and traffic is treated according to this classification, which is referred to as honoring the marking. However, in practice this is often not entirely possible because:

• Some network devices do not support sufficient QoS capabilities. Examples are low-end routers.

• COS values are often not managed in small networks.

• ISPs may change DSCP markings along the internet path, e.g. from DSCP 46 to 0.

• In large corporate enterprise networks, with sites connected to an MPLS or Metro-Ethernet network, a DSCP to COS mapping must be performed by the WAN network border devices. This mapping may not exactly maintain the COS-DCSP values indicated in Table 7. More details are provided in Section 9.7.

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

Practical requirements and recommendations for traffic classification, DSCP marking, and a description of Layer 2 WAN interconnections are provided in the next sections to address these constraints.
 

9.3 - Traffic Classification Methods

Depending on the QoS capabilities of the local network devices, one of two traffic classification methods can be implemented to support RingCentral communication services:
 
Multi-Band Classification – Traffic to and from RingCentral cloud servers is mapped according to Table 7.
Dual-Band Classification – Realtime voice and video UDP traffic and SIP TCP traffic originating from or destined to RingCentral cloud communication media servers are all classified as DCSP 46. Other traffic is classified as unprioritized data traffic with DSCP and COS value equal to 0. The dual-band classification method is indicated in Table 8.
 
Multi-band classification offers the best way to handle QoS in large corporate networks and whenever the network devices support this. Dual-band classification is relatively simple to implement and works well in most SoHO and corporate environments with devices with limited QoS capabilities. In some cases, when sufficient network capacity exists, some enterprises choose to implement a variant of the dual-band classification illustrated in Table 8, where all RingCentral traffic (e.g. media, SIP, phone provisioning, and firmware update) is classified as DSCP 46.
 
Table 8. Traffic Types and Classification
Traffic ClassCOS
Decimal Value
DSCP
Decimal Value
NameDrop Probability
VoIP Media - Real Time
Video Media - Real Time SIP
546EFN/A
Transactional:
• Network Time Service
• Mobile App Data Sync
• LDAP Directory Service
• Best Effort: Phone Provisioning and firmware update
00BEUndetermined
 Layer 2Layer 3


9.4 - Endpoint and Internet DSCP Traffic Marking Constraints
The following types of DSCP marking are applied by RingCentral endpoints, cloud media server, and Internet Service Providers:

• RingCentral Endpoints
 
• RingCentral desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding - EF) marking for UDP media packets. In this way, routers in an enterprise network can prioritize VoIP media traffic over best effort data traffic.

• RingCentral soft endpoints (softphones, RingCentral Meetings, 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).

RingCentral Media Servers - RingCentral cloud media servers mark UDP traffic as DSCP 46.

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

The RingCentral 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 RingCentral supernets must be used in the QoS policy definition.
 

9.6 - Bandwidth Management Policy
Some routers support bandwidth management, which can be used to guarantee the capacity for certain types of traffic even under saturation conditions. If routers support bandwidth management, then it is advised to enable this feature and set the bandwidth for RingCentral 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 RingCentral traffic exceeds the configured bandwidth, RingCentral traffic may still get prioritized over regular data traffic although bandwidth may not be guaranteed for all calls (depends on the router and setting). 
 

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

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

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

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

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

10. Bandwidth and LAN / WAN Link Capacity Determination
Two methods can be used to determine the bandwidth produced by RingCentral traffic on LAN and WAN links and their capacity required to carry RingCentral unified communication traffic.

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

Appendix A. VLANs Configuration of Polycom Phones 
General Phone Request Process for VLAN and IP Information

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

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


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

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

DHCP Server Voice VLAN Provisioning

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

1. LLDP/CDP must be disabled on the Ethernet Switch port when using DHCP to configure the Voice VLAN.

2. DHCP Options required by the phone that must be defined in the Data VLAN Scope of the DHCP server (click to view the wireshark file) are:

• 1 Subnet Mask
• 3 Router (Default Gateway) IP Address
• 6 Domain Name Server (DNS) IP address

3. Optionally, four different DHCP options can be used to configure a Data VLAN in the DHCP Data scope.

• One of the following options may be used (sometimes an option does not work and a different one has to be selected): Options 128, 144, 157 or 191

4. The VLAN must be configured as VLAN-A=x -- where x = Voice VLAN number. Example:

• VLAN-A=10 -set Voice VLAN to 10, VLAN-A must be with capitalized letters and must end with a semi-colon.

5. Define a Voice VLAN Scope with the proper IP and Options 1, 3 and 6.

6. Optionally, the following provisioning service can be configured in Option 160 in the DHCP Voice Scope:

• https://pp.ringcentral.com/pp
 

Phone Voice VLAN DHCP Request-Response Process

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

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

DHCP Option for Connecting to the Provisioning Service

To use any IP phone, it must be provisioned in the RingCentral Service Portal identifying the phone’s MAC Address. Polycom phones can be obtained in two ways:

• Polycom phones purchased from RingCentral are already configured with the link https://pp.ringcentral.com/pp pointing to the RingCentral Provisioning service. After receiving the IP address via DHCP, the phone will connect to the RingCentral Provisioning server and provision the phone appropriately.

• If the Polycom phone is not purchased from RingCentral and reused from a previous VoIP deployment, then it does not have the provisioning server configured. In that case DHCP can be used to provide the RingCentral provisioning service:

• Create DHCP Option 160 on the DHCP Server for the IP Address scope servicing the IP Phone
• Set DHCP Option 160 to an ASCII string equal to: https://pp.ringcentral.com/pp
• Perform a factory reset of the Polycom phone via the phone display
 

Polycom Boot Process – Summary

The phone boot process is summarized as:

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

Wireshark Trace of the DHCP Discovery Process

• Frame 1 – IP Phone DHCP Discover: Parameter request asking for Options 191,157,144, 128 and 160
• Frame 2 – DHCP Offer: Option 160 (Provisioning Server) and 144 (VLAN Info) being returned
• Frame 5 – IP Phone sending DHCP Release: Release of old IP address on Data VLAN
• Frame 6 – IP Phone DHCP Discover on 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 RingCentral endpoints. The following general properties hold for the port tables:

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

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

Table B.6 and Table B.7 cover RC Meetings Desktop and Web Clients. The previous version contained a combined table for these clients.

• The port tables are more or less organized from top to bottom according to QoS traffic prioritization, with media requiring highest priority and supporting data service traffic at the lowest priority (Section 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.

• Table rows indicating Signaling/Media-Secured can be ignored when the customer account is not configured by RingCentral Provisioning for ‘secured signaling and media'.

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

• Media in RingCentral Meetings and Rooms indicate realtime video with embedded voice.

• The designation ‘random’ in the source port column indicates that the port number is randomly selected by the RingCentral endpoint.

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

• A summary port table is provided in Table B.9. If the complete set of RingCentral endpoints is deployed at a local site, then the summary table can be used for firewall configuration instead of the individual endpoint tables. 
 

Table B.1 -  Desk Phone

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media

RTP/UDP

random

20000-64999

Media - Secured

SRTP/UDP

random

20000-64999

Signaling

SIP/UDP

random

5090

Signaling

SIP/TCP

random

5090, 5099**

Signaling - Secured

SIP/TLS/TCP

random

5096
5098

Network Time Service

NTP/UDP

random

123

LDAP Directory Service

LDAP/(TLS/SSL)/TCP

random

636

Provisioning

HTTP/TCP and HTTPS/TCP

random

443

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

Table B.2 - Desktop Softphone Application

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media

RTP/UDP

8000-8200

20000-64999

Media - Secured

STRP/UDP

4000-5000, 20000-60000

20000-64999

Signaling

SIP/TCP

random

5091

Signaling - Secured

SIP/TLS/TCP

random

5097

LDAP Directory Service

LDAP/(TLS/SSL)/TCP

random

636

Provisioning and Presence Status

HTTP/TCP and HTTPS/TCP

random

80 and 443

 

Table B.3 - iOS and Android Mobile Phone Application (on Wi-Fi Network)

The following is the specific ports usage, but it's recommended to open the port range 5090-5099 for UDP/TCP/TLS because new ports may be added and some ports configuration may be changed within this range.

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media

RTP/UDP

4000-5000, 20000-60000

20000-64999

Media - Secured

SRTP/UDP

4000-5000, 20000-60000

20000-64999

Signaling

SIP/UDP and SIP/TCP

5060 or random

5090 and 5091

Signaling (IPv6 client)

SIP/TCP/TLS

random

5093 and 5094

Signaling - Secured

SIP/TLS/TCP

random

5096 and 5097

Mobile App Data Sync with RingCentral backend
(e.g., call log info, presence, and voicemails)

HTTPS

random

443

LDAP Directory service

LDAP/TCP

random

636

Provisioning and Presence Status

HTTP/TCP and HTTPS/TCP

80 and 443

80 and 443

 

Table B.4 - Glip Mobile Application

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media and Signaling

HTTP/TCP and HTTPS/TCP
HTTP/UDP and HTTPS/UDP

80 and 443

80 and 443

 

Table B.5 -  Google Chrome Extension

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media

UDP

10000-65535

20000-64999

Signaling

TCP

random

8083

LDAP Directory Service

LDAP/TLS/TCP

random

636 and 3269

Presence Status

TCP

random

6182

Access Control

STUN/UDP

random

19302 (IP 74.125.194.127)

 

Table B.6 - RingCentral Meetings - Desktop Client

Traffic Type

Protocols

Source Port Numbers

Destination Port Numbers

Media

RTP/UDP
HTTPS/TCP

random

8801 and 8802

Media - Secured Signaling - Secured

HTTPS/TLS/TCP
HTTPS/TLS/UDP

random

443

Access Control

STUN/UDP
STUN/TCP

random

3478 and 3479

 

Table B. 7 - RingCentral Meetings - Web Client

Traffic Type

Protocols

Source Port Number

Destination Port Number

Media - Secured Signaling - Secured

TCP/TLS
UDP/TLS

random

443

 

Table B.8 - RingCentral Meetings with Room Connector (H.323 and SIP)

Traffic Type

Protocols

Source Port Numbers

Destination Port Numbers

Media

RTP/UDP

random

9000-10000

Signaling

SIP/TCP and SIP/UDP

random

3000-4000
5060

Signaling

H.323/TCP

random

1720

Signaling - Secured

SIP/TLS/TCP and
SIP/TLS/UDP

random

5061

Streaming

TCP and UDP

random

8801

Authentication and Software Update

TLS/TCP

random

80, 443


The next table provides a summary of all previous tables and can be used when all RC types of endpoints are deployed.
 

Table B.9 - Summary of all RingCentral Endpoints

Traffic Type

Protocols

Source Port Numbers

Destination Port Numbers

Media

RTP/UDP

4000-5000
8000-8200
20000-65535
random

9000-10000
20000-64999

Media - Secured

SRTP/UDP

4000-5000
20000-60000
random

20000-64999

Media and Signaling

HTTP/TCP and
HTTPS/TCP
HTTP/UDP and
HTTPS/UDP
RTP/UDP
Signaling/TCP

80 and 443
random

80 and 443
8801 and 8802

Media - Secured
Signaling - Secured

TCP/TLS
UDP/TLS

random

443

Signaling

SIP/UDP
SIP/TCP
H.323/TCP

5060
random

1720
3000-4000
5060

5090 and 5091
5093 and 5094
(IPv6)
5099**
8803

Signaling - Secured

SIP/TLS/TCP
SIP/TLS/UDP

random

5061, 5096, 5097, and 5098

Streaming

TCP and UDP

random

8801

Access Control

STUN/UDP
STUN/TCP

random

3478 and 3479
19302 (IP 74.125.194.127)

Network Time Service

NTP/UDP

random

123

Mobile App Data Sync

HTTPS

random

443

LDAP Directory Service

LDAP-TLS/TCP
LDAP-SSL/TCP
LDAP/TCP

random

636 and 3269

Provisioning and Presence Status

HTTP/TCP and
HTTPS/TCP

random

80 and 443

Presence Status

TCP

random

6182

*Already in Media Port range
**TCP port 5099 only needs to be opened when line sharing is used. 
 

Appendix C. CloudFront IP Address Range for Phone Firmware Upgrades
 

CloudFront Global IP List:

CloudFront Regional Edge IP List:

13.32.0.0/15
13.35.0.0/16
52.46.0.0/18
52.84.0.0/15
52.124.128.0/17
52.222.128.0/17
54.182.0.0/16
54.192.0.0/16
54.230.0.0/16
54.239.128.0/18
54.239.192.0/19
54.240.128.0/18
64.252.64.0/18
70.132.0.0/18
71.152.0.0/17
143.204.0.0/16
204.246.164.0/22
204.246.168.0/22
204.246.174.0/23
204.246.176.0/20
205.251.192.0/19
205.251.249.0/24
205.251.250.0/23
205.251.252.0/23
205.251.254.0/24
216.137.32.0/19
13.54.63.128/26
13.59.250.0/26
13.113.203.0/24
13.124.199.0/24
13.228.69.0/24
18.216.170.128/25
34.195.252.0/24
34.216.51.0/25
34.226.14.0/24
34.232.163.208/29
35.158.136.0/24
35.162.63.192/26
35.167.191.128/26
52.15.127.128/26
52.47.139.0/24
52.52.191.128/26
52.56.127.0/25
52.57.254.0/24
52.66.194.128/26
52.78.247.128/26
52.199.127.192/26
52.212.248.0/26
52.220.191.0/26
54.233.255.128/26

 

References

For more information on the RingCentral Unified Communications Solutions, go to success.ringcentral.com/RCSupportPortalGuidesVideos.

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.
Ranking
Was this information helpful?
Yes
No
Somewhat

Tell us why and what can we do to improve this information