Firewall rules and ports for the Pexip Service

This article describes the firewall rules and port requirements for the Pexip Service. It covers:

Recommended general firewall rules

The current set of recommended general firewall rules for the Pexip Service are listed at https://pexip.me/test/firewall. Note that port 389 is a secure LDAP connection (StartTLS).

Please note that the firewall changes announced in December 2020 have now been implemented August 2021 — please see Alignment of firewall addresses on the Pexip Service for details.

Video network readiness evaluation

The Activate Endpoint app can be used to check the suitability of your network environment for registering your endpoint to the Pexip Service. The test evaluates whether your network supports the Pexip services, verifies that no firewalls will block the service, identifies any issues and explains how to resolve them. You can save the report and forward it to your IT administrator.

Here's more information on testing your network for suitability with the Pexip Service.

Safelisting domains: firewall, proxies and group policy

In certain network environments, Pexip Service domains may need to be safelisted in the group policy, web proxy or filtering corporate firewalls to allow traffic to pass without interference.

The following domains are required for the baseline Pexip Service (SIP / Pexip app / Edge services):

  • *.pexip.me
  • *.videxio.net (mpg.videxio.net & static.videxio.net)
  • *.vp.vc
  • *.vmr.vc

The following domains are required for One-Touch Join for Pexip Service:

  • *.otj.pexip.io
  • cisco-macros.pexip.io (if you have Cisco endpoints included in your One-Touch Join deployment).

When using Meeting Controls for Cisco endpoints:

  • The Cisco endpoint must be able to access port TCP/443 on Pexip's API server (as configured in the settings file): https://api-gateway.pexip.io

Administrators are also advised to keep the below rule to enable URL redirects:

  • *.videxio.com

Some web proxies may not support WebSocket (wss://) connections and break the connection to the Pexip servers. Please check vendor documentation to confirm the support status for the hardware/software versions. In these scenarios we recommend that you allow traffic to bypass the proxy inspection for the above domains.

Further Pexip app or SIP domains may be required for customers who are using a partner's white-labeled service. If you are unsure, please contact your account manager at your local certified Pexip Partner for more information.

Pexip Control Center (PCC)

To use PCC, you need to allow access to the *.vp.vc and *.pexip.io domains.

In addition, to obtain the live data that's displayed in some of the metrics cards at the top of the Overview and other pages, and various live data on the Troubleshooting page, PCC uses WebSocket. This means for you to see the live data content, your organization's network policy must allow the wss:// protocol via port 443 for the control.pexip.io domain.

See Safelisting firewall domains for more information.

Skype for Business

The following domains are required for Skype for Business:

  • *.pexip.me
  • *.vmr.vc
  • ms.videxio.com (for calling to Premium subscription endpoints from Skype for Business)

See Skype for Business requirements for use with Pexip VMRs for more information on Skype for Business as an on premises deployments.

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

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

Inbound SIP calls to the service also require the same IP connectivity between the service calling network and SBC or video gateway that originated the inbound 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.

Inbound 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 the Calling network section of the Alternative rules, limited hosts / networks to open in your Firewall page in 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 91.240.204.151 or meet@pexip.me and then entering the conference ID via DTMF to join a Virtual Meeting Room (VMR)
  • 91.240.204.151##<conferenceID> for example: 91.240.204.151##87654321
  • <conferenceID>@91.240.204.151 for example: 87654321@91.240.204.151
  • <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.

H.323 gatekeeper ports

These ports are used by the service network’s H.323 gatekeepers:

  • H.323 call signaling port: 1720 TCP
  • H.245 signaling: 33000 to 39999 TCP
  • Media port range: 11050 to 39999 UDP

For security policies that limit IP addresses, for the latest list of IP ranges used by the service network, refer to the Calling network section of the Alternative rules, limited hosts / networks to open in your Firewall tables in our page of firewall rules.