Additional firewall rules and ports information for the Pexip Service

This article provides additional information to support the main firewall rules and port requirements for the Pexip Service as described here.

It covers:

Application downloads

Companies with strict group policies may prevent the download of any application through web browsers. In this instance administrators need to package these applications into their enterprise software deployments.

Alternatively they can safelist the Pexip download domain:

  • download.vmr.vc (and/or a specific file or sub directory)

Web proxies and the Pexip web app

The Pexip Service uses standards-based WebRTC and the framework given by Google for the Pexip web app. This framework is designed to work through web proxies using secure HTTPS (443) tunneling.

By default a web proxy will only forward HTTP data and does not understand how to handle outbound media in WebRTC (i.e. TCP/UDP STUN/TURN or other real-time communication (RTC) media). Therefore, the only way to send WebRTC media through a proxy is to do HTTPS tunneling, i.e. 443 tunneling where the browser opens a secure SSL channel. This allows the browser to send WebRTC media and in most cases to bypass the proxy, as the proxy will think this is normal HTTP traffic and not try to interpret the secure HTTPS packets.

Some proxies might be set up to "break" the SSL layer (MitM, e.g. the Burp proxy). It can reject communications as the TURN request is not understood as an HTTP request. If this is the case, we cannot make changes on the Pexip side, however, the customer can in some cases make the Pexip Service (or location) trusted and have the traffic pass through.

Proxy authentication protocols:

  • Basic: supported
  • Digest, NTLM, Negotiate and Keberos authentication are not supported.

If the client site cannot traverse or bypass the proxy, the only other option is to open up the firewall with the current SIP & UDP port ranges. This is also the only way to get non-browser based clients, such as Cisco, Polycom and other standard SIP endpoints to communicate through the firewall as these require STUN/TURN/ICE firewalls and are unable to use web proxies for traversal firewalls.

SIP calling port ranges for devices not registered to the Pexip Service network

The service supports calling to and from SIP video systems that are not registered to the service network. This includes calls to and from video systems registered to other call control systems such as Pexip Infinity, Cisco Expressway, Cisco VCS, and Cisco Unified Communications Manager.

When your endpoints are hosted on your own SBC / call control system, the Pexip Service calling network requires connectivity to the IP/port announced by the SBC. This will be the public-facing leg of your SBC and normally port TCP/5061 for SIP TLS signaling (or TCP/5060 for SIP TCP).

In addition, the Pexip Service calling network needs to reach your SBC on the UDP media ports announced by your SBC (for example 36000-59999 on a Cisco VCS).

Inbound SIP calls from the service require DNS records and IP connectivity from the Pexip service calling network to the SBC or video gateway host and port that the service learns from resolving the called domain's DNS records. In practice this requires either TCP/5061 or TCP/5060 or both to be accessible from the Pexip Service calling network. Additionally, the entire UDP media port range configured locally on the SBC or video gateway also needs to be open from the Pexip Service calling network.

Outbound SIP calls to the service also require the same IP connectivity between the service calling network and SBC or video gateway that originated the outbound call to the service. In practice this requires either TCP/5061 or TCP/5060 or both to be accessible from the service calling network. Additionally, the SBC or video gateway's locally configured media port range also needs to be open from the service calling network.

Outbound calls to the service may work only briefly if the IP address and SIP signaling port (TCP/5061 or 5060) of the SBC or video gateway is not reachable from the service calling network. These problematic calls fail when the service attempts to refresh the SIP session but is not able to reach the IP address and SIP signaling port announced by the SBC or video gateway in the preceding SIP dialog.

Content sharing problems may also be observed for both inbound and outbound SIP calls to the service if the SBC or video gateway's entire UDP media port range is not open to the service calling network. SIP content video streams are negotiated via BFCP, and result in a unidirectional stream. This is in contrast to standard bidirectional audio and main video streams. The unidirectional nature of these content sharing streams can be problematic if the required firewall rules are not in place. So if a SIP video system is registered to a third-party call control and is not receiving content being shared from the service, but audio and video are working bidirectionally, it may be the SBC or video gateway's locally configured UDP media port range is not open from the service calling network.

For security policies that limit IP addresses, for the latest list of IP ranges used by the service network, refer to our firewall rules.

Inbound H.323 calling port ranges for devices not registered to the Pexip Service network

The service supports calling to rooms and subscribers from H.323 devices that are not registered to the service network. It supports inbound URI (Annex O) and IP address dialing.

Some dialing examples include:

  • Direct IP dialing to the IVR at 185.94.242.66 or meet@pexip.me and then entering the conference ID via DTMF to join a Virtual Meeting Room (VMR)
  • 185.94.242.66##<conferenceID> for example: 185.94.242.66##87654321
  • <conferenceID>@185.94.242.66 for example: 87654321@185.94.242.66
  • <conferenceID>@vmr.vc for example: 87654321@vmr.vc
  • Video URI addresses for users or VMRs, for example: person@pexip.com or person.vmr@pexip.com

The service network uses multiple gatekeepers within our PoPs for H.323 call processing. These gatekeepers use different port ranges from the endpoints and soft clients that are registered directly to the service.

  • To properly route calls geographically to the closest PoP we use some gatekeepers solely for signaling purposes (H.225/Q.931) and other gatekeepers for both signaling and media (H.245, RTP).
  • H.323 Application Layer Gateways (ALG) should be disabled on edge firewalls, routing and switching as they can negatively interfere with the processing of calls in and out of the network.
  • For H.323 devices that do not have static firewall rules configured on inbound ports, we cannot guarantee that signaling and media during calls will perform as expected.