SIP INFO PFU

Understand SIP INFO Picture Fast Update — the legacy keyframe request mechanism that operates through SIP signaling instead of RTCP feedback.

SIP INFO PFU (Picture Fast Update) is a legacy mechanism for requesting a video keyframe. Unlike NACK, PLI, and FIR, which travel through the RTCP feedback channel alongside media, PFU sends the keyframe request through the SIP signaling path using a SIP INFO message.

Think of it as sending a letter through the postal service to ask someone to re-fax a document, instead of pressing the "resend" button on the fax machine itself. It gets the job done, but it takes a different — and slower — route.

How It Works

When a video receiver needs a fresh keyframe and does not have RTCP feedback available (or when the system predates AVPF support), it can send a SIP INFO request to the sender with an XML body containing the Picture Fast Update command. The sender's SIP stack receives this message, extracts the keyframe request, and instructs the video encoder to produce a new I-frame.

The SIP INFO method was originally designed for mid-call signaling of arbitrary application data. Video conferencing systems adopted it for keyframe requests before RTCP-based feedback (RFC 4585) became widely supported.

Legacy mechanism

SIP INFO PFU predates the standardized RTCP feedback mechanisms (NACK, PLI, FIR). Modern systems should use RTCP-based feedback, which is faster and does not load the SIP signaling path. If you see SIP INFO PFU in your test results, it typically means you are testing against older video conferencing equipment or a system that has not adopted AVPF.

Why It Matters

The presence of SIP INFO PFU messages in your test results provides two insights:

Compatibility indicator — The remote system is using a legacy keyframe request path instead of modern RTCP feedback. This is common in older H.323-to-SIP gateways, legacy video conferencing units, and some enterprise PBX systems with video support.
Recovery outside RTCP — Keyframe requests are flowing through the signaling channel. This is inherently slower than RTCP feedback because SIP messages are processed by the SIP stack (with potential proxy hops) rather than traveling directly on the media path. The delay between request and keyframe delivery is typically higher.

For enterprise VoIP testing, tracking SIP INFO PFU helps you identify which endpoints in your infrastructure rely on legacy feedback mechanisms. This is valuable when planning upgrades or troubleshooting video quality differences between modern and legacy endpoints.

Common Causes

Cause	Explanation
Legacy equipment	Older video conferencing systems that predate RFC 4585
AVPF not negotiated	SDP offer/answer did not include AVPF profile, falling back to SIP-based feedback
B2BUA stripping RTCP	A back-to-back user agent or SBC is not forwarding RTCP feedback, forcing SIP-based recovery
Interop requirements	Some vendor-specific implementations require SIP INFO PFU for compatibility

How to Address It

Enable AVPF in SDP — Ensure both endpoints negotiate the AVPF profile (RTP/AVPF or RTP/SAVPF) in SDP so that RTCP-based feedback is available.
Verify RTCP path — If AVPF is negotiated but PFU is still being used, check whether RTCP packets are being blocked by firewalls, NATs, or intermediary proxies.
Check SBC/B2BUA configuration — Session Border Controllers may strip or not forward RTCP feedback messages. Verify that your media path allows end-to-end RTCP.
Plan for legacy support — If you must support legacy endpoints, SIP INFO PFU is functional and correct. Monitor it alongside RTCP-based feedback to understand the mix of legacy and modern equipment in your environment.

PLI Messages — The modern RTCP-based equivalent of PFU
FIR Messages — Stronger RTCP keyframe request defined in RFC 5104
NACK Messages — Packet-level retransmission via RTCP feedback

RFC Reference

SIP INFO PFU is described in RFC 5168 (XML Schema for Media Control). The mechanism uses the SIP INFO method (RFC 6086) to carry an XML payload requesting a fast video update. Note that RFC 5168 has been largely superseded by the RTCP-based feedback mechanisms in RFC 4585 and RFC 5104 for keyframe requests.