Internet Engineering Task Force (IETF) B. Burman
Request for Comments: 7728 A. Akram
Updates: 5104 Ericsson
Category: Standards Track R. Even
ISSN: 2070-1721 Huawei Technologies
February 2016 RTP Stream Pause and Resume
With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback
messages when using the Real-time Transport Protocol (RTP) for real-
time data transport. This document extends the Codec Control Message
(CCM) RTP Control Protocol (RTCP) feedback package by explicitly
allowing and describing specific use of existing CCMs and adding a
group of new real-time feedback messages used to pause and resume RTP
data streams. This document updates RFC 5104.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3910.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 4010.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 4110.3. Point to Multipoint Using Mixer . . . . . . . . . . . . 4510.4. Point to Multipoint Using Translator . . . . . . . . . . 4711. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5012. Security Considerations . . . . . . . . . . . . . . . . . . . 5013. References . . . . . . . . . . . . . . . . . . . . . . . . . 5213.1. Normative References . . . . . . . . . . . . . . . . . . 5213.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 551. Introduction
As real-time communication attracts more people, more applications
are created; multimedia conversation applications is one example.
Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its
own preferences for the communication session, not only at the start
but also during the session. This document describes several
scenarios in multimedia communication where a conferencing node or
participant chooses to temporarily pause an incoming RTP [RFC3550]
stream and later resume it when needed. The receiver does not need
to terminate or inactivate the RTP session and start all over again
by negotiating the session parameters, for example, using SIP
[RFC3261] with the Session Description Protocol (SDP) [RFC4566]
Centralized nodes, like RTP Mixers or Multipoint Control Units (MCUs)
that use either logic based on voice activity, other measurements, or
user input could reduce the resources consumed in both the sender and
the network by temporarily pausing the RTP streams that aren't
required by the RTP Mixer. If the number of conference participants
are greater than what the conference logic has chosen to present
simultaneously to receiving participants, some participant RTP
streams sent to the RTP Mixer may not need to be forwarded to any
other participant. Those RTP streams could then be temporarily
paused. This becomes especially useful when the media sources are
provided in multiple encoding versions (Simulcast) [SDP-SIMULCAST] or
with Multi-Session Transmission (MST) of scalable encoding such as
Scalable Video Coding (SVC) [RFC6190]. There may be some of the
defined encodings or a combination of scalable layers that are not
used or cannot be used all of the time. As an example, a centralized
node may choose to pause such unused RTP streams without being
explicitly requested to do so, maybe due to temporarily limited
network or processing resources. It may then also send an explicit
indication that the streams are paused.
As the set of RTP streams required at any given point in time is
highly dynamic in such scenarios, using the out-of-band signaling
channel for pausing, and even more importantly resuming, an RTP
stream is difficult due to the performance requirements. Instead,
the pause and resume signaling should be in the media plane and go
directly between the affected nodes. When using RTP [RFC3550] for
media transport, using "Extended RTP Profile for Real-time Transport
Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] appears
appropriate. No currently existing RTCP feedback message explicitly
supports pausing and resuming an incoming RTP stream. As this
affects the generation of packets and may even allow the encoding
process to be paused, the functionality appears to match Codec
Control Messages (CCMs) in the RTP Audio-Visual Profile with Feedback
(AVPF) [RFC5104]. This document defines the solution as a CCM
The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is
used by video conferencing systems for flow control. It is desirable
to be able to use that method with a bitrate value of zero for pause,
whenever possible. This specification updates RFC 5104 by adding the
new pause and resume semantics to the TMMBR and Temporary Maximum
Media Bitrate Notification (TMMBN) messages.
AVPF: Audio-Visual Profile with Feedback (RFC 4585)
CCM: Codec Control Message (RFC 5104)
CNAME: Canonical Name (RTCP Source Description)
CSRC: Contributing Source (RTP)
FCI: Feedback Control Information (AVPF)
FIR: Full Intra Refresh (CCM)
FMT: Feedback Message Type (AVPF)
MCU: Multipoint Control Unit
MTU: Maximum Transfer Unit
PT: Payload Type (RTP)
RTP: Real-time Transport Protocol (RFC 3550)
RTCP: RTP Control Protocol (RFC 3550)
RTCP RR: RTCP Receiver Report
RTCP SR: RTCP Sender Report
SDP: Session Description Protocol (RFC 4566)
SIP: Session Initiation Protocol (RFC 3261)
SSRC: Synchronization Source (RTP)
SVC: Scalable Video Coding
TMMBR: Temporary Maximum Media Bitrate Request (CCM)
TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
UA: User Agent (SIP)
UDP: User Datagram Protocol (RFC 768)
In addition to the following, the definitions from RTP [RFC3550],
AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy [RFC7656] also apply
in this document.
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback
messages into four types: Request, Command, Indication, and
Notification. This document places the PAUSE and RESUME messages
into the Request category, PAUSED as an Indication, and REFUSED as
PAUSE: Request from an RTP stream receiver to pause a stream
RESUME: Request from an RTP stream receiver to resume a paused
PAUSED: Indication from an RTP stream sender that a stream is
REFUSED: Notification from an RTP stream sender that a PAUSE or
RESUME request will not be honored
Mixer: The intermediate RTP node that receives an RTP stream from
different endpoints, combines them to make one RTP stream, and
forwards them to destinations, in the sense described for Topo-
Mixer in "RTP Topologies" [RFC7667].
Participant: A member that is part of an RTP session, acting as the
receiver, sender, or both.
Paused sender: An RTP stream sender that has stopped its
transmission, i.e., no other participant receives its RTP
transmission, based on having received either a PAUSE request,
defined in this specification, or a local decision.
Pausing receiver: An RTP stream receiver that sends a PAUSE request,
defined in this specification, to another participant(s).
Stream: Used as a short term for RTP stream, unless otherwise noted.
Stream receiver: Short for RTP stream receiver; the RTP entity
responsible for receiving an RTP stream, usually a Media
Stream sender: Short for RTP stream sender; the RTP entity
responsible for creating an RTP stream, usually a Media
2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
3. Use Cases
This section discusses the main use cases for RTP stream pause and
The RTCWEB WG's use case and requirements document [RFC7478] defines
the following API requirements in Appendix A, which is also used by
the W3C WebRTC WG:
A8 The web API must provide means for the web application to mute/
unmute a stream or stream component(s). When a stream is sent to
a peer, mute status must be preserved in the stream received by
A9 The web API must provide means for the web application to cease
the sending of a stream to a peer.
This document provides means to optimize transport usage by stopping
the sending of muted streams and starting the sending of streams
again when unmuted. Here, it is assumed that "mute" above can be
taken to apply also to media other than audio. At the time of
publication for this specification, the RTCWEB WG did not specify any
3.1. Point to Point
This is the most basic use case with an RTP session containing two
endpoints. Each endpoint sends one or more streams.
| A |<------->| B |
Figure 1: Point to Point
The usage of RTP stream pause in this use case is to temporarily halt
delivery of streams that the sender provides but the receiver does
not currently use. This can, for example, be due to minimized
applications where the video stream is not actually shown on any
display, or it is not used in any other way, such as being recorded.
In this case, since there is only a single receiver of the stream,
pausing or resuming a stream does not impact anyone else other than
the sender and the single receiver of that stream.
3.2. RTP Mixer to Media Sender
One of the most commonly used topologies in centralized conferencing
is based on the RTP Mixer [RFC7667]. The main reason for this is
that it provides a very consistent view of the RTP session towards
each participant. That is accomplished through the Mixer originating
its own streams, identified by distinct SSRC values, and any RTP
streams sent to the participants will be sent using those SSRC
values. If the Mixer wants to identify the underlying media sources
for its conceptual streams, it can identify them using CSRC. The
stream the Mixer provides can be an actual mix of multiple media
sources, but it might also be switching received streams as described
in Sections 3.6 - 3.8 of "RTP Topologies" [RFC7667].
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +-----------+ +---+
Figure 2: RTP Mixer in Unicast Only
Which streams from clients B, C, and D that are delivered to a given
receiver, A, can depend on several things:
o The RTP Mixer's own logic and measurements, such as voice activity
on the incoming audio streams.
o The number of sent media sources exceed what is reasonable to
present simultaneously at any given receiver.
o A human controlling the conference that determines how the media
should be mixed. This would be more common in lecture or similar
applications where regular listeners may be prevented from
breaking into the session unless approved by the moderator.
o The streams may also be part of a Simulcast [SDP-SIMULCAST] or
scalable encoded (for Multi-Session Transmission) [RFC6190], thus
providing multiple versions that can be delivered by the RTP
These examples indicate that there are numerous reasons why a
particular stream would not currently be in use but must be available
for use at very short notice if any dynamic event occurs that causes
a different stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could
request the RTP stream sender to pause a particular stream. The
Mixer also needs to be able to request the RTP stream sender to
resume delivery with minimal delay.
In some cases, especially when the Mixer sends multiple RTP streams
per receiving client, there may be situations that make it desirable
for the Mixer to pause some of its sent RTP streams, even without
being explicitly asked to do so by the receiving client. Such
situations can, for example, be caused by a temporary lack of
available Mixer network or processing resources. An RTP stream
receiver that no longer receives an RTP stream could interpret this
as an error condition and try to take action to re-establish the RTP
stream. Such action would likely be undesirable if the RTP stream
was in fact deliberately paused by the Mixer. Undesirable RTP stream
receiver actions could be avoided if the Mixer is able to explicitly
indicate that an RTP stream is deliberately paused.
Just as for point to point (Section 3.1), there is only a single
receiver of the stream, the RTP Mixer, and pausing or resuming a
stream does not affect anyone else other than the sender and single
receiver of that stream.
3.3. RTP Mixer to Media Sender in Point to Multipoint
This use case is similar to the previous section; however, the RTP
Mixer is involved in three domains that need to be separated: the
Multicast Network (including participants A and C), participant B,
and participant D. The difference from above is that A and C share a
multicast domain, which is depicted below.
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
Figure 3: RTP Mixer in Point to Multipoint
If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should
thus have a say on.
If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested, it can simply
ignore the stream and is not impacted as much as above.
In this use case, there are several receivers of a stream, and the
Mixer must take special care so as not to pause a stream that is
still wanted by some receivers.
3.4. Media Receiver to RTP Mixer
In this use case, the direction of the request to pause is the
opposite compared to the two previous use cases. An endpoint in
Figure 2 could potentially request to pause the delivery of a given
stream. Possible reasons include those in the point-to-point case
(Section 3.1) above.
When the RTP Mixer is only connected to individual unicast paths, the
use case and any considerations are identical to the point-to-point
However, when the endpoint requesting stream pause is connected to
the RTP Mixer through a multicast network, such as A or C in
Figure 3, the use case instead becomes identical to the one in
Section 3.3, only with reverse direction of the streams and pause/
3.5. Media Receiver to Media Sender across RTP Mixer
An endpoint, like A in Figure 2, could potentially request to pause
the delivery of a given stream, like one of B's, over any of the
SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the stream. However, the authors are of the opinion that
this is not a suitable solution for several reasons:
1. The Mixer might not include CSRC in its stream indications.
2. An endpoint cannot rely on the CSRC to correctly identify the
stream to be paused when the delivered media is some type of mix.
A more elaborate stream identification solution is needed to
support this in the general case.
3. The endpoint cannot determine if a given stream is still needed
by the RTP Mixer to deliver to another session participant.
Due to the above reasons, we exclude this use case from further
4. Design Considerations
This section describes the requirements that this specification needs
4.1. Real-Time Nature
The first section (Section 1) of this specification describes some
possible reasons why a receiver may pause an RTP sender. Pausing and
resuming is time dependent, i.e., a receiver may choose to pause an
RTP stream for a certain duration, after which the receiver may want
the sender to resume. This time dependency means that the messages
related to pause and resume must be transmitted to the sender in a
timely fashion in order for them to be purposeful. The pause
operation is arguably not as time critical as the resume operation,
since it mainly provides a reduction of resource usage. Timely
handling of the resume operation is, however, likely to directly
impact the end-user's perceived quality experience, since it affects
the availability of media that the user expects to receive more or
less instantly. It may also be highly desirable for a receiver to
quickly learn that an RTP stream is intentionally paused on the RTP
sender's own behalf.
4.2. Message Direction
It is the responsibility of an RTP stream receiver that wants to
pause or resume a stream from the sender(s) to transmit PAUSE and
RESUME messages. An RTP stream sender that wants to pause itself can
often simply do it, but sometimes this will adversely affect the
receiver and an explicit indication that the RTP stream is paused may
then help. Any indication that an RTP stream is paused is the
responsibility of the RTP stream sender and may in some cases not
even be needed by the stream receiver.
4.3. Apply to Individual Sources
The PAUSE and RESUME messages apply to single RTP streams identified
by their SSRC, which means the receiver targets the sender's SSRC in
the PAUSE and RESUME requests. If a paused sender starts sending
with a new SSRC, the receivers will need to send a new PAUSE request
in order to pause it. PAUSED indications refer to a single one of
the sender's own paused SSRC.
An RTP stream sender should not pause an SSRC that some receiver
still wishes to receive.
The reason is that in RTP topologies where the stream is shared
between multiple receivers, a single receiver on that shared network
must not single-handedly cause the stream to be paused without
letting all other receivers voice their opinions on whether or not
the stream should be paused. Such shared networks can, for example,
be multicast, a mesh with a joint RTP session, or a transport
Translator-based network. A consequence of this is that a newly
joining receiver first needs to learn the existence of paused streams
and secondly should be able to resume any paused stream. A newly
joining receiver can, for example, be detected through an RTCP
Receiver Report containing both a new SSRC and a CNAME that does not
already occur in the session. Any single receiver wanting to resume
a stream should also cause it to be resumed. An important exception
to this is when the RTP stream sender is aware of conditions that
make it desirable or even necessary to pause the RTP stream on its
own behalf, without being explicitly asked to do so. Such local
consideration in the RTP sender takes precedence over RTP receiver
wishes to receive the stream.
4.5. Message Acknowledgments
RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower-layer transport protocol can provide.
However, this is commonly UDP that provides no reliability
guarantees. Thus, it is possible that a PAUSE and/or RESUME message
transmitted from an RTP endpoint does not reach its destination,
i.e., the targeted RTP stream sender. When PAUSE or RESUME reaches
the RTP stream sender and is effective, i.e., an active RTP stream
sender pauses or a resuming RTP stream sender has media data to
transmit, it is immediately seen from the arrival or non-arrival of
RTP packets for that RTP stream. Thus, no explicit acknowledgments
are required in this case.
In some cases, when a PAUSE or RESUME message reaches the RTP stream
sender, it will not be able to pause or resume the stream due to some
local consideration, for example, lack of data to transmit. In this
error condition, a negative acknowledgment may be needed to avoid
unnecessary retransmission of requests (Section 4.6).
4.6. Request Retransmission
When the stream is not affected as expected by a PAUSE or RESUME
request, the request may have been lost and the sender of the request
will need to retransmit it. The retransmission should take the
round-trip time into account, and will also need to take the normal
RTCP bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback.
When it comes to resume requests or unsolicited paused indications
that are more time critical, the best performance may be achieved by
repeating the message as often as possible until a sufficient number
have been sent to reach a high probability of message delivery or at
an explicit indication that the message was delivered. For resume
requests, such explicit indication can be delivery of the RTP stream
being requested to be resumed.
4.7. Sequence Numbering
A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps
the sequence number unchanged, while it is incremented every time a
new PAUSE request is transmitted that is not a retransmission of a
Since RESUME always takes precedence over PAUSE and is even allowed
to avoid pausing a stream, there is a need to keep strict ordering of
PAUSE and RESUME. Thus, RESUME needs to share sequence number space
with PAUSE and implicitly reference which PAUSE it refers to. For
the same reasons, the explicit PAUSED indication also needs to share
sequence number space with PAUSE and RESUME.
4.8. Relation to Other Solutions
A performance comparison between SIP/SDP and RTCP signaling
technologies was made and included in draft versions of this
specification. Using SIP and SDP to carry pause and resume
information means that they will need to traverse the entire
signaling path to reach the signaling destination (either the remote
endpoint or the entity controlling the RTP Mixer) across any
signaling proxies that potentially also have to process the SDP
content to determine if they are expected to act on it. The amount
of bandwidth required for a signaling solution based on SIP/SDP is in
the order of at least 10 times more than an RTCP-based solution.
Especially for a UA sitting on mobile wireless access, this will risk
introducing delays that are too long (Section 4.1) to provide a good
user experience, and the bandwidth cost may also be considered
infeasible compared to an RTCP-based solution. RTCP data sent
through the media path, which is likely shorter (contains fewer
intermediate nodes) than the signaling path, may have to traverse a
few intermediate nodes anyway. The amount of processing and
buffering required in intermediate nodes to forward those RTCP
messages is, however, believed to be significantly less than for
intermediate nodes in the signaling path. Based on those
considerations, RTCP is chosen as the signaling protocol for the
pause and resume functionality.
5. Solution Overview
The proposed solution implements pause and resume functionality based
on sending AVPF RTCP feedback messages from any RTP session
participant that wants to pause or resume a stream targeted at the
stream sender, as identified by the sender SSRC.
This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
possible and defines a small set of new RTCP feedback messages where
new semantics is needed.
A single feedback message specification is used to implement the new
messages. The message consists of a number of Feedback Control
Information (FCI) blocks, where each block can be a PAUSE request, a
RESUME request, a PAUSED indication, a REFUSED notification, or an
extension to this specification. This structure allows a single
feedback message to handle pause functionality on a number of
The PAUSED functionality is also defined in such a way that it can be
used as a standalone by the RTP stream sender to indicate a local
decision to pause, and it can inform any receiver of the fact that
halting media delivery is deliberate and which RTP packet was the
Special considerations that apply when using TMMBR/TMMBN for pause
and resume purposes are described in Section 5.6. This specification
applies to both the new messages defined herein as well as their
TMMBR/TMMBN counterparts, except when explicitly stated otherwise.
An obvious exception is any reference to the message parameters that
are only available in the messages defined here. For example, any
reference to PAUSE in the text below is equally applicable to
TMMBR 0, and any reference to PAUSED is equally applicable to TMMBN
0. Therefore, and for brevity, TMMBR/TMMBN will not be mentioned in
the text, unless there is specific reason to do so.
This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification.
5.1. Expressing Capability
An endpoint can use an extension to CCM SDP signaling to declare
capability to understand the messages defined in this specification.
Capability to understand only a subset of messages is possible, to
support partial implementation, which is specifically believed to be
feasible for the 'RTP Mixer to Media Sender' use case (Section 3.2).
In that use case, only the RTP Mixer has capability to request the
media sender to pause or resume. Consequently, in that same use
case, only the media sender has capability to pause and resume its
sent streams based on requests from the RTP Mixer. Allowing for
partial implementation of this specification is not believed to
hamper interoperability, as long as the subsets are well defined and
describe a consistent functionality, including a description of how a
more capable implementation must perform fallback.
For the case when TMMBR/TMMBN are used for pause and resume purposes,
it is possible to explicitly express joint support for TMMBR and
TMMBN, but not for TMMBN only.
All messages defined in this specification (Section 8) contain a
PauseID, satisfying the design consideration on sequence numbering
(Section 4.7). This PauseID is scoped by and thus a property of the
targeted RTP stream (SSRC) and is not only a sequence number for
individual messages. Instead, it numbers an entire "pause and resume
operation" for the RTP stream, typically keeping PauseID constant for
multiple, related messages. The PauseID value used during such
operation is called the current PauseID. A new "pause and resume
operation" is defined to start when the RTP stream sender resumes the
RTP stream after it was being paused. The current PauseID is then
incremented by one in modulo arithmetic. In the subsequent
descriptions below, it is sometimes necessary to refer to PauseID
values that were already used as the current PauseID, which is
denoted as the past PauseID. It should be noted that since PauseID
uses modulo arithmetic, a past PauseID may have a larger value than
the current PauseID. Since PauseID uses modulo arithmetic, it is
also useful to define what PauseID values are considered "past" to
clearly separate it from what could be considered "future" PauseID
values. Half of the entire PauseID value range is chosen to
represent a past PauseID, while a quarter of the PauseID value range
is chosen to represent future values. The remaining quarter of the
PauseID value range is intentionally left undefined in that respect.
5.3. Requesting to Pause
An RTP stream receiver can choose to send a PAUSE request at any
time, subject to AVPF timing rules.
The PAUSE request contains the current PauseID (Section 5.2).
When a non-paused RTP stream sender receives the PAUSE request, it
continues to send the RTP stream while waiting for some time to allow
other RTP stream receivers in the same RTP session that saw this
PAUSE request to disapprove by sending a RESUME (Section 5.5) for the
same stream and with the same current PauseID as in the PAUSE being
disapproved. If such a disapproving RESUME arrives at the RTP stream
sender during the hold-off period before the stream is paused, the
pause is not performed. In point-to-point configurations, the hold-
off period may be set to zero. Using a hold-off period of zero is
also appropriate when using TMMBR 0 and is in line with the semantics
for that message.
If the RTP stream sender receives further PAUSE requests with the
current PauseID while waiting as described above, those additional
requests are ignored.
If the PAUSE request is lost before it reaches the RTP stream sender,
it will be discovered by the RTP stream receiver because it continues
to receive the RTP stream. It will also not see any PAUSED
indication (Section 5.4) for the stream. The same condition can be
caused by the RTP stream sender having received a disapproving RESUME
from stream receiver A for a PAUSE request sent by stream sender B,
except that the PAUSE sender (B) did not receive the RESUME (from A)
and may instead think that the PAUSE was lost. In both cases, a
PAUSE request can be retransmitted using the same current PauseID.
If using TMMBR 0, the request MAY be retransmitted when the requester
fails to receive a TMMBN 0 confirmation.
If the pending stream pause is aborted due to a disapproving RESUME,
the pause and resume operation for that PauseID is concluded, the
current PauseID is updated, and any new PAUSE must therefore use the
new current PauseID to be effective.
An RTP stream sender receiving a PAUSE not using the current PauseID
informs the RTP stream receiver sending the ineffective PAUSE of this
condition by sending a REFUSED notification that contains the current
A situation where an ineffective PauseID is chosen can appear when a
new RTP stream receiver joins a session and wants to PAUSE a stream
but does not yet know the current PauseID to use. The REFUSED
notification will then provide sufficient information to create a
valid PAUSE. The required extra signaling round trip is not
considered harmful, since it is assumed that pausing a stream is not
time critical (Section 4.1).
There may be local considerations making it impossible or infeasible
to pause the stream, and the RTP stream sender can then respond with
a REFUSED. In this case, if the used current PauseID would otherwise
have been effective, REFUSED contains the same current PauseID as in
the PAUSE request. Note that when using TMMBR 0 as PAUSE, that
request cannot be refused (TMMBN > 0) due to the existing restriction
in Section 188.8.131.52 of [RFC5104] that TMMBN shall contain the current
bounding set, and the fact that a TMMBR 0 will always be the most
restrictive point in any bounding set, regardless of the bounding set
If the RTP stream sender receives several identical PAUSE requests
for an RTP stream that was already responded to at least once with
REFUSED and the condition causing REFUSED remains, those additional
REFUSED notifications should be sent with regular RTCP timing. A
single REFUSED can respond to several identical PAUSE requests.
5.4. Media Sender Pausing
An RTP stream sender can choose to pause the stream at any time.
This can be either a result of receiving a PAUSE or based on some
local sender consideration. When it does, it sends a PAUSED
indication, containing the current PauseID. Note that the current
PauseID in an unsolicited PAUSED (without having received a PAUSE) is
incremented compared to a previously sent PAUSED. It also sends the
PAUSED indication in the next two regular RTCP reports, given that
the pause condition is then still effective.
There is no reply to a PAUSED indication; it is simply an explicit
indication of the fact that an RTP stream is paused. This can be
helpful for the RTP stream receiver, for example, to quickly
understand that transmission is deliberately and temporarily
suspended and no specific corrective action is needed.
The RTP stream sender may want to apply some local consideration to
exactly when the RTP stream is paused, for example, completing some
media unit or a forward error correction block, before pausing the
The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective.
This provides RTP stream receivers with firsthand information that
allows them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP
stream receivers to quickly and safely take into account that the
stream is paused in, for example, retransmission or congestion
If the RTP stream sender receives PAUSE requests with the current
PauseID while the stream is already paused, those requests are
As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP Sender Report (SR) or Receiver
Report (RR). Including PAUSED in this way allows RTP stream
receivers to join while the stream is paused and to quickly know that
there is a paused stream, what the last sent extended RTP sequence
number is, and what the current PauseID is, which enables them to
construct valid PAUSE and RESUME requests at a later stage.
When the RTP stream sender learns that a new endpoint has joined the
RTP session, for example, by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. In addition,
it should continue to include PAUSED indications in at least two
regular RTCP reports.
5.5. Requesting to Resume
An RTP stream receiver can request the RTP stream sender to resume a
stream with a RESUME request at any time, subject to AVPF timing
rules. The RTP stream receiver must include the current PauseID in
the RESUME request for it to be effective.
A pausing RTP stream sender that receives a RESUME including the
current PauseID resumes the stream at the earliest opportunity.
Receiving RESUME requests for a stream that is not paused does not
require any action and can be ignored.
There may be local considerations at the RTP stream sender, for
example, that the media device is not ready, making it temporarily
impossible to resume the stream at that point in time, and the RTP
stream sender can then respond with a REFUSED containing the current
PauseID. When receiving such REFUSED with a current PauseID
identical to the one in the sent RESUME, RTP stream receivers should
avoid sending further RESUME requests for some reasonable amount of
time to allow the condition to clear. An RTP stream sender having
sent a REFUSED SHOULD resume the stream through local considerations
(see below) when the condition that caused the REFUSED is no longer
If the RTP stream sender receives several identical RESUME requests
for an RTP stream that was already at least once responded to with
REFUSED and the condition causing REFUSED remains, those additional
REFUSED notifications should be sent with regular RTCP timing. A
single REFUSED can respond to several identical RESUME requests.
A pausing RTP stream sender can apply local considerations and can
resume a paused RTP stream at any time. If TMMBR 0 was used to pause
the RTP stream, resumption is prevented by protocol, even if the RTP
sender would like to resume due to local considerations. If TMMBR/
TMMBN signaling is used, the RTP stream is paused due to local
considerations (Section 5.4), and the RTP stream sender thus owns the
TMMBN bounding set, the RTP stream can be resumed due to local
When resuming a paused stream, especially for media that makes use of
temporal redundancy between samples such as video, it may not be
appropriate to use such temporal dependency in the encoding between
samples taken before the pause and at the time instant the stream is
resumed. Should such temporal dependency between media samples
before and after the media was paused be used by the RTP stream
sender, it requires the RTP stream receiver to have saved the samples
from before the pause for successful continued decoding when
resuming. The use of this temporal dependency of media samples from
before the pause is left up to the RTP stream sender. If temporal
dependency on samples from before the pause is not used when the RTP
stream is resumed, the first encoded sample after the pause will not
contain any temporal dependency on samples before the pause (for
video it may be a so-called intra picture). If temporal dependency
on samples from before the pause is used by the RTP stream sender
when resuming, and if the RTP stream receiver did not save any sample
from before the pause, the RTP stream receiver can use a FIR request
[RFC5104] to explicitly ask for a sample without temporal dependency
(for video a so-called intra picture), even at the same time as
sending the RESUME.
5.6. TMMBR/TMMBN Considerations
As stated above, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not
point to point, TMMBR/TMMBN cannot safely be used for pause or
resume. This use is expected to be mainly for interworking with
implementations that don't support the messages defined in this
specification (Section 8) but make use of TMMBR/TMMBN to achieve a
This is a brief summary of what functionality is provided when using
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
off period to wait for RESUME before pausing the RTP stream.
TMMBR > 0: Corresponds to RESUME when the RTP stream was previously
paused with TMMBR 0. Since there is only a single RTP stream
receiver, there is no need for the RTP stream sender to delay
resuming the stream until after sending TMMBN > 0 or to apply the
hold-off period specified in [RFC5104] before increasing the
bitrate from zero. The bitrate value used when resuming after
pausing with TMMBR 0 is either according to known limitations or
based on starting a stream with the configured maximum for the
stream or session, for example, given by "b=" line in SDP.
TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with
TMMBR 0 but may, just as PAUSED, also be used unsolicited. An
unsolicited RTP stream pause based on local sender considerations
uses the RTP stream's own SSRC as the TMMBR restriction owner in
the TMMBN message bounding set. It also corresponds to a REFUSED
notification when a stream is requested to be resumed with
TMMBR > 0, thus resulting in the stream sender becoming the owner
of the bounding set in the TMMBN message.
TMMBN > 0: Cannot be used as a REFUSED notification when a stream is
requested to be paused with TMMBR 0, for reasons stated in