+-----+
+---+     /       \     +-----------+      +---+
| 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 special care must be taken as not to pause a stream that is still wanted by some receivers.

3.4. Media Receiver to RTP Mixer

An End Point in Figure 2 could potentially request to pause the delivery of a given stream. Possible reasons include the ones in the point to point case [sec-point-to-point] 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 use case.

However, when the End Point 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/resume requests.

3.5. Media Receiver to Media Sender Across RTP Mixer

An End Point, 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 it´s stream indications.
2. An End Point 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 End Point 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 consideration.

4. Design Considerations

This section describes the requirements that this specification needs to meet.

4.1. Real-time Nature

The first section [sec-intro] 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 real-time in order for them to be purposeful. The pause operation is arguably not very time critical 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.

4.2. Message Direction

It is the responsibility of an RTP stream receiver, who wants to pause or resume a stream from the sender(s), to transmit PAUSE and RESUME messages. An RTP stream sender who likes to pause itself, can simply do it. 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.

4.4. Consensus

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, independent of it being multicast, a mesh with joint RTP session or a transport Translator based, must not single-handedly cause the stream to be paused without letting all other receivers to voice their opinions on whether or not the stream should be paused. A consequence of this is that a newly joining receiver, for example indicated by an RTCP Receiver Report containing both a new SSRC and a CNAME that does not already occur in the session, firstly needs to learn the existence of paused streams, and secondly should be able to resume any paused stream. Any single receiver wanting to resume a stream should also cause it to be resumed.

4.5. 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 End Point does not reach its destination, i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP stream sender and are effective, i.e., an active RTP stream sender pauses, or a resuming RTP stream sender have 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. This error condition, a negative acknowledgment, may be needed to avoid unnecessary retransmission of requests [sec-retransmit].

4.6. Retransmitting Requests

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 that are more time critical, the best resume performance may be achieved by repeating the request as often as possible until a sufficient number have been sent to reach a high probability of request delivery, or the stream gets delivered.

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 previous request.

Since RESUME always takes precedence over PAUSE and are 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 references 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 [RFC4566] to carry pause and resume information means that it will need to traverse the entire signaling path to reach the signaling destination (either the remote End Point or the entity controlling the RTP Mixer), across any signaling proxies that potentially also has to process the SDP content to determine if they are expected to act on it. The amount of bandwidth required for a SIP/SDP-based signaling solution is in the order of at least 10 times more than an RTCP-based solution. Especially for UA sitting on mobile wireless access, this will risk introducing delays that are too long [sec-real-time] to provide a good user experience, and the bandwidth cost may also be considered infeasible compared to an RTCP-based solution. RTCP data is sent through the media path, which is likely shorter (contains fewer intermediate nodes) than the signaling path, may anyway have to traverse a few intermediate nodes. 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 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.

It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent possible, and to define a small set of new RTCP feedback messages where new semantics is needed. Considerations that apply when using TMMBR/TMMBN for pause and resume purposes are also described.

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, PAUSED indication, a REFUSE response, or an extension to this specification. This structure allows a single feedback message to handle pause functionality on a number of streams.

The PAUSED functionality is also defined in such a way that it can be used standalone by the RTP stream sender to indicate a local decision to pause, and inform any receiver of the fact that halting media delivery is deliberate and which RTP packet was the last transmitted.

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 End Point can use an extension to CCM SDP signaling to declare capability to understand the messages defined in this specification. Capability to understand PAUSED indication is defined separately from the others to support partial implementation, which is specifically believed to be feasible for the RTP Mixer to Media Sender use case [sec-mixer-to-media-sender].

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.

5.2. Requesting to Pause

An RTP stream receiver can choose to request PAUSE at any time, subject to AVPF timing rules. This also applies when using TMMBR 0 in the point-to-point case.

The PAUSE request contains a PauseID, which is incremented by one (in modulo arithmetic) with each PAUSE request that is not a re-transmission. The PauseID is scoped by and thus a property of the targeted RTP stream (SSRC).

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 [sec-overview-resume] for the same stream and with the same PauseID as in the disapproved PAUSE. If such disapproving RESUME arrives at the RTP stream sender during the wait period before the stream is paused, the pause is not performed. In point-to-point configurations, the wait period may be set to zero. Using a wait period of zero is also appropriate when using TMMBR 0 and in line with the semantics for that message.

