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

  • *
  • * ( &
  • *
  • *

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

  • *
  • (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):

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

  • *

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 * and * 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 domain.

See Safelisting firewall domains for more information.

Skype for Business

The following domains are required for Skype for Business:

  • *
  • *
  • (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:

  • (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 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 or and then entering the conference ID via DTMF to join a Virtual Meeting Room (VMR)
  •<conferenceID> for example:
  • <conferenceID>@ for example: 87654321@
  • <conferenceID> for example:
  • Video URI addresses for users or VMRs, for example: or

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.