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

lt;-----------------|                  |                  |
        |                  | t9:PAUSE(S1)     |                  |
        |                  |----------------->|                  |
        |                  | t10:PAUSED(S1)   |                  |
        |                  |<-----------------|                  |
        |                  | <S1:No RTP to M> |                  |
        :                  :                  :                  :

     Figure 13: 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 the Mixer SSRC but with S1 as CSRC (indicated after the
   colon in the figure).  Then S2 joins the session at t3 and starts
   delivering an RTP stream to the Mixer.  As S2 has less voice activity
   then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE
   request.  At t5, S2 acknowledges with a PAUSED and at the same
   instant stops delivering RTP to the Mixer.  At t6, the user at S2
   starts speaking and becomes the most active speaker and the Mixer
   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

Burman, et al.          Expires January 25, 2015               [Page 37]
Internet-Draft              RTP Stream Pause                   July 2014

   stream from t7 arrives at the Mixer, it switches this RTP stream into
   its SSRC (M) at t8 and changes the CSRC to S2.  As S1 now becomes
   unused, the Mixer issues a PAUSE request to S1 at t9, which is
   acknowledged at t10 with a PAUSED and the RTP stream from S1 stops
   being delivered.

10.4.  Point-to-Multipoint using Translator

   A transport Translator in an RTP session forwards the message from
   one peer to all the others.  Unlike Mixer, the Translator 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 Translator case.
   The parentheses in the figures contains (Target SSRC, PauseID)
   information for the messages defined in this specification.

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

   Figure 14: Pause and Resume Operation Between Two Participants Using
                               a Translator

Burman, et al.          Expires January 25, 2015               [Page 38]
Internet-Draft              RTP Stream Pause                   July 2014

   Figure 14 describes how a Translator can help the receiver in pausing
   and resuming the sender.  The sender S sends RTP data to the receiver
   R through Translator, which just forwards the data without modifying
   the SSRCs.  The receiver sends a PAUSE request to the sender, which
   in this example knows that there may be more receivers of the stream
   and waits a non-zero hold-off time to see if there is any other
   receiver that wants to receive the data, does not receive any
   disapproving RESUME, hence pauses itself and replies with PAUSED.
   Similarly the receiver resumes the sender by sending RESUME request
   through Translator.  Since this describes only a single pause
   operation for a single RTP stream sender, all messages uses a single
   PauseID, in this example 3.

Burman, et al.          Expires January 25, 2015               [Page 39]
Internet-Draft              RTP Stream Pause                   July 2014

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

     Figure 15: Pause and Resume Operation Between One Sender and Two
                       Receivers Through Translator

   Figure 15 explains the pause and resume operations when a transport
   Translator 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
   Translator, which is forwarded to R1 and R2 through the Translator,
   T.  R1 and R2 receives RTP data from Translator at t2.  At this

Burman, et al.          Expires January 25, 2015               [Page 40]
Internet-Draft              RTP Stream Pause                   July 2014

   point, both R1 and R2 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 translator T.  The sender S
   sees the RESUME at time t6 and continues to send data to T 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
   time, 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.  The RTP sender
   immediately resumes the stream.

   Consider also an RTP session which includes one or more receivers,
   paused sender(s), and a Translator.  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

   As outlined in Section 7, this specification requests IANA to
   allocate

   1.  The FMT number TBA1 to be allocated to the PAUSE and RESUME
       functionality from this specification.

   2.  The 'pause' and 'paused' tags to be used with ccm under rtcp-fb
       AVPF attribute in SDP.

   3.  The 'nowait' parameter to be used with the 'pause' and 'paused'
       tags in SDP.

Burman, et al.          Expires January 25, 2015               [Page 41]
Internet-Draft              RTP Stream Pause                   July 2014

   4.  A registry listing registered values for 'pause' Types.

   5.  PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the
       pause Type registry.

12.  Security Considerations

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

   1.  Identity spoofing - An attacker can spoof him/herself as an
       authenticated user and can falsely pause or resume any source
       transmission.  In order to prevent this type of attack, a strong
       authentication and integrity protection mechanism is needed.

   2.  Denial of Service (DoS) - An attacker can falsely pause all
       source streams which MAY result in Denial of Service (DoS).  An
       Authentication protocol may prevent this attack.

   3.  Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP
       source is prone to a Man-in-Middle attack.  Public key
       authentication may be used to prevent MiMT.

13.  Contributors

   Daniel Grondal contributed in the creation and writing of early
   versions of this specification.

14.  Acknowledgements

   Daniel Grondal made valuable contributions during the initial
   versions of this draft.

15.  References

15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

Burman, et al.          Expires January 25, 2015               [Page 42]
Internet-Draft              RTP Stream Pause                   July 2014

   [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, July
              2006.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

15.2.  Informative References

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

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

   [I-D.ietf-rtcweb-use-cases-and-requirements]
              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements", draft-
              ietf-rtcweb-use-cases-and-requirements-14 (work in
              progress), February 2014.

   [I-D.westerlund-avtcore-rtp-simulcast]
              Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP
              Sessions", draft-westerlund-avtcore-rtp-simulcast-03 (work
              in progress), October 2013.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2974]  Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

Burman, et al.          Expires January 25, 2015               [Page 43]
Internet-Draft              RTP Stream Pause                   July 2014

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June
              2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC6190]  Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
              "RTP Payload Format for Scalable Video Coding", RFC 6190,
              May 2011.

Appendix A.  Changes From Earlier Versions

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

A.1.  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.2.  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

   Phone: +46107141311
   Email: bo.burman@ericsson.com
   URI:   www.ericsson.com

Burman, et al.          Expires January 25, 2015               [Page 44]
Internet-Draft              RTP Stream Pause                   July 2014

   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

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE- Kista 164 80
   Sweden

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

Burman, et al.          Expires January 25, 2015               [Page 45]