If the RTP stream sender receives further PAUSE requests with the available PauseID while waiting as described above, those additional requests are ignored.

If the PAUSE request or TMMBR 0 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 [sec-overview-pausing] or TMMBN 0 for the stream. The same condition can be caused by the RTP stream sender having received a disapproving RESUME from a stream receiver A for a PAUSE request sent by a stream sender B, but 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 re-transmitted using the same PauseID. If using TMMBR 0 the request MAY be re-transmitted when the requester fails to receive a TMMBN 0 confirmation.

If the pending stream pause is aborted due to a disapproving RESUME, the PauseID from the disapproved PAUSE is invalidated by the RESUME and any new PAUSE must use an incremented PauseID (in modulo arithmetic) to be effective.

An RTP stream sender receiving a PAUSE not using the available PauseID informs the RTP stream receiver sending the ineffective PAUSE of this condition by sending a REFUSE response that contains the next available PauseID value. This REFUSE also informs the RTP stream receiver that it is probably not feasible to send another PAUSE for some time, not even with the available PauseID, since there are other RTP stream receivers that wish to receive the stream.

A similar 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 available PauseID to use. The REFUSE response 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 [sec-real-time].

There may be local considerations making it impossible or infeasible to pause the stream, and the RTP stream sender can then respond with a REFUSE. In this case, if the used PauseID would otherwise have been effective, the REFUSE contains the same PauseID as in the PAUSE request, and the PauseID is kept as available. Note that when using TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to the existing restriction in section 4.2.2.2 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.

If the RTP stream sender receives several identical PAUSE for an RTP stream that was already at least once responded with REFUSE and the condition causing REFUSE remains, those additional REFUSE should be sent with regular RTCP timing. A single REFUSE can respond to several identical PAUSE requests.

5.3. Media Sender Pausing

An RTP stream sender can choose to pause the stream at any time. This can either be as a result of receiving a PAUSE, or be based on some local sender consideration. When it does, it sends a PAUSED indication, containing the available PauseID. If the stream was paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is said on PAUSED in the rest of this paragraph apply also to the use of TMMBN 0, except for PAUSED message parameters. Note that PauseID is incremented when pausing locally (without having received a PAUSE). It also sends the PAUSED indication in the next two regular RTCP reports, given that the pause condition is then still effective.

The RTP stream sender may want to apply some local consideration to exactly when the stream is paused, for example completing some media unit or a forward error correction block, before pausing the stream.

The PAUSED indication also contains information about the RTP extended highest sequence number when the pause became effective. This provides RTP stream receivers with first hand information allowing 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 control algorithms.

If the RTP stream sender receives PAUSE requests with the available PauseID while the stream is already paused, those requests are ignored.

As long as the stream is being paused, the PAUSED indication MAY be sent together with any regular RTCP SR or RR. Including PAUSED in this way allows RTP stream receivers joining while the stream is paused to quickly know that there is a paused stream, what the last sent extended RTP sequence number was, and what the next available PauseID is to be able to construct valid PAUSE and RESUME requests at a later stage.

When the RTP stream sender learns that a new End Point 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. It should in addition continue to include PAUSED indications in at least two regular RTCP reports.

5.4. Requesting to Resume

An RTP stream receiver can request to resume a stream with a RESUME request at any time, subject to AVPF timing rules. If the stream was paused with TMMBR 0, resuming the stream is made with TMMBR containing a bitrate value larger than 0. The bitrate value used when resuming after a PAUSE with TMMBR 0 is either according to known limitations, or the configured maximum for the stream or session. What is said on RESUME in the rest of this paragraph apply also to the use of TMMBR with a bitrate value larger than 0, except for RESUME message parameters.

The RTP stream receiver must include the available PauseID in the RESUME request for it to be effective.

A pausing RTP stream sender that receives a RESUME including the correct available 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, 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 MAY then respond with a REFUSE containing the same PauseID as in the RESUME. When receiving such REFUSE with a PauseID identical to the one in the sent RESUME, RTP stream receivers SHOULD then avoid sending further RESUME requests for some reasonable amount of time, to allow the condition to clear.

If the RTP stream sender receives several identical RESUME for an RTP stream that was already at least once responded with REFUSE and the condition causing REFUSE remains, those additional REFUSE should be sent with regular RTCP timing. A single REFUSE can respond to several identical RESUME requests.

