Skip to main content

RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-09

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7728.
Authors Bo Burman , Azam Akram , Roni Even , Magnus Westerlund
Last updated 2015-09-03
Replaces draft-westerlund-avtext-rtp-stream-pause
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jonathan Lennox
Shepherd write-up Show Last changed 2015-06-08
IESG IESG state Became RFC 7728 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Ben Campbell
Send notices to draft-ietf-avtext-rtp-stream-pause@ietf.org, draft-ietf-avtext-rtp-stream-pause.ad@ietf.org, jonathan@vidyo.com, draft-ietf-avtext-rtp-stream-pause.shepherd@ietf.org, avtext-chairs@ietf.org
IANA IANA review state Version Changed - Review Needed
draft-ietf-avtext-rtp-stream-pause-09
gt;               |                  |
        | 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

   Figure 19 explains the pause and resume operations when a transport
   Relay is involved between a sender and two receivers in an RTP
   session.  Each message exchange is represented by the time it
   happens.  At time t1, Sender (S) starts sending an RTP stream to the
   Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and
   R2 receives RTP data from Relay at t2.  At this point, both R1 and R2

Burman, et al.            Expires March 6, 2016                [Page 48]
Internet-Draft              RTP Stream Pause              September 2015

   will send RTCP Receiver Reports to S informing that they receive 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 are 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 the sender S by the Relay.  The sender S sees
   the RESUME at time t6 and continues to send data to Relay which
   forwards to both R1 and R2.  At t7, the receiver R2 chooses to pause
   the stream by sending a PAUSE request with an updated PauseID.  The
   sender S still knows that there are 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,
   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) chooses to resume the stream from S, in this
   example R1, it sends a RESUME request to the sender (also seen by
   R2).  The RTP sender immediately resumes the stream.

   Consider also an RTP session which 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.

11.  IANA Considerations

   This specification requests the following registrations from IANA:

   1.  A new value for media stream pause / resume to be registered with
       IANA in the "FMT Values for RTPFB Payload Types" registry located
       at the time of publication at: http://www.iana.org/assignments/
       rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8

       Value:  TBA1

       Name:  PAUSE-RESUME

       Long Name:  Media Pause / Resume

Burman, et al.            Expires March 6, 2016                [Page 49]
Internet-Draft              RTP Stream Pause              September 2015

       Reference:  This RFC

   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/sdp-
       parameters.xhtml#sdp-parameters-19

       Value Name:  pause

       Long Name:  Media Pause / Resume

       Usable with:  ccm

       Reference:  This RFC

12.  Security Considerations

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

   The messages defined in this specification can have 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 signalling messages often carry
   the SSRC value, while the 16-bit PauseID have to be guessed or tried.
   The way of protecting the RTP session from these injections is to
   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 an attacker could for sessions that are long lived enough
   to wrap the PauseID 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.
   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 multi-party use
   case.  In case one of the session participants is malicious, it can
   wreck significant havoc within the RTP session and similarly cause a

Burman, et al.            Expires March 6, 2016                [Page 50]
Internet-Draft              RTP Stream Pause              September 2015

   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 multi-party 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
   utilizing another participant's SSRCs.  An attacker that can send a
   PAUSE request without it reaching any other participant than the
   media sender can have its request being unopposed.  This is mitigated
   in multi-party topologies that ensure that requests are seen by all
   or most of the RTP session participants, enabling these participants
   to send 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 that the media streams are delivered.
   However, such an attack basically prevents the use the Pause and
   Resume functionality.  Thus, potentially forcing a reduction of the
   media quality due to limitation in available resources, like
   bandwidth that must be shared.

   The session establishment signalling is also a potential venue of
   attack, as that can be used to prevent the enabling of Pause and
   Resume functionality by modifying the signalling messages.  The above
   mitigation of attacks based on source authentication also requires
   the signalling system to securely handle identities, and assert that
   only the intended identities are allowed into the RTP session and
   provided the relevant security contexts.

13.  Contributors

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

14.  Acknowledgements

   Daniel Grondal made valuable contributions during the initial
   versions of this draft.  The authors would also like to thank Emil
   Ivov, Christian Groves, David Madnelberg, Meral Shirazipour, Spencer

Burman, et al.            Expires March 6, 2016                [Page 51]
Internet-Draft              RTP Stream Pause              September 2015

   Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
   review comments.

15.  References

15.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.            Expires March 6, 2016                [Page 52]
Internet-Draft              RTP Stream Pause              September 2015

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

