Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7728

RTP Stream Pause and Resume

Pages: 55
Proposed Standard
Updates:  5104
Part 3 of 3 – Pages 39 to 55
First   Prev   None

Top   ToC   RFC7728 - Page 39   prevText

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
Top   ToC   RFC7728 - Page 40
   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 s=Pausing Media t=0 0 c=IN IP4 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 s=- t=0 0 c=IN IP4 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.
Top   ToC   RFC7728 - Page 41
   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.
Top   ToC   RFC7728 - Page 42
           +---------------+                   +---------------+
           |  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.
Top   ToC   RFC7728 - Page 43
           +---------------+                 +----------------+
           | 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.
Top   ToC   RFC7728 - Page 44
         +---------------+                       +---------------+
         |  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
Top   ToC   RFC7728 - Page 45
   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
Top   ToC   RFC7728 - Page 46
   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
Top   ToC   RFC7728 - Page 47
   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
Top   ToC   RFC7728 - Page 48
   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

     +-----+            +-----+            +-----+            +-----+
     |  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
Top   ToC   RFC7728 - Page 49
   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.
Top   ToC   RFC7728 - Page 50

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: < 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: <> 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
Top   ToC   RFC7728 - Page 51
   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
Top   ToC   RFC7728 - Page 52
   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, <>. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <>. [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, <>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <>. [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, <>. [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, <>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <>. [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, <>.
Top   ToC   RFC7728 - Page 53
   [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,

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, <>. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 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, DOI 10.17487/RFC3261, June 2002, <>. [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, <>. [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, <>. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <>. [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <>.
Top   ToC   RFC7728 - Page 54
   [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,

   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
              DOI 10.17487/RFC7667, November 2015,

              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


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.


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.
Top   ToC   RFC7728 - Page 55

Authors' Addresses

Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden Email: Azam Akram Ericsson Farogatan 6 SE - 164 80 Kista Sweden Phone: +46107142658 Email: URI: Roni Even Huawei Technologies Tel Aviv Israel Email: Magnus Westerlund Ericsson Farogatan 6 SE - 164 80 Kista Sweden Phone: +46107148287 Email: