Large-scale proctoring depends on video delivery as well as analysis. The architecture needs to account for cameras, concurrent viewers, network conditions and the way recordings are preserved.
P2P and SFU address this differently. Neither model is always safer or guaranteed to work on every network.
P2P: connections between participants
In a peer-to-peer model, a participant and a reviewer can exchange media directly. Establishing a connection still uses supporting infrastructure, and some network conditions require a relay. The WebRTC documentation on TURN explains the relay case.
Multiple viewers can increase the participant’s outgoing bandwidth requirement. Actual behaviour depends on the implementation and network conditions.
SFU: forwarding streams through a server
A Selective Forwarding Unit receives media streams and forwards them to recipients. This can support several staff members viewing one session without requiring a separate direct upload from the participant to every viewer.
Jitsi Videobridge provides one explanation of this architecture. It is a reference for the principle, not a claim that TrustExam uses Jitsi.
Bandwidth, computing resources and server configuration remain constraints. An SFU does not imply unlimited viewers or compatibility with every firewall.
Live monitoring and recording
Live viewing and preserving a recording are separate tasks. Before deployment, establish where recording happens, how interruptions are handled and how upload completeness is checked.
If a selected application supports local recording segments, test available storage, upload recovery and behaviour when the application closes. A capability in one mode should not be assumed to exist on every platform.
What to compare in a pilot
Test multiple cameras and screen sharing, a reviewer and additional observer on one session, constrained upstream bandwidth, latency and packet loss. Include the institution’s real network restrictions and a short disconnect followed by recovery.
Check recording completeness and alignment with the event timeline. Separately measure the planned peak number of concurrent exams. One successful call does not establish readiness for a busy examination period.
Questions for the TrustExam team
Confirm the architecture of the chosen operating mode, network requirements, server locations and recording process. Ask to see what a degraded connection looks like to the participant and reviewer.
Record bandwidth requirements with the number of streams and video quality. A single universal speed figure without conditions can mislead deployment planning.
Frequently asked questions
Does the architecture establish confidentiality?
No. Encryption, access, processing location and retention need separate assessment.
Does choosing P2P or SFU guarantee complete recordings?
No. Recording implementation, error handling and recovery checks are also necessary.