When a user is in a developed country, at their home or using a mobile Internet connection, they may be behind a NAT router but the firewall on these devices is usually very permissive for connections initiated by the user. In the vast majority of cases, the user will be able to initiate outbound TCP connections to any destination (such as a SIP, XMPP or WebSocket server on any arbitrary port number) and will be able to send and receive UDP.

For some NAT routers, the UDP flows will only work reliably when the peer is using a public IP address. This problem is automatically detected by ICE connectivity checks and it is resolved by sending the UDP packets through the TURN server.

For users with more repressive Internet providers, in some less sophisticated wifi hotspots and in some corporate networks there are more aggressive firewall policies. With a little care, the RTC deployment can be designed to work reliably in many of these environments too.

The first issue is the signalling connection, whether it is SIP, XMPP or WebSockets. More restricted corporate networks block outgoing TCP connections, except for those on port 80 or 443, which they redirect to a transparent proxy.

As a consequence of this TCP blocking, it should be anticipated that the user's softphone may need to use the HTTP proxy for all RTC traffic, including media streaming and signalling.

HTTP Proxy servers have a number of issues. Older proxy servers do not understand the WebSocket protocol and newer proxy servers are not always configured to allow the WebSocket protocol by default. To avoid these problems, it is recommended that the WebSocket connection should always use TLS (WebRTC clients uses a wss:// URL instead of a ws:// URL) and the port 443 only. Many HTTP proxy servers are correctly configured to allow the web browser to use the HTTP CONNECT method to initiate pass-through connections to https:// URLs using the default port, 443. Sometimes, however, the HTTP proxy does not allow any port other than 443. Thanks to the encryption provided by TLS, the proxy server can not observe whether the HTTP CONNECT method is being used to reach a web server, a SIP server, a WebSocket server or even something else such as an ssh server. Therefore, all services, including SIP over TLS, XMPP client connectivity (c2s), TURN over TLS and WebSockets, should listen on port 443 so that any of them can be reached by a user stuck behind a HTTP proxy.

The next issue is the transmission of UDP. In some networks, users simply can not exchange any UDP packets with external hosts. The only resolution to this issue is to tunnel the UDP packets through TCP. Fortunately, the TURN server can also assist, as the TURN specification includes support for tunneling packets through a TLS connection. To maximize the chance of success, it is recommended that the TURN server is also configured to listen on port 443 so that the connection to the TURN server will be able to pass through HTTP proxy servers using the HTTP CONNECT method.

This strategy often requires several different processes (the standard SIP server, the XMPP c2s service, the webserver hosting a WebRTC phone, the WebSocket server and the TURN server) to all listen on the same port, 443. For multiple processes to use the same port, it is necessary to either have a different public IP address for each process or to use a solution for port multiplexing, such as the sslh daemon.

With these strategies, connectivity will be possible for the vast majority of Internet users, whether at home, at the office or on the road.