15.2.  Informative References

   [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
              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",
              draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work
              in progress), July 2015.

   [I-D.ietf-avtcore-rtp-topologies-update]
              Westerlund, M. and S. Wenger, "RTP Topologies", draft-
              ietf-avtcore-rtp-topologies-update-10 (work in progress),
              July 2015.

   [I-D.ietf-avtext-rtp-grouping-taxonomy]
              Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
              B. Burman, "A Taxonomy of Semantics and Mechanisms for
              Real-Time Transport Protocol (RTP) Sources", draft-ietf-
              avtext-rtp-grouping-taxonomy-08 (work in progress), July
              2015.

   [I-D.ietf-mmusic-sdp-simulcast]
              Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
              "Using Simulcast in SDP and RTP Sessions", draft-ietf-
              mmusic-sdp-simulcast-01 (work in progress), July 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>.

Burman, et al.            Expires March 6, 2016                [Page 53]
Internet-Draft              RTP Stream Pause              September 2015

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

Appendix A.  Changes From Earlier Versions

   NOTE TO RFC EDITOR: Please remove this section prior to publication.

A.1.  Modifications Between Version -08 and -09

   Changes based on IETF last call and IESG comments.

   o  Expanded some acronyms on first usage.

   o  Clarified why this document updated RFC 5104.

   o  Removed some unused abbreviations.

   o  Clarified when TMMBR/TMMBN is expected to be used in Section 5.6.

   o  Mandate using SHALL repetition of PAUSED indications in
      Section 6.4.

   o  Removed paragraph in Section 8.4 on PauseID and REFUSED as being
      redundant.

   o  Transmission rules in Section 8.5 was reworded and stoped using
      RFC 2119 terms, instead uses recommendations and lists
      motivations.

   o  In Section 9 (Signalling) it was clarified that one SHOULD only
      send messages supported by receivers, but provide example of cases
      when one may still send messages not supported by every receiver
      of that message.  Also clarified that TMMBR/TMMBN for pause is
      monolithic in capability.

   o  Security consideration was updated to consider replay attacks.

Burman, et al.            Expires March 6, 2016                [Page 54]
Internet-Draft              RTP Stream Pause              September 2015

   o  Security consideration was updated to describe the mitigation
      against malicous RTP session participants in multi-party cases
      that seeing all messages provide.

A.2.  Modifications Between Version -07 and -08

   Changes based on IESG AD Evaluation.

   o  Moved the mentioning of RTCWEB RFC7478 API requirements out from
      3.1 to section 3, adding a couple of clarifying sentences.

   o  Highlighted that the use case in section 3.4 deals with a
      different direction of the pause request than the previous use
      cases.

   o  Added text on partial capability and interoperability to section
      5.1.

   o  Added an overview explanation of PauseID as a new section 5.2, and
      moved a few sentences on PauseID from other 5.x sections in there.

   o  Changed all occurrences of "available" and "valid" PauseID to the
      more clear "current" PauseID, and re-phrased sentences involving
      that to become more clear.

   o  Changed all occurrences of "smaller" and "larger" PauseID to
      "past" and "future", respectively, to better align with "current".

   o  Removed an incorrect sentence in 5.2 about when it is not feasible
      to send repeated PAUSE.

   o  Changed a few capitalized words that could be taken as normative
      text from section 5, which is intended to be a non-normative
      description.

   o  Added some explanatory text on why RTP stream is resumed when the
      stream receiver that paused the stream leaves the RTP session to
      last bullet in 6.3.1.

   o  Added caption to Figure 5.

   o  Moved the detailed description on what PauseID ranges are defined
      as "past" and "future" before section 8.1, instead of having it in
      section 8.1, and added a comment on the "not current" part of the
      value range.

Burman, et al.            Expires March 6, 2016                [Page 55]
Internet-Draft              RTP Stream Pause              September 2015

   o  Added text in section 8.1 on appropriate time to wait between
      sending PAUSE, when the first PAUSE was rejected by a RESUME or a
      REFUSED.

   o  Added text in section 8.3 on appropriate time to wait between
      sending RESUME, when the first RESUME was rejected by a REFUSED.

   o  Added text in section 8.4 on time to wait before sending the
      REFUSED request again, referencing sections 8.1 and 8.3.

   o  Added a couple of paragraphs in section 9 on partial capability
      and interoperability, including a description on when different
      config values are expected to be useful, and when they are not.

   o  Added arrows in Figure 19 to highlight that the Relay sends out
      all received messages to all receivers, not only the first PAUSE
      message.

   o  Changed references to RFC3264 and RFC4566 to be normative.

   o  Updated ietf-rtcweb-use-cases-and-requirements reference to be
      RFC7478.

   o  Editorial improvements and clarifications.

A.3.  Modifications Between Version -06 and -07

   o  Completely rewrote the Security Consideration section.

   o  Aligned text such that REFUSED is always referred to as a
      notification, not indication.

   o  Added and changed text in several places, clarifying the case when
      TMMBR/TMMBN bounding set overhead value matters, related to
      whether local RTP stream sender or remote RTP stream receiver owns
      the TMMBR 0 restriction, and the consequences this has on pause/
      resume logic.

   o  Moved text on when to stop media stream transmission from when
      receiving PAUSE and entering pausing state, to when entering
      paused or local paused states.

   o  Added text on how to determine if there is a single receiver or
      not, aligned with what is specified in draft-ietf-avtcore-multi-
      stream, adding a reference to draft-ietf-avtcore-multi-stream-
      optimisation to be able to use a single RTCP reporting group as
      one criteria.

