The freeze on slide 9 is not a mystery. It is a monitoring gap. By the time a remote presenter’s video stalls, the network path has usually been degrading for tens of seconds, and the signals that describe that degradation were already present in the session. The problem is that nobody was watching them before the keynote started.
This article lays out a line-test protocol for remote presenters that treats the presenter’s network path as a monitored RTP session. It uses the reception-quality vocabulary defined in the RTP and RTCP specifications, and it hands the AV or streaming operator a copyable checklist and escalation card. The goal is not to predict every failure. It is to establish a baseline before doors open, so that a mid-session change is visible against a known reference rather than against a feeling.
Why “it froze on slide 9” is a monitoring gap
RTP provides end-to-end network transport functions for real-time data such as audio and video over multicast or unicast network services, and it does not address resource reservation or guarantee quality-of-service for real-time services (RFC 3550). That is the first thing to internalize: the transport is not promising you a clean path. It is carrying sequence numbers, timestamps, and payload type information that let a receiver reconstruct timing and estimate how many packets are being lost.
The companion control protocol, RTCP, is used to monitor quality of service and to convey information about participants in an ongoing session (RFC 3550). RTCP reports are sent periodically, with the reporting interval determined by the number of synchronization sources in the session and a configured session bandwidth estimate (RFC 8083). In a typical unicast presenter-to-platform session, that interval is on the order of a few seconds, though it varies with session bandwidth and is randomized to avoid synchronization of reports from multiple receivers.
That periodicity matters for line testing. If a receiver detects the onset of congestion part way through a reporting interval, the base RTP specification contains no provision for sending an RTCP Receiver Report early; the receiver has to wait until the next scheduled reporting interval (RFC 8083). A line test that runs for only 30 seconds may capture one or two reports. A line test that runs for 10 minutes captures enough reports to see a trend.
What RTCP Receiver Reports actually carry
The RTCP Receiver Report is the diagnostic unit that matters here. It reports the fraction of packets lost in the last reporting interval, the cumulative number of packets lost, the highest sequence number received, and the inter-arrival jitter. It also carries timing information that allows the sender to estimate the network round-trip time to the receivers (RFC 8083).
Those four fields map directly onto the presenter’s experience:
- Fraction lost tells you whether the path is dropping packets right now. A rising fraction across consecutive reports is a trend, not a blip.
- Cumulative lost tells you whether the session has been degrading since it started. A high cumulative count with a low current fraction means the path recovered; a low cumulative count with a rising current fraction means the path is failing now.
- Highest sequence number received tells you whether media is still arriving at all. If this stops advancing while the session is live, media has stopped.
- Inter-arrival jitter tells you whether packets are arriving at uneven intervals. Jitter is the field that most often explains a presenter who is audible but whose slide advance feels delayed or erratic.
None of these fields tells you the cause. They tell you the symptom, and they tell you whether the symptom is getting worse. That is enough to make a decision before the keynote, and it is enough to justify an escalation during it.
The circuit-breaker vocabulary as pre-show triage
RFC 8083 defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. The document lists four RTP/AVP circuit breakers: RTCP Timeout, Media Timeout, Congestion, and Media Usability.
Those four conditions are useful as a triage vocabulary even when you are not running a standards-compliant circuit breaker. They separate four different failures that operators often lump together as “the connection is bad”:
- RTCP Timeout means feedback has stopped. The receiver is no longer reporting. This can happen when the return path fails even though the forward path is still carrying media.
- Media Timeout means media has stopped. The highest sequence number received is no longer advancing.
- Congestion means the path is overloaded. Loss and delay are rising together, and the sender needs to reduce its rate.
- Media Usability means the stream is arriving but is not usable. Packets are getting through, but the jitter or loss pattern makes the audio or video unintelligible.
When a presenter reports that their slide advance is lagging, the first question is which of these four conditions is present. If RTCP reports are still arriving and media is still flowing, you are likely in the congestion or media-usability bucket, and the fix is a rate or path change. If RTCP reports have stopped, you have a return-path problem, and the fix is different. If media has stopped, you are past the point of tuning and into failover.
A line-test protocol for the presenter’s side
The protocol below is designed to be run by the presenter with remote guidance from the AV or streaming operator. It assumes the presenter has a laptop, a conferencing client, and a way to reach the operator by phone or chat. It does not assume the presenter has packet-analysis tools.
Step 1: Run the same session profile you will use live
A line test is only useful if it runs the same session profile the keynote will use: same codec, same resolution, same bitrate, same transport. Testing a different profile produces a baseline that does not transfer. If the keynote will run at 1080p30 with a specific codec and a specific bitrate ceiling, the line test should run at that profile, not at the default the client picks on first launch.
This is the step most often skipped. A presenter who tests with a low-resolution default and then presents at high resolution has tested a different network path than the one they will use.
Step 2: Run for at least 10 minutes, at the same time of day as the keynote
RTCP reports are periodic, and the base specification does not allow a receiver to send a report early when it detects congestion (RFC 8083). A short test may capture only one or two reports. Ten minutes gives you enough reports to see a trend, and running at the same time of day as the keynote captures the network conditions that will actually be present.
If the keynote is at 09:00, test at 09:00 on a prior day. If the venue’s network load changes in the evening, a morning test will not predict an evening session.
Step 3: Record the baseline
During the test, record the following at each RTCP reporting interval, or as close to it as the client exposes:
- Fraction of packets lost in the last interval
- Cumulative packets lost
- Highest sequence number received
- Inter-arrival jitter
- Round-trip time estimate
- Timestamp of each observation
The timestamp is not optional. Without it, you cannot tell whether a change happened before or after the keynote started, and you cannot correlate it with anything else that happened in the room.
If the conferencing client does not expose these fields directly, the operator can capture the session traffic and inspect it with a packet analyzer. Wireshark’s documentation includes a Display Filter Reference covering all of Wireshark’s display filters, which is the reference to use when constructing filters for RTCP analysis.
Step 4: Identify the reporting interval
Record how often RTCP reports arrive during the test. This is your observation cadence for the live session. If reports arrive every 5 seconds, you will see a change within 5 seconds of it happening, plus the time it takes for the report to reach you. If reports arrive every 15 seconds, your detection latency is longer, and your escalation thresholds should account for that.
This is also the reason a line test should not be judged on a single report. One report is a snapshot. The interval between reports is the resolution of your monitoring.
Step 5: Compare the baseline to the live session
When the keynote starts, the same fields should be observed at the same cadence. The baseline is the reference. A change is meaningful when it is visible against that reference, not when it crosses an absolute threshold that may not apply to this path.
This is where the circuit-breaker vocabulary becomes operational. If the highest sequence number received stops advancing, you are in Media Timeout. If RTCP reports stop arriving, you are in RTCP Timeout. If loss and jitter are rising together, you are in Congestion. If media is arriving but the presenter’s audio or video is unusable, you are in Media Usability.
Escalation card: ordered by reversibility
The escalation card should be ordered by reversibility. The first step should be the one that is easiest to undo. The last step should be the one that changes the session in a way that cannot be quickly reversed.
- Reduce load. Lower the resolution or bitrate. This is reversible and can be done without changing the path. It addresses congestion and media usability without touching the network.
- Switch path. Move the presenter from Wi-Fi to a wired connection, or from one network to another. This is reversible if the original path is still available, but it requires the presenter to have a second path ready.
- Fall back to audio-only. If video is the problem and audio is still usable, dropping video reduces the load on the path and keeps the presenter audible. This is reversible if the path recovers.
- Stop the media flow. This is the circuit-breaker action. It protects the network from excessive congestion, but it ends the presenter’s participation in the session as a live media source. It should be the last step, and it should be paired with a pre-recorded segment or a moderator-led transition.
The operator should know which step is which before the session starts. The presenter should know which steps they can take without waiting for the operator. The moderator should know what happens to the agenda when each step is taken.
Rehearsing failover
A failover that has not been rehearsed is not a failover. It is a hope. The rehearsal should cover three things:
- Path switch. The presenter disconnects from the primary path and reconnects on the backup. The operator confirms that media and RTCP reports resume. The time from disconnect to resume is recorded.
- Audio-only fallback. The presenter disables video. The operator confirms that audio continues and that the slide advance still works. The time from decision to confirmation is recorded.
- Pre-recorded segment. The moderator plays the pre-recorded segment. The operator confirms that the transition is clean and that the presenter’s audio is muted. The time from decision to playback is recorded.
Each rehearsal produces a number: how long the failover takes. That number belongs on the escalation card, because it tells the moderator how much time to fill.
What to capture for the post-mortem
If the session does degrade, the post-mortem needs telemetry, not recollection. The following should be captured during load-in and retained:
- The baseline RTCP fields from the line test, with timestamps
- The live-session RTCP fields, with timestamps
- The reporting interval observed during both
- The time of each escalation step taken
- The time of each failover rehearsal, if one was run
- The session profile used in both the test and the live session
This is enough to answer the question that matters: did the path change, did the load change, or did the session profile change? Without timestamps, the answer is a guess.
A hypothetical example
Consider a presenter on hotel Wi-Fi who runs a 10-minute line test at the same time of day as the keynote. The baseline shows a stable fraction lost, a slowly advancing cumulative count, a steadily advancing highest sequence number, and low inter-arrival jitter. The reporting interval is 5 seconds.
During the keynote, the operator observes jitter rising across three consecutive reports while the fraction lost also rises. The highest sequence number is still advancing, so media has not stopped. RTCP reports are still arriving, so the return path is intact. This is the congestion bucket.
The operator reduces the presenter’s bitrate. The next two reports show jitter and loss returning toward the baseline. The keynote continues. No failover is needed, and the post-mortem has a timestamped record of what changed and when.
This is a hypothetical scenario, not a report of a specific event. It illustrates how the protocol produces a decision rather than a diagnosis by feel.
Copyable artifact: remote-presenter line-test checklist and escalation card
The following is intended to be copied into the operator’s runbook or the presenter’s pre-show packet. It is written for the AV or streaming operator, with presenter-facing steps marked.
REMOTE-PRESENTER LINE-TEST CHECKLIST
Role: AV / Streaming Operator
Presenter: ______________________
Session date/time: ______________________
BEFORE THE TEST
[ ] Confirm the live session profile: codec, resolution, bitrate, transport
[ ] Confirm the presenter's primary path and backup path
[ ] Confirm the operator's contact channel with the presenter
[ ] Confirm the moderator's contact channel with the operator
DURING THE TEST (10 minutes minimum, same time of day as keynote)
[ ] Presenter joins using the live session profile
[ ] Operator records at each RTCP reporting interval:
- Timestamp
- Fraction of packets lost in the last interval
- Cumulative packets lost
- Highest sequence number received
- Inter-arrival jitter
- Round-trip time estimate
[ ] Operator records the observed reporting interval
[ ] Operator notes any change in the trend, not just the value
AFTER THE TEST
[ ] Baseline recorded and stored with timestamps
[ ] Reporting interval recorded
[ ] Session profile recorded
[ ] Backup path confirmed available
[ ] Failover rehearsal scheduled or completed
DURING THE LIVE SESSION
[ ] Operator observes the same fields at the same cadence
[ ] Operator compares each observation to the baseline
[ ] Operator identifies the circuit-breaker condition:
[ ] RTCP Timeout - feedback has stopped
[ ] Media Timeout - media has stopped
[ ] Congestion - loss and delay rising together
[ ] Media Usability - media arriving but unusable
ESCALATION CARD (ordered by reversibility)
1. Reduce load: lower resolution or bitrate
- Reversible: yes
- Who decides: operator, with presenter informed
- Time to effect: ______
2. Switch path: move to wired or backup network
- Reversible: yes, if original path still available
- Who decides: operator, with presenter executing
- Time to effect: ______
3. Fall back to audio-only: disable video
- Reversible: yes, if path recovers
- Who decides: operator, with presenter informed
- Time to effect: ______
4. Stop the media flow: circuit-breaker action
- Reversible: no, within the session
- Who decides: operator, with moderator informed
- Time to effect: ______
- Paired action: pre-recorded segment or moderator-led transition
POST-MORTEM CAPTURE
[ ] Baseline RTCP fields with timestamps
[ ] Live-session RTCP fields with timestamps
[ ] Reporting interval for both
[ ] Time of each escalation step
[ ] Time of each failover rehearsal
[ ] Session profile for both test and live session
Frequently asked questions
Can I run this line test without access to RTCP data?
You can run the presenter-facing steps without RTCP data, but you lose the trend analysis. The presenter can still confirm that the session profile is correct, that the test runs for 10 minutes at the right time of day, and that the backup path is available. The operator can still capture packet-level data with a packet analyzer if the client does not expose RTCP fields. Wireshark’s Display Filter Reference is the starting point for constructing filters.
What if the conferencing client does not expose RTCP fields?
Capture the session traffic and inspect it with a packet analyzer. The RTCP Receiver Report fields are defined in RFC 3550 and RFC 8083, so the fields are present in the traffic even if the client does not surface them in its interface. The operator needs a capture point on the presenter’s side or on the platform’s side, depending on where the analysis is being done.
How long should the line test run?
At least 10 minutes, at the same time of day as the keynote. The minimum is driven by the RTCP reporting interval: the base specification does not allow a receiver to send a report early when it detects congestion (RFC 8083), so a short test may capture only one or two reports. Ten minutes gives you enough reports to see a trend.
What if the baseline itself is bad?
If the baseline shows rising loss or jitter during the test, the path is not viable for the live session at that profile. The options are to change the path, change the profile, or change the time of day. The line test is doing its job if it surfaces this before the keynote rather than during it.
Does this protocol require a specific conferencing platform?
No. The protocol is built on the RTP and RTCP vocabulary defined in RFC 3550 and RFC 8083, which are transport-level specifications. The specific fields available to the operator depend on what the platform exposes, but the diagnostic categories and the escalation order are platform-independent.
How does this relate to the room-to-chat handoff?
The room-to-chat handoff is a different failure mode: it is about what happens when a remote presenter’s contribution needs to be carried into the in-room or chat experience. The line-test protocol here is about the presenter’s network path before and during the session. If your event has a hybrid component, the handoff is worth reading alongside this protocol; see Why Hybrid Events Fall Apart at the Room-to-Chat Handoff.
What this protocol does not do
It does not predict every failure. It does not replace a redundant path. It does not tell you the cause of a degradation; it tells you the symptom and whether it is getting worse. It does not guarantee that a presenter on a hotel network will have a clean session, because RTP does not guarantee quality-of-service for real-time services (RFC 3550).
What it does is give the operator a baseline, a vocabulary, and an ordered set of reversible actions. That is enough to turn “it froze on slide 9” from a mystery into a decision.