idnits 2.17.1 draft-ietf-avtext-rtp-stream-pause-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5104, updated by this document, for RFC5378 checks: 2006-08-29) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2014) is 3463 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-04 == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-02 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Burman 3 Internet-Draft A. Akram 4 Updates: 5104 (if approved) Ericsson 5 Intended status: Standards Track R. Even 6 Expires: April 30, 2015 Huawei Technologies 7 M. Westerlund 8 Ericsson 9 October 27, 2014 11 RTP Stream Pause and Resume 12 draft-ietf-avtext-rtp-stream-pause-05 14 Abstract 16 With the increased popularity of real-time multimedia applications, 17 it is desirable to provide good control of resource usage, and users 18 also demand more control over communication sessions. This document 19 describes how a receiver in a multimedia conversation can pause and 20 resume incoming data from a sender by sending real-time feedback 21 messages when using Real-time Transport Protocol (RTP) for real time 22 data transport. This document extends the Codec Control Messages 23 (CCM) RTCP feedback package by explicitly allowing and describing 24 specific use of existing CCM messages and adding a group of new real- 25 time feedback messages used to pause and resume RTP data streams. 26 This document updates RFC 5104. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 30, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 77 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 79 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 81 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 82 3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9 83 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10 84 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 85 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11 86 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11 87 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 88 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12 89 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12 90 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12 91 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13 92 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13 93 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13 94 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14 95 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15 96 5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15 97 5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16 98 5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 18 99 5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19 100 6. Participant States . . . . . . . . . . . . . . . . . . . . . 19 101 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20 102 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20 103 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21 104 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21 105 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22 106 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22 107 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 23 108 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25 109 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 110 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28 113 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 28 114 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29 115 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32 116 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33 117 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 34 119 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35 120 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 39 121 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 41 122 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 123 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 124 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 125 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 46 128 15.2. Informative References . . . . . . . . . . . . . . . . . 46 129 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 47 130 A.1. Modifications Between Version -04 and -05 . . . . . . . . 47 131 A.2. Modifications Between Version -03 and -04 . . . . . . . . 47 132 A.3. Modifications Between Version -02 and -03 . . . . . . . . 48 133 A.4. Modifications Between Version -01 and -02 . . . . . . . . 48 134 A.5. Modifications Between Version -00 and -01 . . . . . . . . 48 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 137 1. Introduction 139 As real-time communication attracts more people, more applications 140 are created; multimedia conversation applications being one example. 141 Multimedia conversation further exists in many forms, for example, 142 peer-to-peer chat application and multiparty video conferencing 143 controlled by central media nodes, such as RTP Mixers. 145 Multimedia conferencing may involve many participants; each has its 146 own preferences for the communication session, not only at the start 147 but also during the session. This document describes several 148 scenarios in multimedia communication where a conferencing node or 149 participant chooses to temporarily pause an incoming RTP [RFC3550] 150 stream and later resume it when needed. The receiver does not need 151 to terminate or inactivate the RTP session and start all over again 152 by negotiating the session parameters, for example using SIP 153 [RFC3261] with SDP Offer/Answer [RFC3264]. 155 Centralized nodes, like RTP Mixers or MCUs, which either uses logic 156 based on voice activity, other measurements, or user input could 157 reduce the resources consumed in both the sender and the network by 158 temporarily pausing the RTP streams that aren't required by the RTP 159 Mixer. If the number of conference participants are greater than 160 what the conference logic has chosen to present simultaneously to 161 receiving participants, some participant RTP streams sent to the RTP 162 Mixer may not need to be forwarded to any other participant. Those 163 RTP streams could then be temporarily paused. This becomes 164 especially useful when the media sources are provided in multiple 165 encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast] 166 or with Multi-Session Transmission (MST) of scalable encoding such as 167 SVC [RFC6190]. There may be some of the defined encodings or 168 combination of scalable layers that are not used or cannot be used 169 all of the time, for example due to temporarily limited network or 170 processing resources, and a centralized node may choose to pause such 171 RTP streams without being requested to do so, but anyway send an 172 explicit indication that the stream is paused. 174 As the RTP streams required at any given point in time is highly 175 dynamic in such scenarios, using the out-of-band signaling channel 176 for pausing, and even more importantly resuming, an RTP stream is 177 difficult due to the performance requirements. Instead, the pause 178 and resume signaling should be in the media plane and go directly 179 between the affected nodes. When using RTP [RFC3550] for media 180 transport, using Extended RTP Profile for Real-time Transport Control 181 Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears 182 appropriate. No currently existing RTCP feedback message explicitly 183 supports pausing and resuming an incoming RTP stream. As this 184 affects the generation of packets and may even allow the encoding 185 process to be paused, the functionality appears to match Codec 186 Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) 187 [RFC5104] and it is proposed to define the solution as a Codec 188 Control Message (CCM) extension. 190 The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is 191 used by video conferencing systems for flow control. It is desirable 192 to be able to use that method with a bitrate value of zero for pause, 193 whenever possible. 195 2. Definitions 197 2.1. Abbreviations 199 3GPP: 3rd Generation Partnership Project 201 AVPF: Audio-Visual Profile with Feedback (RFC 4585) 203 BGW: Border Gateway 205 CCM: Codec Control Messages (RFC 5104) 207 CNAME: Canonical Name (RTCP SDES) 209 CSRC: Contributing Source (RTP) 211 FB: Feedback (AVPF) 213 FCI: Feedback Control Information (AVPF) 215 FIR: Full Intra Refresh (CCM) 217 FMT: Feedback Message Type (AVPF) 219 LTE: Long-Term Evolution (3GPP) 221 MCU: Multipoint Control Unit 223 MTU: Maximum Transfer Unit 225 PT: Payload Type (RTP) 227 RTP: Real-time Transport Protocol (RFC 3550) 229 RTCP: RTP Control Protocol (RFC 3550) 231 RTCP RR: RTCP Receiver Report 232 SDP: Session Description Protocol (RFC 4566) 234 SGW: Signaling Gateway 236 SIP: Session Initiation Protocol (RFC 3261) 238 SSRC: Synchronization Source (RTP) 240 SVC: Scalable Video Coding 242 TCP: Transmission Control Protocol (RFC 793) 244 TMMBR: Temporary Maximum Media Bitrate Request (CCM) 246 TMMBN: Temporary Maximum Media Bitrate Notification (CCM) 248 UA: User Agent (SIP) 250 UDP: User Datagram Protocol (RFC 768) 252 2.2. Terminology 254 In addition to the following, the definitions from RTP [RFC3550], 255 AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy 256 [I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document. 258 Feedback Messages: CCM [RFC5104] categorized different RTCP feedback 259 messages into four types, Request, Command, Indication and 260 Notification. This document places the PAUSE and RESUME messages 261 into Request category, PAUSED as Indication and REFUSED as 262 Notification. 264 PAUSE Request from an RTP stream receiver to pause a stream 266 RESUME Request from an RTP stream receiver to resume a paused 267 stream 269 PAUSED Indication from an RTP stream sender that a stream is 270 paused 272 REFUSED Indication from an RTP stream sender that a PAUSE or 273 RESUME request will not be honored 275 Mixer: The intermediate RTP node which receives an RTP stream from 276 different end points, combines them to make one RTP stream and 277 forwards to destinations, in the sense described in Topo-Mixer of 278 RTP Topologies [I-D.ietf-avtcore-rtp-topologies-update]. 280 Participant: A member which is part of an RTP session, acting as 281 receiver, sender or both. 283 Paused sender: An RTP stream sender that has stopped its 284 transmission, i.e. no other participant receives its RTP 285 transmission, either based on having received a PAUSE request, 286 defined in this specification, or based on a local decision. 288 Pausing receiver: An RTP stream receiver which sends a PAUSE 289 request, defined in this specification, to other participant(s). 291 Stream: Used as a short term for RTP stream, unless otherwise noted. 293 Stream receiver: Short for RTP stream receiver; the RTP entity 294 responsible for receiving an RTP stream, usually a Media 295 Depacketizer. 297 Stream sender: Short for RTP stream sender; the RTP entity 298 responsible for creating an RTP stream, usually a Media 299 Packetizer. 301 2.3. Requirements Language 303 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 304 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 305 document are to be interpreted as described in RFC 2119 [RFC2119]. 307 3. Use Cases 309 This section discusses the main use cases for RTP stream pause and 310 resume. 312 3.1. Point to Point 314 This is the most basic use case with an RTP session containing two 315 End Points. Each End Point sends one or more streams. 317 +---+ +---+ 318 | A |<------->| B | 319 +---+ +---+ 321 Figure 1: Point to Point 323 The usage of RTP stream pause in this use case is to temporarily halt 324 delivery of streams that the sender provides but the receiver does 325 not currently use. This can for example be due to minimized 326 applications where the video stream is not actually shown on any 327 display, and neither is it used in any other way, such as being 328 recorded. 330 In this case, since there is only a single receiver of the stream, 331 pausing or resuming a stream does not impact anyone else than the 332 sender and the single receiver of that stream. 334 RTCWEB WG's use case and requirements document 335 [I-D.ietf-rtcweb-use-cases-and-requirements] defines the following 336 API requirements in Appendix A, used also by W3C WebRTC WG: 338 A8 The Web API must provide means for the web application to mute/ 339 unmute a stream or stream component(s). When a stream is sent to 340 a peer mute status must be preserved in the stream received by the 341 peer. 343 A9 The Web API must provide means for the web application to cease 344 the sending of a stream to a peer. 346 This memo provides means to optimize transport usage by stop sending 347 muted streams and start sending again when unmuting. 349 3.2. RTP Mixer to Media Sender 351 One of the most commonly used topologies in centralized conferencing 352 is based on the RTP Mixer [I-D.ietf-avtcore-rtp-topologies-update]. 353 The main reason for this is that it provides a very consistent view 354 of the RTP session towards each participant. That is accomplished 355 through the Mixer originating its' own streams, identified by SSRC, 356 and any RTP streams sent to the participants will be sent using those 357 SSRCs. If the Mixer wants to identify the underlying media sources 358 for its' conceptual streams, it can identify them using CSRC. The 359 stream the Mixer provides can be an actual mix of multiple media 360 sources, but it might also be switching received streams as described 361 in Sections 3.6-3.8 of [I-D.ietf-avtcore-rtp-topologies-update]. 363 +---+ +-----------+ +---+ 364 | A |<---->| |<---->| B | 365 +---+ | | +---+ 366 | Mixer | 367 +---+ | | +---+ 368 | C |<---->| |<---->| D | 369 +---+ +-----------+ +---+ 371 Figure 2: RTP Mixer in Unicast-only 373 Which streams that are delivered to a given receiver, A, can depend 374 on several things. It can either be the RTP Mixer's own logic and 375 measurements such as voice activity on the incoming audio streams. 376 It can be that the number of sent media sources exceed what is 377 reasonable to present simultaneously at any given receiver. It can 378 also be a human controlling the conference that determines how the 379 media should be mixed; this would be more common in lecture or 380 similar applications where regular listeners may be prevented from 381 breaking into the session unless approved by the moderator. The 382 streams may also be part of a Simulcast 383 [I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for 384 Multi-Session Transmission) [RFC6190], thus providing multiple 385 versions that can be delivered by the RTP stream sender. These 386 examples indicate that there are numerous reasons why a particular 387 stream would not currently be in use, but must be available for use 388 at very short notice if any dynamic event occurs that causes a 389 different stream selection to be done in the Mixer. 391 Because of this, it would be highly beneficial if the Mixer could 392 request to pause a particular stream from being delivered to it. It 393 also needs to be able to resume delivery with minimal delay. 395 In some cases, especially when the Mixer sends multiple RTP streams 396 per receiving client, there may be situations that makes it desirable 397 to the Mixer to pause some of its sent RTP streams, even without 398 being explicitly asked to do so by the receiving client. Such 399 situations can for example be caused by a temporary lack of available 400 Mixer network or processing resources. An RTP stream receiver that 401 no longer receives an RTP stream could interpret this as an error 402 condition and try to take action to re-establish the RTP stream. 403 Such action would likely be undesirable if the RTP stream was in fact 404 deliberately paused by the Mixer. Undesirable RTP stream receiver 405 actions could be avoided if the Mixer is able to explicitly indicate 406 that an RTP stream is deliberately paused. 408 Just as for point-to-point (Section 3.1), there is only a single 409 receiver of the stream, the RTP Mixer, and pausing or resuming a 410 stream does not affect anyone else than the sender and single 411 receiver of that stream. 413 3.3. RTP Mixer to Media Sender in Point-to-Multipoint 415 This use case is similar to the previous section, however the RTP 416 Mixer is involved in three domains that need to be separated; the 417 Multicast Network (including participants A and C), participant B, 418 and participant D. The difference from above is that A and C share a 419 multicast domain, which is depicted below. 421 +-----+ 422 +---+ / \ +-----------+ +---+ 423 | A |<---/ \ | |<---->| B | 424 +---+ / Multi- \ | | +---+ 425 + Cast +->| Mixer | 426 +---+ \ Network / | | +---+ 427 | C |<---\ / | |<---->| D | 428 +---+ \ / +-----------+ +---+ 429 +-----+ 431 Figure 3: RTP Mixer in Point-to-Multipoint 433 If the RTP Mixer pauses a stream from A, it will not only pause the 434 stream towards itself, but will also stop the stream from arriving to 435 C, which C is heavily impacted by, might not approve of, and should 436 thus have a say on. 438 If the Mixer resumes a paused stream from A, it will be resumed also 439 towards C. In this case, if C is not interested it can simply ignore 440 the stream and is not impacted as much as above. 442 In this use case there are several receivers of a stream and special 443 care must be taken as not to pause a stream that is still wanted by 444 some receivers. 446 3.4. Media Receiver to RTP Mixer 448 An End Point in Figure 2 could potentially request to pause the 449 delivery of a given stream. Possible reasons include the ones in the 450 point to point case (Section 3.1) above. 452 When the RTP Mixer is only connected to individual unicast paths, the 453 use case and any considerations are identical to the point to point 454 use case. 456 However, when the End Point requesting stream pause is connected to 457 the RTP Mixer through a multicast network, such as A or C in 458 Figure 3, the use case instead becomes identical to the one in 459 Section 3.3, only with reverse direction of the streams and pause/ 460 resume requests. 462 3.5. Media Receiver to Media Sender Across RTP Mixer 464 An End Point, like A in Figure 2, could potentially request to pause 465 the delivery of a given stream, like one of B's, over any of the 466 SSRCs used by the Mixer by sending a pause request for the CSRC 467 identifying the stream. However, the authors are of the opinion that 468 this is not a suitable solution, for several reasons: 470 1. The Mixer might not include CSRC in it's stream indications. 472 2. An End Point cannot rely on the CSRC to correctly identify the 473 stream to be paused when the delivered media is some type of mix. 474 A more elaborate stream identification solution is needed to 475 support this in the general case. 477 3. The End Point cannot determine if a given stream is still needed 478 by the RTP Mixer to deliver to another session participant. 480 Due to the above reasons, we exclude this use case from further 481 consideration. 483 4. Design Considerations 485 This section describes the requirements that this specification needs 486 to meet. 488 4.1. Real-time Nature 490 The first section (Section 1) of this specification describes some 491 possible reasons why a receiver may pause an RTP sender. Pausing and 492 resuming is time-dependent, i.e. a receiver may choose to pause an 493 RTP stream for a certain duration, after which the receiver may want 494 the sender to resume. This time dependency means that the messages 495 related to pause and resume must be transmitted to the sender in 496 real-time in order for them to be purposeful. The pause operation is 497 arguably not very time critical since it mainly provides a reduction 498 of resource usage. Timely handling of the resume operation is 499 however likely to directly impact the end-user's perceived quality 500 experience, since it affects the availability of media that the user 501 expects to receive more or less instantly. It may also be highly 502 desirable for a receiver to quickly learn that an RTP stream is 503 intentionally paused on the RTP sender's own behalf. 505 4.2. Message Direction 507 It is the responsibility of an RTP stream receiver, who wants to 508 pause or resume a stream from the sender(s), to transmit PAUSE and 509 RESUME messages. An RTP stream sender who likes to pause itself, can 510 often simply do it, but sometimes this will adversely affect the 511 receiver and an explicit indication that the RTP stream is paused may 512 then help. Any indication that an RTP stream is paused is the 513 responsibility of the RTP stream sender and may in some cases not 514 even be needed by the stream receiver. 516 4.3. Apply to Individual Sources 518 The PAUSE and RESUME messages apply to single RTP streams identified 519 by their SSRC, which means the receiver targets the sender's SSRC in 520 the PAUSE and RESUME requests. If a paused sender starts sending 521 with a new SSRC, the receivers will need to send a new PAUSE request 522 in order to pause it. PAUSED indications refer to a single one of 523 the sender's own, paused SSRC. 525 4.4. Consensus 527 An RTP stream sender should not pause an SSRC that some receiver 528 still wishes to receive. The reason is that in RTP topologies where 529 the stream is shared between multiple receivers, a single receiver on 530 that shared network, independent of it being multicast, a mesh with 531 joint RTP session or a transport Translator based, must not single- 532 handedly cause the stream to be paused without letting all other 533 receivers to voice their opinions on whether or not the stream should 534 be paused. A consequence of this is that a newly joining receiver, 535 for example indicated by an RTCP Receiver Report containing both a 536 new SSRC and a CNAME that does not already occur in the session, 537 firstly needs to learn the existence of paused streams, and secondly 538 should be able to resume any paused stream. Any single receiver 539 wanting to resume a stream should also cause it to be resumed. An 540 important exception to this is when the RTP stream sender is aware of 541 conditions that makes it desirable or even necessitates to pause the 542 RTP stream on its own behalf, without being explicitly asked to do 543 so. Such local consideration in the RTP sender takes precedence over 544 RTP receiver wishes to receive the stream. 546 4.5. Message Acknowledgments 548 RTP and RTCP does not guarantee reliable data transmission. It uses 549 whatever assurance the lower layer transport protocol can provide. 550 However, this is commonly UDP that provides no reliability 551 guarantees. Thus it is possible that a PAUSE and/or RESUME message 552 transmitted from an RTP End Point does not reach its destination, 553 i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches 554 the RTP stream sender and are effective, i.e., an active RTP stream 555 sender pauses, or a resuming RTP stream sender have media data to 556 transmit, it is immediately seen from the arrival or non-arrival of 557 RTP packets for that RTP stream. Thus, no explicit acknowledgments 558 are required in this case. 560 In some cases when a PAUSE or RESUME message reaches the RTP stream 561 sender, it will not be able to pause or resume the stream due to some 562 local consideration, for example lack of data to transmit. This 563 error condition, a negative acknowledgment, may be needed to avoid 564 unnecessary retransmission of requests (Section 4.6). 566 4.6. Request Retransmission 568 When the stream is not affected as expected by a PAUSE or RESUME 569 request, the request may have been lost and the sender of the request 570 will need to retransmit it. The retransmission should take the round 571 trip time into account, and will also need to take the normal RTCP 572 bandwidth and timing rules applicable to the RTP session into 573 account, when scheduling retransmission of feedback. 575 When it comes to resume requests or unsolicited paused indications 576 that are more time critical, the best performance may be achieved by 577 repeating the message as often as possible until a sufficient number 578 have been sent to reach a high probability of message delivery, or at 579 an explicit indication that the message was delivered. For resume 580 requests, such explicit indication can be delivery of the RTP stream 581 being requested to be resumed. 583 4.7. Sequence Numbering 585 A PAUSE request message will need to have a sequence number to 586 separate retransmissions from new requests. A retransmission keeps 587 the sequence number unchanged, while it is incremented every time a 588 new PAUSE request is transmitted that is not a retransmission of a 589 previous request. 591 Since RESUME always takes precedence over PAUSE and are even allowed 592 to avoid pausing a stream, there is a need to keep strict ordering of 593 PAUSE and RESUME. Thus, RESUME needs to share sequence number space 594 with PAUSE and implicitly references which PAUSE it refers to. For 595 the same reasons, the explicit PAUSED indication also needs to share 596 sequence number space with PAUSE and RESUME. 598 4.8. Relation to Other Solutions 600 A performance comparison between SIP/SDP and RTCP signaling 601 technologies was made and included in draft versions of this 602 specification. Using SIP and SDP [RFC4566] to carry pause and resume 603 information means that it will need to traverse the entire signaling 604 path to reach the signaling destination (either the remote End Point 605 or the entity controlling the RTP Mixer), across any signaling 606 proxies that potentially also has to process the SDP content to 607 determine if they are expected to act on it. The amount of bandwidth 608 required for a SIP/SDP-based signaling solution is in the order of at 609 least 10 times more than an RTCP-based solution. Especially for UA 610 sitting on mobile wireless access, this will risk introducing delays 611 that are too long (Section 4.1) to provide a good user experience, 612 and the bandwidth cost may also be considered infeasible compared to 613 an RTCP-based solution. RTCP data is sent through the media path, 614 which is likely shorter (contains fewer intermediate nodes) than the 615 signaling path, may anyway have to traverse a few intermediate nodes. 616 The amount of processing and buffering required in intermediate nodes 617 to forward those RTCP messages is however believed to be 618 significantly less than for intermediate nodes in the signaling path. 619 Based on those considerations, RTCP is chosen as signaling protocol 620 for the pause and resume functionality. 622 5. Solution Overview 624 The proposed solution implements PAUSE and RESUME functionality based 625 on sending AVPF RTCP feedback messages from any RTP session 626 participant that wants to pause or resume a stream targeted at the 627 stream sender, as identified by the sender SSRC. 629 It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent 630 possible, and to define a small set of new RTCP feedback messages 631 where new semantics is needed. 633 A single Feedback message specification is used to implement the new 634 messages. The message consists of a number of Feedback Control 635 Information (FCI) blocks, where each block can be a PAUSE request, a 636 RESUME request, PAUSED indication, a REFUSED response, or an 637 extension to this specification. This structure allows a single 638 feedback message to handle pause functionality on a number of 639 streams. 641 The PAUSED functionality is also defined in such a way that it can be 642 used standalone by the RTP stream sender to indicate a local decision 643 to pause, and inform any receiver of the fact that halting media 644 delivery is deliberate and which RTP packet was the last transmitted. 646 Special considerations that apply when using TMMBR/TMMBN for pause 647 and resume purposes are described in Section 5.5. This specification 648 applies to both the new messages defined in herein as well as their 649 TMMBR/TMMBN counterparts, except when explicitly stated otherwise. 650 An obvious exception are any reference to the message parameters that 651 are only available in the messages defined here. For example, any 652 reference to PAUSE in the text below is equally applicable to TMMBR 653 0, and any reference to PAUSED is equally applicable to TMMBN 0. 654 Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the 655 text, unless there is specific reason to do so. 657 This section is intended to be explanatory and therefore 658 intentionally contains no mandatory statements. Such statements can 659 instead be found in other parts of this specification. 661 5.1. Expressing Capability 663 An End Point can use an extension to CCM SDP signaling to declare 664 capability to understand the messages defined in this specification. 665 Capability to understand only a subset of messages is possible, to 666 support partial implementation, which is specifically believed to be 667 feasible for the RTP Mixer to Media Sender use case (Section 3.2). 669 For the case when TMMBR/TMMBN are used for pause and resume purposes, 670 it is possible to explicitly express joint support for TMMBR and 671 TMMBN, but not for TMMBN only. 673 5.2. Requesting to Pause 675 An RTP stream receiver can choose to request PAUSE at any time, 676 subject to AVPF timing rules. 678 The PAUSE request contains a PauseID, which is incremented by one (in 679 modulo arithmetic) with each PAUSE request that is not a re- 680 transmission. The PauseID is scoped by and thus a property of the 681 targeted RTP stream (SSRC). 683 When a non-paused RTP stream sender receives the PAUSE request, it 684 continues to send the RTP stream while waiting for some time to allow 685 other RTP stream receivers in the same RTP session that saw this 686 PAUSE request to disapprove by sending a RESUME (Section 5.4) for the 687 same stream and with the same PauseID as in the disapproved PAUSE. 688 If such disapproving RESUME arrives at the RTP stream sender during 689 the hold-off period before the stream is paused, the pause is not 690 performed. In point-to-point configurations, the hold-off period may 691 be set to zero. Using a hold-off period of zero is also appropriate 692 when using TMMBR 0 and in line with the semantics for that message. 694 If the RTP stream sender receives further PAUSE requests with the 695 available PauseID while waiting as described above, those additional 696 requests are ignored. 698 If the PAUSE request is lost before it reaches the RTP stream sender, 699 it will be discovered by the RTP stream receiver because it continues 700 to receive the RTP stream. It will also not see any PAUSED 701 indication (Section 5.3) for the stream. The same condition can be 702 caused by the RTP stream sender having received a disapproving RESUME 703 from a stream receiver A for a PAUSE request sent by a stream sender 704 B, but that the PAUSE sender (B) did not receive the RESUME (from A) 705 and may instead think that the PAUSE was lost. In both cases, a 706 PAUSE request can be re-transmitted using the same PauseID. If using 707 TMMBR 0 the request MAY be re-transmitted when the requester fails to 708 receive a TMMBN 0 confirmation. 710 If the pending stream pause is aborted due to a disapproving RESUME, 711 the PauseID from the disapproved PAUSE is invalidated by the RESUME 712 and any new PAUSE must use an incremented PauseID (in modulo 713 arithmetic) to be effective. 715 An RTP stream sender receiving a PAUSE not using the available 716 PauseID informs the RTP stream receiver sending the ineffective PAUSE 717 of this condition by sending a REFUSED response that contains the 718 next available PauseID value. This REFUSED also informs the RTP 719 stream receiver that it is probably not feasible to send another 720 PAUSE for some time, not even with the available PauseID, since there 721 are other RTP stream receivers that wish to receive the stream. 723 A similar situation where an ineffective PauseID is chosen can appear 724 when a new RTP stream receiver joins a session and wants to PAUSE a 725 stream, but does not yet know the available PauseID to use. The 726 REFUSED response will then provide sufficient information to create a 727 valid PAUSE. The required extra signaling round-trip is not 728 considered harmful, since it is assumed that pausing a stream is not 729 time-critical (Section 4.1). 731 There may be local considerations making it impossible or infeasible 732 to pause the stream, and the RTP stream sender can then respond with 733 a REFUSED. In this case, if the used PauseID would otherwise have 734 been effective, REFUSED contains the same PauseID as in the PAUSE 735 request, and the PauseID is kept as available. Note that when using 736 TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to 737 the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN 738 shall contain the current bounding set, and the fact that a TMMBR 0 739 will always be the most restrictive point in any bounding set. 741 If the RTP stream sender receives several identical PAUSE for an RTP 742 stream that was already at least once responded with REFUSED and the 743 condition causing REFUSED remains, those additional REFUSED should be 744 sent with regular RTCP timing. A single REFUSED can respond to 745 several identical PAUSE requests. 747 5.3. Media Sender Pausing 749 An RTP stream sender can choose to pause the stream at any time. 750 This can either be as a result of receiving a PAUSE, or be based on 751 some local sender consideration. When it does, it sends a PAUSED 752 indication, containing the available PauseID. Note that PauseID is 753 incremented when sending an unsolicited PAUSED (without having 754 received a PAUSE). It also sends the PAUSED indication in the next 755 two regular RTCP reports, given that the pause condition is then 756 still effective. 758 There is no reply to a PAUSED indication; it is simply an explicit 759 indication of the fact that an RTP stream is paused. This can be 760 helpful for the RTP stream receiver, for example to quickly 761 understand that transmission is deliberately and temporarily 762 suspended and no specific corrective action is needed. 764 The RTP stream sender may want to apply some local consideration to 765 exactly when the RTP stream is paused, for example completing some 766 media unit or a forward error correction block, before pausing the 767 stream. 769 The PAUSED indication also contains information about the RTP 770 extended highest sequence number when the pause became effective. 771 This provides RTP stream receivers with first hand information 772 allowing them to know whether they lost any packets just before the 773 stream paused or when the stream is resumed again. This allows RTP 774 stream receivers to quickly and safely take into account that the 775 stream is paused, in for example retransmission or congestion control 776 algorithms. 778 If the RTP stream sender receives PAUSE requests with the available 779 PauseID while the stream is already paused, those requests are 780 ignored. 782 As long as the stream is being paused, the PAUSED indication MAY be 783 sent together with any regular RTCP SR or RR. Including PAUSED in 784 this way allows RTP stream receivers joining while the stream is 785 paused to quickly know that there is a paused stream, what the last 786 sent extended RTP sequence number was, and what the next available 787 PauseID is to be able to construct valid PAUSE and RESUME requests at 788 a later stage. 790 When the RTP stream sender learns that a new End Point has joined the 791 RTP session, for example by a new SSRC and a CNAME that was not 792 previously seen in the RTP session, it should send PAUSED indications 793 for all its paused streams at its earliest opportunity. It should in 794 addition continue to include PAUSED indications in at least two 795 regular RTCP reports. 797 5.4. Requesting to Resume 799 An RTP stream receiver can request to resume a stream with a RESUME 800 request at any time, subject to AVPF timing rules. The RTP stream 801 receiver must include the available PauseID in the RESUME request for 802 it to be effective. 804 A pausing RTP stream sender that receives a RESUME including the 805 correct available PauseID resumes the stream at the earliest 806 opportunity. Receiving RESUME requests for a stream that is not 807 paused does not require any action and can be ignored. 809 There may be local considerations at the RTP stream sender, for 810 example that the media device is not ready, making it temporarily 811 impossible to resume the stream at that point in time, and the RTP 812 stream sender MAY then respond with a REFUSED containing the same 813 PauseID as in the RESUME. When receiving such REFUSED with a PauseID 814 identical to the one in the sent RESUME, RTP stream receivers SHOULD 815 then avoid sending further RESUME requests for some reasonable amount 816 of time, to allow the condition to clear. 818 If the RTP stream sender receives several identical RESUME for an RTP 819 stream that was already at least once responded with REFUSED and the 820 condition causing REFUSED remains, those additional REFUSED should be 821 sent with regular RTCP timing. A single REFUSED can respond to 822 several identical RESUME requests. 824 A pausing RTP stream sender can apply local considerations and MAY 825 resume a paused RTP stream at any time. If TMMBR 0 was used to pause 826 the RTP stream, it cannot be resumed due to local considerations, 827 unless the RTP stream is paused only due to local considerations 828 (Section 5.3) and thus no RTP stream receiver has requested to pause 829 the stream with TMMBR 0. 831 When resuming a paused stream, especially for media that makes use of 832 temporal redundancy between samples such as video, the temporal 833 dependency between samples taken before the pause and at the time 834 instant the stream is resumed may not be appropriate to use in the 835 encoding. Should such temporal dependency between before and after 836 the media was paused be used by the RTP stream sender, it requires 837 the RTP stream receiver to have saved the sample from before the 838 pause for successful continued decoding when resuming. The use of 839 this temporal dependency is left up to the RTP stream sender. If 840 temporal dependency is not used when the RTP stream is resumed, the 841 first encoded sample after the pause will not contain any temporal 842 dependency to samples before the pause (for video it may be a so- 843 called intra picture). If temporal dependency to before the pause is 844 used by the RTP stream sender when resuming, and if the RTP stream 845 receiver did not save any sample from before the pause, the RTP 846 stream receiver can use a FIR request [RFC5104] to explicitly ask for 847 a sample without temporal dependency (for video a so-called intra 848 picture), even at the same time as sending the RESUME. 850 5.5. TMMBR/TMMBN Considerations 852 As stated above, TMMBR/TMMBN may be used to provide pause and resume 853 functionality for the point-to-point case. If the topology is not 854 point-to-point, TMMBR/TMMBN cannot safely be used for pause or 855 resume. 857 This is a brief summary of what functionality is provided when using 858 TMMBR/TMMBN: 860 TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- 861 off period to wait for RESUME before pausing the RTP stream. 863 TMMBR >0: Corresponds to RESUME when the RTP stream was previously 864 paused with TMMBR 0. Since there is only a single RTP stream 865 receiver, there is no need for the RTP stream sender to delay 866 resuming the stream until after sending TMMBN >0, or to apply the 867 hold-off period specified in [RFC5104] before increasing the 868 bitrate from zero. The bitrate value used when resuming after 869 pausing with TMMBR 0 is either according to known limitations, or 870 based on starting a stream with the configured maximum for the 871 stream or session, for example given by b-parameter in SDP. 873 TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with 874 TMMBR 0, but may, just as PAUSED, also be used unsolicited. An 875 unsolicited RTP stream pause based on local sender considerations 876 uses the RTP stream's own SSRC as TMMBR restriction owner in the 877 TMMBN message bounding set. Also corresponds to a REFUSED 878 indication when a stream is requested to be resumed with TMMBR >0. 880 TMMBN >0: Cannot be used as REFUSED indication when a stream is 881 requested to be paused with TMMBR 0, for reasons stated in 882 Section 5.2. 884 6. Participant States 886 This document introduces three new states for a stream in an RTP 887 sender, according to the figure and sub-sections below. Any 888 references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL 889 be taken to apply to the extent possible also when TMMBR/TMMBN are 890 used (Section 5.5) for this functionality. 892 +------------------------------------------------------+ 893 | Received RESUME | 894 v | 895 +---------+ Received PAUSE +---------+ Hold-off period +--------+ 896 | Playing |---------------->| Pausing |---------------->| Paused | 897 | |<----------------| | | | 898 +---------+ Received RESUME +---------+ +--------+ 899 ^ | | PAUSE decision | 900 | | v | 901 | | PAUSE decision +---------+ PAUSE decision | 902 | +------------------>| Local |<--------------------+ 903 +-------------------------| Paused | 904 RESUME decision +---------+ 906 Figure 4: RTP Pause States 908 6.1. Playing State 910 This state is not new, but is the normal media sending state from 911 [RFC3550]. When entering the state, the PauseID MUST be incremented 912 by one in modulo arithmetic. The RTP sequence number for the first 913 packet sent after a pause SHALL be incremented by one compared to the 914 highest RTP sequence number sent before the pause. The first RTP 915 Time Stamp for the first packet sent after a pause SHOULD be set 916 according to capture times at the source, meaning the RTP Time Stamp 917 difference compared to before the pause reflects the time the RTP 918 stream was paused. 920 6.2. Pausing State 922 In this state, the RTP stream sender has received at least one PAUSE 923 message for the stream in question. The RTP stream sender SHALL wait 924 during a hold-off period for the possible reception of RESUME 925 messages for the RTP stream being paused before actually pausing RTP 926 stream transmission. The hold-off period to wait SHALL be long 927 enough to allow another RTP stream receiver to respond to the PAUSE 928 with a RESUME, if it determines that it would not like to see the 929 stream paused. This hold-off period is determined by the formula: 931 2 * RTT + T_dither_max, 933 where RTT is the longest round trip known to the RTP stream sender 934 and T_dither_max is defined in section 3.4 of [RFC4585]. The hold- 935 off period MAY be set to 0 by some signaling (Section 9) means when 936 it can be determined that there is only a single receiver, for 937 example in point-to-point or some unicast situations. 939 If the RTP stream sender has set the hold-off period to 0 and 940 receives information that it was an incorrect decision and that there 941 are in fact several receivers of the stream, for example by RTCP RR, 942 it MUST change the hold-off to instead be based on the above formula. 944 6.3. Paused State 946 An RTP stream is in paused state when the sender pauses its 947 transmission after receiving at least one PAUSE message and the hold- 948 off period has passed without receiving any RESUME message for that 949 stream. 951 When entering the state, the RTP stream sender SHALL send a PAUSED 952 indication to all known RTP stream receivers, and SHALL also repeat 953 PAUSED in the next two regular RTCP reports. 955 Pausing an RTP stream MUST NOT affect the sending of RTP keepalive 956 [RFC6263][RFC5245] applicable to that RTP stream. 958 Following sub-sections discusses some potential issues when an RTP 959 sender goes into paused state. These conditions are also valid if an 960 RTP Translator is used in the communication. When an RTP Mixer 961 implementing this specification is involved between the participants 962 (which forwards the stream by marking the RTP data with its own 963 SSRC), it SHALL be a responsibility of the Mixer to control sending 964 PAUSE and RESUME requests to the sender. The below conditions also 965 apply to the sender and receiver parts of the RTP Mixer, 966 respectively. 968 6.3.1. RTCP BYE Message 970 When a participant leaves the RTP session, it sends an RTCP BYE 971 message. In addition to the semantics described in section 6.3.4 and 972 6.3.7 of RTP [RFC3550], following two conditions MUST also be 973 considered when an RTP participant sends an RTCP BYE message, 975 o If a paused sender sends an RTCP BYE message, receivers observing 976 this SHALL NOT send further PAUSE or RESUME requests to it. 978 o Since a sender pauses its transmission on receiving the PAUSE 979 requests from any receiver in a session, the sender MUST keep 980 record of which receiver that caused the RTP stream to pause. If 981 that receiver sends an RTCP BYE message observed by the sender, 982 the sender SHALL resume the RTP stream. 984 6.3.2. SSRC Time-out 986 Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP 987 participant. Every RTP participant maintains a sender and receiver 988 list in a session. If a participant does not get any RTP or RTCP 989 packets from some other participant for the last five RTCP reporting 990 intervals it removes that participant from the receiver list. Any 991 streams that were paused by that removed participant SHALL be 992 resumed. 994 6.4. Local Paused State 996 This state can be entered at any time, based on local decision from 997 the RTP stream sender. As for Paused State (Section 6.3), the RTP 998 stream sender SHALL send a PAUSED indication to all known RTP stream 999 receivers, when entering the state, and repeat it a sufficient number 1000 of times to reach a high probability that the message is correctly 1001 delivered, unless the stream was already in paused state 1002 (Section 6.3). 1004 Editor's note: Consider specifying an explicit PAUSED ACK message 1005 that stops this message retransmission. 1007 When using TMMBN 0 as PAUSED indication, being in paused state, and 1008 entering local paused state, the RTP stream sender SHALL send TMMBN 0 1009 with itself included in the TMMBN bounding set. 1011 As indicated in Figure 4, this state has higher precedence than 1012 paused state (Section 6.3) and RESUME messages alone cannot resume a 1013 paused RTP stream as long as the local decision still applies. 1015 Pausing an RTP stream MUST NOT affect the sending of RTP keepalive 1016 [RFC6263][RFC5245] applicable to that RTP stream. 1018 When leaving the state, the stream state SHALL become Playing, 1019 regardless whether or not there were any RTP stream receivers that 1020 sent PAUSE for that stream, effectively clearing the RTP stream 1021 sender's memory for that stream. This does however not apply when 1022 the stream was paused by a TMMBR 0, either before entering or during 1023 the Local Paused State, in which case leaving Local Paused State just 1024 removes the RTP sender from the TMMBN bounding set, and a new TMMBN 1025 with the updated bounding set MUST be sent accordingly. The stream 1026 state can become Playing only when there is no entry with a bitrate 1027 value of 0 in the stream's bounding set. 1029 7. Message Format 1031 Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP 1032 feedback messages, i.e. Transport layer, Payload-specific, and 1033 Application layer feedback messages. This document defines a new 1034 Transport layer feedback message, this message is either a PAUSE 1035 request, a RESUME request, or one of four different types of 1036 acknowledgments in response to either PAUSE or RESUME requests. 1038 The Transport layer feedback messages are identified by having the 1039 RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The 1040 PAUSE and RESUME messages are identified by Feedback Message Type 1041 (FMT) value in common packet header for feedback message defined in 1042 section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport 1043 feedback message is identified by the FMT value = TBA1. 1045 The Common Packet Format for Feedback Messages defined by AVPF 1046 [RFC4585] is: 1048 0 1 2 3 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |V=2|P| FMT | PT | Length | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | SSRC of packet sender | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | SSRC of media source | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 : Feedback Control Information (FCI) : 1058 : : 1060 For the PAUSE and RESUME messages, the following interpretation of 1061 the packet fields will be: 1063 FMT: The FMT value identifying the PAUSE and RESUME message: TBA1 1065 PT: Payload Type = 205 (RTPFB) 1067 Length: As defined by AVPF, i.e. the length of this packet in 32-bit 1068 words minus one, including the header and any padding. 1070 SSRC of packet sender: The SSRC of the RTP session participant 1071 sending the messages in the FCI. Note, for End Points that have 1072 multiple SSRCs in an RTP session, any of its SSRCs MAY be used to 1073 send any of the pause message types. 1075 SSRC of media source: Not used, SHALL be set to 0. The FCI 1076 identifies the SSRC the message is targeted for. 1078 The Feedback Control Information (FCI) field consist of one or more 1079 PAUSE, RESUME, PAUSED, REFUSED, or any future extension. These 1080 messages have the following FCI format: 1082 0 1 2 3 1083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Target SSRC | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Type | Res | Parameter Len | PauseID | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 : Type Specific : 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 Figure 5: Syntax of FCI Entry in the PAUSE and RESUME message 1094 The FCI fields have the following definitions: 1096 Target SSRC (32 bits): For a PAUSE and RESUME messages, this value 1097 is the SSRC that the request is intended for. For PAUSED, it MUST 1098 be the SSRC being paused. If pausing is the result of a PAUSE 1099 request, the value in PAUSED is effectively the same as Target 1100 SSRC in a related PAUSE request. For REFUSED, it MUST be the 1101 Target SSRC of the PAUSE or RESUME request that cannot change 1102 state. A CSRC MUST NOT be used as a target as the interpretation 1103 of such a request is unclear. 1105 Type (4 bits): The pause feedback type. The values defined in this 1106 specification are as follows, 1108 0: PAUSE request message 1110 1: RESUME request message 1112 2: PAUSED indication message 1114 3: REFUSED indication message 1116 4-15: Reserved for future use 1118 Res: (4 bits): Type specific reserved. SHALL be ignored by 1119 receivers implementing this specification and MUST be set to 0 by 1120 senders implementing this specification. 1122 Parameter Len: (8 bits): Length of the Type Specific field in 32-bit 1123 words. MAY be 0. 1125 PauseID (16 bits): Message sequence identification. SHALL be 1126 incremented by one modulo 2^16 for each new PAUSE message, unless 1127 the message is re-transmitted. The initial value SHOULD be 0. 1128 The PauseID is scoped by the Target SSRC, meaning that PAUSE, 1129 RESUME, and PAUSED messages therefore share the same PauseID space 1130 for a specific Target SSRC. 1132 Type Specific: (variable): Defined per pause feedback Type. MAY be 1133 empty. 1135 8. Message Details 1137 This section contains detailed explanations of each message defined 1138 in this specification. All transmissions of request and indications 1139 are governed by the transmission rules as defined by Section 8.5. 1141 Any references to PAUSE, PAUSED, RESUME and REFUSED in this section 1142 SHALL be taken to apply to the extent possible also when TMMBR/TMMBN 1143 are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be 1144 used instead of the messages defined in this specification when the 1145 effective topology is point-to-point. If either sender or receiver 1146 learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT 1147 be used for pause/resume functionality. If the messages defined in 1148 this specification are supported in addition to TMMBR/TMMBN, pause/ 1149 resume signaling MUST use messages from this specification. If the 1150 topology is not point-to-point and the messages defined in this 1151 specification are not supported, pause/resume functionality with 1152 TMMBR/TMMBN MUST NOT be used. 1154 8.1. PAUSE 1156 An RTP stream receiver MAY schedule PAUSE for transmission at any 1157 time. 1159 PAUSE has no defined Type Specific parameters and Parameter Len MUST 1160 be set to 0. 1162 PauseID SHOULD be the available PauseID, as indicated by PAUSED 1163 (Section 8.2) or implicitly determined by previously received PAUSE 1164 or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be 1165 used if it was not possible to retrieve PauseID information, in which 1166 case the PAUSE will either succeed, or the correct PauseID can be 1167 found in the returned REFUSED (Section 8.4). A PauseID that is 1168 matching the available PauseID is henceforth also called a valid 1169 PauseID. 1171 PauseID needs to be incremented by one, in modulo arithmetic, for 1172 each PAUSE request that is not a retransmission, compared to what was 1173 used in the last PAUSED indication sent by the media sender. This is 1174 to ensure that the PauseID matches what is the current available 1175 PauseID at the RTP stream sender. The RTP stream sender increments 1176 what it considers to be the available PauseID when entering Playing 1177 State (Section 6.1). 1179 For the scope of this specification, a PauseID larger than the 1180 current one is defined as having a value between and including 1181 (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is 1182 the modulo operator. Similarly, a PauseID smaller than the current 1183 one is defined as having a value between and including (PauseID - 1184 2^15) MOD 2^16 and (PauseID - 1) MOD 2^16. 1186 If an RTP stream receiver that sent a PAUSE with a certain PauseID 1187 receives a RESUME with the same PauseID, it is RECOMMENDED that it 1188 refrains from sending further PAUSE requests for some appropriate 1189 time since the RESUME indicates that there are other receivers that 1190 still wishes to receive the stream. 1192 If the targeted RTP stream does not pause, if no PAUSED indication 1193 with a larger PauseID than the one used in PAUSE, and if no REFUSED 1194 is received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled 1195 for retransmission, using the same PauseID. RTT is the observed 1196 round-trip to the RTP stream sender and T_dither_max is defined in 1197 section 3.4 of [RFC4585]. 1199 When an RTP stream sender in Playing State (Section 6.1) receives a 1200 valid PAUSE, and unless local considerations currently makes it 1201 impossible to pause the stream, it SHALL enter Pausing State 1202 (Section 6.2) when reaching an appropriate place to pause in the 1203 stream, and act accordingly. 1205 If an RTP stream sender receives a valid PAUSE while in Pausing, 1206 Paused (Section 6.3) or Local Paused (Section 6.4) States, the 1207 received PAUSE SHALL be ignored. 1209 8.2. PAUSED 1211 The PAUSED indication MUST be sent whenever entering Paused State 1212 (Section 6.3) as a result of receiving a valid PAUSE (Section 8.1) 1213 request, or when entering Local Paused State (Section 6.4) based on a 1214 RTP stream sender local decision. 1216 PauseID MUST contain the available, valid value to be included in a 1217 subsequent RESUME (Section 8.3). 1219 PAUSED SHALL contain a 32 bit parameter with the RTP extended highest 1220 sequence number valid when the RTP stream was paused. Parameter Len 1221 MUST be set to 1. 1223 After having entered Paused or Local Paused State and thus having 1224 sent PAUSED once, PAUSED MUST also be included in the next two 1225 regular RTCP reports, given that the pause condition is then still 1226 effective. 1228 While remaining in Paused or Local Paused States, PAUSED MAY be 1229 included in all regular RTCP reports. 1231 When in Paused or Local Paused States, It is RECOMMENDED to send 1232 PAUSED at the earliest opportunity and also to include it in the next 1233 two regular RTCP reports, whenever the RTP stream sender learns that 1234 there are End Points that did not previously receive the stream, for 1235 example by RTCP reports with an SSRC and a CNAME that was not 1236 previously seen in the RTP session. 1238 8.3. RESUME 1240 An RTP stream receiver MAY schedule RESUME for transmission whenever 1241 it wishes to resume a paused stream, or to disapprove a stream from 1242 being paused. 1244 PauseID SHOULD be the valid PauseID, as indicated by PAUSED 1245 (Section 8.2) or implicitly determined by previously received PAUSE 1246 (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be 1247 used if it was not possible to retrieve PauseID information, in which 1248 case the RESUME will either succeed, or the correct PauseID can be 1249 found in a returned REFUSED (Section 8.4). 1251 RESUME has no defined Type Specific parameters and Parameter Len MUST 1252 be set to 0. 1254 When an RTP stream sender in Pausing (Section 6.2), Paused 1255 (Section 6.3) or Local Paused State (Section 6.4) receives a valid 1256 RESUME, and unless local considerations currently makes it impossible 1257 to resume the stream, it SHALL enter Playing State (Section 6.1) and 1258 act accordingly. If the RTP stream sender is incapable of honoring 1259 the RESUME request with a valid PauseID, or receives a RESUME request 1260 with an invalid PauseID while in Paused or Pausing state, the RTP 1261 stream sender sends a REFUSED message as specified below. 1263 If an RTP stream sender in Playing State receives a RESUME containing 1264 either a valid PauseID or a PauseID that is less than the valid 1265 PauseID, the received RESUME SHALL be ignored. 1267 8.4. REFUSED 1269 REFUSED has no defined Type Specific parameters and Parameter Len 1270 MUST be set to 0. 1272 If an RTP stream sender receives a valid PAUSE (Section 8.1) or 1273 RESUME (Section 8.3) request that cannot be fulfilled by the sender 1274 due to some local consideration, it SHALL schedule transmission of a 1275 REFUSED indication containing the valid PauseID from the rejected 1276 request. 1278 If an RTP stream sender receives PAUSE or RESUME requests with a non- 1279 valid PauseID it SHALL schedule a REFUSED response containing the 1280 available, valid PauseID, except if the RTP stream sender is in 1281 Playing State and receives a RESUME with a PauseID less than the 1282 valid one, in which case the RESUME SHALL be ignored. 1284 If several PAUSE or RESUME that would render identical REFUSED 1285 responses are received before the scheduled REFUSED is sent, 1286 duplicate REFUSED MUST NOT be scheduled for transmission. This 1287 effectively lets a single REFUSED respond to several invalid PAUSE or 1288 RESUME requests. 1290 If REFUSED containing a certain PauseID was already sent and yet more 1291 PAUSE or RESUME messages are received that require additional REFUSED 1292 with that specific PauseID to be scheduled, and unless the PauseID 1293 number space has wrapped since REFUSED was last sent with that 1294 PauseID, further REFUSED messages with that PauseID SHOULD be sent in 1295 regular RTCP reports. 1297 An RTP stream receiver that sent a PAUSE or RESUME request and 1298 receives a REFUSED containing the same PauseID as in the request 1299 SHOULD refrain from sending an identical request for some appropriate 1300 time to allow the condition that caused REFUSED to clear. 1302 An RTP stream receiver that sent a PAUSE or RESUME request and 1303 receives a REFUSED containing a PauseID different from the request 1304 MAY schedule another request using the PauseID from the REFUSED 1305 indication. 1307 8.5. Transmission Rules 1309 The transmission of any RTCP feedback messages defined in this 1310 specification MUST follow the normal AVPF defined timing rules and 1311 depends on the session's mode of operation. 1313 All messages defined in this specification, as well as TMMBR/TMMBN 1314 used for pause/resume purposes (Section 5.5), MAY use either Regular, 1315 Early or Immediate timings, taking the following into consideration: 1317 o PAUSE SHOULD use Early or Immediate timing, except for 1318 retransmissions that SHOULD use Regular timing. 1320 o The first transmission of PAUSED for each (non-wrapped) PauseID 1321 SHOULD be sent with Immediate or Early timing, while subsequent 1322 PAUSED for that PauseID SHOULD use Regular timing. Unsolicited 1323 PAUSED (sent when entering Local Paused State (Section 6.4)) 1324 SHOULD always use Immediate or Early timing, until PAUSED for that 1325 PauseID is considered delivered at least once to all receivers of 1326 the paused RTP stream, after which it SHOULD use Regular timing. 1328 Editor's note: Consider specifying a PAUSED ACK message as 1329 explicit indication of reception. 1331 o RESUME SHOULD always use Immediate or Early timing. 1333 o The first transmission of REFUSED for each (non-wrapped) PauseID 1334 SHOULD be sent with Immediate or Early timing, while subsequent 1335 REFUSED for that PauseID SHOULD use Regular timing. 1337 9. Signaling 1339 The capability of handling messages defined in this specification MAY 1340 be exchanged at a higher layer such as SDP. This document extends 1341 the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to 1342 include the request for pause and resume. This specification follows 1343 all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an 1344 rtcp-fb attribute relating to payload type in a session description. 1346 This specification defines a new parameter "pause" to the "ccm" 1347 feedback value defined in CCM [RFC5104], representing the capability 1348 to understand the RTCP feedback message and all of the defined FCIs 1349 of PAUSE, RESUME, PAUSED and REFUSED. 1351 Note: When TMMBR 0 / TMMBN 0 are used to implement pause and 1352 resume functionality (with the restrictions described in this 1353 specification), signaling rtcp-fb attribute with ccm tmmbr 1354 parameter is sufficient and no further signaling is necessary. 1355 There is however no guarantee that TMMBR/TMMBN implementations 1356 pre-dating this specification work exactly as described here when 1357 used with a bitrate value of 0. 1359 The "pause" parameter has two optional attributes, "nowait" and 1360 "config": 1362 o "nowait" indicates that the hold-off period defined in Section 6.2 1363 can be set to 0, reducing the latency before the stream can paused 1364 after receiving a PAUSE request. This condition occurs when there 1365 will be only a single receiver per direction in the RTP session, 1366 for example in point-to-point sessions. It is also possible to 1367 use in scenarios using unidirectional media. The conditions that 1368 allow "nowait" to be set also indicate that it would be possible 1369 to use CCM TMMBR/TMMBN as pause/resume signaling. 1371 o "config" allows for partial implementation of this specification 1372 according to the different roles in the use cases section 1373 (Section 3), and takes a value that describes what sub-set is 1374 implemented: 1376 1 Full implementation of this specification. This is the default 1377 configuration. A missing config attribute MUST be treated 1378 equivalent to providing a config value of 1. 1380 2 The implementation intends to send PAUSE and RESUME requests 1381 for received RTP streams and is thus also capable of receiving 1382 PAUSED and REFUSED. It does not support receiving PAUSE and 1383 RESUME requests, but may pause sent RTP streams due to local 1384 considerations and then intends to send PAUSED for them. 1386 3 The implementation supports receiving PAUSE and RESUME requests 1387 targeted for RTP streams it sends. It will send PAUSED and 1388 REFUSED as needed. The node will not send any PAUSE and RESUME 1389 requests, but supports and desires receiving PAUSED if received 1390 RTP streams are paused. 1392 4 The implementation intends to send PAUSE and RESUME requests 1393 for received RTP streams and is thus also capable of receiving 1394 PAUSED and REFUSED. It cannot pause any RTP streams it sends, 1395 and thus does not support receiving PAUSE and RESUME requests, 1396 and also does not support sending PAUSED indications. 1398 5 The implementation supports receiving PAUSE and RESUME requests 1399 targeted for RTP streams it sends. It will send PAUSED and 1400 REFUSED as needed. It does not support sending PAUSE and 1401 RESUME requests to pause received RTP streams, and also does 1402 not support receiving PAUSED indications. 1404 6 The implementation supports sent and received RTP streams being 1405 paused due to local considerations, and thus supports sending 1406 and receiving PAUSED indications. 1408 7 The implementation supports and desires to receive PAUSED 1409 indications for received RTP streams, but does not pause or 1410 send PAUSED indications for sent RTP streams. It does not 1411 support any other messages defined in this specification. 1413 8 The implementation supports pausing sent RTP streams and 1414 sending PAUSED indications for them, but does not support 1415 receiving PAUSED indications for received RTP streams. It does 1416 not support any other messages defined in this specification. 1418 When signaling a config value other than 1, an implementation MAY 1419 ignore non-supported messages on reception, and MAY omit sending non- 1420 supported messages. The below table summarizes per-message send and 1421 receive support for the different config attribute values ("X" 1422 indicating support and "-" indicating non-support): 1424 +---+-----------------------------+-----------------------------+ 1425 | # | Send | Receive | 1426 | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | 1427 +---+-----------------------------+-----------------------------+ 1428 | 1 | X X X X | X X X X | 1429 | 2 | X X X - | - - X X | 1430 | 3 | - - X X | X X X - | 1431 | 4 | X X - - | - - X X | 1432 | 5 | - - X X | X X - - | 1433 | 6 | - - X - | - - X - | 1434 | 7 | - - - - | - - X - | 1435 | 8 | - - X - | - - - - | 1436 +---+-----------------------------+-----------------------------+ 1438 Figure 6: Supported messages for different config values 1440 This is the resulting ABNF [RFC5234], extending existing ABNF in 1441 section 7.1 of CCM [RFC5104]: 1443 rtcp-fb-ccm-param =/ SP "pause" [SP pause-attr] 1444 pause-attr = [pause-config] [SP "nowait"] [SP byte-string] 1445 pause-config = "config=" pause-config-value 1446 pause-config-value = %x31-38 1447 ; byte-string as defined in RFC 4566, for future extensions 1449 Figure 7: ABNF 1451 An endpoint implementing this specification and using SDP to signal 1452 capability SHOULD indicate the new "pause" parameter with ccm 1453 signaling, but MAY use existing ccm tmmbr signaling [RFC5104] if the 1454 limitations in functionality as described in this specification 1455 coming from such usage are considered acceptable. The messages from 1456 this specification SHOULD NOT be used towards receivers that did not 1457 declare capability to receive those messages. 1459 There MUST NOT be more than one "a=rtcp-fb" line with "pause" 1460 applicable to a single payload type in the SDP, unless the additional 1461 line uses "*" as payload type, in which case "*" SHALL be interpreted 1462 as applicable to all listed payload types that does not have an 1463 explicit "pause" specification. 1465 9.1. Offer-Answer Use 1467 An offerer implementing this specification needs to include "pause" 1468 CCM parameter with suitable configuration attribute ("config") in the 1469 SDP, according to what messages it intends to send and desires to 1470 receive in the session. 1472 In SDP offer/answer, the "config" attribute and its message 1473 directions are interpreted based on the agent providing the SDP. The 1474 offerer is described in an offer, and the answerer is described in an 1475 answer. 1477 An answerer receiving an offer with a "pause" CCM parameter and a 1478 config attribute with a certain value, describing a certain 1479 capability to send and receive messages, MAY change the config 1480 attribute value in the answer to another configuration. The 1481 permitted answers are listed in the below table. 1483 SDP Offer config value | Permitted SDP Answer config values 1484 -----------------------+----------------------------------- 1485 1 | 1, 2, 3, 4, 5, 6, 7, 8 1486 2 | 3, 4, 5, 6, 7, 8 1487 3 | 2, 4, 5, 6, 7, 8 1488 4 | 5, 6, 7, 8 1489 5 | 4, 6, 7, 8 1490 6 | 6, 7, 8 1491 7 | 8 1492 8 | 7 1494 Figure 8: Config values in Offer/Answer 1496 An offer or answer omitting the config attribute, MUST be interpreted 1497 as equivalent to config=1. In all cases the answerer MAY also 1498 completely remove any "pause" CCM parameter to indicate that it does 1499 not understand or desire to use any pause functionality for the 1500 affected payload types. 1502 If the offerer believes that itself and the intended answerer are 1503 likely the only End Points in the RTP session, it MAY include the 1504 "nowait" sub-parameter on the "pause" line in the offer. If an 1505 answerer receives the "nowait" sub-parameter on the "pause" line in 1506 the SDP, and if it has information that the offerer and itself are 1507 not the only End Points in the RTP session, it MUST NOT include any 1508 "nowait" sub-parameter on its "pause" line in the SDP answer. The 1509 answerer MUST NOT add "nowait" on the "pause" line in the answer 1510 unless it is present on the "pause" line in the offer. If both offer 1511 and answer contained a "nowait" parameter, then the hold-off period 1512 is configured to 0 at both offerer and answerer. 1514 9.2. Declarative Use 1516 In declarative use, the SDP is used to configure the node receiving 1517 the SDP. This has implications on the interpretation of the SDP 1518 signaling extensions defined in this specification. 1520 First, the "config" attribute and its message directions are 1521 interpreted based on the node receiving the SDP. 1523 Second, the "nowait" parameter, if included, is followed as 1524 specified. It is the responsibility of the declarative SDP sender to 1525 determine if a configured node will participate in a session that 1526 will be point to point, based on the usage. For example, a 1527 conference client being configured for an any source multicast 1528 session using SAP [RFC2974] will not be in a point to point session, 1529 thus "nowait" cannot be included. An RTSP [RFC2326] client receiving 1530 a declarative SDP may very well be in a point to point session, 1531 although it is highly doubtful that an RTSP client would need to 1532 support this specification, considering the inherent PAUSE support in 1533 RTSP. 1535 10. Examples 1537 The following examples shows use of PAUSE and RESUME messages, 1538 including use of offer-answer: 1540 1. Offer-Answer 1542 2. Point-to-Point session 1544 3. Point-to-Multipoint using Mixer 1546 4. Point-to-Multipoint using Translator 1548 10.1. Offer-Answer 1550 The below figures contains an example how to show support for pausing 1551 and resuming the streams, as well as indicating whether or not the 1552 hold-off period can be set to 0. 1554 v=0 1555 o=alice 3203093520 3203093520 IN IP4 alice.example.com 1556 s=Pausing Media 1557 t=0 0 1558 c=IN IP4 alice.example.com 1559 m=audio 49170 RTP/AVPF 98 99 1560 a=rtpmap:98 G719/48000 1561 a=rtpmap:99 PCMA/8000 1562 a=rtcp-fb:* ccm pause nowait 1564 Figure 9: SDP Offer With Pause and Resume Capability 1566 The offerer supports all of the messages defined in this 1567 specification, leaving out the optional config attribute. The 1568 offerer also believes that it will be the sole receiver of the 1569 answerer's stream as well as that the answerer will be the sole 1570 receiver of the offerer's stream and thus includes the "nowait" sub- 1571 parameter for the "pause" parameter. 1573 This is the SDP answer: 1575 v=0 1576 o=bob 293847192 293847192 IN IP4 bob.example.com 1577 s=- 1578 t=0 0 1579 c=IN IP4 bob.example.com 1580 m=audio 49202 RTP/AVPF 98 1581 a=rtpmap:98 G719/48000 1582 a=rtcp-fb:98 ccm pause config=2 1584 Figure 10: SDP Answer With Pause and Resume Capability 1586 The answerer will not allow its sent streams to be paused or resumed 1587 and thus restricts the answer to indicate config=2. It also supports 1588 pausing its own RTP streams due to local considerations, which is why 1589 config=2 is chosen rather than config=4. The answerer somehow knows 1590 that it will not be a point-to-point RTP session and has therefore 1591 removed "nowait" from the "pause" line, meaning that the offerer must 1592 use a non-zero hold-off period when being requested to pause the 1593 stream. 1595 When using TMMBR 0 / TMMBN 0 to achieve pause and resume 1596 functionality, there are no differences in SDP compared to CCM 1597 [RFC5104] and therefore no such examples are included here. 1599 10.2. Point-to-Point Session 1601 This is the most basic scenario, which involves two participants, 1602 each acting as a sender and/or receiver. Any RTP data receiver sends 1603 PAUSE or RESUME messages to the sender, which pauses or resumes 1604 transmission accordingly. The hold-off period before pausing a 1605 stream is 0. 1607 +---------------+ +---------------+ 1608 | RTP Sender | | RTP Receiver | 1609 +---------------+ +---------------+ 1610 : t1: RTP data : 1611 | -------------------------------> | 1612 | t2: PAUSE(3) | 1613 | <------------------------------- | 1614 | < RTP data paused > | 1615 | t3: PAUSED(3) | 1616 | -------------------------------> | 1617 : < Some time passes > : 1618 | t4: RESUME(3) | 1619 | <------------------------------- | 1620 | t5: RTP data | 1621 | -------------------------------> | 1622 : < Some time passes > : 1623 | t6: PAUSE(4) | 1624 | <------------------------------- | 1625 | < RTP data paused > | 1626 : : 1628 Figure 11: Pause and Resume Operation in Point-to-Point 1630 Figure 11 shows the basic pause and resume operation in Point-to- 1631 Point scenario. At time t1, an RTP sender sends data to a receiver. 1632 At time t2, the RTP receiver requests the sender to pause the stream, 1633 using PauseID 3 (which it knew since before in this example). The 1634 sender pauses the data and replies with a PAUSED containing the same 1635 PauseID. Some time later (at time t4) the receiver requests the 1636 sender to resume, which resumes its transmission. The next PAUSE, 1637 sent at time t6, contains an updated PauseID (4). 1639 +---------------+ +---------------+ 1640 | RTP Sender | | RTP Receiver | 1641 +---------------+ +---------------+ 1642 : t1: RTP data : 1643 | -------------------------------> | 1644 | t2: TMMBR 0 | 1645 | <------------------------------- | 1646 | < RTP data paused > | 1647 | t3: TMMBN 0 | 1648 | -------------------------------> | 1649 : < Some time passes > : 1650 | t4: TMMBR 150000 | 1651 | <------------------------------- | 1652 | t5: RTP data | 1653 | -------------------------------> | 1654 : < Some time passes > : 1655 | t6: TMMBR 0 | 1656 | <------------------------------- | 1657 | < RTP data paused > | 1658 : : 1660 Figure 12: TMMBR Pause and Resume in Point-to-Point 1662 Figure 12 describes the same point-to-point scenario as above, but 1663 using TMMBR/TMMBN signaling. 1665 +---------------+ +----------------+ 1666 | RTP Sender A | | RTP Receiver B | 1667 +---------------+ +----------------+ 1668 : t1: RTP data : 1669 | -------------------------------> | 1670 | < RTP data paused > | 1671 | t2: TMMBN {A:0} | 1672 | -------------------------------> | 1673 : < Some time passes > : 1674 | t3: TMMBR 0 | 1675 | <------------------------------- | 1676 | t4: TMMBN {A:0,B:0} | 1677 | -------------------------------> | 1678 : < Some time passes > : 1679 | t5: TMMBN {B:0} | 1680 | -------------------------------> | 1681 : < Some time passes > : 1682 | t6: TMMBR 80000 | 1683 | <------------------------------- | 1684 | t7: RTP data | 1685 | -------------------------------> | 1686 : : 1688 Figure 13: Unsolicited PAUSED using TMMBN 1690 Figure 13 describes the case when an RTP stream sender (A) chooses to 1691 pause an RTP stream due to local considerations. Both the RTP stream 1692 sender (A) and the RTP stream receiver (B) use TMMBR/TMMBN signaling 1693 for pause/resume purposes. A decides to pause the RTP stream at time 1694 t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN 1695 bounding set. At time t3, despite the fact that the RTP stream is 1696 still paused, B decides that it is no longer interested to receive 1697 the RTP stream and signals PAUSE by sending a TMMBR 0. As a result 1698 of that, the bounding set now contains both A and B, and A sends out 1699 a new TMMBN reflecting that. After a while, at time t5, the local 1700 considerations that caused A to pause the RTP stream no longer apply, 1701 causing it to remove itself from the bounding set and to send a new 1702 TMMBN indicating this. At time t6, B decides that it is now 1703 interested to receive the RTP stream again and signals RESUME by 1704 sending a TMMBR containing a bitrate value greater than 0, causing A 1705 to resume sending RTP data. 1707 +---------------+ +---------------+ 1708 | RTP Sender | | RTP Receiver | 1709 +---------------+ +---------------+ 1710 : t1: RTP data : 1711 | ------------------------------------> | 1712 | t2: PAUSE(7), lost | 1713 | <---X-------------- | 1714 | | 1715 | t3: RTP data | 1716 | ------------------------------------> | 1717 : : 1718 | | 1719 | t4: PAUSE(7) | 1720 | <------------------------------------ | 1721 | < RTP data paused > | 1722 | t5: PAUSED(7) | 1723 | ------------------------------------> | 1724 : < Some time passes > : 1725 | t6: RESUME(7), lost | 1726 | <---X-------------- | 1727 | t7: RESUME(7) | 1728 | <------------------------------------ | 1729 | t8: RTP data | 1730 | ------------------------------------> | 1731 | t9: RESUME(7) | 1732 | <------------------------------------ | 1733 : : 1735 Figure 14: Pause and Resume Operation With Messages Lost 1737 Figure 14 describes what happens if a PAUSE message from an RTP 1738 stream receiver does not reach the RTP stream sender. After sending 1739 a PAUSE message, the RTP stream receiver waits for a time-out to 1740 detect if the RTP stream sender has paused the data transmission or 1741 has sent PAUSED indication according to the rules discussed in 1742 Section 6.3. As the PAUSE message is lost on the way (at time t2), 1743 RTP data continues to reach to the RTP stream receiver. When the 1744 timer expires, the RTP stream receiver schedules a retransmission of 1745 the PAUSE message, which is sent at time t4. If the PAUSE message 1746 now reaches the RTP stream sender, it pauses the RTP stream and 1747 replies with PAUSED. 1749 At time t6, the RTP stream receiver wishes to resume the stream again 1750 and sends a RESUME, which is lost. This does not cause any severe 1751 effect, since there is no requirement to wait until further RESUME 1752 are sent and another RESUME are sent already at time t7, which now 1753 reaches the RTP stream sender that consequently resumes the stream at 1754 time t8. The time interval between t6 and t7 can vary, but may for 1755 example be one RTCP feedback transmission interval as determined by 1756 the AVPF rules. 1758 The RTP stream receiver did not realize that the RTP stream was 1759 resumed in time to stop yet another scheduled RESUME from being sent 1760 at time t9. This is however harmless since the RESUME PauseID is 1761 less than the valid one and will be ignored by the RTP stream sender. 1762 It will also not cause any unwanted resume even if the stream was 1763 paused based on a PAUSE from some other receiver before receiving the 1764 RESUME, since the valid PauseID is now larger than the one in the 1765 stray RESUME and will only cause a REFUSED containing the new valid 1766 PauseID from the RTP stream sender. 1768 +---------------+ +---------------+ 1769 | RTP Sender | | RTP Receiver | 1770 +---------------+ +---------------+ 1771 : t1: RTP data : 1772 | ------------------------------> | 1773 | t2: PAUSE(11) | 1774 | <------------------------------ | 1775 | | 1776 | < Can not pause RTP data > | 1777 | t3: REFUSED(11) | 1778 | ------------------------------> | 1779 | | 1780 | t4: RTP data | 1781 | ------------------------------> | 1782 : : 1784 Figure 15: Pause Request is Refused in Point-to-Point 1786 In Figure 15, the receiver requests to pause the sender, which 1787 refuses to pause due to some consideration local to the sender and 1788 responds with a REFUSED message. 1790 10.3. Point-to-Multipoint using Mixer 1792 An RTP Mixer is an intermediate node connecting different transport- 1793 level clouds. The Mixer receives streams from different RTP sources, 1794 selects or combines them based on the application's needs and 1795 forwards the generated stream(s) to the destination. The Mixer 1796 typically puts its' own SSRC(s) in RTP data packets instead of the 1797 original source(s). 1799 The Mixer keeps track of all the streams delivered to the Mixer and 1800 how they are currently used. In this example, it selects the video 1801 stream to deliver to the receiver R based on the voice activity of 1802 the RTP stream senders. The video stream will be delivered to R 1803 using M's SSRC and with an CSRC indicating the original source. 1805 Note that PauseID is not of any significance for the example and is 1806 therefore omitted in the description. 1808 +-----+ +-----+ +-----+ +-----+ 1809 | R | | M | | S1 | | S2 | 1810 +-----+ +-----| +-----+ +-----+ 1811 : : t1:RTP(S1) : : 1812 | t2:RTP(M:S1) |<-----------------| | 1813 |<-----------------| | | 1814 | | t3:RTP(S2) | | 1815 | |<------------------------------------| 1816 | | t4: PAUSE(S2) | | 1817 | |------------------------------------>| 1818 | | | t5: PAUSED(S2) | 1819 | |<------------------------------------| 1820 | | | | 1821 | | t6: RESUME(S2) | | 1822 | |------------------------------------>| 1823 | | | t7: RTP to M | 1824 | |<------------------------------------| 1825 | t8:RTP(M:S2) | | | 1826 |<-----------------| | | 1827 | | t9:PAUSE(S1) | | 1828 | |----------------->| | 1829 | | t10:PAUSED(S1) | | 1830 | |<-----------------| | 1831 | | | | 1832 : : : : 1834 Figure 16: Pause and Resume Operation for a Voice Activated Mixer 1836 The session starts at t1 with S1 being the most active speaker and 1837 thus being selected as the single video stream to be delivered to R 1838 (t2) using the Mixer SSRC but with S1 as CSRC (indicated after the 1839 colon in the figure). Then S2 joins the session at t3 and starts 1840 delivering an RTP stream to the Mixer. As S2 has less voice activity 1841 then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE 1842 request. At t5, S2 acknowledges with a PAUSED and at the same 1843 instant stops delivering RTP to the Mixer. At t6, the user at S2 1844 starts speaking and becomes the most active speaker and the Mixer 1845 decides to switch the video stream to S2, and therefore quickly sends 1846 a RESUME request to S2. At t7, S2 has received the RESUME request 1847 and acts on it by resuming RTP stream delivery to M. When the RTP 1848 stream from t7 arrives at the Mixer, it switches this RTP stream into 1849 its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes 1850 unused, the Mixer issues a PAUSE request to S1 at t9, which is 1851 acknowledged at t10 with a PAUSED and the RTP stream from S1 stops 1852 being delivered. 1854 10.4. Point-to-Multipoint using Translator 1856 A transport Translator in an RTP session forwards the message from 1857 one peer to all the others. Unlike Mixer, the Translator does not 1858 mix the streams or change the SSRC of the messages or RTP media. 1859 These examples are to show that the messages defined in this 1860 specification can be safely used also in a transport Translator case. 1861 The parentheses in the figures contains (Target SSRC, PauseID) 1862 information for the messages defined in this specification. 1864 +-------------+ +-------------+ +--------------+ 1865 | Sender(S) | | Translator | | Receiver(R) | 1866 +-------------+ +-------------| +--------------+ 1867 : t1: RTP(S) : : 1868 |------------------>| | 1869 | | t2: RTP (S) | 1870 | |------------------>| 1871 | | t3: PAUSE(S,3) | 1872 | |<------------------| 1873 | t4:PAUSE(S,3) | | 1874 |<------------------| | 1875 : < Sender waiting for possible RESUME> : 1876 | < RTP data paused > | 1877 | t5: PAUSED(S,3) | | 1878 |------------------>| | 1879 | | t6: PAUSED(S,3) | 1880 | |------------------>| 1881 : : : 1882 | | t7: RESUME(S,3) | 1883 | |<------------------| 1884 | t8: RESUME(S,3) | | 1885 |<------------------| | 1886 | t9: RTP (S) | | 1887 |------------------>| | 1888 | | t10: RTP (S) | 1889 | |------------------>| 1890 : : : 1892 Figure 17: Pause and Resume Operation Between Two Participants Using 1893 a Translator 1895 Figure 17 describes how a Translator can help the receiver in pausing 1896 and resuming the sender. The sender S sends RTP data to the receiver 1897 R through Translator, which just forwards the data without modifying 1898 the SSRCs. The receiver sends a PAUSE request to the sender, which 1899 in this example knows that there may be more receivers of the stream 1900 and waits a non-zero hold-off period to see if there is any other 1901 receiver that wants to receive the data, does not receive any 1902 disapproving RESUME, hence pauses itself and replies with PAUSED. 1903 Similarly the receiver resumes the sender by sending RESUME request 1904 through Translator. Since this describes only a single pause 1905 operation for a single RTP stream sender, all messages uses a single 1906 PauseID, in this example 3. 1908 +-----+ +-----+ +-----+ +-----+ 1909 | S | | T | | R1 | | R2 | 1910 +-----+ +-----| +-----+ +-----+ 1911 : t1:RTP(S) : : : 1912 |----------------->| | | 1913 | | t2:RTP(S) | | 1914 | |----------------->------------------>| 1915 | | t3:PAUSE(S,7) | | 1916 | |<-----------------| | 1917 | t4:PAUSE(S,7) | | | 1918 |<-----------------|------------------------------------>| 1919 | | | t5:RESUME(S,7) | 1920 | |<------------------------------------| 1921 | t6:RESUME(S,7) | | | 1922 |<-----------------| | | 1923 | | | 1924 | | | t7: PAUSE(S,8) | 1925 | |<------------------------------------| 1926 | t8:PAUSE(S,8) | | | 1927 |<-----------------| | | 1928 : : : : 1929 | < Pauses RTP Stream > | | 1930 | t9:PAUSED(S,8) | | | 1931 |----------------->| | | 1932 | | t10:PAUSED(S,8) | | 1933 | |----------------->------------------>| 1934 : : : : 1935 | | t11:RESUME(S,8) | | 1936 | |<-----------------| | 1937 | t12:RESUME(S,8) | | | 1938 |<-----------------| | | 1939 | t13:RTP(S) | | | 1940 |----------------->| | | 1941 | | t14:RTP(S) | | 1942 | |----------------->------------------>| 1943 : : : : 1945 Figure 18: Pause and Resume Operation Between One Sender and Two 1946 Receivers Through Translator 1948 Figure 18 explains the pause and resume operations when a transport 1949 Translator is involved between a sender and two receivers in an RTP 1950 session. Each message exchange is represented by the time it 1951 happens. At time t1, Sender (S) starts sending an RTP stream to the 1952 Translator, which is forwarded to R1 and R2 through the Translator, 1953 T. R1 and R2 receives RTP data from Translator at t2. At this 1954 point, both R1 and R2 will send RTCP Receiver Reports to S informing 1955 that they receive S's stream. 1957 After some time (at t3), R1 chooses to pause the stream. On 1958 receiving the PAUSE request from R1 at t4, S knows that there are at 1959 least one receiver that may still want to receive the data and uses a 1960 non-zero hold-off period to wait for possible RESUME messages. R2 1961 did also receive the PAUSE request at time t4 and since it still 1962 wants to receive the stream, it sends a RESUME for it at time t5, 1963 which is forwarded to the sender S by the translator T. The sender S 1964 sees the RESUME at time t6 and continues to send data to T which 1965 forwards to both R1 and R2. At t7, the receiver R2 chooses to pause 1966 the stream by sending a PAUSE request with an updated PauseID. The 1967 sender S still knows that there are more than one receiver (R1 and 1968 R2) that may want the stream and again waits a non-zero hold-off 1969 period, after which and not having received any disapproving RESUME, 1970 it concludes that the stream must be paused. S now stops sending the 1971 stream and replies with PAUSED to R1 and R2. When any of the 1972 receivers (R1 or R2) chooses to resume the stream from S, in this 1973 example R1, it sends a RESUME request to the sender. The RTP sender 1974 immediately resumes the stream. 1976 Consider also an RTP session which includes one or more receivers, 1977 paused sender(s), and a Translator. Further assume that a new 1978 participant joins the session, which is not aware of the paused 1979 sender(s). On receiving knowledge about the newly joined 1980 participant, e.g. any RTP traffic or RTCP report (i.e. either SR or 1981 RR) from the newly joined participant, the paused sender(s) 1982 immediately sends PAUSED indications for the paused streams since 1983 there is now a receiver in the session that did not pause the 1984 sender(s) and may want to receive the streams. Having this 1985 information, the newly joined participant has the same possibility as 1986 any other participant to resume the paused streams. 1988 11. IANA Considerations 1990 This specification requests the following registrations from IANA: 1992 1. A new value for media stream pause / resume to be registered with 1993 IANA in the "FMT Values for RTPFB Payload Types" registry located 1994 at the time of publication at: http://www.iana.org/assignments/ 1995 rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8 1997 Value: TBA1 1999 Name: PAUSE-RESUME 2001 Long Name: Media Pause / Resume 2002 Reference: This RFC 2004 2. A new value "pause" to be registered with IANA in the "Codec 2005 Control Messages" registry located at the time of publication at: 2006 http://www.iana.org/assignments/sdp-parameters/sdp- 2007 parameters.xhtml#sdp-parameters-19 2009 Value Name: pause 2011 Long Name: Media Pause / Resume 2013 Usable with: ccm 2015 Reference: This RFC 2017 12. Security Considerations 2019 This document extends the CCM [RFC5104] and defines new messages, 2020 i.e. PAUSE and RESUME. The exchange of these new messages MAY have 2021 some security implications, which need to be addressed by the user. 2022 Following are some important implications, 2024 1. Identity spoofing - An attacker can spoof him/herself as an 2025 authenticated user and can falsely pause or resume any source 2026 transmission. In order to prevent this type of attack, a strong 2027 authentication and integrity protection mechanism is needed. 2029 2. Denial of Service (DoS) - An attacker can falsely pause all 2030 source streams which MAY result in Denial of Service (DoS). An 2031 Authentication protocol may prevent this attack. 2033 3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP 2034 source is prone to a Man-in-Middle attack. Public key 2035 authentication may be used to prevent MiMT. 2037 13. Contributors 2039 Daniel Grondal contributed in the creation and writing of early 2040 versions of this specification. Christian Groves contributed 2041 significantly to the SDP config attribute and its use in Offer/ 2042 Answer. 2044 14. Acknowledgements 2046 Daniel Grondal made valuable contributions during the initial 2047 versions of this draft. Emil Ivov, Christian Groves and Bernard 2048 Aboba provided valuable review comments. 2050 15. References 2052 15.1. Normative References 2054 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2055 Requirement Levels", BCP 14, RFC 2119, March 1997. 2057 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2058 Jacobson, "RTP: A Transport Protocol for Real-Time 2059 Applications", STD 64, RFC 3550, July 2003. 2061 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2062 "Extended RTP Profile for Real-time Transport Control 2063 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2064 2006. 2066 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2067 "Codec Control Messages in the RTP Audio-Visual Profile 2068 with Feedback (AVPF)", RFC 5104, February 2008. 2070 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2071 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2073 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2074 (ICE): A Protocol for Network Address Translator (NAT) 2075 Traversal for Offer/Answer Protocols", RFC 5245, April 2076 2010. 2078 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 2079 Keeping Alive the NAT Mappings Associated with RTP / RTP 2080 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 2082 15.2. Informative References 2084 [I-D.ietf-avtcore-rtp-topologies-update] 2085 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 2086 ietf-avtcore-rtp-topologies-update-04 (work in progress), 2087 August 2014. 2089 [I-D.ietf-avtext-rtp-grouping-taxonomy] 2090 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 2091 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 2092 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 2093 rtp-grouping-taxonomy-02 (work in progress), June 2014. 2095 [I-D.ietf-rtcweb-use-cases-and-requirements] 2096 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 2097 Time Communication Use-cases and Requirements", draft- 2098 ietf-rtcweb-use-cases-and-requirements-14 (work in 2099 progress), February 2014. 2101 [I-D.westerlund-avtcore-rtp-simulcast] 2102 Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP 2103 Sessions", draft-westerlund-avtcore-rtp-simulcast-04 (work 2104 in progress), July 2014. 2106 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2107 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2109 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2110 Announcement Protocol", RFC 2974, October 2000. 2112 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2113 A., Peterson, J., Sparks, R., Handley, M., and E. 2114 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2115 June 2002. 2117 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2118 with Session Description Protocol (SDP)", RFC 3264, June 2119 2002. 2121 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2122 Description Protocol", RFC 4566, July 2006. 2124 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 2125 "RTP Payload Format for Scalable Video Coding", RFC 6190, 2126 May 2011. 2128 Appendix A. Changes From Earlier Versions 2130 NOTE TO RFC EDITOR: Please remove this section prior to publication. 2132 A.1. Modifications Between Version -04 and -05 2134 o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and 2135 timing of unsolicited PAUSED, to improve the message timeliness 2136 and probability of reception. 2138 A.2. Modifications Between Version -03 and -04 2140 o Change of Copyright boilerplate 2142 A.3. Modifications Between Version -02 and -03 2144 o Changed the section on SDP signaling to be more explicit and clear 2145 in what is supported, replacing the 'paused' parameter and the 2146 'dir' attribute with a 'config' parameter that can take a value, 2147 and an explicit listing of what each value means. 2149 o Added a sentence in section on paused state (Section 6.3) that 2150 pause must not affect RTP keepalive. 2152 o Replaced REFUSE message name with REFUSED throughout, to better 2153 indicate that it is not a command but a notification. 2155 o Added text in a few places, clarifying that PAUSED message may be 2156 used unsolicited due to RTP sender local considerations, and also 2157 clarified the interaction between this usage and an RTP stream 2158 receiver pausing the stream. Also added an example describing 2159 this case. 2161 o Clarified that when TMMBN 0 is used as PAUSED message, and when 2162 sent unsolicited due to RTP sender local considerations, the TMMBN 2163 message includes the RTP stream sender itself as part of the 2164 bounding set. 2166 o Clarified that there is no reply to a PAUSED indication. 2168 o Improved the IANA section. 2170 o Editorial improvements. 2172 A.4. Modifications Between Version -01 and -02 2174 o Replaced most text on relation with other signaling technologies 2175 in previous section 5 with a single, summarizing paragraph, as 2176 discussed at IETF 90 in Toronto, and placed it as the last sub- 2177 section of section 4 (design considerations). 2179 o Removed unused references. 2181 A.5. Modifications Between Version -00 and -01 2183 o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE 2184 signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0 2186 o Improved alignment with RTP Taxonomy draft, including the change 2187 of Packet Stream to RTP Stream 2189 o Editorial improvements 2191 Authors' Addresses 2193 Bo Burman 2194 Ericsson 2195 Kistavagen 25 2196 SE - 164 80 Kista 2197 Sweden 2199 Phone: +46107141311 2200 Email: bo.burman@ericsson.com 2201 URI: www.ericsson.com 2203 Azam Akram 2204 Ericsson 2205 Farogatan 6 2206 SE - 164 80 Kista 2207 Sweden 2209 Phone: +46107142658 2210 Email: muhammad.azam.akram@ericsson.com 2211 URI: www.ericsson.com 2213 Roni Even 2214 Huawei Technologies 2215 Tel Aviv 2216 Israel 2218 Email: roni.even@mail01.huawei.com 2220 Magnus Westerlund 2221 Ericsson 2222 Farogatan 6 2223 SE- 164 80 Kista 2224 Sweden 2226 Phone: +46107148287 2227 Email: magnus.westerlund@ericsson.com