When resuming a paused stream, especially for media that makes use of temporal redundancy between samples such as video, the temporal dependency between samples taken before the pause and at the time instant the stream is resumed may not be appropriate to use in the encoding. Should such temporal dependency between before and after the media was paused be used by the RTP stream sender, it requires the RTP stream receiver to have saved the sample from before the pause for successful continued decoding when resuming. The use of this temporal dependency is left up to the RTP stream sender. If temporal dependency is not used when the RTP stream is resumed, the first encoded sample after the pause will not contain any temporal dependency to samples before the pause (for video it may be a so-called intra picture). If temporal dependency to 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.5. TMMBR/TMMBN Considerations

As stated, 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 is a brief summary of what functionality is provided when using TMMBR/TMMBN:

TMMBR 0:

Corresponds to PAUSE, without the requirement for any hold-off period to wait for RESUME before pausing the stream.

TMMBR >0:

Corresponds to RESUME when the 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.

TMMBN 0:

Corresponds to PAUSED. Also corresponds to a REFUSE indication when a stream is requested to be resumed with TMMBR >0.

TMMBN >0:

Cannot be used as REFUSE indication when a stream is requested to be paused with TMMBR 0, for reasons stated in Section 5.2.

6. Participant States

This document introduces three new states for a stream in an RTP sender, according to the figure and sub-sections below. Any references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL be taken to apply to the extent possible also when TMMBR/TMMBN are used [sec-overview-tmmbr] 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   +---------+

 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)                 :
:                                                               :

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                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
                   / SP "paused" *(SP paused-attr)
pause-attr        = direction
                  / "nowait"
                  / token ; for future extensions
paused-attr       = direction
                  / token ; for future extensions
direction         = "dir=" direction-alts
direction-alts    = "sendonly" / "recvonly" / "sendrecv"

v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media
t=0 0
c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait
a=rtcp-fb:* ccm paused

v=0
o=bob 293847192 293847192 IN IP4 bob.example.com
s=-
t=0 0
c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause dir=sendonly
a=rtcp-fb:98 ccm paused 

+---------------+                   +---------------+
|  RTP Sender   |                   | RTP Receiver  |
+---------------+                   +---------------+
       :           t1: RTP data           :
       | -------------------------------> |
       |           t2: PAUSE(3)           |
       | <------------------------------- |
       |       < RTP data paused >        |
       |           t3: PAUSED(3)          |
       | -------------------------------> |
       :       < Some time passes >       :
       |           t4: RESUME(3)          |
       | <------------------------------- |
       |           t5: RTP data           |
       | -------------------------------> |
       :       < Some time passes >       :
       |           t6: PAUSE(4)           |
       | <------------------------------- |
       |       < RTP data paused >        |
       :                                  :

+---------------+                   +---------------+
|  RTP Sender   |                   | RTP Receiver  |
+---------------+                   +---------------+
       :           t1: RTP data           :
       | -------------------------------> |
       |           t2: TMMBR 0            |
       | <------------------------------- |
       |       < RTP data paused >        |
       |           t3: TMMBN 0            |
       | -------------------------------> |
       :       < Some time passes >       :
       |           t4: TMMBR 150000       |
       | <------------------------------- |
       |           t5: RTP data           |
       | -------------------------------> |
       :       < Some time passes >       :
       |           t6: TMMBR 0            |
       | <------------------------------- |
       |       < RTP data paused >        |
       :                                  :

+---------------+                       +---------------+
|  RTP Sender   |                       | RTP Receiver  |
+---------------+                       +---------------+
       :           t1: RTP data                :
       | ------------------------------------> |
       |                   t2: PAUSE(7), lost  |
       |                   <---X-------------- |
       |                                       |
       |           t3: RTP data                |
       | ------------------------------------> |
       :                                       :
       |    <Timeout, still receiving data>    |
       |           t4: PAUSE(7)                |
       | <------------------------------------ |
       |          < RTP data paused >          |
       |           t5: PAUSED(7)               | 
       | ------------------------------------> |
       :          < Some time passes >         :
       |                   t6: RESUME(7), lost |
       |                   <---X-------------- |
       |           t7: RESUME(7)               |
       | <------------------------------------ |
       |           t8: RTP data                |
       | ------------------------------------> |
       |           t9: RESUME(7)               |
       | <------------------------------------ |
       :                                       :

