    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
                                                               M. Westerlund
                                                                    Ericsson
                                                               February 2016

                          RTP Stream Pause and Resume

    Abstract

       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
       http://www.rfc-editor.org/info/rfc7728.

    Burman, et al.               Standards Track                    [Page 1]

    RFC 7728                    RTP Stream Pause               February 2016

    Copyright Notice

       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
       than English.

    Burman, et al.               Standards Track                    [Page 2]

    RFC 7728                    RTP Stream Pause               February 2016

    Table of Contents

       1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   5
         2.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   5
         2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
         2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   7
       3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
         3.1.  Point to Point  . . . . . . . . . . . . . . . . . . . . .   8
         3.2.  RTP Mixer to Media Sender . . . . . . . . . . . . . . . .   9
         3.3.  RTP Mixer to Media Sender in Point to Multipoint  . . . .  10
         3.4.  Media Receiver to RTP Mixer . . . . . . . . . . . . . . .  11
         3.5.  Media Receiver to Media Sender across RTP Mixer . . . . .  11
       4.  Design Considerations . . . . . . . . . . . . . . . . . . . .  12
         4.1.  Real-Time Nature  . . . . . . . . . . . . . . . . . . . .  12
         4.2.  Message Direction . . . . . . . . . . . . . . . . . . . .  12
         4.3.  Apply to Individual Sources . . . . . . . . . . . . . . .  12
         4.4.  Consensus . . . . . . . . . . . . . . . . . . . . . . . .  13
         4.5.  Message Acknowledgments . . . . . . . . . . . . . . . . .  13
         4.6.  Request Retransmission  . . . . . . . . . . . . . . . . .  14
         4.7.  Sequence Numbering  . . . . . . . . . . . . . . . . . . .  14
         4.8.  Relation to Other Solutions . . . . . . . . . . . . . . .  14
       5.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .  15
         5.1.  Expressing Capability . . . . . . . . . . . . . . . . . .  16
         5.2.  PauseID . . . . . . . . . . . . . . . . . . . . . . . . .  16
         5.3.  Requesting to Pause . . . . . . . . . . . . . . . . . . .  17
         5.4.  Media Sender Pausing  . . . . . . . . . . . . . . . . . .  18
         5.5.  Requesting to Resume  . . . . . . . . . . . . . . . . . .  19
         5.6.  TMMBR/TMMBN Considerations  . . . . . . . . . . . . . . .  20
       6.  Participant States  . . . . . . . . . . . . . . . . . . . . .  22
         6.1.  Playing State . . . . . . . . . . . . . . . . . . . . . .  22
         6.2.  Pausing State . . . . . . . . . . . . . . . . . . . . . .  22
         6.3.  Paused State  . . . . . . . . . . . . . . . . . . . . . .  23
           6.3.1.  RTCP BYE Message  . . . . . . . . . . . . . . . . . .  24
           6.3.2.  SSRC Time-Out . . . . . . . . . . . . . . . . . . . .  24
         6.4.  Local Paused State  . . . . . . . . . . . . . . . . . . .  24
       7.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .  26
       8.  Message Details . . . . . . . . . . . . . . . . . . . . . . .  28
         8.1.  PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . .  29
         8.2.  PAUSED  . . . . . . . . . . . . . . . . . . . . . . . . .  30
         8.3.  RESUME  . . . . . . . . . . . . . . . . . . . . . . . . .  31
         8.4.  REFUSED . . . . . . . . . . . . . . . . . . . . . . . . .  32
         8.5.  Transmission Rules  . . . . . . . . . . . . . . . . . . .  32
       9.  Signaling . . . . . . . . . . . . . . . . . . . . . . . . . .  33
         9.1.  Offer/Answer Use  . . . . . . . . . . . . . . . . . . . .  37
         9.2.  Declarative Use . . . . . . . . . . . . . . . . . . . . .  39

    Burman, et al.               Standards Track                    [Page 3]

    RFC 7728                    RTP Stream Pause               February 2016

       10. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  39
         10.1.  Offer/Answer . . . . . . . . . . . . . . . . . . . . . .  40
         10.2.  Point-to-Point Session . . . . . . . . . . . . . . . . .  41
         10.3.  Point to Multipoint Using Mixer  . . . . . . . . . . . .  45
         10.4.  Point to Multipoint Using Translator . . . . . . . . . .  47
       11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  50
       12. Security Considerations . . . . . . . . . . . . . . . . . . .  50
       13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
         13.1.  Normative References . . . . . . . . . . . . . . . . . .  52
         13.2.  Informative References . . . . . . . . . . . . . . . . .  53
       Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  54
       Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  54
       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  55

    1.  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]
       offer/answer [RFC3264].

       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

    Burman, et al.               Standards Track                    [Page 4]

    RFC 7728                    RTP Stream Pause               February 2016

       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
       extension.

       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.

    2.  Definitions

    2.1.  Abbreviations

       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)

    Burman, et al.               Standards Track                    [Page 5]

    RFC 7728                    RTP Stream Pause               February 2016

       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)

    2.2.  Terminology

       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
          a Notification.

          PAUSE:    Request from an RTP stream receiver to pause a stream

          RESUME:   Request from an RTP stream receiver to resume a paused
                    stream

    Burman, et al.               Standards Track                    [Page 6]

    RFC 7728                    RTP Stream Pause               February 2016

          PAUSED:   Indication from an RTP stream sender that a stream is
                    paused

          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
          Depacketizer.

       Stream sender:  Short for RTP stream sender; the RTP entity
          responsible for creating an RTP stream, usually a Media
          Packetizer.

    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
       2119 [RFC2119].

    Burman, et al.               Standards Track                    [Page 7]

    RFC 7728                    RTP Stream Pause               February 2016

    3.  Use Cases

       This section discusses the main use cases for RTP stream pause and
       resume.

       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
           the peer.

       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
       pause/resume functionality.

    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.

    Burman, et al.               Standards Track                    [Page 8]

    RFC 7728                    RTP Stream Pause               February 2016

    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
          stream sender.

       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.

    Burman, et al.               Standards Track                    [Page 9]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 10]

    RFC 7728                    RTP Stream Pause               February 2016

       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
       use case.

       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/
       resume requests.

    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
       consideration.

    Burman, et al.               Standards Track                   [Page 11]

    RFC 7728                    RTP Stream Pause               February 2016

    4.  Design Considerations

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

    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.

    Burman, et al.               Standards Track                   [Page 12]

    RFC 7728                    RTP Stream Pause               February 2016

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

    Burman, et al.               Standards Track                   [Page 13]

    RFC 7728                    RTP Stream Pause               February 2016

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

       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

    Burman, et al.               Standards Track                   [Page 14]

    RFC 7728                    RTP Stream Pause               February 2016

       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
       streams.

       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
       last transmitted.

       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.

    Burman, et al.               Standards Track                   [Page 15]

    RFC 7728                    RTP Stream Pause               February 2016

    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.

    5.2.  PauseID

       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.

    Burman, et al.               Standards Track                   [Page 16]

    RFC 7728                    RTP Stream Pause               February 2016

    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
       PauseID value.

       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

    Burman, et al.               Standards Track                   [Page 17]

    RFC 7728                    RTP Stream Pause               February 2016

       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 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, regardless of the bounding set
       overhead value.

       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
       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 firsthand information that
       allows them to know whether they lost any packets just before the

    Burman, et al.               Standards Track                   [Page 18]

    RFC 7728                    RTP Stream Pause               February 2016

       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 current
       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 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
       true.

    Burman, et al.               Standards Track                   [Page 19]

    RFC 7728                    RTP Stream Pause               February 2016

       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
       considerations.

       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
       similar effect.

    Burman, et al.               Standards Track                   [Page 20]

    RFC 7728                    RTP Stream Pause               February 2016

       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 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
          Section 5.3.

    Burman, et al.               Standards Track                   [Page 21]

    RFC 7728                    RTP Stream Pause               February 2016

    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 Sender

    6.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,

    Burman, et al.               Standards Track                   [Page 22]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 23]

    RFC 7728                    RTP Stream Pause               February 2016

    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

    Burman, et al.               Standards Track                   [Page 24]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 25]

    RFC 7728                    RTP Stream Pause               February 2016

    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.

    Burman, et al.               Standards Track                   [Page 26]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 27]

    RFC 7728                    RTP Stream Pause               February 2016

          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.

    Burman, et al.               Standards Track                   [Page 28]

    RFC 7728                    RTP Stream Pause               February 2016

       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

    Burman, et al.               Standards Track                   [Page 29]

    RFC 7728                    RTP Stream Pause               February 2016

       [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.

    Burman, et al.               Standards Track                   [Page 30]

    RFC 7728                    RTP Stream Pause               February 2016

       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

    Burman, et al.               Standards Track                   [Page 31]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 32]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 33]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 34]

    RFC 7728                    RTP Stream Pause               February 2016

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

    Burman, et al.               Standards Track                   [Page 35]

    RFC 7728                    RTP Stream Pause               February 2016

         +---+-----------------------------+-----------------------------+
         | # | 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.

    Burman, et al.               Standards Track                   [Page 36]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 37]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    Burman, et al.               Standards Track                   [Page 38]

    RFC 7728                    RTP Stream Pause               February 2016

       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.

    10.  Examples

       The following examples show use of PAUSE and RESUME messages,
       including use of offer/answer:

       1.  Offer/Answer

       2.  Point-to-Point Session

       3.  Point to Multipoint using Mixer

    Burman, et al.               Standards Track                   [Page 39]

    RFC 7728                    RTP Stream Pause               February 2016

       4.  Point to Multipoint using Relay

    10.1.  Offer/Answer

       The below figures contain an example of how to show support for
       pausing and resuming the streams, as well as indicating whether or
       not the hold-off period can be set to 0.

       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

               Figure 10: SDP Offer with Pause and Resume Capability

       The offerer supports all of the messages defined in this
       specification, leaving out the optional "config" pause attribute.
       The offerer also believes that it will be the sole receiver of the
       answerer's stream as well as that the answerer will be the sole
       receiver of the offerer's stream and thus includes the "nowait" pause
       attribute for the "pause" parameter.

       This is the SDP answer:

       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 config=2

              Figure 11: SDP Answer with Pause and Resume Capability

       The answerer will not allow its sent streams to be paused or resumed
       and thus restricts the answer to indicate "config=2".  It also
       supports pausing its own RTP streams due to local considerations,
       which is why "config=2" is chosen rather than "config=4".  The
       answerer somehow knows that it will not be a point-to-point RTP
       session and has therefore removed "nowait" from the "pause" line,
       meaning that the offerer must use a non-zero hold-off period when
       being requested to pause the stream.

    Burman, et al.               Standards Track                   [Page 40]

    RFC 7728                    RTP Stream Pause               February 2016

       When using TMMBR 0 / TMMBN 0 to achieve pause and resume
       functionality, there are no differences in SDP compared to CCM
       [RFC5104]; therefore, no such examples are included here.

    10.2.  Point-to-Point Session

       This is the most basic scenario, which involves two participants,
       each acting as a sender and/or receiver.  Any RTP data receiver sends
       PAUSE or RESUME messages to the sender, which pauses or resumes
       transmission accordingly.  The hold-off period before pausing a
       stream is 0.

               +---------------+                   +---------------+
               |  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 >        |
                      |           t7: PAUSED(4)          |
                      | -------------------------------> |
                      :                                  :

              Figure 12: Pause and Resume Operation in Point to Point

       Figure 12 shows the basic pause and resume operation in a
       point-to-point scenario.  At time t1, an RTP sender sends data to a
       receiver.  At time t2, the RTP receiver requests the sender to pause
       the stream, using PauseID 3 (which it knew since before in this
       example).  The sender pauses the data and replies with a PAUSED
       containing the same PauseID.  Some time later (at time t4), the
       receiver requests the sender to resume, which resumes its
       transmission.  The next PAUSE, sent at time t6, contains an updated
       PauseID (4), with a corresponding PAUSED being sent at time t7.

    Burman, et al.               Standards Track                   [Page 41]

    RFC 7728                    RTP Stream Pause               February 2016

               +---------------+                   +---------------+
               |  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 >        |
                      |           t7: TMMBN 0            |
                      | -------------------------------> |
                      :                                  :

                Figure 13: TMMBR Pause and Resume in Point to Point

       Figure 13 describes the same point-to-point scenario as above, but
       using TMMBR/TMMBN signaling.

    Burman, et al.               Standards Track                   [Page 42]

    RFC 7728                    RTP Stream Pause               February 2016

               +---------------+                 +----------------+
               | RTP Sender A  |                 | RTP Receiver B |
               +---------------+                 +----------------+
                      :           t1: RTP data           :
                      | -------------------------------> |
                      |       < RTP data paused >        |
                      |           t2: TMMBN {A:0}        |
                      | -------------------------------> |
                      :       < Some time passes >       :
                      |           t3: TMMBR 0            |
                      | <------------------------------- |
                      |           t4: TMMBN {A:0,B:0}    |
                      | -------------------------------> |
                      :       < Some time passes >       :
                      |           t5: TMMBN {B:0}        |
                      | -------------------------------> |
                      :       < Some time passes >       :
                      |           t6: TMMBR 80000        |
                      | <------------------------------- |
                      |           t7: RTP data           |
                      | -------------------------------> |
                      :                                  :

                     Figure 14: Unsolicited PAUSED Using TMMBN

       Figure 14 describes the case when an RTP stream sender (A) chooses to
       pause an RTP stream due to local considerations.  Both A and the RTP
       stream receiver (B) use TMMBR/TMMBN signaling for pause/resume
       purposes.  A decides to pause the RTP stream at time t2 and uses
       TMMBN 0 to signal PAUSED, including itself in the TMMBN bounding set.
       At time t3, despite the fact that the RTP stream is still paused, B
       decides that it is no longer interested in receiving the RTP stream
       and signals PAUSE by sending a TMMBR 0.  As a result of that, the
       bounding set now contains both A and B, and A sends out a new TMMBN
       reflecting that.  After a while, at time t5, the local considerations
       that caused A to pause the RTP stream no longer apply, causing it to
       remove itself from the bounding set and to send a new TMMBN
       indicating this.  At time t6, B decides that it is now interested in
       receiving the RTP stream again and signals RESUME by sending a TMMBR
       containing a bitrate value greater than 0, causing A to resume
       sending RTP data.

    Burman, et al.               Standards Track                   [Page 43]

    RFC 7728                    RTP Stream Pause               February 2016

             +---------------+                       +---------------+
             |  RTP Sender   |                       | RTP Receiver  |
             +---------------+                       +---------------+
                    :           t1: RTP data                :
                    | ------------------------------------> |
                    |                   t2: PAUSE(7), lost  |
                    |                   <---X-------------- |
                    |                                       |
                    |           t3: RTP data                |
                    | ------------------------------------> |
                    :                                       :
                    |   < Time-out, 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)               |
                    | <------------------------------------ |
                    :                                       :

             Figure 15: Pause and Resume Operation with Messages Lost

       Figure 15 describes what happens if a PAUSE message from an RTP
       stream receiver does not reach the RTP stream sender.  After sending
       a PAUSE message, the RTP stream receiver waits for a time-out to
       detect if the RTP stream sender has paused the data transmission or
       has sent a PAUSED indication according to the rules discussed in
       Section 6.3.  As the PAUSE message is lost on the way (at time t2),
       RTP data continues to reach to the RTP stream receiver.  When the
       timer expires, the RTP stream receiver schedules a retransmission of
       the PAUSE message, which is sent at time t4.  If the PAUSE message
       now reaches the RTP stream sender, it pauses the RTP stream and
       replies with PAUSED.

       At time t6, the RTP stream receiver wishes to resume the stream again
       and sends a RESUME, which is lost.  This does not cause any severe
       effect, since there is no requirement to wait until further RESUME
       requests are sent, and another RESUME is sent already at time t7,
       which now reaches the RTP stream sender that consequently resumes the
       stream at time t8.  The time interval between t6 and t7 can vary but

    Burman, et al.               Standards Track                   [Page 44]

    RFC 7728                    RTP Stream Pause               February 2016

       may, for example, be one RTCP feedback transmission interval as
       determined by the AVPF rules.

       The RTP stream receiver did not realize that the RTP stream was
       resumed in time to stop yet another scheduled RESUME from being sent
       at time t9.  This is, however, harmless since RESUME contains a past
       PauseID and will be ignored by the RTP stream sender.  It will also
       not cause the RTP stream to be resumed even if the stream was paused
       again based on a PAUSE from some other receiver before receiving the
       RESUME, since the current PauseID was updated compared to the one in
       the stray RESUME, which contains a past PauseID and will be ignored
       by the RTP stream sender.

                +---------------+                 +---------------+
                |  RTP Sender   |                 | RTP Receiver  |
                +---------------+                 +---------------+
                       :           t1: RTP data          :
                       | ------------------------------> |
                       |           t2: PAUSE(11)         |
                       | <------------------------------ |
                       |                                 |
                       |    < Cannot pause RTP data >    |
                       |           t3: REFUSED(11)       |
                       | ------------------------------> |
                       |                                 |
                       |           t4: RTP data          |
                       | ------------------------------> |
                       :                                 :

               Figure 16: Pause Request is Refused in Point to Point

       In Figure 16, the receiver requests to pause the sender, which
       refuses to pause due to some consideration local to the sender and
       responds with a REFUSED message.

    10.3.  Point to Multipoint Using Mixer

       An RTP Mixer is an intermediate node connecting different transport-
       level clouds.  The Mixer receives streams from different RTP sources,
       selects or combines them based on the application's needs, and
       forwards the generated stream(s) to the destination.  The Mixer
       typically puts its own SSRC(s) in RTP data packets instead of the
       original source(s).

       The Mixer keeps track of all the streams delivered to the Mixer and
       how they are currently used.  In this example, Mixer (M) selects the
       video stream to deliver to the RTP stream receiver (R) based on the
       voice activity of the RTP stream senders (S1 and S2).  The video

    Burman, et al.               Standards Track                   [Page 45]

    RFC 7728                    RTP Stream Pause               February 2016

       stream will be delivered to R using M's SSRC and with a CSRC
       indicating the original source.

       Note that PauseID is not of any significance for the example and is
       therefore omitted in the description.

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

         Figure 17: Pause and Resume Operation for a Voice-Activated Mixer

       The session starts at t1 with S1 being the most active speaker and
       thus being selected as the single video stream to be delivered to R
       (t2) using M's SSRC but with S1 as the CSRC (indicated after the
       colon in the figure).  Then S2 joins the session at t3 and starts
       delivering an RTP stream to M.  As S2 has less voice activity then
       S1, M decides to pause S2 at t4 by sending S2 a PAUSE request.  At
       t5, S2 acknowledges with PAUSED and at the same instant stops
       delivering RTP to M.  At t6, the user at S2 starts speaking and
       becomes the most active speaker and M decides to switch the video
       stream to S2 and therefore quickly sends a RESUME request to S2.  At
       t7, S2 has received the RESUME request and acts on it by resuming RTP
       stream delivery to M.  When the RTP stream from t7 arrives at M, it
       switches this RTP stream into its SSRC (M) at t8 and changes the CSRC
       to S2.  As S1 now becomes unused, M issues a PAUSE request to S1 at

    Burman, et al.               Standards Track                   [Page 46]

    RFC 7728                    RTP Stream Pause               February 2016

       t9, which is acknowledged at t10 with PAUSED, and the RTP stream from
       S1 stops being delivered.

    10.4.  Point to Multipoint Using Translator

       A transport Relay in an RTP session forwards the message from one
       peer to all the others.  Unlike Mixer, the Relay does not mix the
       streams or change the SSRC of the messages or RTP media.  These
       examples are to show that the messages defined in this specification
       can be safely used also in a transport Relay case.  The parentheses
       in the figures contains (Target SSRC, PauseID) information for the
       messages defined in this specification.

              +-------------+     +-------------+     +-------------+
              |  Sender(S)  |     |    Relay    |     | 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)      |
                     |                   |------------------>|
                     :                   :                   :

       Figure 18: Pause and Resume Operation between Two Participants Using
                                      a Relay

       Figure 18 describes how a Relay can help the receiver (R) in pausing
       and resuming the sender (S).  S sends RTP data to R through the
       Relay, which just forwards the data without modifying the SSRCs.  R
       sends a PAUSE request to S which, in this example, knows that there

    Burman, et al.               Standards Track                   [Page 47]

    RFC 7728                    RTP Stream Pause               February 2016

       may be more receivers of the stream and waits a non-zero hold-off
       period to see if there is any other receiver that wants to receive
       the data, and when no disapproving RESUME messages are received, it
       pauses itself and replies with PAUSED.  Similarly R resumes S by
       sending a RESUME request through the Relay.  Since this describes
       only a single pause and resume operation for a single RTP stream
       sender, all messages use a single PauseID; in this example, it's
       three.

         +-----+            +-----+            +-----+            +-----+
         |  S  |            | Rel |            | 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)       |                  |
            |                  |----------------->------------------>|
            :                  :                  :                  :

         Figure 19: Pause and Resume Operation between One Sender and Two
                              Receivers through Relay

    Burman, et al.               Standards Track                   [Page 48]

    RFC 7728                    RTP Stream Pause               February 2016

       Figure 19 explains the pause and resume operations when a transport
       Relay (Rel) is involved between a sender (S) and two receivers (R1
       and R2) in an RTP session.  Each message exchange is represented by
       the time it happens.  At time t1, S starts sending an RTP stream to
       Rel, which forwards it to R1 and R2.  R1 and R2 receives RTP data
       from Rel at t2.  At this point, both R1 and R2 will send RTCP
       Receiver Reports to S informing that they received S's stream.

       After some time (at t3), R1 chooses to pause the stream.  On
       receiving the PAUSE request from R1 at t4, S knows that there is at
       least one receiver that may still want to receive the data and uses a
       non-zero hold-off period to wait for possible RESUME messages.  R2
       did also receive the PAUSE request at time t4 and since it still
       wants to receive the stream, it sends a RESUME for it at time t5,
       which is forwarded to sender S by Rel.  S sees the RESUME at time t6
       and continues to send data to Rel, which forwards it to both R1 and
       R2.  At t7, R2 chooses to pause the stream by sending a PAUSE request
       with an updated PauseID.  S still knows that there is more than one
       receiver (R1 and R2) that may want the stream and again waits a non-
       zero hold-off period, after which, and not having received any
       disapproving RESUME messages, it concludes that the stream must be
       paused.  S now stops sending the stream and replies with PAUSED to R1
       and R2.  When any of the receivers (R1 or R2) choose to resume the
       stream from S, in this example R1, it sends a RESUME request to S
       (also seen by R2).  S immediately resumes the stream.

       Consider also an RTP session that includes one or more receivers,
       paused sender(s), and a Relay.  Further assume that a new participant
       joins the session, which is not aware of the paused sender(s).  On
       receiving knowledge about the newly joined participant, e.g., any RTP
       traffic or RTCP report (i.e., either SR or RR) from the newly joined
       participant, the paused sender(s) immediately sends PAUSED
       indications for the paused streams since there is now a receiver in
       the session that did not pause the sender(s) and may want to receive
       the streams.  Having this information, the newly joined participant
       has the same possibility as any other participant to resume the
       paused streams.

    Burman, et al.               Standards Track                   [Page 49]

    RFC 7728                    RTP Stream Pause               February 2016

    11.  IANA Considerations

       Per this specification, IANA has made the following registrations:

       1.  A new value for media stream pause/resume has been registered in
           the "FMT Values for RTPFB Payload Types" registry located at the
           time of publication at: <http://www.iana.org/assignments/rtp-
           parameters>

           Value:  9

           Name:  PAUSE-RESUME

           Long Name:  Media Pause/Resume

           Reference:  RFC 7728

       2.  A new value "pause" to be registered with IANA in the "Codec
           Control Messages" registry located at the time of publication at:
           <http://www.iana.org/assignments/sdp-parameters>

           Value Name:  pause

           Long Name:  Media Pause/Resume

           Usable with:  ccm

           Reference:  RFC 7728

    12.  Security Considerations

       This document extends CCM [RFC5104] and defines new messages, i.e.,
       PAUSE, RESUME, PAUSED, and REFUSED.  The exchange of these new
       messages has some security implications, which need to be addressed
       by the user.

       The messages defined in this specification can have a substantial
       impact on the perceived media quality if used in a malicious way.
       First of all, there is the risk for Denial of Service (DoS) on any
       RTP session that uses the PAUSE-RESUME functionality.  By injecting
       one or more PAUSE requests into the RTP session, an attacker can
       potentially prevent any media from flowing, especially when the hold-
       off period is zero.  The injection of PAUSE messages is quite simple,
       requiring knowledge of the SSRC and the PauseID.  This information is
       visible to an on-path attacker unless RTCP messages are encrypted.
       Even off-path attacks are possible as signaling messages often carry
       the SSRC value, while the 16-bit PauseID has to be guessed or tried.
       The way of protecting the RTP session from these injections is to

    Burman, et al.               Standards Track                   [Page 50]

    RFC 7728                    RTP Stream Pause               February 2016

       perform source authentication combined with message integrity to
       prevent other than intended session participants from sending these
       messages.  The security solution should provide replay protection.
       Otherwise, if a session is long lived enough for the PauseID value to
       wrap, an attacker could replay old messages at the appropriate time
       to influence the media sender state.  There exist several different
       choices for securing RTP sessions to prevent this type of attack.
       The Secure Real-time Transport Protocol (SRTP) is the most common,
       but also other methods exist as discussed in "Options for Securing
       RTP Sessions" [RFC7201].

       Most of the methods for securing RTP, however, do not provide source
       authentication of each individual participant in a multiparty use
       case.  In case one of the session participants is malicious, it can
       wreck significant havoc within the RTP session and similarly cause a
       DoS on the RTP session from within.  That damage can also be
       attempted to be obfuscated by having the attacker impersonate other
       endpoints within the session.  These attacks can be mitigated by
       using a solution that provides true source authentication of all
       participants' RTCP packets.  However, that has other implications.
       For multiparty sessions including a middlebox, that middlebox is
       RECOMMENDED to perform checks on all forwarded RTCP packets so that
       each participant only uses its set of SSRCs to prevent the attacker
       from utilizing another participant's SSRCs.  An attacker that can
       send a PAUSE request that does not reach any participants other than
       the media sender can cause a stream to be paused without providing
       opportunity for opposition.  This is mitigated in multiparty
       topologies that ensure that requests are seen by all or most of the
       RTP session participants, enabling these participants to send a
       RESUME.  In topologies with middleboxes that consume and process
       PAUSE requests, the middlebox can also mitigate such behavior as it
       will commonly not generate or forward a PAUSE message if it knows of
       another participant having use for the media stream.

       The above text has been focused on using the PAUSE message as the
       tool for malicious impact on the RTP session.  That is because of the
       greater impact from denying users access to RTP media streams.  In
       contrast, if an attacker attempts to use RESUME in a malicious
       purpose, it will result in the media streams being delivered.
       However, such an attack basically prevents the use of the pause and
       resume functionality.  Thus, it potentially forces a reduction of the
       media quality due to limitation in available resources, like
       bandwidth that must be shared.

       The session establishment signaling is also a potential venue of
       attack, as that can be used to prevent the enabling of pause and
       resume functionality by modifying the signaling messages.  The above
       mitigation of attacks based on source authentication also requires

    Burman, et al.               Standards Track                   [Page 51]

    RFC 7728                    RTP Stream Pause               February 2016

       the signaling system to securely handle identities and assert that
       only the intended identities are allowed into the RTP session and
       provided with the relevant security contexts.

    13.  References

    13.1.  Normative References

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119,
                  DOI 10.17487/RFC2119, March 1997,
                  <http://www.rfc-editor.org/info/rfc2119>.

       [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
                  with Session Description Protocol (SDP)", RFC 3264,
                  DOI 10.17487/RFC3264, June 2002,
                  <http://www.rfc-editor.org/info/rfc3264>.

       [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
                  Jacobson, "RTP: A Transport Protocol for Real-Time
                  Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
                  July 2003, <http://www.rfc-editor.org/info/rfc3550>.

       [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
                  Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
                  July 2006, <http://www.rfc-editor.org/info/rfc4566>.

       [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
                  "Extended RTP Profile for Real-time Transport Control
                  Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
                  DOI 10.17487/RFC4585, July 2006,
                  <http://www.rfc-editor.org/info/rfc4585>.

       [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
                  "Codec Control Messages in the RTP Audio-Visual Profile
                  with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
                  February 2008, <http://www.rfc-editor.org/info/rfc5104>.

       [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", STD 68, RFC 5234,
                  DOI 10.17487/RFC5234, January 2008,
                  <http://www.rfc-editor.org/info/rfc5234>.

       [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
                  (ICE): A Protocol for Network Address Translator (NAT)
                  Traversal for Offer/Answer Protocols", RFC 5245,
                  DOI 10.17487/RFC5245, April 2010,
                  <http://www.rfc-editor.org/info/rfc5245>.

    Burman, et al.               Standards Track                   [Page 52]

    RFC 7728                    RTP Stream Pause               February 2016

       [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
                  Keeping Alive the NAT Mappings Associated with RTP / RTP
                  Control Protocol (RTCP) Flows", RFC 6263,
                  DOI 10.17487/RFC6263, June 2011,
                  <http://www.rfc-editor.org/info/rfc6263>.

    13.2.  Informative References

       [MULTI-STREAM-OPT]
                  Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
                  "Sending Multiple Media Streams in a Single RTP Session:
                  Grouping RTCP Reception Statistics and Other Feedback",
                  Work in Progress, draft-ietf-avtcore-rtp-multi-stream-
                  optimisation-11, December 2015.

       [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
                  Streaming Protocol (RTSP)", RFC 2326,
                  DOI 10.17487/RFC2326, April 1998,
                  <http://www.rfc-editor.org/info/rfc2326>.

       [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
                  Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
                  October 2000, <http://www.rfc-editor.org/info/rfc2974>.

       [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                  A., Peterson, J., Sparks, R., Handley, M., and E.
                  Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                  DOI 10.17487/RFC3261, June 2002,
                  <http://www.rfc-editor.org/info/rfc3261>.

       [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
                  "RTP Control Protocol Extended Reports (RTCP XR)",
                  RFC 3611, DOI 10.17487/RFC3611, November 2003,
                  <http://www.rfc-editor.org/info/rfc3611>.

       [RFC6190]  Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
                  "RTP Payload Format for Scalable Video Coding", RFC 6190,
                  DOI 10.17487/RFC6190, May 2011,
                  <http://www.rfc-editor.org/info/rfc6190>.

       [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
                  Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
                  <http://www.rfc-editor.org/info/rfc7201>.

       [RFC7478]  Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
                  Time Communication Use Cases and Requirements", RFC 7478,
                  DOI 10.17487/RFC7478, March 2015,
                  <http://www.rfc-editor.org/info/rfc7478>.

    Burman, et al.               Standards Track                   [Page 53]

    RFC 7728                    RTP Stream Pause               February 2016

       [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
                  B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
                  for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
                  DOI 10.17487/RFC7656, November 2015,
                  <http://www.rfc-editor.org/info/rfc7656>.

       [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
                  DOI 10.17487/RFC7667, November 2015,
                  <http://www.rfc-editor.org/info/rfc7667>.

       [SDP-SIMULCAST]
                  Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
                  "Using Simulcast in SDP and RTP Sessions", Work in
                  Progress, draft-ietf-mmusic-sdp-simulcast-04, February
                  2016.

    Acknowledgments

       Daniel Grondal made valuable contributions during the initial
       versions of this document.  The authors would also like to thank Emil
       Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer
       Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
       review comments.

    Contributors

       Daniel Grondal contributed in the creation and writing of early
       versions of this specification.  Christian Groves contributed
       significantly to the SDP "config" pause attribute and its use in
       offer/answer.

    Burman, et al.               Standards Track                   [Page 54]

    RFC 7728                    RTP Stream Pause               February 2016

    Authors' Addresses

       Bo Burman
       Ericsson
       Kistavagen 25
       SE - 164 80 Kista
       Sweden

       Email: bo.burman@ericsson.com

       Azam Akram
       Ericsson
       Farogatan 6
       SE - 164 80 Kista
       Sweden

       Phone: +46107142658
       Email: akram.muhammadazam@gmail.com
       URI:   www.ericsson.com

       Roni Even
       Huawei Technologies
       Tel Aviv
       Israel

       Email: roni.even@mail01.huawei.com

       Magnus Westerlund
       Ericsson
       Farogatan 6
       SE - 164 80 Kista
       Sweden

       Phone: +46107148287
       Email: magnus.westerlund@ericsson.com

    Burman, et al.               Standards Track                   [Page 55]