tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7728

 
 
 

RTP Stream Pause and Resume

Part 2 of 3, p. 22 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      ToC       Page 22 
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,

Top      Up      ToC       Page 23 
   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.

Top      Up      ToC       Page 24 
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

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
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.

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
      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.

Top      Up      ToC       Page 29 
   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

Top      Up      ToC       Page 30 
   [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.

Top      Up      ToC       Page 31 
   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

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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.

Top      Up      ToC       Page 34 
   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.

Top      Up      ToC       Page 35 
      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):

Top      Up      ToC       Page 36 
     +---+-----------------------------+-----------------------------+
     | # | 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.

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
   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.

Top      Up      ToC       Page 39 
   If both "pause" and "tmmbr" are present in the offer, both MAY be
   included also in the answer, in which case TMMBR/TMMBN MUST NOT be
   used for pause/resume purposes (with a bitrate value of 0), to avoid
   signaling ambiguity.

9.2.  Declarative Use

   In declarative use, the SDP is used to configure the node receiving
   the SDP.  This has implications on the interpretation of the SDP
   signaling extensions defined in this specification.

   First, the "config" pause attribute and its message directions are
   interpreted based on the node receiving the SDP, and it describes the
   RECOMMENDED level of operation.  If the joining client does not
   support the indicated "config" value, some RTP session stream
   optimizations may not be possible in that some RTP streams will not
   be paused by the joining client, and/or the joining client may not be
   able to resume and receive wanted streams because they are paused.

   Second, the "nowait" pause attribute, if included, is followed as
   specified.  It is the responsibility of the declarative SDP sender to
   determine if a configured node will participate in a session that
   will be point to point, based on the usage.  For example, a
   conference client being configured for an any source multicast
   session using the Session Announcement Protocol (SAP) [RFC2974] will
   not be in a point-to-point session, thus "nowait" cannot be included.
   A Real-Time Streaming Protocol (RTSP) [RFC2326] client receiving a
   declarative SDP may very well be in a point-to-point session,
   although it is highly doubtful that an RTSP client would need to
   support this specification, considering the inherent PAUSE support in
   RTSP.

   Unknown pause attributes MUST be ignored.

   If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
   NOT be used for pause/resume purposes (with a bitrate value of 0) to
   avoid signaling ambiguity.



(page 39 continued on part 3)

Next RFC Part