The Pexip Service is using standards-based WebRTC and the framework given by Google for both MyPages and MyMeetingVideo application. This framework has been designed to work through Web Proxies using secure HTTPS (443) tunnelling. Pexip has implemented this for use in its WebRTC implementation.
A web proxy will by default only forward HTTP data and will not understand how to handle outbound media in WebRTC (ie TCP/UDP STUN/TURN or other real-time communication (RTC) media).
Therefore, the only way to do WebRTC media through a proxy is to do HTTPS tunnelling, i.e. 443 tunnelling 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 are unable to make changes on our side. However, the customer can in some cases make the Pexip Service (or location) trusted and have the traffic pass through.
Proxy Authentication Protocols:
Digest, NTLM, Negotiate and Keberos authentication are not supported.
If the client site is not able to 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 none-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.