All critical media services are tied to these ranges. Ideally, they should go directly through any network perimeter and not through a proxy.

The hypothesis is that all GoTo Meeting traffic not going to these ranges uses plain HTTPS or WebSocket and can easily be redirected through an inspecting HTTPS proxy.

In an unrestricted network, GoTo Meeting will open a number of TCP and UDP connections to a variety of ports, some of them essential e.g., to transmit audio data and others non-essential e.g., the one for marketing pop-ups. The first eight (8) domains in the list above need to be excluded from deep packet inspection, if there are any on the network path.

If you use a VPN, there are several ways to route the different streams. The options reflect the modes listed in the table above; however, you will have to use routing to decide which traffic goes where (which makes it difficult to separate UDP from TCP traffic).

TCP traffic sent through the VPN tunnel may or may not go through a proxy after traversing through the tunnel. There are other configurations that can be discussed with the GoTo Engineering team on a case-by-case basis.

If your proxy is performing deep packet inspection, please be sure that all domains listed above are allowlisted. Deep packet inspection can impact the initial TLS connection and slow down media streams due to processing delays.

Although GoTo Meeting reads many sources for proxy configuration (e.g., system proxy, Firefox proxy, PAC files, WPAD), the proxy detection might yield unexpected results. One aspect is that the logic used to parse PAC files does not support all variations of possible rules. The other aspect is that proxies stored in the GoTo Meeting registry are sometimes used in the connection detection. As soon as GoTo Meeting finds out it can establish a connection through a stored proxy, it might also use it, although other configurations might indicate another proxy.

The easiest way to verify proxy usage is through the GoTo Meeting log file.