Burman, et al.            Expires March 6, 2016                [Page 56]
Internet-Draft              RTP Stream Pause              September 2015

   o  Added clarifying text on repeating PAUSED and RESUME messages only
      as long as remaining in the relevant state.

   o  Clarified that it is the RTP stream sender's responsibility to
      leave local paused state when the condition causing that state is
      no longer true.

   o  Added text to better allow for extensions to this specification,
      since there is already some text on extensions.

   o  Corrected and amended ABNF to make CCM pause parameters order-
      independent, allow for a larger config pause attribute value
      range, and added corresponding text to handle that additional
      flexibility.

   o  Added SDP rules on how to handle unknown pause attribute values.

   o  Clarified how to handle an SDP with both "ccm pause" and "ccm
      tmmbr".

   o  Changed from "Translator" to "Relay" in examples, to make it
      clearer in relation to the updated topologies draft.

   o  Editorial improvements.

A.4.  Modifications Between Version -05 and -06

   o  Clarified in Message Details section for PAUSED that
      retransmission of the message can be used to increase the
      probability that the message reaches the receiver in a timely
      fashion, and also added text that says the number of repetitions
      can be tuned to observed loss rate and the desired loss
      probability.  Also removed Editor's notes on potential ACK for
      unsolicited PAUSED, since the issue is solved by the above.

   o  In the same section as above, added that PAUSED may be included in
      all compound RTCP reports, as long as the negotiated RTCP
      bandwidth is not exceeded.

   o  In Message Details section for RESUME, added text on
      retransmission similar to the one mentioned for PAUSED above.
      Also included text that says such retransmission SHOULD stop as
      soon as RTP packets or a REFUSED with a valid PauseID from the
      targeted stream are received.

   o  Changed simulcast reference, since that draft was moved from
      AVTCORE to MMUSIC and made WG draft.

Burman, et al.            Expires March 6, 2016                [Page 57]
Internet-Draft              RTP Stream Pause              September 2015

   o  Changed End Point to Endpoint to reflect change in RTP Grouping
      Taxonomy draft.

   o  Editorial improvements.

A.5.  Modifications Between Version -04 and -05

   o  Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and
      timing of unsolicited PAUSED, to improve the message timeliness
      and probability of reception.

A.6.  Modifications Between Version -03 and -04

   o  Change of Copyright boilerplate

A.7.  Modifications Between Version -02 and -03

   o  Changed the section on SDP signaling to be more explicit and clear
      in what is supported, replacing the 'paused' parameter and the
      'dir' attribute with a 'config' parameter that can take a value,
      and an explicit listing of what each value means.

   o  Added a sentence in section on paused state (Section 6.3) that
      pause must not affect RTP keepalive.

   o  Replaced REFUSE message name with REFUSED throughout, to better
      indicate that it is not a command but a notification.

   o  Added text in a few places, clarifying that PAUSED message may be
      used unsolicited due to RTP sender local considerations, and also
      clarified the interaction between this usage and an RTP stream
      receiver pausing the stream.  Also added an example describing
      this case.

   o  Clarified that when TMMBN 0 is used as PAUSED message, and when
      sent unsolicited due to RTP sender local considerations, the TMMBN
      message includes the RTP stream sender itself as part of the
      bounding set.

   o  Clarified that there is no reply to a PAUSED indication.

   o  Improved the IANA section.

   o  Editorial improvements.

Burman, et al.            Expires March 6, 2016                [Page 58]
Internet-Draft              RTP Stream Pause              September 2015

A.8.  Modifications Between Version -01 and -02

   o  Replaced most text on relation with other signaling technologies
      in previous section 5 with a single, summarizing paragraph, as
      discussed at IETF 90 in Toronto, and placed it as the last sub-
      section of section 4 (design considerations).

   o  Removed unused references.

A.9.  Modifications Between Version -00 and -01

   o  Corrected text in section 6.5 and 6.2 to indicate that a PAUSE
      signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0

   o  Improved alignment with RTP Taxonomy draft, including the change
      of Packet Stream to RTP Stream

   o  Editorial improvements

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: muhammad.azam.akram@ericsson.com
   URI:   www.ericsson.com

   Roni Even
   Huawei Technologies
   Tel Aviv
   Israel

   Email: roni.even@mail01.huawei.com

Burman, et al.            Expires March 6, 2016                [Page 59]
Internet-Draft              RTP Stream Pause              September 2015

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE- 164 80 Kista
   Sweden

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

Burman, et al.            Expires March 6, 2016                [Page 60]