Secure proxy prevents Zoom Web Client from loading/working

[dholbert]

STR:

1. Install the FPN Secure Proxy extension
2. Try to connect to a zoom meeting using the Zoom Web Client, by visiting https://mozilla.zoom.us/wc/join/ followed by your meeting ID

EXPECTED RESULTS:
Zoom should connect to the meeting (the first sign that things are working is it'll prompt you to choose your audio input).

ACTUAL RESULTS:
Zoom doesn't finish loading. The video area is black, and there's grayed-out controls at the bottom, and that's it.

I get "expected results" if I disconnect the FPN extension, vs. "actual results" if I have FPN connected.

I'm using Nightly 77.0a1 (2020-04-21) (64-bit) on Linux.

[motlaq0]

Ok

[bakulf]

I managed to reproduce the issue and record it. @mayhmer, do you mind taking a look?

LOG.zip

[bakulf]

@mayhemer ^

[mayhemer]

@Baku, I don't see any HTTP related problem in the log (no network error and no server error-code response). Isn't this an existing problem with webrtc not working well with the proxy? I though it was fixed by enabling tcp-only webrtc through an http(s) proxy.

@docfaraday do you know more about where to look?

Other option could be a problem with websockets, but those are known to WORK. Can anyone add nsWebSocket:5 to the list of module (MOZ_LOG) and provide a new log? thanks.

[docfaraday]

When I tested this, it did not even get as far as creating a PeerConnection, so there must have been some other error earlier unless the behavior has changed since I last looked.

[mayhemer]

I don't see any problem with websockets in the log from @Baku sent on May 2, so those are ruled out. If there is a problem with WebRTC then it's beyond my knowledge.

I don't see any http connection in the log hitting this line with onlyconnect=1. There is also no proxy failure logged. It means that proxying WebRTC through the h2 proxy as TCP is never requested. In other words - WebrtcTCPSocket::OpenWithHttpProxy was never called?

[nils-ohlmeier]

Without looking into logs: we know that WebRTC through FPN only works if the WebRTC service provides a TURN TCP server, as we can only relay TCP through HTTP proxies.
And Zoom does not provide any TURN relays at all. So it is not going to work unless Zoom starts providing TURN TCP relays.

We could potentially make this a little easier for them by looking into relaying ICE TCP through HTTP Proxies as well. But I'm not sure if Zoom would be willing to add TCP support to their servers.

Thinking about this a little more the Zoom web client has already a fallback to websockets in case the PeerConnection can't connect to Zoom's servers. I guess the easiest solution would be to get Zoom to find out why their web client apparently doesn't fall back to websockets when FPN is turned on.