RFC 7728
RTP Stream Pause and Resume
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
4. Point to Multipoint using Relay10.1. Offer/Answer
The below figures contain an example of how to show support for pausing and resuming the streams, as well as indicating whether or not the hold-off period can be set to 0. v=0 o=alice 3203093520 3203093520 IN IP4 alice.example.com s=Pausing Media t=0 0 c=IN IP4 alice.example.com m=audio 49170 RTP/AVPF 98 99 a=rtpmap:98 G719/48000 a=rtpmap:99 PCMA/8000 a=rtcp-fb:* ccm pause nowait Figure 10: SDP Offer with Pause and Resume Capability The offerer supports all of the messages defined in this specification, leaving out the optional "config" pause attribute. The offerer also believes that it will be the sole receiver of the answerer's stream as well as that the answerer will be the sole receiver of the offerer's stream and thus includes the "nowait" pause attribute for the "pause" parameter. This is the SDP answer: v=0 o=bob 293847192 293847192 IN IP4 bob.example.com s=- t=0 0 c=IN IP4 bob.example.com m=audio 49202 RTP/AVPF 98 a=rtpmap:98 G719/48000 a=rtcp-fb:98 ccm pause config=2 Figure 11: SDP Answer with Pause and Resume Capability The answerer will not allow its sent streams to be paused or resumed and thus restricts the answer to indicate "config=2". It also supports pausing its own RTP streams due to local considerations, which is why "config=2" is chosen rather than "config=4". The answerer somehow knows that it will not be a point-to-point RTP session and has therefore removed "nowait" from the "pause" line, meaning that the offerer must use a non-zero hold-off period when being requested to pause the stream.
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.
+---------------+ +---------------+ | 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.
+---------------+ +----------------+ | 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.
+---------------+ +---------------+ | 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
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
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
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
may be more receivers of the stream and waits a non-zero hold-off period to see if there is any other receiver that wants to receive the data, and when no disapproving RESUME messages are received, it pauses itself and replies with PAUSED. Similarly R resumes S by sending a RESUME request through the Relay. Since this describes only a single pause and resume operation for a single RTP stream sender, all messages use a single PauseID; in this example, it's three. +-----+ +-----+ +-----+ +-----+ | S | | Rel | | R1 | | R2 | +-----+ +-----+ +-----+ +-----+ : t1:RTP(S) : : : |----------------->| | | | | t2:RTP(S) | | | |----------------->------------------>| | | t3:PAUSE(S,7) | | | |<-----------------| | | t4:PAUSE(S,7) | | | |<-----------------|------------------------------------>| | | | t5:RESUME(S,7) | | |<------------------------------------| | t6:RESUME(S,7) | | | |<-----------------|----------------->| | | | <RTP stream continues to R1 and R2> | | | | t7: PAUSE(S,8) | | |<------------------------------------| | t8:PAUSE(S,8) | | | |<-----------------|----------------->| | : : : : | < Pauses RTP stream > | | | t9:PAUSED(S,8) | | | |----------------->| | | | | t10:PAUSED(S,8) | | | |----------------->------------------>| : : : : | | t11:RESUME(S,8) | | | |<-----------------| | | t12:RESUME(S,8) | | | |<-----------------|------------------------------------>| | t13:RTP(S) | | | |----------------->| | | | | t14:RTP(S) | | | |----------------->------------------>| : : : : Figure 19: Pause and Resume Operation between One Sender and Two Receivers through Relay
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.
11. IANA Considerations
Per this specification, IANA has made the following registrations: 1. A new value for media stream pause/resume has been registered in the "FMT Values for RTPFB Payload Types" registry located at the time of publication at: <http://www.iana.org/assignments/rtp- parameters> Value: 9 Name: PAUSE-RESUME Long Name: Media Pause/Resume Reference: RFC 7728 2. A new value "pause" to be registered with IANA in the "Codec Control Messages" registry located at the time of publication at: <http://www.iana.org/assignments/sdp-parameters> Value Name: pause Long Name: Media Pause/Resume Usable with: ccm Reference: RFC 772812. 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
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
the signaling system to securely handle identities and assert that only the intended identities are allowed into the RTP session and provided with the relevant security contexts.13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>. [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <http://www.rfc-editor.org/info/rfc6263>.13.2. Informative References
[MULTI-STREAM-OPT] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", Work in Progress, draft-ietf-avtcore-rtp-multi-stream- optimisation-11, December 2015. [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>. [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>. [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <http://www.rfc-editor.org/info/rfc7478>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>. [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>. [SDP-SIMULCAST] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", Work in Progress, draft-ietf-mmusic-sdp-simulcast-04, February 2016.Acknowledgments
Daniel Grondal made valuable contributions during the initial versions of this document. The authors would also like to thank Emil Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable review comments.Contributors
Daniel Grondal contributed in the creation and writing of early versions of this specification. Christian Groves contributed significantly to the SDP "config" pause attribute and its use in offer/answer.
Authors' Addresses
Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden Email: bo.burman@ericsson.com Azam Akram Ericsson Farogatan 6 SE - 164 80 Kista Sweden Phone: +46107142658 Email: akram.muhammadazam@gmail.com URI: www.ericsson.com Roni Even Huawei Technologies Tel Aviv Israel Email: roni.even@mail01.huawei.com Magnus Westerlund Ericsson Farogatan 6 SE - 164 80 Kista Sweden Phone: +46107148287 Email: magnus.westerlund@ericsson.com