CallMeter Docs

Keyframe Requests Received

Understand inbound keyframe requests — what they measure, why the remote side is requesting keyframes from your endpoint, and what it means for overall video quality.

Keyframe Requests Received counts the number of keyframe requests your endpoint has received from the remote side. Each request means the remote video decoder lost synchronization and needs your encoder to produce a fresh keyframe so it can rebuild the picture.

Think of it from the other perspective: the person watching your video feed keeps losing the picture. They are asking you to resend a complete image so they can see you again. Frequent requests mean the remote viewer is experiencing persistent video disruption.

How It Works

When the remote endpoint's video decoder cannot properly render the incoming stream — due to packet loss, corruption, or other issues — it sends a keyframe request via RTCP feedback (PLI or FIR message). Your endpoint receives this request and responds by encoding the next frame as a full keyframe (I-frame) rather than a delta frame.

CallMeter counts these inbound requests per measurement interval. This metric complements Keyframe Requests Sent by showing the other direction — what the remote side is experiencing with the video you are sending.

Asymmetric quality

High inbound requests with low outbound requests indicate an asymmetric problem: the video you send is being damaged in transit, but the video you receive is fine. This points to a directional network issue.

Why It Matters

Each inbound keyframe request forces your encoder to produce a keyframe, which is significantly larger than a normal delta frame. This creates a burst of data that can:

  • Consume bandwidth — Keyframes are 5 to 10 times larger than delta frames, potentially causing congestion
  • Trigger a cascade — The bandwidth burst from the keyframe can itself cause packet loss, leading to more requests
  • Impact other streams — In multi-stream scenarios, the bandwidth spike from one stream's keyframe can affect other streams sharing the same link

For enterprise VoIP testing, monitoring inbound keyframe requests helps identify problems on the outbound video path before they escalate into visible quality issues.

Common Causes of High Inbound Keyframe Request Counts

CauseExplanation
Outbound packet lossPackets from your endpoint being dropped before reaching the remote side
Asymmetric network pathThe outbound path is congested or lossy while the inbound path is fine
Remote jitter buffer issuesThe remote endpoint discarding late-arriving packets from your stream
High video bitrateSending at a bitrate the network path cannot sustain
MTU issuesLarge video packets being fragmented and partially lost

How to Fix It

  1. Check outbound packet loss — If you are sending many packets but the remote side is losing them, focus on the outbound network path.
  2. Reduce outbound video bitrate — Lower Video Bitrate to reduce the chance of congestion on the outbound path.
  3. Compare both directions — If both sent and received keyframe requests are high, the problem is likely network-wide. If only received is high, the issue is specific to your outbound path.
  4. Check for MTU issues — Large video packets that exceed the path MTU get fragmented. Loss of any fragment loses the entire packet. Ensure MTU is configured correctly.
  5. Review QoS in both directions — Quality of Service may be configured asymmetrically, prioritizing inbound traffic but not outbound.
  • Keyframe Requests Sent — Outbound requests; compare to understand directional quality differences
  • Keyframes Received — Keyframes the remote side produced, should correlate with your outbound requests
  • Keyframes Sent — Keyframes your encoder produced in response to inbound requests
  • Video Bitrate — Sending bitrate; keyframes cause temporary bitrate spikes
  • Packet Loss Rate — Network-level loss driving the remote side's keyframe requests

RFC Reference

PLI (Picture Loss Indication) is defined in RFC 4585 (Extended RTP Profile for RTCP-Based Feedback), Section 6.3.1. FIR (Full Intra Request) is defined in RFC 5104 (Codec Control Messages in the RTP Audio-Visual Profile with Feedback), Section 3.5.1.

On this page