Video calls blocked on a work or school network

Published 2026-10-24

On many office, campus and hotel networks a website opens, a text chat works, and yet a video call never connects or drops after a few seconds. That pattern is not random. It follows from how browsers set up real-time calls and from the rules that network owners apply. This article explains the pattern in plain language, shows how to confirm it, and lists what you can reasonably ask your administrator to change.

Why a call is different from a web page

Loading a web page or sending a chat message uses the same kind of connection as everything else on the web: a browser opens an encrypted connection to a server and exchanges text. Almost every network allows that, because without it nobody could work. A video call is different. To keep delay low, browsers send the picture and the sound over a fast, loose protocol called UDP, and they try to send it straight to the other person's browser instead of through a central server. The technology that sets this up is called WebRTC.

Before a call starts, the two browsers search for a path between them. Each possible path is an ICE candidate. The browsers prefer direct paths, then paths that use a public address learned from a STUN server, and only as a last resort a relay server, which is called TURN. MDN's documentation notes that UDP is preferred because it is faster and recovers from interruptions more easily, and that TCP candidates are generally used only when UDP is not available or is restricted in a way that makes it unsuitable. If a network blocks UDP and offers no TCP route, the browsers may find no usable path at all.

What network owners block and why

Outgoing UDP traffic. Some firewalls allow only the web ports and DNS, which is a safe default for an office and breaks direct calls. Calls then fall back to a relay, if one exists.
Connections to unfamiliar servers. A filter may allow the sites on a list and refuse everything else, including the STUN and relay servers a call service uses.
Web proxies. A proxy handles web traffic but usually cannot carry UDP, and a call that must go through a proxy loses quality or fails. RFC 8828, the document that defines how browsers handle IP addresses for WebRTC, notes that proxies typically lack UDP support, so media falls back to TCP with lower quality.
Inspection of encrypted traffic. Some organisations decrypt and re-encrypt web traffic to scan it, which can break services that do not expect it.
Device policies. On managed computers and school devices, an administrator can switch off the camera, the microphone or WebRTC entirely in the browser, and no personal setting can override that.
Time-limited or captive-portal Wi-Fi in hotels, cafes and trains, where you must accept terms first and where heavy traffic may be throttled.

Owners usually have good reasons: security, bandwidth, privacy of students and exam integrity. The goal of this article is to help you describe your problem precisely, not to bypass the rules.

How to recognise the pattern

Messages work, calls do not. In ChatLite and many other services, text can pass through a server while the call needs a path between the two browsers, so a network that blocks real-time media shows exactly this split.
The call connects but the picture freezes or the sound breaks up after a short time. This often means the call is squeezing through a restricted path.
The same call works at once on a phone hotspot or at home. That is the clearest sign that the first network is the cause and the devices are fine.
One person on a call hears the other but not the reverse. Different networks block in different directions.
The camera test passes on this site but the call does not. The camera is fine; the network is the next suspect.

Test it in two minutes

Run the free camera and microphone test on this site. If it passes, your devices and browser permissions are fine and the problem lies with the connection.
Run the WebRTC connectivity test on the troublesome network. It starts the same search that a call starts and reports whether a public address could be learned. If it finds only local addresses and the STUN servers do not answer, UDP to the internet is probably blocked.
Run it again on a phone hotspot. A good result there and a poor one on the first network confirms the diagnosis.
Turn off any VPN or proxy and repeat. A VPN can add its own limits.

Write down what you see: which test, which network, and the verdict. A short, factual report is the most useful thing you can send to the people who run the network.

What you can try yourself

Use a wired connection or a nearer access point. Congested Wi-Fi causes the same symptoms as blocking.
Close bandwidth-heavy programs, such as large downloads and cloud backups, during the call.
Switch to a voice call or turn the camera off. Audio uses far less bandwidth and survives narrower paths.
Use a phone hotspot for important calls if your organisation's policy allows it. Check the policy first; some organisations forbid bridging networks on managed devices.
Join from a phone on mobile data instead of the managed laptop.
Try another call service. Services that operate their own relay servers can connect where a service without one cannot. ChatLite relies on a direct connection, and does not guarantee that a relay server is available.

What to ask your network administrator

Administrators respond better to specific requests than to complaints. Send the test result and ask for the narrowest change that would help. Depending on the service, that may be some of the following.

Allow outgoing UDP for real-time media to the call service, or allow the service's STUN and TURN servers by name. STUN uses port 3478 by default according to RFC 8489, and STUN over TLS uses 5349.
Allow the service's relay servers over TCP, including TLS on port 443 if the service offers it. RFC 8656 specifies that a client can reach a TURN server over UDP, TCP, TLS or DTLS, which is why a relay can work on networks that only allow web traffic.
Add the service's domains to the allow list of a web filter.
Check that the managed browser policy does not disable the camera, the microphone or WebRTC for the call site.
Exclude real-time traffic from decryption and inspection when policy permits.

For ChatLite specifically, the browser tries the public STUN servers stun.l.google.com, stun1.l.google.com and stun2.l.google.com on port 19302, as the connectivity test on this site also does. Calls need a direct path between browsers, so if your network blocks that path, ChatLite messages can still reach people but calls may not connect.

A note on staying within the rules

Do not use tools meant to hide your traffic to get around a school or workplace network unless the policy allows it. Doing so can break rules, expose your organisation's data, or lock you out of an account. Ask for an exception, or do the call from a device and network where it is permitted.

About ChatLite

ChatLite shows the same pattern: messages can arrive through its server while a call needs a direct path. The WebRTC connectivity test on this site is the quickest way to see which side of that line your network is on.

References

Official documentation used to check this article. Pages are maintained by their owners and may change.

Reviewed against ChatLite's current behavior on 2026-10-24.