Use your browser's print or “Save as PDF” to attach this to a ticket.
For network & information-security teams
Network requirements
BSL Learning Platform — live British Sign Language classes delivered in the browser. Platform address: bsl.deafsigns.co.uk.
The short version
- Nothing is installed. The platform runs entirely in a standard browser. No plugin, extension, agent or admin rights.
- No inbound connections.Every connection is outbound from the user's browser. Nothing listens on the workstation and no port forwarding or NAT change is required.
- Port 443 is enough. Live video prefers UDP for quality, but the platform includes a Restricted network mode that relays all media over TLS on TCP 443. If opening UDP is not acceptable on your network, it does not need to be opened — see below.
- Everything is encrypted in transit. HTTPS/TLS for web traffic and DTLS-SRTP for live audio and video, which is the standard browser WebRTC stack.
Required destinations
Allow outbound access from user workstations to the following. All are TLS-encrypted.
| Host | Ports / protocol | What it is used for |
|---|---|---|
| bsl.deafsigns.co.uk | TCP 443 (HTTPS) | The learning platform itself — signing in, courses, the classroom page. |
| *.livekit.cloud | TCP 443 (HTTPS + WebSocket) | Live classroom signalling: who is in the room, slide changes, the whiteboard, chat.Signalling is a WebSocket upgrade over TLS on 443. Some inspection proxies terminate idle WebSockets — a class runs for up to two hours, so the connection must be allowed to stay open. Project host: bls-streaming-yow6nqmy.livekit.cloud |
| *.livekit.cloud | UDP 3478 and UDP 50000-60000 (preferred) — otherwise TCP/TLS 443 | The live audio and video itself.If outbound UDP cannot be opened, no exception is needed for it: the platform's Restricted network mode relays all media over TLS on TCP 443 to the same hosts. Media quality is slightly lower and latency slightly higher, but class works. |
| theagencyengineer-adcreative-thumbnails.s3.us-east-2.amazonaws.com | TCP 443 (HTTPS) | Lesson materials, slides, handouts, chat attachments and session recordings.Downloads and uploads go browser-to-storage using short-lived signed URLs. |
Optional destinations
Class works without these. Blocking them degrades convenience only.
| Host | Ports / protocol | What it is used for |
|---|---|---|
| ws-eu.pusher.com, sockjs-eu.pusher.com | TCP 443 (HTTPS + WebSocket) | Notifications and messages outside the classroom (new message badge, 'your class is starting').Not required to attend a class. Where WebSockets are blocked the client falls back automatically to ordinary HTTPS requests against the same hosts. |
| fonts.googleapis.com, fonts.gstatic.com | TCP 443 (HTTPS) | Page fonts.Cosmetic only — the platform is fully usable if these are blocked. |
If outbound UDP cannot be opened
That is a common and reasonable policy, and it is supported. The user turns on Restricted network modein the platform (Classroom → Connection check), and every media packet is then relayed over TLS on TCP 443 to the same hosts listed above. From the network's point of view it is an ordinary long-lived HTTPS connection.
Two things still matter on the HTTPS path:
- WebSocket upgrades must be permitted to the classroom host. Some web filters allow HTTPS but strip the Upgrade header, which prevents joining entirely.
- Connections must be allowed to stay open for the length of a class (up to two hours). Proxies that time out idle-looking sockets will drop users mid-lesson.
Workstation requirements
- Browser
- Google Chrome, Microsoft Edge, Firefox or Safari, kept within about a year of current. No plugin, extension or installed software is needed.
- Camera
- Needed only if the student must be seen signing — required for assessed sessions, optional otherwise. A student with no camera can still attend, watch, read live captions and use chat.
- Microphone
- Optional. Student microphones stay muted unless the tutor turns one on.
- Screen sharing
- Optional, browser-native. No software install.
- Data stored on the device
- The platform keeps a sign-in cookie plus small preference values in browser storage. Where site data is disabled by policy the platform still works; only convenience features such as restoring a half-typed chat message after a reload are lost.
Data handling, in brief
- Live audio and video are encrypted in transit (DTLS-SRTP) and are not written to the workstation.
- Sessions are recorded only when the tutor explicitly starts a recording, and participants can see that a recording is running.
- Nothing on the workstation is scanned, enumerated or uploaded. The camera and microphone are used only while the user has them switched on, and only within a class.
- Screen sharing is browser-native and always initiated by the user, who chooses what to share.
Verifying the change
After making a change, the user can confirm it from the affected workstation: sign in and open /student/connection-check. That page makes a real connection to the classroom servers and reports precisely which parts succeeded, with a copyable log to attach to the ticket.