RTP Stream Pause and Resume
updates
- rfc-5104 — Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
Extracted elements (29)
A hold-off period of 2*RTT + T_dither_max was introduced in Pausing state to achieve consensus: in shared-network topologies (multicast, mesh, translator), a single receiver must not single-handedly pause a stream that other receivers still want. Any receiver wishing to disapprove simply sends a RESUME with the same PauseID within the hold-off window.
Pause-by-CSRC (a receiver requesting pause of a stream via the Mixer's CSRC identifying the original source, Section 3.5) was deliberately excluded because: the Mixer may not include CSRC; CSRC cannot reliably identify the stream when media is mixed; and the requesting endpoint cannot determine whether the Mixer still needs that stream for other participants.
PAUSE, RESUME, and PAUSED share a single PauseID sequence space (rather than having separate counters) so that strict ordering between pause and resume operations is maintained. Since RESUME always takes precedence over PAUSE, they must reference the same logical sequence to unambiguously determine which PAUSE a RESUME is overriding.
RTCP was chosen over SIP/SDP for pause/resume signaling because SIP/SDP requires traversal of the full signaling path through proxies and is approximately 10 times more bandwidth-intensive. RTCP travels through the shorter media path with less processing overhead at intermediate nodes, and the real-time nature of resume (Section 4.1) makes the latency of SIP/SDP signaling unacceptable, particularly over mobile wireless access.
TMMBR 0 may be used as an equivalent of PAUSE and TMMBN 0 as PAUSED/REFUSED for point-to-point interworking with implementations predating this specification. TMMBR 0 has no hold-off period requirement. TMMBR > 0 serves as RESUME when the stream was paused with TMMBR 0; however, TMMBN > 0 cannot serve as a REFUSED for TMMBR 0 due to existing RFC 5104 bounding-set constraints.
When the negotiated signaling uses only 'rtcp-fb ccm tmmbr', no additional 'pause' attribute is required for TMMBR/TMMBN-based pause/resume, but there is no guarantee that pre-RFC-7728 TMMBR/TMMBN implementations behave exactly as described here when using a bitrate value of 0.
A CSRC MUST NOT be used as the Target SSRC in any PAUSE-RESUME message because the interpretation of a pause request targeting a CSRC is unclear. The SSRC of the media source field in the common RTCP feedback header SHALL be set to 0 for PAUSE-RESUME messages; the Target SSRC within the FCI identifies the actual target.
All RTCP feedback messages defined in this specification MUST follow normal AVPF-defined timing rules. PAUSE and RESUME are recommended to use Early or Immediate timing; PAUSED first transmission for each PauseID is recommended Immediate or Early to stop unnecessary PAUSE repetitions; REFUSED first transmission is also recommended Immediate or Early.
If a paused sender receives an RTCP BYE from the receiver that originally caused the stream to pause, the sender SHALL resume the RTP stream. Additionally, receivers observing an RTCP BYE from a paused sender SHALL NOT send further PAUSE or RESUME requests to it.
If a receiver whose SSRC times out (per RFC 3550 Section 6.3.5, i.e., no RTP or RTCP for five RTCP reporting intervals) was the one that caused an RTP stream to pause, any streams paused by that removed SSRC SHALL be resumed.
If an RTP sender receives PAUSE or RESUME with the current PauseID but cannot fulfill the request, it SHALL schedule a REFUSED containing that PauseID. If the request uses a non-current PauseID, it SHALL schedule a REFUSED containing the current PauseID (except RESUME with past PauseID in Playing state, which is ignored). Duplicate REFUSED notifications for identical requests MUST NOT be scheduled.
In Pausing state, the RTP stream sender SHALL wait a hold-off period of 2*RTT + T_dither_max (where RTT is the longest known round-trip time and T_dither_max is from RFC 4585 Section 3.4) before actually pausing transmission, to allow other receivers to send a disapproving RESUME. The hold-off period MAY be set to 0 when signaling confirms a single receiver.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive (per RFC 6263 and RFC 5245) applicable to that stream. This requirement applies equally in both Paused state and Local Paused state.
The PAUSED indication MUST be sent whenever entering Paused state or Local Paused state. It MUST also be included in at least the next two regular RTCP reports while still in that state. The PauseID in PAUSED MUST contain the current PauseID usable in a subsequent RESUME.
TMMBR/TMMBN MUST NOT be used for pause/resume functionality if the topology is not point-to-point. Furthermore, if the messages defined in this specification are supported by all involved parties, pause/resume signaling MUST use the new messages rather than TMMBR/TMMBN.
When a non-paused sender in Playing state receives a PAUSE with the current PauseID, it SHALL enter Pausing state unless local considerations make pausing impossible. PAUSE received while already in Pausing, Paused, or Local Paused state SHALL be ignored. If the PAUSE uses a non-current PauseID, the sender SHALL schedule a REFUSED containing the current PauseID.
When an RTP sender in Pausing, Paused, or Local Paused state receives a RESUME with the current PauseID and has no local barrier, it SHALL enter Playing state. If it cannot honor the RESUME, it SHALL schedule a REFUSED. A RESUME with a past PauseID received in Playing state SHALL be ignored.
When entering Paused state, the RTP stream sender SHALL send a PAUSED indication to all known receivers and SHALL repeat PAUSED in the next two regular RTCP reports while still in paused state. Pausing transmission SHOULD only be done at an appropriate media boundary to avoid triggering repair or concealment at the receiver.
When entering Playing state after a pause, the current PauseID MUST be incremented by one (modulo arithmetic). The RTP sequence number for the first packet SHALL be incremented by one compared to the highest sent before the pause, and the first RTP timestamp SHOULD reflect actual capture time so that the timestamp gap reflects the pause duration.
A new SDP 'pause' parameter is defined for the 'ccm' rtcp-fb attribute, indicating capability for PAUSE/RESUME/PAUSED/REFUSED. It has two optional sub-attributes: 'nowait' (permits hold-off period of 0 when only a single receiver exists) and 'config' (values 1-8 describing partial implementation subsets for different deployment roles).
Eight 'config' values define partial implementation subsets. Config=1 is full support (default). Configs 2-5 address the RTP Mixer use case with various combinations of send/receive capability for each message type. Configs 6-8 cover local-pause-only implementations. Implementing any config other than those defined is NOT RECOMMENDED.
PauseID is a 16-bit sequence identifier scoped by Target SSRC that numbers entire pause-and-resume operations rather than individual messages. PAUSE, RESUME, and PAUSED share the same PauseID space for a given Target SSRC. Half the PauseID value range represents past values, a quarter represents future values; the remaining quarter is intentionally left undefined. Modulo arithmetic is used throughout.
The PAUSE-RESUME message is a new transport-layer RTCP feedback message (PT=205, FMT=9) that carries one or more FCI blocks, each of which is a PAUSE request, RESUME request, PAUSED indication, or REFUSED notification. PAUSE and RESUME are categorized as Requests, PAUSED as an Indication, and REFUSED as a Notification per CCM taxonomy.
This document registers FMT value 9 in the 'FMT Values for RTPFB Payload Type (PT=205)' registry within the 'RTP Control Protocol Feedback Messages' IANA registry, assigned to the PAUSE-RESUME transport-layer feedback message defined herein.
A malicious participant could send spurious RESUME requests to force resumption of a stream that a legitimate receiver deliberately paused. Conversely, injection of REFUSED notifications could prevent legitimate RESUME requests from being retried for an inappropriate time. Authentication of RTCP feedback messages via SRTCP addresses both attack vectors.
Unauthorized PAUSE requests could be used to perform denial-of-service attacks by halting legitimate RTP streams. The specification inherits the security framework of AVPF (RFC 4585) and CCM (RFC 5104); SRTP/SRTCP (RFC 3711) SHOULD be used to provide authentication and integrity protection for PAUSE-RESUME messages to prevent such attacks.
An RTP stream sender has four states: Playing (normal sending), Pausing (received PAUSE, waiting hold-off period for potential RESUME), Paused (hold-off expired without RESUME, transmission stopped), and Local Paused (paused by sender's own local decision, cannot be resumed by RESUME alone). Transitions: Playing→Pausing on PAUSE received; Pausing→Paused after hold-off; Pausing/Paused→Playing on RESUME; any state→Local Paused on local PAUSE decision; Local Paused→Playing on local RESUME decision.
Each FCI entry in the PAUSE-RESUME message contains: Target SSRC (32 bits), Type (4 bits: 0=PAUSE, 1=RESUME, 2=PAUSED, 3=REFUSED, 4-15 reserved), Res (4 bits, must be 0), Parameter Len (8 bits, length of Type Specific in 32-bit words), PauseID (16 bits), and a variable-length Type Specific field.
The PAUSED message includes a mandatory fixed-length 32-bit Type Specific parameter at the start of the Type Specific field carrying the extended RTP sequence number of the last RTP packet sent before the stream was paused, in the same format as the extended highest sequence number received defined in RFC 3550 Section 6.4.1.