08/03/17 00:57 AM  

RingCentral Network Requirements and Recommendations

« Go Back


SummaryWhat are the RingCentral Network Requirements and recommendations to improve phone call quality?
Last Modified: July 14, 2017


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

NOTE: This condensed version contains the same requirements as the Expanded Version of RingCentral Network Requirements and Recommendations article but does not include background on the requirements, their architectural context, or bandwidth calculations.


The following acronyms are used in this document:
ACLAccess Control ListQoSQuality of Service
ALGApplication Layer GatewayRTPReal-time Protocol
DPIDeep Packet InspectionSIPSession Initiation Protocol
DSCPDifferentiated Services Code PointSPIStateful Packet Inspection
EFExpedited ForwardingTCPTransport Control Protocol
IPInternet ProtocolUDPUser Diagram Protocol
ISPInternet Service ProviderVLANVirtual LAN
LANLocal Area NetworkVoIPVoice over IP
NTPNetwork Time ProtocolWANWide-Area Network

Required and Recommended Devices and Configurations

RingCentral requires and recommends that a customer network and soft-client computers support a minimal set of features to ensure high-quality VoIP service.

After boot up, RingCentral 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.
Tested Routers
For smaller enterprises, 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.

In general, Enterprise class routers support most of the QoS capabilities and configuration options described in the Expanded Version of RingCentral Network Requirements and Recommendations.

QoS / Traffic Prioritization
To ensure reliable media traffic transport through the local network to and from all RingCentral endpoints, routers must support and enable traffic prioritization: routers need to be configured such that VoIP and video traffic are handled with Expedited Forwarding (EF) DSCP 46.

QoS / Bandwidth Management
It is advised to set a minimum guaranteed bandwidth in accordance with the maximum number of expected phone and video calls. The required bandwidth and network link capacities can be calculated according to the procedure provided on the Expanded Version of RingCentral Network Requirements and Recommendations.

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.

Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended by the RingCentral 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 RingCentral 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 RingCentral 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 RingCentral 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 RingCentral Unified Communications services, the functions listed in Table 1 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 RingCentral Supernets listed in Table 4 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to RingCentral. 
• Session Initiation Protocol Application Layer Gateway (SIP ALG), also referred to as SIP Transformations
• Deep Packet Inspection (DPI)
• Application Layer Access Control
• Stateful Packet Inspection (SPI), also called Dynamic Packet Filtering
• Intrusion Detection/Intrusion Prevention System (IDS/IPS)
• WAN Acceleration
• Port filtering
• Packet-by-packet load balancing across multiple Service Providers links
IP & Data Link
• Auto-QoS, when used in combination with Polycom phones
• Dynamic ARP Inspection
• 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).

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 RingCentral 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 RingCentral endpoints. The next tables indicate the TCP/IP source port and destination port numbers that are used in traffic generated by each RingCentral 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 Table.

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 2. Summary of all RingCentral Endpoints
Traffic Type
Source Port Numbers
Destination Port Numbers
80 and 433
5060 and 5061
SignalingSIP/TCP5060-6000, random1720
5060 and 5061
5090 and 5091
5096, 5097
Signaling - SecuredSIP/TLS/TCP5060-6000, random443
5096 and 5097
4000-5000, 8000-8200, 16384-16482, 20000-60000, random
Media - SecuredSRTP/UDP4000-5000
Signaling and Media for Chrome ExtensionsHTTP/TLS/TCP, STUN/UDP5060, 6182, 8080, 8083*5060, 6182, 8080, 8083
Network Time ServiceNTP/UDPrandom123
Mobile App Data SyncHTTPSrandom443
LDAP Directory ServiceLDAP-SSL/TCPrandom636
*Already in Media Port range

Depending on the type of firewall, additional configuration settings must be applied per Table 3 when a deny all policy is applied on inbound or outbound traffic. 
Table 3. Additional Access Control Policies
Stateful Firewall
Stateless Firewall
OutboundAllow all traffic to RingCentral supernets
Allow all traffic to RingCentral supernets
No configuration required
Allow all traffic from RingCentral supernets
Routers and firewalls usually support an Access Control List (ACL) which can be configured to allow or deny inbound traffic based on source/destination IP address or port numbers produced by remote applications. The following inbound ACL rules may be configured in order to disable certain firewall feature such as Deep Packet Inspection (DPI). 
• For inbound traffic, the ACL must be set to the RingCentral originating source IP address ranges below.
• Avoid use of "any / any" ACL rules to prevent opening too many ports.
The following supernets (concatenated subnets) are owned and used by RingCentral for unified communication:
Table 4. RingCentral Supernets
RingCentral announces these networks globally so it is highly recommended to permit all these networks at all customer locations.

NOTE: For detailed information about RingCentral's network requirements and recommendations, you can read the Expanded Version: RingCentral Network Requirements and Recommendations.

Was this information helpful?

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