+---------------+                 +---------------+
|  RTP Sender   |                 | RTP Receiver  |
+---------------+                 +---------------+
       :           t1: RTP data          :
       | ------------------------------> |
       |           t2: PAUSE(11)         |
       | <------------------------------ |
       |                                 | 
       |  < Can not pause RTP data >     |
       |           t3: REFUSE(11)        | 
       | ------------------------------> |
       |                                 |
       |           t4: RTP data          |
       | ------------------------------> |
       :                                 :

+-----+            +-----+            +-----+            +-----+
|  R  |            |  M  |            | S1  |            | S2  |
+-----+            +-----|            +-----+            +-----+
   :                  :   t1:RTP(S1)     :                  :
   | t2:RTP(M:S1)     |<-----------------|                  |
   |<-----------------|                  |                  |
   |                  | t3:RTP(S2)       |                  |
   |                  |<------------------------------------|
   |                  |  t4: PAUSE(S2)   |                  |
   |                  |------------------------------------>|
   |                  |                  |   t5: PAUSED(S2) |
   |                  |<------------------------------------|
   |                  |                  | <S2:No RTP to M> |
   |                  | t6: RESUME(S2)   |                  |
   |                  |------------------------------------>|
   |                  |                  | t7: RTP to M     |
   |                  |<------------------------------------|
   |   t8:RTP(M:S2)   |                  |                  |
   |<-----------------|                  |                  |
   |                  | t9:PAUSE(S1)     |                  |
   |                  |----------------->|                  |
   |                  | t10:PAUSED(S1)   |                  |
   |                  |<-----------------|                  |
   |                  | <S1:No RTP to M> |                  |
   :                  :                  :                  :

+-------------+     +-------------+     +--------------+
|  Sender(S)  |     | Translator  |     | Receiver(R)  |
+-------------+     +-------------|     +--------------+
       : t1: RTP(S)        :                   :
       |------------------>|                   |
       |                   | t2: RTP (S)       |
       |                   |------------------>|
       |                   | t3: PAUSE(S,3)    |
       |                   |<------------------|
       | t4:PAUSE(S,3)     |                   |
       |<------------------|                   |
       : < Sender waiting for possible RESUME> :
       |          < RTP data paused >          |              
       | t5: PAUSED(S,3)   |                   |
       |------------------>|                   |
       |                   | t6: PAUSED(S,3)   |
       |                   |------------------>|
       :                   :                   :
       |                   | t7: RESUME(S,3)   |
       |                   |<------------------|
       | t8: RESUME(S,3)   |                   |
       |<------------------|                   |
       | t9: RTP (S)       |                   |
       |------------------>|                   |
       |                   | t10: RTP (S)      |
       |                   |------------------>|
       :                   :                   :

+-----+            +-----+            +-----+            +-----+
|  S  |            |  T  |            | R1  |            | R2  |
+-----+            +-----|            +-----+            +-----+
   : t1:RTP(S)        :                  :                  :
   |----------------->|                  |                  |
   |                  | t2:RTP(S)        |                  |
   |                  |----------------->------------------>|
   |                  | t3:PAUSE(S,7)    |                  |
   |                  |<-----------------|                  |
   | t4:PAUSE(S,7)    |                  |                  |
   |<-----------------|------------------------------------>|
   |                  |                  |   t5:RESUME(S,7) |
   |                  |<------------------------------------|
   | t6:RESUME(S,7)   |                  |                  |
   |<-----------------|                  |                  |
   |                  |<RTP stream continues to R1 and R2>  |
   |                  |                  |   t7: PAUSE(S,8) |
   |                  |<------------------------------------|
   | t8:PAUSE(S,8)    |                  |                  |
   |<-----------------|                  |                  |
   :                  :                  :                  :
   | < Pauses RTP Stream >               |                  |
   | t9:PAUSED(S,8)   |                  |                  |
   |----------------->|                  |                  |
   |                  | t10:PAUSED(S,8)  |                  |
   |                  |----------------->------------------>|
   :                  :                  :                  :
   |                  | t11:RESUME(S,8)  |                  |
   |                  |<-----------------|                  |
   | t12:RESUME(S,8)  |                  |                  |
   |<-----------------|                  |                  |
   | t13:RTP(S)       |                  |                  |
   |----------------->|                  |                  |
   |                  | t14:RTP(S)       |                  |
   |                  |----------------->------------------>|
   :                  :                  :                  :