RFC 7728
RTP Stream Pause and Resume
6. Participant States
This document introduces three new states for a stream in an RTP sender, according to the figure and subsections below. Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section SHALL be taken to apply to the extent possible also when TMMBR/TMMBN are used (Section 5.6) for this functionality. +------------------------------------------------------+ | Received RESUME | v | +---------+ Received PAUSE +---------+ Hold-off period +--------+ | Playing |---------------->| Pausing |---------------->| Paused | | |<----------------| | | | +---------+ Received RESUME +---------+ +--------+ ^ | | PAUSE decision | | | v | | | PAUSE decision +---------+ PAUSE decision | | +------------------>| Local |<--------------------+ +-------------------------| Paused | RESUME decision +---------+ Figure 4: RTP Pause States in Sender6.1. Playing State
This state is not new but is the normal media sending state from [RFC3550]. When entering the state, the current PauseID MUST be incremented by one in modulo arithmetic. The RTP sequence number for the first packet sent after a pause SHALL be incremented by one compared to the highest RTP sequence number sent before the pause. The first RTP timestamp for the first packet sent after a pause SHOULD be set according to capture times at the source, meaning the RTP timestamp difference compared to before the pause reflects the time the RTP stream was paused.6.2. Pausing State
In this state, the RTP stream sender has received at least one PAUSE message for the stream in question. The RTP stream sender SHALL wait during a hold-off period for the possible reception of RESUME messages for the RTP stream being paused before actually pausing RTP stream transmission. The hold-off period to wait SHALL be long enough to allow another RTP stream receiver to respond to the PAUSE with a RESUME, if it determines that it would not like to see the stream paused. This hold-off period is determined by the formula: 2 * RTT + T_dither_max,
where RTT is the longest round trip known to the RTP stream sender and T_dither_max is defined in Section 3.4 of [RFC4585]. The hold- off period MAY be set to 0 by some signaling (Section 9) means when it can be determined that there is only a single receiver, for example, in point to point or some unicast situations. If the RTP stream sender has set the hold-off period to 0 and receives information that it was an incorrect decision and that there are in fact several receivers of the stream, it MUST change the hold- off period to be based on the above formula instead. An RTP stream sender SHOULD use the following criteria to determine if there is only a single receiver, unless it has explicit and more reliable information: o Observing only a single CNAME across all received SSRCs (CNAMEs for received CSRCs are insignificant), or o If RTCP reporting groups [MULTI-STREAM-OPT] is used, observing only a single, endpoint external RTCP reporting group.6.3. Paused State
An RTP stream is in paused state when the sender pauses its transmission after receiving at least one PAUSE message and the hold- off period has passed without receiving any RESUME message for that stream. Pausing transmission SHOULD only be done when reaching an appropriate place to pause in the stream, like a media boundary that avoids a media receiver to trigger repair or concealment actions. When entering the state, the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, and SHALL also repeat PAUSED in the next two regular RTCP reports, as long as it is then still in paused state. Pausing an RTP stream MUST NOT affect the sending of RTP keepalive [RFC6263][RFC5245] applicable to that RTP stream. The following subsections discuss some potential issues when an RTP sender goes into paused state. These conditions are also valid if an RTP Translator is used in the communication. When an RTP Mixer implementing this specification is involved between the participants (which forwards the stream by marking the RTP data with its own SSRC), it SHALL be a responsibility of the Mixer to control sending PAUSE and RESUME requests to the sender. The below conditions also apply to the sender and receiver parts of the RTP Mixer, respectively.
6.3.1. RTCP BYE Message
When a participant leaves the RTP session, it sends an RTCP BYE message. In addition to the semantics described in Sections 6.3.4 and 6.3.7 of RTP [RFC3550], the following two conditions MUST also be considered when an RTP participant sends an RTCP BYE message: o If a paused sender sends an RTCP BYE message, receivers observing this SHALL NOT send further PAUSE or RESUME requests to it. o Since a sender pauses its transmission on receiving the PAUSE requests from any receiver in a session, the sender MUST keep record of which receiver caused the RTP stream to pause. If that receiver sends an RTCP BYE message observed by the sender, the sender SHALL resume the RTP stream. No receivers that were in the RTP session when the stream was paused objected that the stream was paused, but if there were so far undetected receivers added to the session during pause, those may not have learned about the existence of the paused stream because either there was no PAUSED sent for the paused RTP stream or those receivers did not support PAUSED. Resuming the stream when the pausing party leaves the RTP session allows those potentially undetected receivers to learn that the stream exists.6.3.2. SSRC Time-Out
Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP participant. Every RTP participant maintains a sender and receiver list in a session. If a participant does not get any RTP or RTCP packets from some other participant for the last five RTCP reporting intervals, it removes that participant from the receiver list. Any streams that were paused by that removed participant SSRC SHALL be resumed.6.4. Local Paused State
This state can be entered at any time, based on local decision from the RTP stream sender. Pausing transmission SHOULD only be done when reaching an appropriate place to pause in the stream, like a media boundary that avoids a media receiver to trigger repair or concealment actions. As with paused state (Section 6.3), the RTP stream sender SHALL send a PAUSED indication to all known RTP stream receivers, when entering the state, unless the stream was already in paused state (Section 6.3). Such PAUSED indication SHALL be repeated a sufficient
number of times to reach a high probability that the message is
correctly delivered, stopping such repetition whenever leaving the
state.
When using TMMBN 0 as a PAUSED indication and when already in paused
state, the actions when entering local paused state depends on the
bounding set overhead value in the received TMMBR 0 that caused the
paused state and the bounding set overhead value used in (the RTP
stream sender's own) TMMBN 0:
TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL
NOT send any new TMMBN 0 replacing that active (more restrictive)
bounding set, even if entering local paused state.
TMMBN 0 overhead > TMMBR 0 overhead: The RTP stream sender SHALL
send TMMBN 0 with itself in the TMMBN bounding set when entering
local paused state.
The case above, when using TMMBN 0 as a PAUSED indication, being in
local paused state, and having received a TMMBR 0 with a bounding set
overhead value greater than the value the RTP stream sender would
itself use in a TMMBN 0, requires further consideration and is for
clarity henceforth referred to as "restricted local paused state".
As indicated in Figure 4, local paused state has higher precedence
than paused state (Section 6.3), and RESUME messages alone cannot
resume a paused RTP stream as long as the local decision still
applies. An RTP stream sender in local paused state is responsible
for leaving the state whenever the conditions that caused the
decision to enter the state no longer apply.
If the RTP stream sender is in restricted local paused state, it
cannot leave that state until the TMMBR 0 limit causing the state is
removed by a TMMBR > 0 (RESUME). If the RTP stream sender then needs
to stay in local paused state due to local considerations, it MAY
continue pausing the RTP stream by entering local paused state and
MUST then act accordingly, including sending a TMMBN 0 with itself in
the bounding set.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream.
When leaving the local paused state, the stream state SHALL become
Playing, regardless of whether or not there were any RTP stream
receivers that sent PAUSE for that stream during the local paused
state, effectively clearing the RTP stream sender's memory for that
stream.
7. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP feedback messages, i.e., transport-layer, payload-specific, and application-layer feedback messages. This document defines a new transport-layer feedback message, which is further subtyped into either a PAUSE request, a RESUME request, a PAUSED indication, or a REFUSED notification. The transport-layer feedback messages are identified by having the RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This transport-layer feedback message, containing one or more of the subtyped messages, is henceforth referred to as the PAUSE-RESUME message. The specific FCI format is identified by a Feedback Message Type (FMT) value in a common packet header for the feedback message defined in Section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport-layer feedback message FCI is identified by FMT value = 9. The Common Packet Format for feedback messages defined by AVPF [RFC4585] is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT | PT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Feedback Control Information (FCI) : : : Figure 5: AVPF Common Feedback Message Packet Format For the PAUSE-RESUME message defined in this memo, the following interpretations of the packet fields apply: FMT: The FMT value identifying the PAUSE-RESUME FCI: 9 PT: Payload Type = 205 (RTPFB) Length: As defined by AVPF, i.e., the length of this packet in 32-bit words minus one, including the header and any padding.
SSRC of packet sender: The SSRC of the RTP session participant
sending the messages in the FCI. Note, for endpoints that have
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to
send any of the pause message types.
SSRC of media source: Not used; SHALL be set to 0. The FCI
identifies the SSRC the message is targeted for.
The FCI field consists of one or more PAUSE, RESUME, PAUSED, or
REFUSED messages or any future extension. These messages have the
following FCI format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of FCI Entry in the PAUSE and RESUME Message
The FCI fields have the following definitions:
Target SSRC (32 bits): For a PAUSE-RESUME message, this value is the
SSRC that the request is intended for. For PAUSED, it MUST be the
SSRC being paused. If pausing is the result of a PAUSE request,
the value in PAUSED is effectively the same as Target SSRC in a
related PAUSE request. For REFUSED, it MUST be the Target SSRC of
the PAUSE or RESUME request that cannot change state. A CSRC MUST
NOT be used as a target as the interpretation of such a request is
unclear.
Type (4 bits): The pause feedback type. The values defined in this
specification are as follows:
0: PAUSE request message.
1: RESUME request message.
2: PAUSED indication message.
3: REFUSED notification message.
4-15: Reserved for future use. FCI fields with these Type values
SHALL be ignored on reception by receivers and MUST NOT be used
by senders implementing this specification.
Res: (4 bits): Type Specific reserved. It SHALL be ignored by
receivers implementing this specification and MUST be set to 0 by
senders implementing this specification.
Parameter Len (8 bits): Length of the Type Specific field in 32-bit
words. MAY be 0.
PauseID (16 bits): Message sequence identification, as described in
Section 5.2. SHALL be incremented by one modulo 2^16 for each new
PAUSE message, unless the message is retransmitted. The initial
value SHOULD be 0. The PauseID is scoped by the Target SSRC,
meaning that PAUSE, RESUME, and PAUSED messages therefore share
the same PauseID space for a specific Target SSRC.
Type Specific (variable): Defined per pause feedback type. MAY be
empty. A receiver implementing this specification MUST be able to
skip and ignore any unknown Type Specific data, even for Type
values defined in this specification.
8. Message Details
This section contains detailed explanations of each message defined
in this specification. All transmissions of requests and indications
are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section
SHALL be taken to apply to the extent possible and also when TMMBR/
TMMBN are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY
be used instead of the messages defined in this specification when
the effective topology is point to point. This use is expected to be
mainly for interworking with implementations that don't support the
messages defined in this specification but make use of TMMBR/TMMBN to
achieve a similar effect. If either sender or receiver learns that
the topology is not point to point, TMMBR/TMMBN MUST NOT be used for
pause/resume functionality. If the messages defined in this
specification are supported in addition to TMMBR/TMMBN by all
involved parties, pause/resume signaling MUST use messages from this
specification. If the topology is not point to point and the
messages defined in this specification are not supported, pause/
resume functionality with TMMBR/TMMBN MUST NOT be used.
For the scope of this specification, a past PauseID (Section 5.2) is
defined as having a value between and including (PauseID - 2^15) MOD
2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator.
Similarly, a future PauseID is defined as having a value between and including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. It is intentional that future PauseID is not defined as the entire range outside that of past PauseID. The remaining range of PauseID is simply "not current".8.1. PAUSE
An RTP stream receiver MAY schedule PAUSE for transmission at any time. PAUSE has no defined Type Specific parameters. PauseID SHOULD be the current PauseID, as indicated by PAUSED (Section 8.2), REFUSED (Section 8.4), or implicitly determined by previously received PAUSE or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be used if it was not possible to retrieve current PauseID information, in which case the PAUSE will either succeed or the current PauseID can be found in the returned REFUSED (Section 8.4). It can be noted that as a result of what is described in Section 6.1, PauseID is incremented by one, in modulo arithmetic, for each PAUSE request that is not a retransmission, compared to what was used in the last PAUSED indication sent by the media sender. PauseID in the message is supposed to match current PauseID at the RTP stream sender. If an RTP stream receiver that sent a PAUSE with a certain PauseID for a Target SSRC receives a RESUME or a REFUSED with the same PauseID for the same Target SSRC, it is RECOMMENDED that it refrains from scheduling further PAUSE requests for some appropriate time. This is because the RESUME indicates that there are other receivers that still wish to receive the stream, and the REFUSED indicates that the RTP stream sender is currently not able to pause the stream. What is an appropriate time can vary from application to application and will also depend on the importance of achieving the bandwidth saving, but 2-5 regular RTCP intervals is expected to be appropriate. If the targeted RTP stream does not pause, if no PAUSED indication with a future PauseID compared to the one used in PAUSE is received, and if no REFUSED with the current or a future PauseID is received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for retransmission, using the same current PauseID. RTT is the observed round trip to the RTP stream sender, and T_dither_max is defined in Section 3.4 of [RFC4585]. An RTP stream receiver in a bi-directional RTP communication will generally have an RTT estimate to the RTP stream sender, e.g., from RTCP SR/RR as described in Section 6.4 of
[RFC3550]. However, RTP stream receivers that don't send any RTP streams will lack an RTT estimate unless they use additional mechanisms, such as the "Receiver Reference Time Report Block" part of RTCP XR [RFC3611]. RTP stream receivers that lack an RTT estimate to the sender SHOULD use 500 ms as the default value. When an RTP stream sender in playing state (Section 6.1) receives a PAUSE with the current PauseID, and unless local considerations currently make it impossible to pause the stream, it SHALL enter pausing state (Section 6.2) and act accordingly. If an RTP stream sender receives a PAUSE with the current PauseID while in pausing, paused (Section 6.3), or local paused (Section 6.4) states, the received PAUSE SHALL be ignored.8.2. PAUSED
The PAUSED indication, if supported, MUST be sent whenever entering paused state (Section 6.3) or local paused state (Section 6.4). PauseID in the PAUSED message MUST contain the current PauseID that can be included in a subsequent RESUME (Section 8.3). For local paused state, this means that PauseID in the message is the current PauseID, just as if the RTP stream sender had sent a PAUSE to itself. PAUSED SHALL contain a fixed-length 32-bit parameter at the start of the Type Specific field with the extended RTP sequence number of the last RTP packet sent before the RTP stream was paused, in the same format as the extended highest sequence number received (Section 6.4.1 of [RFC3550]). After having entered paused or local paused state and thus having sent PAUSED once, PAUSED MUST also be included in (at least) the next two regular RTCP reports, given that the pause condition is then still effective. PAUSED indications MAY be retransmitted, subject to transmission rules (Section 8.5), to increase the probability that the message reaches the receiver in a timely fashion. This can be especially important when entering local paused state. The number of repetitions to use could be tuned to observed loss rate and desired loss probability, for example, based on RTCP reports received from the intended message target. While remaining in paused or local paused states, PAUSED MAY be included in all compound RTCP reports, as long as the negotiated RTCP bandwidth is not exceeded.
When in paused or local paused states, whenever the RTP stream sender learns that there are endpoints that did not previously receive the stream, for example, by RTCP reports with an SSRC and a CNAME that were not previously seen in the RTP session, it is RECOMMENDED to send PAUSED at the earliest opportunity and also to include it in (at least) the next two regular RTCP reports, given that the pause condition is then still effective.8.3. RESUME
An RTP stream receiver MAY schedule RESUME for transmission whenever it wishes to resume a paused stream or disapprove a stream from being paused. PauseID SHOULD be the current PauseID, as indicated by PAUSED (Section 8.2) or implicitly determined by previously received PAUSE (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be used if it was not possible to retrieve current PauseID information, in which case the RESUME will either succeed or the current PauseID can be found in a returned REFUSED (Section 8.4). If an RTP stream receiver that sent a RESUME with a certain PauseID receives a REFUSED with the same PauseID, it is RECOMMENDED that it refrains from scheduling further RESUME requests for some appropriate time since the REFUSE indicates that it is currently not possible to resume the stream. What is an appropriate time can vary from application to application and will also depend on the importance of resuming the stream, but 1-2 regular RTCP intervals is expected to be appropriate. RESUME requests MAY be retransmitted, subject to transmission rules (Section 8.5), to increase the probability that the message reaches the receiver in a timely fashion. The number of repetitions to use could be tuned to observed loss rate and desired loss probability, for example, based on RTCP reports received from the intended message target. Such retransmission SHOULD stop as soon as RTP packets from the targeted stream are received or when a REFUSED with the current PauseID for the targeted RTP stream is received. RESUME has no defined Type Specific parameters. When an RTP stream sender in pausing (Section 6.2), paused (Section 6.3), or local paused state (Section 6.4) receives a RESUME with the current PauseID, and unless local considerations currently make it impossible to resume the stream, it SHALL enter playing state (Section 6.1) and act accordingly. If the RTP stream sender is incapable of honoring a RESUME request with the current PauseID, or if it receives a RESUME request with a PauseID that is not the
current PauseID while in paused or pausing state, the RTP stream sender SHALL schedule a REFUSED message for transmission as specified below. If an RTP stream sender in playing state receives a RESUME containing either the current PauseID or a past PauseID, the received RESUME SHALL be ignored.8.4. REFUSED
If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME (Section 8.3) request containing the current PauseID, where the requested action cannot be fulfilled by the RTP stream sender due to some local consideration, it SHALL schedule transmission of a REFUSED notification containing the current PauseID from the rejected request. REFUSED has no defined Type Specific parameters. If an RTP stream sender receives a PAUSE or RESUME request with a PauseID that is not the current PauseID, it SHALL schedule a REFUSED notification containing the current PauseID, except if the RTP stream sender is in playing state and receives a RESUME with a past PauseID, in which case the RESUME SHALL be ignored. If several PAUSE or RESUME requests that would render identical REFUSED notifications are received before the scheduled REFUSED is sent, duplicate REFUSED notifications MUST NOT be scheduled for transmission. This effectively lets a single REFUSED respond to several ineffective PAUSE or RESUME requests. An RTP stream receiver that sent a PAUSE or RESUME request and receives a REFUSED containing the same PauseID as in the request SHOULD refrain from sending an identical request for some appropriate time to allow the condition that caused REFUSED to clear. For PAUSE, an appropriate time is suggested in Section 8.1. For RESUME, an appropriate time is suggested in Section 8.3. An RTP stream receiver that sent a PAUSE or RESUME request and receives a REFUSED containing a PauseID different from the request MAY schedule another request using the PauseID from the REFUSED notification.8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this specification MUST follow the normal AVPF-defined timing rules and depend on the session's mode of operation.
All messages defined in this specification, as well as TMMBR/TMMBN used for pause/resume purposes (Section 5.6), can use either Regular, Early, or Immediate timings but should make a trade-off between timely transmission (Section 4.1) and RTCP bandwidth consumption. This can be achieved by taking the following into consideration: o It is recommended that PAUSE use Early or Immediate timing, except for retransmissions where RTCP bandwidth can motivate the use of Regular timing. o The first transmission of PAUSED for each (non-wrapped) PauseID is recommended to be sent with Immediate or Early timing to stop unnecessary repetitions of PAUSE. It is recommended that subsequent transmissions of PAUSED for that PauseID use Regular timing to avoid excessive PAUSED RTCP bandwidth caused by multiple PAUSE requests. o It is recommended that unsolicited PAUSED (sent when entering local paused state (Section 6.4)) always use Immediate or Early timing, until PAUSED for that PauseID is considered delivered at least once to all receivers of the paused RTP stream, to avoid RTP stream receivers that take unnecessary corrective action when the RTP stream is no longer received, after which it is recommended that PAUSE uses Regular timing (as for PAUSED triggered by PAUSE above). o RESUME is often time critical, and it is recommended that it always uses Immediate or Early timing. o The first transmission of REFUSED for each (non-wrapped) PauseID is recommended to be sent with Immediate or Early timing to stop unnecessary repetitions of PAUSE or RESUME. It is recommended that subsequent REFUSED notifications for that PauseID use Regular timing to avoid excessive REFUSED RTCP bandwidth caused by multiple unreasonable requests.9. Signaling
The capability of handling messages defined in this specification MAY be exchanged at a higher layer such as SDP. This document extends the "rtcp-fb" attribute defined in Section 4 of AVPF [RFC4585] to include the request for pause and resume. This specification follows all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an "rtcp-fb" attribute relating to the payload type in a session description.
This specification defines a new parameter "pause" to the "ccm" feedback value defined in CCM [RFC5104], representing the capability to understand the RTCP feedback message and all of the defined FCIs of PAUSE, RESUME, PAUSED, and REFUSED. Note: When TMMBR 0 / TMMBN 0 are used to implement pause and resume functionality (with the restrictions described in this specification), signaling the "rtcp-fb" attribute with the "ccm" and "tmmbr" parameters is sufficient and no further signaling is necessary. There is, however, no guarantee that TMMBR/TMMBN implementations predating this specification work exactly as described here when used with a bitrate value of 0. The "pause" parameter has two optional attributes, which are "nowait" and "config": o "nowait" indicates that the hold-off period defined in Section 6.2 can be set to 0, reducing the latency before the stream can be paused after receiving a PAUSE request. This condition occurs when there will only be a single receiver per direction in the RTP session, for example, in point-to-point sessions. It is also possible to use in scenarios using unidirectional media. The conditions that allow "nowait" to be set (Section 6.2) also indicate that it would be possible to use CCM TMMBR/TMMBN as pause/resume signaling. o "config" allows for partial implementation of this specification according to the different roles in the use-cases section (Section 3) and takes a value that describes what subset is implemented: 1 Full implementation of this specification. This is the default configuration. A missing "config" pause attribute MUST be treated equivalent to providing a "config" value of 1. 2 The implementation intends to send PAUSE and RESUME requests for received RTP streams and is thus also capable of receiving PAUSED and REFUSED. It does not support receiving PAUSE and RESUME requests, but it may pause sent RTP streams due to local considerations and then intend to send PAUSED for them. 3 The implementation supports receiving PAUSE and RESUME requests targeted for RTP streams it sends. It will send PAUSED and REFUSED as needed. The node will not send any PAUSE and RESUME requests but supports and desires receiving PAUSED if received RTP streams are paused.
4 The implementation intends to send PAUSE and RESUME requests
for received RTP streams and is thus also capable of receiving
PAUSED and REFUSED. It cannot pause any RTP streams it sends,
and thus does not support receiving PAUSE and RESUME requests,
and it also does not support sending PAUSED indications.
5 The implementation supports receiving PAUSE and RESUME requests
targeted for RTP streams it sends. It will send PAUSED and
REFUSED as needed. It does not support sending PAUSE and
RESUME requests to pause received RTP streams, and it also does
not support receiving PAUSED indications.
6 The implementation supports sent and received RTP streams being
paused due to local considerations and thus supports sending
and receiving PAUSED indications.
7 The implementation supports and desires to receive PAUSED
indications for received RTP streams but does not pause or send
PAUSED indications for sent RTP streams. It does not support
any other messages defined in this specification.
8 The implementation supports pausing sent RTP streams and
sending PAUSED indications for them but does not support
receiving PAUSED indications for received RTP streams. It does
not support any other messages defined in this specification.
All implementers of this specification are encouraged to include full
support for all messages ("config=1"), but it is recognized that this
is sometimes not meaningful for implementations operating in an
environment where only parts of the functionality provided by this
specification are needed. The above defined "config" functionality
subsets provide a trade-off between completeness and the need for
implementation interoperability, achieving at least a level of
functionality corresponding to what is desired by the least-capable
party when used as specified here. Implementing any functionality
subsets other than those defined above is NOT RECOMMENDED.
When signaling a "config" value other than 1, an implementation MUST
ignore non-supported messages on reception and SHOULD omit sending
messages not supported by the remote peer. One example where it can
be motivated to send messages that some receivers do not support is
when there are multiple message receivers with different message
support (different "config" values). That approach avoids letting
the least-capable receiver limit the functionality provided to
others. The below table summarizes per-message send and receive
support for the different "config" pause attribute values ("X"
indicating support and "-" indicating non-support):
+---+-----------------------------+-----------------------------+ | # | Send | Receive | | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | +---+-----------------------------+-----------------------------+ | 1 | X X X X | X X X X | | 2 | X X X - | - - X X | | 3 | - - X X | X X X - | | 4 | X X - - | - - X X | | 5 | - - X X | X X - - | | 6 | - - X - | - - X - | | 7 | - - - - | - - X - | | 8 | - - X - | - - - - | +---+-----------------------------+-----------------------------+ Figure 7: Supported Messages for Different "config" Values In the above description of partial implementations, "config" values 2 and 4 correspond to the RTP Mixer in the 'RTP Mixer to Media Sender' use case (Section 3.2), and "config" values 3 and 5 correspond to the media sender in that same use case. For that use case, it should be clear that an RTP Mixer implementing only "config" values 3 or 5 will not provide a working solution. Similarly, for that use case, a media sender implementing only "config" values 2 or 4 will not provide a working solution. Both the RTP Mixer and the media sender will of course work when implementing the full set of messages, corresponding to "config=1". A partial implementation is not suitable for pause/resume support between cascaded RTP Mixers, but it would require support corresponding to "config=1" between such RTP Mixers. This is because an RTP Mixer is then also a media sender towards the other RTP Mixer, requiring support for the union of "config" values 2 and 3 or "config" values 4 and 5, which effectively becomes "config=1". As can be seen from Figure 7 above, "config" values 2 and 3 differ from "config" values 4 and 5 only in that in the latter, the PAUSE/ RESUME message sender (e.g., the RTP Mixer side) does not support local pause (Section 6.4) for any of its own streams and therefore also does not support sending PAUSED. Partial implementations that only support local pause functionality can declare this capability through "config" values 6-8. Viable fallback rules between different "config" values are described in Section 9.1 and Figure 9.
This is the resulting ABNF [RFC5234], extending the existing ABNF in Section 7.1 of CCM [RFC5104]: rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr) pause-attr = pause-config ; partial message support / "nowait" ; no hold-off period / byte-string ; for future extensions pause-config = "config=" pause-config-value pause-config-value = 1*2DIGIT ; byte-string as defined in RFC 4566 Figure 8: ABNF An endpoint implementing this specification and using SDP to signal capability SHOULD indicate the new "pause" parameter with "ccm" signaling but MAY instead use existing "ccm tmmbr" signaling [RFC5104] if the limitations in functionality when using TMMBR/TMMBN as described in this specification (Section 5.6) are considered acceptable. In that case, no partial message support is possible. The messages from this specification (Section 8) SHOULD NOT be used towards receivers that did not declare capability to receive those messages. The pause functionality can normally be expected to work independently of the payload type. However, there might exist situations where an endpoint needs to restrict or at least configure the capabilities differently depending on the payload type carrying the media stream. Reasons for this might relate to capabilities to correctly handle media boundaries and avoid any pause or resume operation to occur where it would leave a receiver or decoder with no choice than to attempt to repair or discard the media received just prior to or at the point of resuming. There MUST NOT be more than one "a=rtcp-fb" line with "pause" applicable to a single payload type in the SDP, unless the additional line uses "*" as the payload type, in which case "*" SHALL be interpreted as applicable to all listed payload types that do not have an explicit "pause" specification. The "config" pause attribute MUST NOT appear more than once for each "pause" CCM parameter. The "nowait" pause attribute MUST NOT appear more than once for each "pause" CCM parameter.9.1. Offer/Answer Use
An offerer implementing this specification needs to include the "pause" CCM parameter with a suitable configuration attribute ("config") in the SDP, according to what messages it intends to send and desires to receive in the session.
In SDP offer/answer, the "config" pause attribute and its message directions are interpreted based on the agent providing the SDP. The offerer is described in an offer, and the answerer is described in an answer. An answerer receiving an offer with a "pause" CCM line and a "config" pause attribute with a certain value, describing a certain capability to send and receive messages, MAY change the "config" pause attribute value in the answer to another configuration. The permitted answers are listed in the below table. SDP Offer "config" value | Permitted SDP Answer "config" values -------------------------+------------------------------------- 1 | 1, 2, 3, 4, 5, 6, 7, 8 2 | 3, 4, 5, 6, 7, 8 3 | 2, 4, 5, 6, 7, 8 4 | 5, 6, 7, 8 5 | 4, 6, 7, 8 6 | 6, 7, 8 7 | 8 8 | 7 Figure 9: "config" Values in Offer/Answer An offer or answer omitting the "config" pause attribute MUST be interpreted as equivalent to "config=1". Implementations of this specification MUST NOT use any "config" values other than those defined above in an offer or answer and MUST remove the "pause" CCM line in the answer when receiving an offer with a "config" value it does not understand. In all cases, the answerer MAY also completely remove any "pause" CCM line to indicate that it does not understand or desire to use any pause functionality for the affected payload types. If the offerer believes that itself and the intended answerer are likely the only endpoints in the RTP session, it MAY include the "nowait" pause attribute on the "pause" line in the offer. If an answerer receives the "nowait" pause attribute on the "pause" line in the SDP, and if it has information that the offerer and itself are not the only endpoints in the RTP session, it MUST NOT include any "nowait" pause attribute on its "pause" line in the SDP answer. The answerer MUST NOT add "nowait" on the "pause" line in the answer unless it is present on the "pause" line in the offer. If both offer and answer contain a "nowait" pause attribute, then the hold-off period is configured to 0 at both the offerer and answerer. Unknown pause attributes MUST be ignored in the offer and MUST then be omitted from the answer.
If both "pause" and "tmmbr" are present in the offer, both MAY be included also in the answer, in which case TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0), to avoid signaling ambiguity.9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving the SDP. This has implications on the interpretation of the SDP signaling extensions defined in this specification. First, the "config" pause attribute and its message directions are interpreted based on the node receiving the SDP, and it describes the RECOMMENDED level of operation. If the joining client does not support the indicated "config" value, some RTP session stream optimizations may not be possible in that some RTP streams will not be paused by the joining client, and/or the joining client may not be able to resume and receive wanted streams because they are paused. Second, the "nowait" pause attribute, if included, is followed as specified. It is the responsibility of the declarative SDP sender to determine if a configured node will participate in a session that will be point to point, based on the usage. For example, a conference client being configured for an any source multicast session using the Session Announcement Protocol (SAP) [RFC2974] will not be in a point-to-point session, thus "nowait" cannot be included. A Real-Time Streaming Protocol (RTSP) [RFC2326] client receiving a declarative SDP may very well be in a point-to-point session, although it is highly doubtful that an RTSP client would need to support this specification, considering the inherent PAUSE support in RTSP. Unknown pause attributes MUST be ignored. If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0) to avoid signaling ambiguity.
(page 39 continued on part 3)
