idnits 2.17.1 draft-westerlund-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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2014) is 3722 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) == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-01 == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-00 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 == Outdated reference: A later version (-04) exists of draft-westerlund-avtcore-rtp-simulcast-03 -- 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: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Akram 3 Internet-Draft B. Burman 4 Updates: 5104 (if approved) Ericsson 5 Intended status: Standards Track R. Even 6 Expires: August 18, 2014 Huawei Technologies 7 M. Westerlund 8 Ericsson 9 February 14, 2014 11 RTP Media Stream Pause and Resume 12 draft-westerlund-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 August 18, 2014. 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 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 67 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 69 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 70 3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9 71 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9 72 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 73 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10 75 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 76 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11 77 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 11 79 4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12 80 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12 81 5. Relation to Other Solutions . . . . . . . . . . . . . . . . . 12 82 5.1. Signaling Technology Performance Comparison . . . . . . . 12 83 5.2. CCM TMMBR / TMMBN . . . . . . . . . . . . . . . . . . . . 20 84 5.3. SDP "inactive" Attribute . . . . . . . . . . . . . . . . 21 85 5.4. Media Source Selection in SDP . . . . . . . . . . . . . . 21 86 5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22 87 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 22 88 6.1. Expressing Capability . . . . . . . . . . . . . . . . . . 23 89 6.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 23 90 6.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 25 91 6.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 26 92 6.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 27 94 7. Participant States . . . . . . . . . . . . . . . . . . . . . 27 95 7.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 28 96 7.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 28 97 7.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 29 98 7.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 29 99 7.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 29 100 7.4. Local Paused State . . . . . . . . . . . . . . . . . . . 30 101 8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 30 102 9. Message Details . . . . . . . . . . . . . . . . . . . . . . . 32 103 9.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 9.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 9.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 34 106 9.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 9.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 36 108 10. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 10.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 39 110 10.2. Declarative Use . . . . . . . . . . . . . . . . . . . . 40 111 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 112 11.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 41 113 11.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 42 114 11.3. Point-to-multipoint using Mixer . . . . . . . . . . . . 45 115 11.4. Point-to-multipoint using Translator . . . . . . . . . . 47 116 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 117 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 118 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 119 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 120 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 121 16.1. Normative References . . . . . . . . . . . . . . . . . . 51 122 16.2. Informative References . . . . . . . . . . . . . . . . . 52 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 125 1. Introduction 127 As real-time communication attracts more people, more applications 128 are created; multimedia conversation applications being one example. 129 Multimedia conversation further exists in many forms, for example, 130 peer-to-peer chat application and multiparty video conferencing 131 controlled by central media nodes, such as RTP Mixers. 133 Multimedia conferencing may involve many participants; each has its 134 own preferences for the communication session, not only at the start 135 but also during the session. This document describes several 136 scenarios in multimedia communication where a conferencing node or 137 participant chooses to temporarily pause an incoming RTP [RFC3550] 138 media stream from a specific source and later resume it when needed. 139 The receiver does not need to terminate or inactivate the RTP session 140 and start all over again by negotiating the session parameters, for 141 example using SIP [RFC3261] with SDP Offer/Answer [RFC3264]. 143 Centralized nodes, like RTP Mixers or MCUs, which either uses logic 144 based on voice activity, other measurements, or user input could 145 reduce the resources consumed in both the media sender and the 146 network by temporarily pausing the media streams that aren't required 147 by the RTP Mixer. If the number of conference participants are 148 greater than what the conference logic has chosen to present 149 simultaneously to receiving participants, some participant media 150 streams sent to the RTP Mixer may not need to be forwarded to any 151 other participant. Those media streams could then be temporarily 152 paused. This becomes especially useful when the media sources are 153 provided in multiple encoding versions (Simulcast) 154 [I-D.westerlund-avtcore-rtp-simulcast] or with Multi-Session 155 Transmission (MST) of scalable encoding such as SVC [RFC6190]. There 156 may be some of the defined encodings or combination of scalable 157 layers that are not used all of the time. 159 As the media streams required at any given point in time is highly 160 dynamic in such scenarios, using the out-of-band signalling channel 161 for pausing, and even more importantly resuming, a media stream is 162 difficult due to the performance requirements. Instead, the pause 163 and resume signalling should be in the media plane and go directly 164 between the affected nodes. When using RTP [RFC3550] for media 165 transport, using Extended RTP Profile for Real-time Transport Control 166 Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears 167 appropriate. No currently existing RTCP feedback message explicitly 168 supports pausing and resuming an incoming media stream. As this 169 affects the generation of packets and may even allow the encoding 170 process to be paused, the functionality appears to match Codec 171 Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) 172 [RFC5104] and it is proposed to define the solution as a Codec 173 Control Message (CCM) extension. 175 The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is 176 used by video conferencing systems for flow control. It is desirable 177 to be able to use that method with a bitrate value of zero for pause 178 and resume, whenever possible. 180 2. Definitions 182 2.1. Abbreviations 184 3GPP: 3rd Generation Partnership Project 186 AVPF: Audio-Visual Profile with Feedback (RFC 4585) 188 BGW: Border Gateway 190 CCM: Codec Control Messages (RFC 5104) 191 CNAME: Canonical Name (RTCP SDES) 193 CSRC: Contributing Source (RTP) 195 FB: Feedback (AVPF) 197 FCI: Feedback Control Information (AVPF) 199 FIR: Full Intra Refresh (CCM) 201 FMT: Feedback Message Type (AVPF) 203 LTE: Long-Term Evolution (3GPP) 205 MCU: Multipoint Control Unit 207 MTU: Maximum Transfer Unit 209 PT: Payload Type (RTP) 211 RTP: Real-time Transport Protocol (RFC 3550) 213 RTCP: Real-time Transport Control Protocol (RFC 3550) 215 RTCP RR: RTCP Receiver Report 217 SDP: Session Description Protocol (RFC 4566) 219 SGW: Signaling Gateway 221 SIP: Session Initiation Protocol (RFC 3261) 223 SSRC: Synchronization Source (RTP) 225 SVC: Scalable Video Coding 227 TCP: Transmission Control Protocol (RFC 793) 229 TMMBR: Temporary Maximum Media Bitrate Request (CCM) 231 TMMBN: Temporary Maximum Media Bitrate Notification (CCM) 233 UA: User Agent (SIP) 235 UDP: User Datagram Protocol (RFC 768) 237 2.2. Terminology 239 In addition to following, the definitions from RTP [RFC3550], AVPF 240 [RFC4585], CCM [RFC5104], and RTP Taxonomy 241 [I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document. 243 Feedback Messages: CCM [RFC5104] categorized different RTCP feedback 244 messages into four types, Request, Command, Indication and 245 Notification. This document places the PAUSE and RESUME messages 246 into Request category, PAUSED as Indication and REFUSE as 247 Notification. 249 PAUSE Request from a media receiver to pause a stream 251 RESUME Request from a media receiver to resume a paused stream 253 PAUSED Indication from a media sender that a stream is paused 255 REFUSE Notification from a media sender that a PAUSE or RESUME 256 request will not be honored 258 Acknowledgement: The confirmation from receiver to sender that the 259 message has been received. 261 Sender: The RTP entity that sends an RTP Packet Stream. 263 Receiver: The RTP entity that receives an RTP Packet Stream. 265 Mixer: The intermediate RTP node which receives a Packet Stream from 266 different nodes, combines them to make one stream and forwards to 267 destinations, in the sense described in Topo-Mixer of RTP 268 Topologies [I-D.ietf-avtcore-rtp-topologies-update]. 270 Participant: A member which is part of an RTP session, acting as 271 receiver, sender or both. 273 Paused Sender: An RTP sender that has stopped its transmission, i.e. 274 no other participant receives its RTP transmission, either based 275 on having received a PAUSE request, defined in this specification, 276 or based on a local decision. 278 Pausing Receiver: An RTP receiver which sends a PAUSE request, 279 defined in this specification, to other participant(s). 281 Stream: Used as a short term for Source Packet Stream, unless 282 otherwise noted. 284 2.3. Requirements Language 286 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 287 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 288 document are to be interpreted as described in RFC 2119 [RFC2119]. 290 3. Use Cases 292 This section discusses the main use cases for media stream pause and 293 resume. 295 3.1. Point to Point 297 This is the most basic use case with an RTP session containing two 298 end-points. Each end-point sends one or more streams. 300 +---+ +---+ 301 | A |<------->| B | 302 +---+ +---+ 304 Figure 1: Point to Point 306 The usage of media stream pause in this use case is to temporarily 307 halt media delivery of streams that the sender provides but the 308 receiver does not currently use. This can for example be due to 309 minimized applications where the video stream is not actually shown 310 on any display, and neither is it used in any other way, such as 311 being recorded. 313 In this case, since there is only a single receiver of the stream, 314 pausing or resuming a stream does not impact anyone else than the 315 sender and the single receiver of that stream. 317 RTCWEB WG's use case and requirements document 318 [I-D.ietf-rtcweb-use-cases-and-requirements] defines the following 319 API requirements in Appendix A, used also by W3C WebRTC WG: 321 A8 The Web API must provide means for the web application to mute/ 322 unmute a stream or stream component(s). When a stream is sent to 323 a peer mute status must be preserved in the stream received by the 324 peer. 326 A9 The Web API must provide means for the web application to cease 327 the sending of a stream to a peer. 329 This memo provides means to optimize transport usage by stop sending 330 muted streams and start sending again when unmuting. 332 3.2. RTP Mixer to Media Sender 334 One of the most commonly used topologies in centralized conferencing 335 is based on the RTP Mixer [I-D.ietf-avtcore-rtp-topologies-update]. 336 The main reason for this is that it provides a very consistent view 337 of the RTP session towards each participant. That is accomplished 338 through the Mixer originating its' own streams, identified by SSRC, 339 and any media sent to the participants will be sent using those 340 SSRCs. If the Mixer wants to identify the underlying Media Sources 341 for its' conceptual streams, it can identify them using CSRC. The 342 stream the Mixer provides can be an actual media mix of multiple 343 Media Sources, but it might also be switching received streams as 344 described in Sections 3.6-3.8 of 345 [I-D.ietf-avtcore-rtp-topologies-update]. 347 +---+ +-----------+ +---+ 348 | A |<---->| |<---->| B | 349 +---+ | | +---+ 350 | Mixer | 351 +---+ | | +---+ 352 | C |<---->| |<---->| D | 353 +---+ +-----------+ +---+ 355 Figure 2: RTP Mixer in Unicast-only 357 Which streams that are delivered to a given receiver, A, can depend 358 on several things. It can either be the RTP Mixer's own logic and 359 measurements such as voice activity on the incoming audio streams. 360 It can be that the number of sent Media Sources exceed what is 361 reasonable to present simultaneously at any given receiver. It can 362 also be a human controlling the conference that determines how the 363 media should be mixed; this would be more common in lecture or 364 similar applications where regular listeners may be prevented from 365 breaking into the session unless approved by the moderator. The 366 streams may also be part of a Simulcast 367 [I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for 368 Multi-Stream Transmission) [RFC6190], thus providing multiple 369 versions that can be delivered by the media sender. These examples 370 indicate that there are numerous reasons why a particular stream 371 would not currently be in use, but must be available for use at very 372 short notice if any dynamic event occurs that causes a different 373 stream selection to be done in the Mixer. 375 Because of this, it would be highly beneficial if the Mixer could 376 request to pause a particular stream from being delivered to it. It 377 also needs to be able to resume delivery with minimal delay. 379 Just as for point-to-point (Section 3.1), there is only a single 380 receiver of the stream, the RTP Mixer, and pausing or resuming a 381 stream does not affect anyone else than the sender and single 382 receiver of that stream. 384 3.3. RTP Mixer to Media Sender in Point-to-Multipoint 386 This use case is similar to the previous section, however the RTP 387 Mixer is involved in three domains that need to be separated; the 388 Multicast Network (including participants A and C), participant B, 389 and participant D. The difference from above is that A and C share a 390 multicast domain, which is depicted below. 392 +-----+ 393 +---+ / \ +-----------+ +---+ 394 | A |<---/ \ | |<---->| B | 395 +---+ / Multi- \ | | +---+ 396 + Cast +->| Mixer | 397 +---+ \ Network / | | +---+ 398 | C |<---\ / | |<---->| D | 399 +---+ \ / +-----------+ +---+ 400 +-----+ 402 Figure 3: RTP Mixer in Point-to-Multipoint 404 If the RTP Mixer pauses a stream from A, it will not only pause the 405 stream towards itself, but will also stop the stream from arriving to 406 C, which C is heavily impacted by, might not approve of, and should 407 thus have a say on. 409 If the Mixer resumes a paused stream from A, it will be resumed also 410 towards C. In this case, if C is not interested it can simply ignore 411 the stream and is not impacted as much as above. 413 In this use case there are several receivers of a stream and special 414 care must be taken as not to pause a stream that is still wanted by 415 some receivers. 417 3.4. Media Receiver to RTP Mixer 419 An end-point in Figure 2 could potentially request to pause the 420 delivery of a given media stream. Possible reasons include the ones 421 in the point to point case (Section 3.1) above. 423 When the RTP Mixer is only connected to individual unicast paths, the 424 use case and any considerations are identical to the point to point 425 use case. 427 However, when the end-point requesting media stream pause is 428 connected to the RTP Mixer through a multicast network, such as A or 429 C in Figure 3, the use case instead becomes identical to the one in 430 Section 3.3, only with reverse direction of the streams and pause/ 431 resume requests. 433 3.5. Media Receiver to Media Sender Across RTP Mixer 435 An end-point, like A in Figure 2, could potentially request to pause 436 the delivery of a given media stream, like one of B's, over any of 437 the SSRCs used by the Mixer by sending a pause request for the CSRC 438 identifying the media stream. However, the authors are of the 439 opinion that this is not a suitable solution, for several reasons: 441 1. The Mixer might not include CSRC in it's stream indications. 443 2. An end-point cannot rely on the CSRC to correctly identify the 444 media stream to be paused when the delivered media is some type 445 of mix. A more elaborate media stream identification solution is 446 needed to support this in the general case. 448 3. The end-point cannot determine if a given media stream is still 449 needed by the RTP Mixer to deliver to another session 450 participant. 452 Due to the above reasons, we exclude this use case from further 453 consideration. 455 4. Design Considerations 457 This section describes the requirements that this specification needs 458 to meet. 460 4.1. Real-time Nature 462 The first section (Section 1) of this specification describes some 463 possible reasons why a receiver may pause an RTP sender. Pausing and 464 resuming is time-dependent, i.e. a receiver may choose to pause an 465 RTP stream for a certain duration, after which the receiver may want 466 the sender to resume. This time dependency means that the messages 467 related to pause and resume must be transmitted to the sender in 468 real-time in order for them to be purposeful. The pause operation is 469 arguably not very time critical since it mainly provides a reduction 470 of resource usage. Timely handling of the resume operation is 471 however likely to directly impact the end-user's perceived quality 472 experience, since it affects the availability of media that the user 473 expects to receive more or less instantly. 475 4.2. Message Direction 477 It is the responsibility of a media receiver, who wants to pause or 478 resume a media stream from the sender(s), to transmit PAUSE and 479 RESUME messages. A media sender who likes to pause itself, can 480 simply do it. Any indication that an RTP media stream is paused is 481 the responsibility of the RTP media stream sender and may in some 482 cases not even be needed by the media stream receiver. 484 4.3. Apply to Individual Sources 486 The PAUSE and RESUME messages apply to single RTP media streams 487 identified by their SSRC, which means the receiver targets the 488 sender's SSRC in the PAUSE and RESUME requests. If a paused sender 489 starts sending with a new SSRC, the receivers will need to send a new 490 PAUSE request in order to pause it. PAUSED indications refer to a 491 single one of the sender's own, paused SSRC. 493 4.4. Consensus 495 An RTP media stream sender should not pause an SSRC that some 496 receiver still wishes to receive. The reason is that in RTP 497 topologies where the media stream is shared between multiple 498 receivers, a single receiver on that shared network, independent of 499 it being multicast, a mesh with joint RTP session or a transport 500 Translator based, must not single-handedly cause the media stream to 501 be paused without letting all other receivers to voice their opinions 502 on whether or not the stream should be paused. A consequence of this 503 is that a newly joining receiver, for example indicated by an RTCP 504 Receiver Report containing both a new SSRC and a CNAME that does not 505 already occur in the session, firstly needs to learn the existence of 506 paused streams, and secondly should be able to resume any paused 507 stream. Any single receiver wanting to resume a stream should also 508 cause it to be resumed. 510 4.5. Acknowledgements 512 RTP and RTCP does not guarantee reliable data transmission. It uses 513 whatever assurance the lower layer transport protocol can provide. 514 However, this is commonly UDP that provides no reliability 515 guarantees. Thus it is possible that a PAUSE and/or RESUME message 516 transmitted from an RTP end-point does not reach its destination, 517 i.e. the targeted RTP media stream sender. When PAUSE or RESUME 518 reaches the RTP media stream sender and are effective, i.e., an 519 active media sender pauses, or a resuming have media data to 520 transmit, it is immediately seen from the arrival or non-arrival of 521 RTP packets for that RTP media stream. Thus, no explicit 522 acknowledgements are required in this case. 524 In some cases when a PAUSE or RESUME message reaches the media 525 sender, it will not be able to pause or resume the stream due to some 526 local consideration, for example lack of data to transmit. This 527 error condition, a negative acknowledgement, may be needed to avoid 528 unnecessary retransmission of requests (Section 4.6). 530 4.6. Retransmitting Requests 532 When the media stream is not affected as expected by a PAUSE or 533 RESUME request, the request may have been lost and the sender of the 534 request will need to retransmit it. The retransmission should take 535 the round trip time into account, and will also need to take the 536 normal RTCP bandwidth and timing rules applicable to the RTP session 537 into account, when scheduling retransmission of feedback. 539 When it comes to resume requests that are more time critical, the 540 best resume performance may be achieved by repeating the request as 541 often as possible until a sufficient number have been sent to reach a 542 high probability of request delivery, or the media stream gets 543 delivered. 545 4.7. Sequence Numbering 547 A PAUSE request message will need to have a sequence number to 548 separate retransmissions from new requests. A retransmission keeps 549 the sequence number unchanged, while it is incremented every time a 550 new PAUSE request is transmitted that is not a retransmission of a 551 previous request. 553 Since RESUME always takes precedence over PAUSE and are even allowed 554 to avoid pausing a stream, there is a need to keep strict ordering of 555 PAUSE and RESUME. Thus, RESUME needs to share sequence number space 556 with PAUSE and implicitly references which PAUSE it refers to. For 557 the same reasons, the explicit PAUSED indication also needs to share 558 sequence number space with PAUSE and RESUME. 560 5. Relation to Other Solutions 562 This section compares other possible solutions to achieve a similar 563 functionality, along with motivations why the current solution is 564 chosen. 566 5.1. Signaling Technology Performance Comparison 568 Editor's note: This section is related to the motivation for 569 selecting RTCP as signaling technology rather than SIP/SDP and 570 should be considered to be removed or at least significantly 571 reduced if and when this draft is adopted as a working group 572 draft, since there now seems to be consensus that RTCP is the 573 preferred technology. 575 This section contains what is thought to be a realistic estimate of 576 one-way data transmission times for signaling implementing 577 functionalities of this specification. 579 Two signaling protocols are compared. SIP is chosen to represent 580 signaling in the control plane and RTCP is chosen to represent 581 signaling in the media plane. For the sake of the comparison, each 582 of these two protocols are listed with one favorable and one 583 unfavorable condition to give the reader a hint of what range of 584 delays that can be expected. The favorable condition is chosen as 585 good as possible, while still realistic. The unfavorable condition 586 is also chosen to be realistically occurring, and is not the worst 587 possible or imaginable. Actual delays can in most cases be expected 588 to lie somewhere between those two values. 590 It would also be possible to include a signaling protocol using a 591 some dedicated signaling channel, separate from SIP and RTCP, into 592 the comparison. Such signaling protocol can be expected to show 593 performance somewhere in the range covered by the SIP and RTCP 594 comparison below. The protocol can either use UDP as transport, like 595 RTCP, or it can use TCP, like SIP, when the messages becomes too 596 large for the MTU. The data sent on such channel can either be text 597 based, in which case the amount of data can be similar to SIP, or it 598 can be binary, in which case the amount of data can be similar to 599 RTCP. Therefore, the dedicated signaling channel case is not 600 described further in this specification. 602 Two different access technologies are compared: 604 o Wired, fixed access is chosen as a representative low-delay 605 alternative. 607 o Mobile wireless access according to 3GPP LTE [TS36.201], also 608 known as "4G", is chosen as a representative high-delay 609 alternative. 611 NOTE: LTE is at the time of writing the most recent and best 612 performing mobile wireless access. If an earlier mobile wireless 613 access was to be used instead, the estimated transmission times would 614 be considerably increased. For example, it is estimated that using 615 3GPP HSPA [TS25.308] (evolved 3G, just previous to LTE) would 616 increase RTCP signaling times somewhat and significantly increase 617 signaling times for SIP, although those estimates are too preliminary 618 to provide any values here. 620 The target scenario includes two UA, residing in two different 621 provider's (operator's) network. Those networks are assumed to be 622 geographically close, that is no inter-continental transmission 623 delays are included in the estimates. 625 Three signaling alternatives are compared: 627 o Wireless UA to wireless UA, including two wireless links, uplink 628 and downlink. 630 o Wireless UA to media server (MCU), including a single wireless 631 uplink. 633 o Media server (MCU) to wireless UA, including a single wireless 634 downlink. 636 The reason to include separate results for wireless uplink and 637 downlink is that delay times can differ significantly. 639 The targeted topology is outlined in the following figure. 641 Provider A's network . Provider B's network 642 . 643 +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+ 644 |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy| 645 +-----+ +------+ +-------+ . +-------+ +-----+ 646 ^ ^ . ^ 647 | | SIP/H.248 . | 648 | v . | 649 SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP | 650 | | MCU |<---->| BGW A |<--.-->| BGW B | | 651 | +-----+ +-------+ . +-------+ | 652 v ^ . ^ v 653 +------+ / RTCP . \ RTCP +------+ 654 | UA A |<---+ . +------>| UA B | 655 +------+ . +------+ 657 Figure 4: Comparison Signaling Topology 659 In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS 660 is an Application Server, MCU is a Multipoint Conference Unit, SGW a 661 Signaling GateWay, and BGW a media Border GateWay. 663 It can be noted that when either one or both UAs use call forwarding 664 or have roamed into yet another provider's network, several more 665 signaling path nodes and a few more media path nodes could be 666 included in the end-to-end signaling path. 668 The MCU is assumed to be located in one of the provider's network. 669 Signaling delays between the MCU and a UA are presented as the 670 average of MCU and UA being located in the same and different 671 provider's networks. 673 These assumptions are used for SIP signaling: 675 o A SIP UPDATE is used within an established session to dynamically 676 impact individual streams to achieve the pause and resume 677 functionality. The offer and answer SDP contains one audio and 678 one video media, compliant with what is suggested in 3GPP MTSI 679 [TS26.114], with the addition of SDP feedback message indication 680 outlined in this specification (Section 10). A more complex media 681 session with more streams would significantly add to the SDP size. 683 o UDP is used as transport, except when risking to exceed MTU, in 684 which case TCP is used instead. This is evaluated on a per- 685 message basis. 687 o Only SIP forward direction is included in the delay estimate, that 688 is, delays needed to receive a response such as 200 OK are not 689 included. 691 o Favorable case: 693 * SIP SigComp [RFC5049] in dynamic mode is used for SIP and SDP 694 signaling on the mobile link, reducing the SIP message size to 695 approximately 1/3 of the original size. 697 o Unfavorable case: 699 * SIP message is not compressed on the mobile link. 701 * SIP signaling on the mobile link uses a dedicated mobile 702 wireless access radio channel that was idle for some time, has 703 entered low power state and thus has to be re-established by 704 radio layer signaling before any data can be sent. 706 These assumptions are used for RTCP signaling: 708 o A minimal compound RTCP feedback packet is used, including one SR 709 and one SDES with only the CNAME item present, with the addition 710 of the feedback message outlined in Section 8. 712 o RTCP bandwidth is chosen based on a 200 kbit/s session, which is 713 considered to be a low bandwidth for media that would be worth 714 pausing, and using the default 5% of this for RTCP traffic results 715 in 10 kbit/s. This low bandwidth makes RTCP scheduling delays be a 716 significant factor in the unfavorable case. 718 o Since there are random delay factors in RTCP transmission, the 719 expected, most probable value is used in the estimates. 721 o The mobile wireless access channel used for RTCP will always be 722 active, that is there will be sufficient data to send at any time 723 such that the radio channel will never have to be re-established. 724 This is considered reasonable since it is assumed that the same 725 channel is not only used for the messages defined in this 726 specification, but also for other RTP and RTCP data. 728 o Favorable case: 730 * It is assumed that AVPF Early or Immediate mode can always be 731 used for the signaling described in this specification, since 732 such signaling will be small in size and only occur 733 occasionally in RTCP time scale. 735 * Early mode does not use dithering of send times (T_dither_max 736 is set to 0), that is, sender and receiver of the message are 737 connected point-to-point. It can be noted that in case of a 738 multiparty session where multiple end-points can see each 739 others' messages, and unless the number of end-points is very 740 large, it is very unlikely that more than a single end-point 741 has the desire to send the same message (defined in this 742 specification) as another end-point, and at almost exactly the 743 same time. It is therefore arguably not very meaningful for 744 messages in this specification to try to do feedback 745 suppression by using a non-zero T_dither_max, even in 746 multiparty sessions, but AVPF does not allow for any exemption 747 from that rule. 749 * Reduced-size RTCP is used, which is considered appropriate for 750 the type of messages defined in this specification. 752 * RTP/RTCP header compression [RFC5225] is not used, not even on 753 the mobile link. 755 o Unfavorable case: 757 * The expected, regular AVPF RTCP interval is used, including an 758 expected value for timer re-consideration. 760 * A full, not reduced-size, minimal compound RTCP feedback packet 761 without header compression is always used. No reduction of 762 scheduling delays from the use of reduced-size RTCP is included 763 in the evaluation, since that would also require a reasonable 764 estimate of the mix of compound and non-compound RTCP, which 765 was considered too difficult for this study. The given 766 unfavorable delays are thus an over-estimate compared to a more 767 realistic case. 769 Common to both SIP and RTCP signaling estimates is that no UA 770 processing delays are included. The reason for that decision is that 771 processing delays are highly implementation and UA dependent. It is 772 expected that wireless UA will be more limited than fixed UA by 773 processing, but they are also constantly and quickly improving so any 774 estimate will very quickly be outdated. More realistic estimates 775 will however have to add such delays, which can be expected to be in 776 the order of a few to a few tens of milliseconds. It is expected 777 that SIP will be more penalized than RTCP by including processing 778 delays, since it has larger and more complex messages. The 779 processing may also include SigComp [RFC5049] compression and 780 decompression in the favorable cases. 782 As a partial result, the message sizes can be compared, based on the 783 messages defined in this specification (Section 8) and a SIP UPDATE 784 with contents (Section 10) as discussed above. Favorable and 785 unfavorable message sizes are presented as stacked bars in the figure 786 below. Message sizes include IPv4 headers but no lower layer data, 787 are rounded to the nearest 25 bytes, and the bars are to scale. 789 250 500 750 1000 1250 1500 [byte] 790 +---------+---------+---------+---------+---------+---------+--> Size 791 | 792 +-+--+ 793 | |50| 125 RTCP 794 +-+--+---------------+--------------------------------------------+ 795 | SIP | 525 1650 | 796 +--------------------+--------------------------------------------+ 797 | 799 Figure 5: Message Size Comparison 801 The signaling delay results of the study are summarized in the 802 following two figures. Favorable and unfavorable values are 803 presented as stacked bars. Since there are many factors that impact 804 the calculations, including some random processes, there are 805 uncertainty in the calculations and delay values are thus rounded to 806 nearest 5 ms. The bars are to scale. 808 50 100 150 200 250 300 [ms] 809 +---------+---------+---------+---------+---------+---------+---> t 810 | 811 | Wireless UA to Wireless UA 812 +---------------------+--------------------------------------+ 813 | SIP | 110 | 305 814 +-----+---------------+-----------------------------+--------+ 815 |RTCP | 30 | 260 816 +-----+---------------------------------------------+ 817 | 818 | Wireless UA to MCU 819 +-------------+--+ 820 | SIP |70| 85 821 +----+--------+--+--------------------------+ 822 |RTCP| 25 | 225 823 +----+--------------------------------------+ 824 | 825 | MCU to Wireless UA 826 +--------------+-----------------------------------+ 827 | SIP | 75 | 255 828 +---+----------+------------------------------+----+ 829 | | 20 RTCP | 230 830 +---+-----------------------------------------+ 831 | 833 Figure 6: Mobile Access Transmission Delay Comparison 835 As can be seen, RTCP has a smaller signaling delay than SIP in a 836 majority of cases for this mobile access. Non-favorable RTCP is 837 however always worse than favorable SIP. 839 The UA to MCU signaling corresponds to the use case in Section 3.4. 840 The reason that unfavorable SIP is more beneficial than unfavorable 841 RTCP in this case comes from the fact that latency is fairly short to 842 re-establish an uplink radio channel (as was assumed needed for 843 unfavorable SIP), while unfavorable RTCP does not benefit from this 844 since the delay is mainly due to RTCP Scheduling. 846 The MCU to UA signaling corresponds to the use case in Section 3.2. 847 It has an unfavorable SIP signaling case with much longer delay than 848 UA to MCU above, because the mixer cannot re-establish a downlink 849 radio channel as quickly as the UA can establish an uplink. This 850 case is applicable when an MCU wants to resume a paused stream, which 851 is likely the most delay sensitive functionality, as discussed in 852 Section 4.1. 854 Below are the same cases for fixed access depicted. Although delays 855 are generally shorter, scales are kept the same for easy comparison 856 with the previous figure. 858 50 100 150 200 250 300 [ms] 859 +---------+---------+---------+---------+---------+---------+---> t 860 | 861 | Fixed UA to Fixed UA 862 +------------+ 863 | SIP | 65 864 +----+-------+---------------------------+ 865 |RTCP| 25 | 205 866 +----+-----------------------------------+ 867 | 868 | Fixed UA to MCU 869 +---------+ 870 | SIP | 50 871 +---+-----+-----------------------+ 872 | | 15 RTCP | 200 873 +---+-----------------------------+ 874 | 875 | MCU to Fixed UA 876 +---------+ 877 | SIP | 50 878 +---+-----+-----------------------+ 879 | | 15 RTCP | 200 880 +---+-----------------------------+ 881 | 883 Figure 7: Fixed Access Transmission Delay Comparison 885 For fixed access, favorable RTCP is still significantly better than 886 SIP, but unfavorable RTCP is significantly worse than SIP. There is 887 no difference between favorable and unfavorable SIP, since in fixed 888 access there is no channel that needs to be re-established. 890 Regarding the unfavorable values above, it should be possible with 891 reasonable effort to design UA and network nodes that show favorable 892 delays in a majority of cases. 894 For SIP, the major delays in the unfavorable cases above comes from 895 re-establishing a radio bearer that has entered low power state due 896 to inactivity, and large size SIP messages. The inactivity problem 897 can be removed by using for example SIP keep-alive [RFC5626], at the 898 cost of reduced battery life to keep the signaling radio bearer 899 active, and some very minimal amount of extra data transmission. The 900 large SIP messages can to some extent be reduced by SIP SigComp 902 [RFC5049]. It may however prove harder to reduce delays that comes 903 from forwarding the SDP many times between different signaling nodes. 905 For RTCP, the major delays comes from low RTCP bandwidth and not 906 being able to use Immediate or Early mode, including use of timer re- 907 consideration. UAs and network nodes can explicitly allocate an 908 appropriate amount of RTCP bandwidth through use of the b=RS and b=RR 909 RTCP bandwidth SDP attributes [RFC3556]. For RTP media streams of 910 higher bandwidth than the 200 kbit/s used in this comparison, which 911 will be even more interesting to pause, RTCP bandwidth will per 912 default also be higher, significantly reducing the signaling delays. 913 For example, using a 1000 kbit/s media stream instead of a 200 kbit/s 914 stream will reduce the unfavorable RTCP delays from 260 ms to 115 ms 915 for Wireless-Wireless, from 225 ms to 80 ms for Wireless-MCU, and 916 from 230 ms to 80 ms for MCU-Wireless. 918 5.2. CCM TMMBR / TMMBN 920 The Codec Control Messages specification [RFC5104] contains two 921 messages, Temporary Maximum Media Bitrate Request (TMMBR) and 922 Temporary Maximum Media Bitrate Notification (TMMBN), which could 923 provide some of the necessary functionality. TMMBR with a bitrate 924 value of 0 could effectively constitute a PAUSE request and TMMBN 0 925 could effectively be a PAUSED indication, and there are already 926 implementations making use of TMMBR 0 in this way. It is possible to 927 signal per SSRC (Section 4.3) and using the media path for signaling 928 (AVPF) [RFC4585] will in most cases provide the shortest achievable 929 signaling delay (Section 4.1). However, in some cases the defined 930 semantics for TMMBR differ from what is required for PAUSE. 932 When there is only a single receiver of a media stream, TMMBR 0 and 933 PAUSE are effectively identical. 935 When there are several receivers of the same media stream, the stream 936 must not be paused until there are no receiver that desires to 937 receive it (Section 4.4), for example there is no disapproving RESUME 938 for a PAUSE. In the presence of several simultaneous receivers, the 939 TMMBR semantics is the opposite; the first media receiver that sends 940 TMMBR 0 will pause the stream for all receivers. 942 When there is only a single receiver of a media stream that is 943 paused, TMMBR with a bitrate greater than 0 can effectively function 944 as a RESUME, resuming the media stream immediately as needed 945 (Section 4.4). 947 For the case of multiple simultaneous receivers, TMMBR specifies to 948 use a guard period when increasing the bandwidth. In this case, 949 TMMBR/TMMBN semantics (Section 4.2.1.2 of [RFC5104]) requires a media 950 sender to wait 2*RTT+T_dither_max after having sent a TMMBN, 951 indicating the intention to increase the bandwidth, before it 952 actually increases its bandwidth usage. The RTT is specified to be 953 the longest the media sender knows in the RTP session. So, there is 954 both the delay between the media sender receiving the TMMBR until it 955 can send a TMMBN, and the above delay for the guard period before the 956 media sender are allowed to resume transmission. This delay before 957 resuming transmission is the most time critical operation in this 958 solution, making use of TMMBR as RESUME according to the defined 959 semantics infeasible in practice when there are multiple simultaneous 960 media stream receivers. 962 5.3. SDP "inactive" Attribute 964 In SDP [RFC4566], an "inactive" attribute is defined on media level 965 and session level. The attribute is intended to be used to put media 966 "on hold", either at the beginning of a session or as a result of 967 session re-negotiation [RFC3264], for example using SIP re-INVITE 968 [RFC3261], possibly in combination with ITU-T H.248 media gateway 969 control. 971 This attribute is only possible to specify with media level 972 resolution, is not possible to signal per individual media stream 973 (SSRC) (Section 4.3), and is thus not usable for RTP sessions 974 containing more than a single SSRC. 976 There is a per-ssrc attribute defined in [RFC5576], but that does 977 currently not allow to set an individual stream (SSRC) inactive. 979 Using "inactive" does thus not provide sufficient functionality for 980 the purpose of this specification. 982 5.4. Media Source Selection in SDP 984 There is a draft that selects sources based on SDP 985 [I-D.lennox-mmusic-sdp-source-selection] information. It builds on 986 the per-ssrc attribute [RFC5576] discussed above (Section 5.3). 988 The semantics differ between selecting a Media Source and pause / 989 resume for a stream in topologies other than point-to-point. For 990 example, in RTP Receiver to Mixer (Section 3.4), pausing a stream 991 (SSRC) from the mixer should stop it being received altogether, while 992 excluding a stream (CSRC) from the mix would just avoid that specific 993 Media Source being included in the stream from the mixer. There is a 994 similar difference between resuming a stream (SSRC) from the mixer 995 and allowing a Media Source (CSRC) to be included in the mix again. 996 This suffers from a lack of functionality for consensus (Section 4.4) 997 and would likely also suffer from lower real-time performance 998 (Section 4.1). 1000 5.5. Conclusion 1002 As can be seen from Section 5.1, using SIP and SDP to carry pause and 1003 resume information means that it will need to traverse the entire 1004 signaling path to reach the signaling destination (either the remote 1005 end-point or the entity controlling the RTP Mixer), across any 1006 signaling proxies that potentially also has to process the SDP 1007 content to determine if they are expected to act on it. The amount 1008 of bandwidth required for a SIP/SDP-based signaling solution is in 1009 the order of at least 10 times more than an RTCP-based solution. 1011 Especially for UA sitting on mobile wireless access, this will risk 1012 introducing delays that are too long (Section 4.1) to provide a good 1013 user experience, and the bandwidth cost may also be considered 1014 infeasible compared to an RTCP-based solution. 1016 As seen in the same section, the RTCP data is sent through the media 1017 path, which is likely shorter (contains fewer intermediate nodes) 1018 than the signaling path but may anyway have to traverse a few 1019 intermediate nodes. The amount of processing and buffering required 1020 in intermediate nodes to forward those RTCP messages is however 1021 believed to be significantly less than for intermediate nodes in the 1022 signaling path. 1024 Based on those reasons, RTCP is proposed as signaling protocol for 1025 the pause and resume functionality. Much of the wanted functionality 1026 can in a point-to-point case be achieved with the existing TMMBR/ 1027 TMMBN CCM messages [RFC5104], but they cannot be used when the media 1028 stream is sent to multiple simultaneous receivers. 1030 6. Solution Overview 1032 The proposed solution implements PAUSE and RESUME functionality based 1033 on sending AVPF RTCP feedback messages from any RTP session 1034 participant that wants to pause or resume a media stream targeted at 1035 the media stream sender, as identified by the sender SSRC. 1037 It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent 1038 possible, and to define a small set of new RTCP feedback messages 1039 where new semantics is needed. Considerations that that apply when 1040 using TMMBR/TMMBN for pause and resume purposes are also described. 1042 A single Feedback message specification is used to implement the new 1043 messages. The message consists of a number of Feedback Control 1044 Information (FCI) blocks, where each block can be a PAUSE request, a 1045 RESUME request, PAUSED indication, a REFUSE response, or an extension 1046 to this specification. This structure allows a single feedback 1047 message to handle pause functionality on a number of media streams. 1049 The PAUSED functionality is also defined in such a way that it can be 1050 used standalone by the media sender to indicate a local decision to 1051 pause, and inform any receiver of the fact that halting media 1052 delivery is deliberate and which RTP packet was the last transmitted. 1054 This section is intended to be explanatory and therefore 1055 intentionally contains no mandatory statements. Such statements can 1056 instead be found in other parts of this specification. 1058 6.1. Expressing Capability 1060 An end-point can use an extension to CCM SDP signaling to declare 1061 capability to understand the messages defined in this specification. 1062 Capability to understand PAUSED indication is defined separately from 1063 the others to support partial implementation, which is specifically 1064 believed to be feasible for the RTP Mixer to Media Sender use case 1065 (Section 3.2). 1067 For the case when TMMBR/TMMBN are used for pause and resume purposes, 1068 it is possible to explicitly express joint support for TMMBR and 1069 TMMBN, but not for TMMBN only. 1071 6.2. Requesting to Pause 1073 An RTP media stream receiver can choose to request PAUSE at any time, 1074 subject to AVPF timing rules. This also applies when using TMMBR 0 1075 in the point-to-point case. 1077 The PAUSE request contains a PauseID, which is incremented by one (in 1078 modulo arithmetic) with each PAUSE request that is not a re- 1079 transmission. The PauseID is scoped by and thus a property of the 1080 targeted RTP media stream (SSRC). 1082 When a non-paused RTP media stream sender receives the PAUSE request, 1083 it continues to send media while waiting for some time to allow other 1084 RTP media stream receivers in the same RTP session that saw this 1085 PAUSE request to disapprove by sending a RESUME (Section 6.4) for the 1086 same stream and with the same PauseID as in the disapproved PAUSE. 1087 If such disapproving RESUME arrives at the RTP media stream sender 1088 during the wait period before the stream is paused, the pause is not 1089 performed. In point-to-point configurations, the wait period may be 1090 set to zero. Using a wait period of zero is also appropriate when 1091 using TMMBR 0 and in line with the semantics for that message. 1093 If the RTP media stream sender receives further PAUSE requests with 1094 the available PauseID while waiting as described above, those 1095 additional requests are ignored. 1097 If the PAUSE request or TMMBR 0 is lost before it reaches the RTP 1098 media stream sender, it will be discovered by the RTP media stream 1099 receiver because it continues to receive the RTP media stream. It 1100 will also not see any PAUSED indication (Section 6.3) or TMMBN 0 for 1101 the stream. The same condition can be caused by the RTP media stream 1102 sender having received a disapproving RESUME from a media stream 1103 receiver A for a PAUSE request sent by a media stream sender B, but 1104 that the PAUSE sender (B) did not receive the RESUME (from A) and may 1105 instead think that the PAUSE was lost. In both cases, a PAUSE 1106 request can be re-transmitted using the same PauseID. If using TMMBR 1107 0 the request MAY be re-transmitted when the requestor fails to 1108 receive a TMMBN 0 confirmation. 1110 If the pending stream pause is aborted due to a disapproving RESUME, 1111 the PauseID from the disapproved PAUSE is invalidated by the RESUME 1112 and any new PAUSE must use an incremented PauseID (in modulo 1113 arithmetic) to be effective. 1115 An RTP media stream sender receiving a PAUSE not using the available 1116 PauseID informs the RTP media stream receiver sending the ineffective 1117 PAUSE of this condition by sending a REFUSE response that contains 1118 the next available PauseID value. This REFUSE also informs the RTP 1119 media stream receiver that it is probably not feasible to send 1120 another PAUSE for some time, not even with the available PauseID, 1121 since there are other RTP media stream receivers that wish to receive 1122 the stream. 1124 A similar situation where an ineffective PauseID is chosen can appear 1125 when a new RTP media stream receiver joins a session and wants to 1126 PAUSE a stream, but does not yet know the available PauseID to use. 1127 The REFUSE response will then provide sufficient information to 1128 create a valid PAUSE. The required extra signaling round-trip is not 1129 considered harmful, since it is assumed that pausing a stream is not 1130 time-critical (Section 4.1). 1132 There may be local considerations making it impossible or infeasible 1133 to pause the stream, and the RTP media stream sender can then respond 1134 with a REFUSE. In this case, if the used PauseID would otherwise 1135 have been effective, the REFUSE contains the same PauseID as in the 1136 PAUSE request, and the PauseID is kept as available. 1138 If the RTP media stream sender receives several identical PAUSE for 1139 an RTP media stream that was already at least once responded with 1140 REFUSE and the condition causing REFUSE remains, those additional 1141 REFUSE should be sent with regular RTCP timing. A single REFUSE can 1142 respond to several identical PAUSE requests. 1144 6.3. Media Sender Pausing 1146 An RTP media stream sender can choose to pause the stream at any 1147 time. This can either be as a result of receiving a PAUSE, or be 1148 based on some local sender consideration. When it does, it sends a 1149 PAUSED indication, containing the available PauseID. If the stream 1150 was paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What 1151 is said on PAUSED in the rest of this paragraph apply also to the use 1152 of TMMBN 0, except for PAUSED message parameters. Note that PauseID 1153 is incremented when pausing locally (without having received a 1154 PAUSE). It also sends the PAUSED indication in the next two regular 1155 RTCP reports, given that the pause condition is then still effective. 1157 The RTP media stream sender may want to apply some local 1158 consideration to exactly when the stream is paused, for example 1159 completing some media unit or a forward error correction block, 1160 before pausing the stream. 1162 The PAUSED indication also contains information about the RTP 1163 extended highest sequence number when the pause became effective. 1164 This provides RTP media stream receivers with first hand information 1165 allowing them to know whether they lost any packets just before the 1166 stream paused or when the stream is resumed again. This allows RTP 1167 media stream receivers to quickly and safely take into account that 1168 the stream is paused, in for example retransmission or congestion 1169 control algorithms. 1171 If the RTP media stream sender receives PAUSE requests with the 1172 available PauseID while the stream is already paused, those requests 1173 are ignored. 1175 As long as the stream is being paused, the PAUSED indication MAY be 1176 sent together with any regular RTCP SR or RR. Including PAUSED in 1177 this way allows RTP media stream receivers joining while the stream 1178 is paused to quickly know that there is a paused stream, what the 1179 last sent extended RTP sequence number was, and what the next 1180 available PauseID is to be able to construct valid PAUSE and RESUME 1181 requests at a later stage. 1183 When the RTP media stream sender learns that a new end-point has 1184 joined the RTP session, for example by a new SSRC and a CNAME that 1185 was not previously seen in the RTP session, it should send PAUSED 1186 indications for all its paused streams at its earliest opportunity. 1187 It should in addition continue to include PAUSED indications in at 1188 least two regular RTCP reports. 1190 6.4. Requesting to Resume 1192 An RTP media stream receiver can request to resume a stream with a 1193 RESUME request at any time, subject to AVPF timing rules. If the 1194 stream was paused with TMMBR 0, resuming the stream is made with 1195 TMMBR containing a bitrate value larger than 0. The bitrate value 1196 used when resuming after a PAUSE with TMMBR 0 is either according to 1197 known limitations, or the configured maximum for the stream or 1198 session. What is said on RESUME in the rest of this paragraph apply 1199 also to the use of TMMBR with a bitrate value larger than 0, except 1200 for RESUME message parameters. 1202 The RTP media stream receiver must include the available PauseID in 1203 the RESUME request for it to be effective. 1205 A pausing RTP media stream sender that receives a RESUME including 1206 the correct available PauseID resumes the stream at the earliest 1207 opportunity. Receiving RESUME requests for a stream that is not 1208 paused does not require any action and can be ignored. 1210 There may be local considerations, for example that the media device 1211 is not ready, making it temporarily impossible to resume the stream 1212 at that point in time, and the RTP media stream sender MAY then 1213 respond with a REFUSE containing the same PauseID as in the RESUME. 1214 When receiving such REFUSE with a PauseID identical to the one in the 1215 sent RESUME, RTP media stream receivers SHOULD then avoid sending 1216 further RESUME requests for some reasonable amount of time, to allow 1217 the condition to clear. 1219 If the RTP media stream sender receives several identical RESUME for 1220 an RTP media stream that was already at least once responded with 1221 REFUSE and the condition causing REFUSE remains, those additional 1222 REFUSE should be sent with regular RTCP timing. A single REFUSE can 1223 respond to several identical RESUME requests. 1225 When resuming a paused media stream, especially for media that makes 1226 use of temporal redundancy between samples such as video, the 1227 temporal dependency between samples taken before the pause and at the 1228 time instant the stream is resumed may not be appropriate to use in 1229 the encoding. Should such temporal dependency between before and 1230 after the media was paused be used by the media sender, it requires 1231 the media receiver to have saved the sample from before the pause for 1232 successful continued decoding when resuming. The use of this 1233 temporal dependency is left up to the media sender. If temporal 1234 dependency is not used when media is resumed, the first encoded 1235 sample after the pause will not contain any temporal dependency to 1236 samples before the pause (for video it may be a so-called intra 1237 picture). If temporal dependency to before the pause is used by the 1238 media sender when resuming, and if the media receiver did not save 1239 any sample from before the pause, the media receiver can use a FIR 1240 request [RFC5104] to explicitly ask for a sample without temporal 1241 dependency (for video a so-called intra picture), even at the same 1242 time as sending the RESUME. 1244 6.5. TMMBR/TMMBN Considerations 1246 As stated, TMMBR/TMMBN may be used to provide pause and resume 1247 functionality for the point-to-point case. If the topology is not 1248 point-to-point, TMMBR/TMMBN cannot safely be used for pause or 1249 resume. 1251 This is a brief summary of what functionality is provided when using 1252 TMMBR/TMMBN: 1254 TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- 1255 off period to wait for RESUME before pausing the media stream. 1257 TMMBR >0: Corresponds to RESUME when the media stream was previously 1258 paused with TMMBR 0. Since there is only a single media receiver, 1259 there is no need for the media sender to delay resuming the media 1260 stream until after sending TMMBN >0, or to apply the hold-off 1261 period specified in [RFC5104] before increasing the bitrate from 1262 zero. 1264 TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE 1265 indication when a media stream is requested to be resumed with 1266 TMMBR >0. 1268 TMMBN >0: Corresponds to a REFUSE indication when a media stream is 1269 requested to be paused with TMMBR 0. 1271 7. Participant States 1273 This document introduces three new states for a media stream in an 1274 RTP sender, according to the figure and sub-sections below. Any 1275 references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL 1276 be taken to apply to the extent possible also when TMMBR/TMMBN are 1277 used (Section 6.5) for this functionality. 1279 +------------------------------------------------------+ 1280 | Received RESUME | 1281 v | 1282 +---------+ Received PAUSE +---------+ Hold-off period +--------+ 1283 | Playing |---------------->| Pausing |---------------->| Paused | 1284 | |<----------------| | | | 1285 +---------+ Received RESUME +---------+ +--------+ 1286 ^ | | PAUSE decision | 1287 | | v | 1288 | | PAUSE decision +---------+ PAUSE decision | 1289 | +------------------>| Local |<--------------------+ 1290 +-------------------------| Paused | 1291 RESUME decision +---------+ 1293 Figure 8: RTP Pause States 1295 7.1. Playing State 1297 This state is not new, but is the normal media sending state from 1298 [RFC3550]. When entering the state, the PauseID MUST be incremented 1299 by one in modulo arithmetic. The RTP sequence number for the first 1300 packet sent after a pause SHALL be incremented by one compared to the 1301 highest RTP sequence number sent before the pause. The first RTP 1302 Time Stamp for the first packet sent after a pause SHOULD be set 1303 according to capture times at the source. 1305 7.2. Pausing State 1307 In this state, the media sender has received at least one PAUSE 1308 message for the stream in question. The media sender SHALL wait 1309 during a hold-off period for the possible reception of RESUME 1310 messages for the RTP media stream being paused before actually 1311 pausing media transmission. The period to wait SHALL be long enough 1312 to allow another media receiver to respond to the PAUSE with a 1313 RESUME, if it determines that it would not like to see the stream 1314 paused. This delay period (denoted by 'Hold-off period' in the 1315 figure) is determined by the formula: 1317 2 * RTT + T_dither_max, 1319 where RTT is the longest round trip known to the media sender and 1320 T_dither_max is defined in section 3.4 of [RFC4585]. The hold-off 1321 period MAY be set to 0 by some signaling (Section 10) means when it 1322 can be determined that there is only a single receiver, for example 1323 in point-to-point or some unicast situations. 1325 If the RTP media stream sender has set the hold-off period to 0 and 1326 receives information that it was an incorrect decision and that there 1327 are in fact several receivers of the stream, for example by RTCP RR, 1328 it MUST change the hold-off to instead be based on the above formula. 1330 7.3. Paused State 1332 An RTP media stream is in paused state when the sender pauses its 1333 transmission after receiving at least one PAUSE message and the hold- 1334 off period has passed without receiving any RESUME message for that 1335 stream. 1337 When entering the state, the media sender SHALL send a PAUSED 1338 indication to all known media receivers, and SHALL also repeat PAUSED 1339 in the next two regular RTCP reports. 1341 Following sub-sections discusses some potential issues when an RTP 1342 sender goes into paused state. These conditions are also valid if an 1343 RTP Translator is used in the communication. When an RTP Mixer 1344 implementing this specification is involved between the participants 1345 (which forwards the stream by marking the RTP data with its own 1346 SSRC), it SHALL be a responsibility of the Mixer to control sending 1347 PAUSE and RESUME requests to the sender. The below conditions also 1348 apply to the sender and receiver parts of the RTP Mixer, 1349 respectively. 1351 7.3.1. RTCP BYE Message 1353 When a participant leaves the RTP session, it sends an RTCP BYE 1354 message. In addition to the semantics described in section 6.3.4 and 1355 6.3.7 of RTP [RFC3550], following two conditions MUST also be 1356 considered when an RTP participant sends an RTCP BYE message, 1358 o If a paused sender sends an RTCP BYE message, receivers observing 1359 this SHALL NOT send further PAUSE or RESUME requests to it. 1361 o Since a sender pauses its transmission on receiving the PAUSE 1362 requests from any receiver in a session, the sender MUST keep 1363 record of which receiver that caused the RTP media stream to 1364 pause. If that receiver sends an RTCP BYE message observed by the 1365 sender, the sender SHALL resume the RTP media stream. 1367 7.3.2. SSRC Time-out 1369 Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP 1370 participant. Every RTP participant maintains a sender and receiver 1371 list in a session. If a participant does not get any RTP or RTCP 1372 packets from some other participant for the last five RTCP reporting 1373 intervals it removes that participant from the receiver list. Any 1374 streams that were paused by that removed participant SHALL be 1375 resumed. 1377 7.4. Local Paused State 1379 This state can be entered at any time, based on local decision from 1380 the media sender. As for Paused State (Section 7.3), the media 1381 sender SHALL send a PAUSED indication to all known media receivers, 1382 when entering the state, and repeat it in the next two regular RTCP 1383 reports. 1385 When leaving the state, the stream state SHALL become Playing, 1386 regardless whether or not there were any media receivers that sent 1387 PAUSE for that stream, effectively clearing the media sender's memory 1388 for that media stream. 1390 8. Message Format 1392 Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP 1393 feedback messages, i.e. Transport layer, Payload-specific, and 1394 Application layer feedback messages. This document defines a new 1395 Transport layer feedback message, this message is either a PAUSE 1396 request, a RESUME request, or one of four different types of 1397 acknowledgements in response to either PAUSE or RESUME requests. 1399 The Transport layer feedback messages are identified by having the 1400 RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The 1401 PAUSE and RESUME messages are identified by Feedback Message Type 1402 (FMT) value in common packet header for feedback message defined in 1403 section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport 1404 feedback message is identified by the FMT value = TBA1. 1406 The Common Packet Format for Feedback Messages is defined by AVPF 1407 [RFC4585] is: 1409 0 1 2 3 1410 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 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 |V=2|P| FMT | PT | Length | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | SSRC of packet sender | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | SSRC of media source | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 : Feedback Control Information (FCI) : 1419 : : 1421 For the PAUSE and RESUME messages, the following interpretation of 1422 the packet fields will be: 1424 FMT: The FMT value identifying the PAUSE and RESUME message: TBA1 1426 PT: Payload Type = 205 (RTPFB) 1428 Length: As defined by AVPF, i.e. the length of this packet in 32-bit 1429 words minus one, including the header and any padding. 1431 SSRC of packet sender: The SSRC of the RTP session participant 1432 sending the messages in the FCI. Note, for end-points that have 1433 multiple SSRCs in an RTP session, any of its SSRCs MAY be used to 1434 send any of the pause message types. 1436 SSRC of media source: Not used, SHALL be set to 0. The FCI 1437 identifies the SSRC the message is targeted for. 1439 The Feedback Control Information (FCI) field consist of one or more 1440 PAUSE, RESUME, PAUSED, REFUSE, or any future extension. These 1441 messages have the following FCI format: 1443 0 1 2 3 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Target SSRC | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Type | Res | Parameter Len | PauseID | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 : Type Specific : 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Figure 9: Syntax of FCI Entry in the PAUSE and RESUME message 1455 The FCI fields have the following definitions: 1457 Target SSRC (32 bits): For a PAUSE and RESUME messages, this value 1458 is the SSRC that the request is intended for. For PAUSED, it MUST 1459 be the SSRC being paused. If pausing is the result of a PAUSE 1460 request, the value in PAUSED is effectively the same as Target 1461 SSRC in a related PAUSE request. For REFUSE, it MUST be the 1462 Target SSRC of the PAUSE or RESUME request that cannot change 1463 state. A CSRC MUST NOT be used as a target as the interpretation 1464 of such a request is unclear. 1466 Type (4 bits): The pause feedback type. The values defined in this 1467 specification are as follows, 1468 0: PAUSE request message 1470 1: RESUME request message 1472 2: PAUSED indication message 1474 3: REFUSE indication message 1476 4-15: Reserved for future use 1478 Res: (4 bits): Type specific reserved. SHALL be ignored by 1479 receivers implementing this specification and MUST be set to 0 by 1480 senders implementing this specification. 1482 Parameter Len: (8 bits): Length of the Type Specific field in 32-bit 1483 words. MAY be 0. 1485 PauseID (16 bits): Message sequence identification. SHALL be 1486 incremented by one modulo 2^16 for each new PAUSE message, unless 1487 the message is re-transmitted. The initial value SHOULD be 0. 1488 The PauseID is scoped by the Target SSRC, meaning that PAUSE, 1489 RESUME, and PAUSED messages therefore share the same PauseID space 1490 for a specific Target SSRC. 1492 Type Specific: (variable): Defined per pause feedback Type. MAY be 1493 empty. 1495 9. Message Details 1497 This section contains detailed explanations of each message defined 1498 in this specification. All transmissions of request and indications 1499 are governed by the transmission rules as defined by Section 9.5. 1501 Any references to PAUSE, PAUSED, RESUME and REFUSE in this section 1502 SHALL be taken to apply to the extent possible also when TMMBR/TMMBN 1503 are used (Section 6.5) for this functionality. TMMBR/TMMBN MAY be 1504 used instead of the messages defined in this specification when the 1505 effective topology is point-to-point. If either sender or receiver 1506 learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT 1507 be used for pause/resume functionality. If the messages defined in 1508 this specification are supported in addition to TMMBR/TMMBN, pause/ 1509 resume signaling MUST revert to use those instead. If the topology 1510 is not point-to-point and the messages defined in this specification 1511 are not supported, pause/resume functionality with TMMBR/TMMBN MUST 1512 NOT be used. 1514 9.1. PAUSE 1516 An RTP media stream receiver MAY schedule PAUSE for transmission at 1517 any time. 1519 PAUSE has no defined Type Specific parameters and Parameter Len MUST 1520 be set to 0. 1522 PauseID SHOULD be the available PauseID, as indicated by PAUSED 1523 (Section 9.2) or implicitly determined by previously received PAUSE 1524 or RESUME (Section 9.3) requests. A randomly chosen PauseID MAY be 1525 used if it was not possible to retrieve PauseID information, in which 1526 case the PAUSE will either succeed, or the correct PauseID can be 1527 learnt from the returned REFUSE (Section 9.4). A PauseID that is 1528 matching the available PauseID is henceforth also called a valid 1529 PauseID. 1531 PauseID needs to be incremented by one, in modulo arithmetic, for 1532 each PAUSE request that is not a retransmission, compared to what was 1533 used in the last PAUSED indication sent by the media sender. This is 1534 to ensure that the PauseID matches what is the current available 1535 PauseID at the media sender. The media sender increments what it 1536 considers to be the available PauseID when entering Playing State 1537 (Section 7.1). 1539 For the scope of this specification, a PauseID larger than the 1540 current one is defined as having a value between and including 1541 (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is 1542 the modulo operator. Similarly, a PauseID smaller than the current 1543 one is defined as having a value between and including (PauseID - 1544 2^15) MOD 2^16 and (PauseID - 1) MOD 2^16. 1546 If an RTP media stream receiver that sent a PAUSE with a certain 1547 PauseID receives a RESUME with the same PauseID, it is RECOMMENDED 1548 that it refrains from sending further PAUSE requests for some 1549 appropriate time since the RESUME indicates that there are other 1550 receivers that still wishes to receive the stream. 1552 If the targeted RTP media stream does not pause, if no PAUSED 1553 indication with a larger PauseID than the one used in PAUSE, and if 1554 no REFUSE is received within 2 * RTT + T_dither_max, the PAUSE MAY be 1555 scheduled for retransmission, using the same PauseID. RTT is the 1556 observed round-trip to the RTP media stream sender and T_dither_max 1557 is defined in section 3.4 of [RFC4585]. 1559 When an RTP media stream sender in Playing State (Section 7.1) 1560 receives a valid PAUSE, and unless local considerations currently 1561 makes it impossible to pause the stream, it SHALL enter Pausing State 1562 (Section 7.2) when reaching an appropriate place to pause in the 1563 media stream, and act accordingly. 1565 If an RTP media stream sender receives a valid PAUSE while in 1566 Pausing, Paused (Section 7.3) or Local Paused (Section 7.4) States, 1567 the received PAUSE SHALL be ignored. 1569 9.2. PAUSED 1571 The PAUSED indication MAY be sent either as a result of a valid PAUSE 1572 (Section 9.1) request, when entering Paused State (Section 7.3), or 1573 based on a RTP media stream sender local decision, when entering 1574 Local Paused State (Section 7.4). 1576 PauseID MUST contain the available, valid value to be included in a 1577 subsequent RESUME (Section 9.3). 1579 PAUSED SHALL contain a 32 bit parameter with the RTP extended highest 1580 sequence number valid when the RTP media stream was paused. 1581 Parameter Len MUST be set to 1. 1583 After having entered Paused or Local Paused State and thus having 1584 sent PAUSED once, PAUSED MUST also be included in the next two 1585 regular RTCP reports, given that the pause condition is then still 1586 effective. 1588 While remaining in Paused or Local Paused States, PAUSED MAY be 1589 included in all regular RTCP reports. 1591 When in Paused or Local Paused States, It is RECOMMENDED to send 1592 PAUSED at the earliest opportunity and also to include it in the next 1593 two regular RTCP reports, whenever the RTP media sender learns that 1594 there are end-points that did not previously receive the stream, for 1595 example by RTCP reports with an SSRC and a CNAME that was not 1596 previously seen in the RTP session. 1598 9.3. RESUME 1600 An RTP media stream receiver MAY schedule RESUME for transmission 1601 whenever it wishes to resume a paused stream, or to disapprove a 1602 stream from being paused. 1604 PauseID SHOULD be the valid PauseID, as indicated by PAUSED 1605 (Section 9.2) or implicitly determined by previously received PAUSE 1606 (Section 9.1) or RESUME requests. A randomly chosen PauseID MAY be 1607 used if it was not possible to retrieve PauseID information, in which 1608 case the RESUME will either succeed, or the correct PauseID can be 1609 learnt from a returned REFUSE (Section 9.4). 1611 RESUME has no defined Type Specific parameters and Parameter Len MUST 1612 be set to 0. 1614 When an RTP media stream sender in Pausing (Section 7.2), Paused 1615 (Section 7.3) or Local Paused State (Section 7.4) receives a valid 1616 RESUME, and unless local considerations currently makes it impossible 1617 to resume the stream, it SHALL enter Playing State (Section 7.1) and 1618 act accordingly. If the RTP media stream sender is incapable of 1619 honoring the RESUME request with a valid PauseID, or receives a 1620 RESUME request with an invalid PauseID while in Paused or Pausing 1621 state, the RTP media stream sender sends a REFUSE message as 1622 specified below. 1624 If an RTP media stream sender in Playing State receives a RESUME 1625 containing either a valid PauseID or a PauseID that is less than the 1626 valid PauseID, the received RESUME SHALL be ignored. 1628 9.4. REFUSE 1630 REFUSE has no defined Type Specific parameters and Parameter Len MUST 1631 be set to 0. 1633 If an RTP media sender receives a valid PAUSE (Section 9.1) or RESUME 1634 (Section 9.3) request that cannot be fulfilled by the sender due to 1635 some local consideration, it SHALL schedule transmission of a REFUSE 1636 indication containing the valid PauseID from the rejected request. 1638 If an RTP media stream sender receives PAUSE or RESUME requests with 1639 a non-valid PauseID it SHALL schedule a REFUSE response containing 1640 the available, valid PauseID, except if the RTP media stream sender 1641 is in Playing State and receives a RESUME with a PauseID less than 1642 the valid one, in which case the RESUME SHALL be ignored. 1644 If several PAUSE or RESUME that would render identical REFUSE 1645 responses are received before the scheduled REFUSE is sent, duplicate 1646 REFUSE MUST NOT be scheduled for transmission. This effectively lets 1647 a single REFUSE respond to several invalid PAUSE or RESUME requests. 1649 If REFUSE containing a certain PauseID was already sent and yet more 1650 PAUSE or RESUME messages are received that require additional REFUSE 1651 with that specific PauseID to be scheduled, and unless the PauseID 1652 number space has wrapped since REFUSE was last sent with that 1653 PauseID, further REFUSE messages with that PauseID SHOULD be sent in 1654 regular RTCP reports. 1656 An RTP media stream receiver that sent a PAUSE or RESUME request and 1657 receives a REFUSE containing the same PauseID as in the request 1658 SHOULD refrain from sending an identical request for some appropriate 1659 time to allow the condition that caused REFUSE to clear. 1661 An RTP media stream receiver that sent a PAUSE or RESUME request and 1662 receives a REFUSE containing a PauseID different from the request MAY 1663 schedule another request using the PauseID from the REFUSE 1664 indication. 1666 9.5. Transmission Rules 1668 The transmission of any RTCP feedback messages defined in this 1669 specification MUST follow the normal AVPF defined timing rules and 1670 depends on the session's mode of operation. 1672 All messages defined in this specification MAY use either Regular, 1673 Early or Immediate timings, taking the following into consideration: 1675 o PAUSE SHOULD use Early or Immediate timing, except for 1676 retransmissions that SHOULD use Regular timing. 1678 o The first transmission of PAUSED for each (non-wrapped) PauseID 1679 SHOULD be sent with Immediate or Early timing, while subsequent 1680 PAUSED for that PauseID SHOULD use Regular timing. 1682 o RESUME SHOULD always use Immediate or Early timing. 1684 o The first transmission of REFUSE for each (non-wrapped) PauseID 1685 SHOULD be sent with Immediate or Early timing, while subsequent 1686 REFUSE for that PauseID SHOULD use Regular timing. 1688 10. Signalling 1690 The capability of handling messages defined in this specification MAY 1691 be exchanged at a higher layer such as SDP. This document extends 1692 the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to 1693 include the request for pause and resume. Like AVPF [RFC4585] and 1694 CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at 1695 media level and it MUST NOT be used at session level. This 1696 specification follows all the rules defined in AVPF for rtcp-fb 1697 attribute relating to payload type in a session description. 1699 Note: When TMMBR 0 / TMMBN 0 are used to implement pause and 1700 resume functionality (with the restrictions described in this 1701 memo), signaling rtcp-fb attribute with ccm tmmbr parameter is 1702 sufficient and no further signaling is necessary. 1704 This specification defines two new parameters to the "ccm" feedback 1705 value defined in CCM [RFC5104], "pause" and "paused". 1707 o "pause" represents the capability to understand the RTCP feedback 1708 message and all of the defined FCIs of PAUSE, RESUME, PAUSED and 1709 REFUSE. A direction sub-parameter is used to determine if a given 1710 node desires to issue PAUSE or RESUME requests, can respond to 1711 PAUSE or RESUME requests, or both. 1713 o "paused" represents the functionality of supporting the playing 1714 and local paused states and generate PAUSED FCI when a media 1715 stream delivery is paused. A direction sub-parameter is used to 1716 determine if a given node desires to receive these indications, 1717 intends to send them, or both. 1719 The reason for this separation is to make it possible for partial 1720 implementation of this specification, according to the different 1721 roles in the use cases section (Section 3). 1723 A sub-parameter named "nowait", indicating that the hold-off time 1724 defined in Section 7.2 can be set to 0, reducing the latency before 1725 the media stream can paused after receiving a PAUSE request. This 1726 condition occurs when there will be only a single receiver per 1727 direction in the RTP session, for example in point-to-point sessions. 1728 It is also possible to use in scenarios using unidirectional media. 1729 The conditions that allow "nowait" to be set also indicate that it 1730 would be possible to use CCM TMMBR/TMMBN as pause/resume signaling. 1732 A sub-parameter named "dir" is used to indicate in which directions a 1733 given node will use the pause or paused functionality. The node 1734 being configured or issuing an offer or an answer uses the 1735 directionality in the following way. Note that pause and paused have 1736 separate and different definitions. 1738 Direction ("dir") values for "pause" is defined as follows: 1740 sendonly: The node intends to send PAUSE and RESUME requests for 1741 other nodes' media streams and is thus also capable of receiving 1742 PAUSED and REFUSE. It will not support receiving PAUSE and RESUME 1743 requests. 1745 recvonly: The node supports receiving PAUSE and RESUME requests 1746 targeted for media streams sent by the node. It will send PAUSED 1747 and REFUSE as needed. The node will not send any PAUSE and RESUME 1748 requests. 1750 sendrecv: The node supports receiving PAUSE and RESUME requests 1751 targeted for media streams sent by the node. The node intends to 1752 send PAUSE and RESUME requests for other nodes' media streams. 1753 Thus the node is capable of sending and receiving all types of 1754 pause messages. This is the default value. If the "dir" 1755 parameter is omitted, it MUST be interpreted to represent this 1756 value. 1758 Direction values for "paused" is defined as follows: 1760 sendonly: The node intends to send PAUSED indications whenever it 1761 pauses media delivery in any of its media streams. It has no need 1762 to receive PAUSED indications itself. 1764 recvonly: The node desires to receive PAUSED indications whenever 1765 any media stream sent by another node is paused. It does not 1766 intend to send any PAUSED indications. 1768 sendrecv: The nodes desires to receive PAUSED indications and 1769 intends to send PAUSED indications whenever any media stream is 1770 paused. This is the default value. If the "dir" parameter is 1771 omitted, it MUST be interpreted to represent this value. 1773 This is the resulting ABNF [RFC5234], extending existing ABNF in 1774 section 7.1 of CCM [RFC5104]: 1776 rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr) 1777 / SP "paused" *(SP paused-attr) 1778 pause-attr = direction 1779 / "nowait" 1780 / token ; for future extensions 1781 paused-attr = direction 1782 / token ; for future extensions 1783 direction = "dir=" direction-alts 1784 direction-alts = "sendonly" / "recvonly" / "sendrecv" 1786 Figure 10: ABNF 1788 An endpoint implementing this specification and using SDP to signal 1789 capability SHOULD indicate both of the new "pause" and "paused" 1790 parameters with ccm signaling. When negotiating usage, it is 1791 possible select either of them, noting that "pause" contain the full 1792 "paused" functionality. A sender or receiver SHOULD NOT use the 1793 messages from this specification towards receivers that did not 1794 declare capability for it. 1796 There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one 1797 with "paused" applicable to a single payload type in the SDP, unless 1798 the additional line uses "*" as payload type, in which case "*" SHALL 1799 be interpreted as applicable to all listed payload types that does 1800 not have an explicit "pause" or "paused" specification. 1802 There MUST NOT be more than a single direction sub-parameter per 1803 "pause" and "paused" parameter. There MUST NOT be more than a single 1804 "nowait" sub-parameter per "pause" parameter. 1806 10.1. Offer-Answer Use 1808 An offerer implementing this specification needs to include "pause" 1809 and/or "paused" CCM parameters with suitable directionality parameter 1810 ("dir") in the SDP, according to what messages it intends to send and 1811 desires or is capable to receive in the session. It is RECOMMENDED 1812 to include both "pause" and "paused" if "pause" is supported, to 1813 enable at least the "paused" functionality if the answer only 1814 supports "paused" or different directionality for the two 1815 functionalities. The "pause" and "paused" functionalities are 1816 negotiated independently, although the "paused" functionality is part 1817 of the "pause" functionality. As a result, an answerer MAY remove 1818 "pause" or "paused" lines from the SDP depending on the agreed mode 1819 of functionality. 1821 In offer/answer, the "dir" parameter is interpreted based on the 1822 agent providing the SDP. The node described in the offer is the 1823 offerer, and the answerer is described in an answer. In other words, 1824 an offer for "paused dir=sendonly" means that the offerer intends to 1825 send PAUSED indications whenever it pauses media delivery in any of 1826 its media streams. 1828 An answerer receiving an offer with a "pause" parameter with 1829 dir=sendrecv MAY remove the pause line in its answer, respond with 1830 pause keeping sendrecv for full bi-directionality, or it may change 1831 dir value to either sendonly or recvonly based on its capabilities 1832 and desired functionality. An offer with a "pause" parameter with 1833 dir=sendonly or dir=recvonly is either completely removed or accepted 1834 with reverse directionality, i.e. sendonly becomes recvonly or 1835 recvonly becomes sendonly. 1837 An answer receiving an offer with "paused" has the same choices as 1838 for "pause" above. It should be noted that the directionality of 1839 pause is the inverse of media direction, while the directionality of 1840 paused is the same as the media direction. 1842 If the offerer believes that itself and the intended answerer are 1843 likely the only end-points in the RTP session, it MAY include the 1844 "nowait" sub-parameter on the "pause" line in the offer. If an 1845 answerer receives the "nowait" sub-parameter on the "pause" line in 1846 the SDP, and if it has information that the offerer and itself are 1847 not the only end-points in the RTP session, it MUST NOT include any 1848 "nowait" sub-parameter on its "pause" line in the SDP answer. The 1849 answerer MUST NOT add "nowait" on the "pause" line in the answer 1850 unless it is present on the "paused" line in the offer. If both 1851 offer and answer contained a "nowait" parameter, then the hold-off 1852 time is configured to 0 at both offerer and answerer. 1854 10.2. Declarative Use 1856 In declarative use, the SDP is used to configure the node receiving 1857 the SDP. This has implications on the interpretation of the SDP 1858 signalling extensions defined in this draft. First, it is normally 1859 only necessary to include either "pause" or "paused" parameter to 1860 indicate the level of functionality the node should use in this RTP 1861 session. Including both is only necessary if some implementations 1862 only understands "paused" and some other can understand both. Thus 1863 indicating both means use pause if you understand it, and if you only 1864 understand paused, use that. 1866 The "dir" directionality parameter indicates how the configured node 1867 should behave. For example "pause" with sendonly: 1869 sendonly: The node intends to send PAUSE and RESUME requests for 1870 other nodes' media streams and is thus also capable of receiving 1871 PAUSED and REFUSE. It will not support receiving PAUSE and RESUME 1872 requests. 1874 In this example, the configured node should send PAUSE and RESUME 1875 requests if has reason for it. It does not need to respond to any 1876 PAUSE or RESUME requests as that is not supported. 1878 The "nowait" parameter, if included, is followed as specified. It is 1879 the responsibility of the declarative SDP sender to determine if a 1880 configured node will participate in a session that will be point to 1881 point, based on the usage. For example, a conference client being 1882 configured for an any source multicast session using SAP [RFC2974] 1883 will not be in a point to point session, thus "nowait" cannot be 1884 included. An RTSP [RFC2326] client receiving a declarative SDP may 1885 very well be in a point to point session, although it is highly 1886 doubtful that an RTSP client would need to support this 1887 specification, considering the inherent PAUSE support in RTSP. 1889 11. Examples 1891 The following examples shows use of PAUSE and RESUME messages, 1892 including use of offer-answer: 1894 1. Offer-Answer 1896 2. Point-to-Point session 1897 3. Point-to-multipoint using Mixer 1899 4. Point-to-multipoint using Translator 1901 11.1. Offer-Answer 1903 The below figures contains an example how to show support for pausing 1904 and resuming the streams, as well as indicating whether or not the 1905 hold-off period can be set to 0. 1907 v=0 1908 o=alice 3203093520 3203093520 IN IP4 alice.example.com 1909 s=Pausing Media 1910 t=0 0 1911 c=IN IP4 alice.example.com 1912 m=audio 49170 RTP/AVPF 98 99 1913 a=rtpmap:98 G719/48000 1914 a=rtpmap:99 PCMA/8000 1915 a=rtcp-fb:* ccm pause nowait 1916 a=rtcp-fb:* ccm paused 1918 Figure 11: SDP Offer With Pause and Resume Capability 1920 The offerer supports all of the messages defined in this 1921 specification and offers a sendrecv stream. The offerer also 1922 believes that it will be the sole receiver of the answerer's stream 1923 as well as that the answerer will be the sole receiver of the 1924 offerer's stream and thus includes the "nowait" sub-parameter for 1925 both "pause" and "paused" parameters. 1927 This is the SDP answer: 1929 v=0 1930 o=bob 293847192 293847192 IN IP4 bob.example.com 1931 s=- 1932 t=0 0 1933 c=IN IP4 bob.example.com 1934 m=audio 49202 RTP/AVPF 98 1935 a=rtpmap:98 G719/48000 1936 a=rtcp-fb:98 ccm pause dir=sendonly 1937 a=rtcp-fb:98 ccm paused 1939 Figure 12: SDP Answer With Pause and Resume Capability 1941 The answerer will not allow its sent streams to be paused or resumed 1942 and thus support pause only in sendonly mode. It does support paused 1943 and intends to send it, and also desires to receive PAUSED 1944 indications. Thus paused in sendrecv mode is included in the answer. 1945 The answerer somehow knows that it will not be a point-to-point RTP 1946 session and has therefore removed "nowait" from the "pause" line, 1947 meaning that the offerer must use a non-zero hold-off time when being 1948 requested to pause the stream. 1950 When using TMMBR 0 / TMMBN 0 to achieve pause and resume 1951 functionality, there are no differences in SDP compared to CCM 1952 [RFC5104] and therefore no such examples are included here. 1954 11.2. Point-to-Point Session 1956 This is the most basic scenario, which involves two participants, 1957 each acting as a sender and/or receiver. Any RTP data receiver sends 1958 PAUSE or RESUME messages to the sender, which pauses or resumes 1959 transmission accordingly. The hold-off time before pausing a stream 1960 is 0. 1962 +---------------+ +---------------+ 1963 | RTP Sender | | RTP Receiver | 1964 +---------------+ +---------------+ 1965 : t1: RTP data : 1966 | -------------------------------> | 1967 | t2: PAUSE(3) | 1968 | <------------------------------- | 1969 | < RTP data paused > | 1970 | t3: PAUSED(3) | 1971 | -------------------------------> | 1972 : < Some time passes > : 1973 | t4: RESUME(3) | 1974 | <------------------------------- | 1975 | t5: RTP data | 1976 | -------------------------------> | 1977 : < Some time passes > : 1978 | t6: PAUSE(4) | 1979 | <------------------------------- | 1980 | < RTP data paused > | 1981 : : 1983 Figure 13: Pause and Resume Operation in Point-to-Point 1985 Figure 13 shows the basic pause and resume operation in Point-to- 1986 Point scenario. At time t1, an RTP sender sends data to a receiver. 1987 At time t2, the RTP receiver requests the sender to pause the stream, 1988 using PauseID 3 (which it knew since before in this example). The 1989 sender pauses the data and replies with a PAUSED containing the same 1990 PauseID. Some time later (at time t4) the receiver requests the 1991 sender to resume, which resumes its transmission. The next PAUSE, 1992 sent at time t6, contains an updated PauseID (4). 1994 +---------------+ +---------------+ 1995 | RTP Sender | | RTP Receiver | 1996 +---------------+ +---------------+ 1997 : t1: RTP data : 1998 | -------------------------------> | 1999 | t2: TMMBR 0 | 2000 | <------------------------------- | 2001 | < RTP data paused > | 2002 | t3: TMMBN 0 | 2003 | -------------------------------> | 2004 : < Some time passes > : 2005 | t4: TMMBR 150000 | 2006 | <------------------------------- | 2007 | t5: RTP data | 2008 | -------------------------------> | 2009 : < Some time passes > : 2010 | t6: TMMBR 0 | 2011 | <------------------------------- | 2012 | < RTP data paused > | 2013 : : 2015 Figure 14: TMMBR Pause and Resume in Point-to-Point 2017 Figure 14 describes the same point-to-point scenario as above, but 2018 using TMMBR/TMMBN signaling. 2020 +---------------+ +---------------+ 2021 | RTP Sender | | RTP Receiver | 2022 +---------------+ +---------------+ 2023 : t1: RTP data : 2024 | ------------------------------------> | 2025 | t2: PAUSE(7), lost | 2026 | <---X-------------- | 2027 | | 2028 | t3: RTP data | 2029 | ------------------------------------> | 2030 : : 2031 | | 2032 | t4: PAUSE(7) | 2033 | <------------------------------------ | 2034 | < RTP data paused > | 2035 | t5: PAUSED(7) | 2036 | ------------------------------------> | 2037 : < Some time passes > : 2038 | t6: RESUME(7), lost | 2039 | <---X-------------- | 2040 | t7: RESUME(7) | 2041 | <------------------------------------ | 2042 | t8: RTP data | 2043 | ------------------------------------> | 2044 | t9: RESUME(7) | 2045 | <------------------------------------ | 2046 : : 2048 Figure 15: Pause and Resume Operation With Messages Lost 2050 Figure 15 describes what happens if a PAUSE message from an RTP media 2051 stream receiver does not reach the RTP media stream sender. After 2052 sending a PAUSE message, the RTP media stream receiver waits for a 2053 time-out to detect if the RTP media stream sender has paused the data 2054 transmission or has sent PAUSED indication according to the rules 2055 discussed in Section 7.3. As the PAUSE message is lost on the way 2056 (at time t2), RTP data continues to reach to the RTP media stream 2057 receiver. When the timer expires, the RTP media stream receiver 2058 schedules a retransmission of the PAUSE message, which is sent at 2059 time t4. If the PAUSE message now reaches the RTP media stream 2060 sender, it pauses the RTP media stream and replies with PAUSED. 2062 At time t6, the RTP media stream receiver wishes to resume the stream 2063 again and sends a RESUME, which is lost. This does not cause any 2064 severe effect, since there is no requirement to wait until further 2065 RESUME are sent and another RESUME are sent already at time t7, which 2066 now reaches the RTP media stream sender that consequently resumes the 2067 stream at time t8. The time interval between t6 and t7 can vary, but 2068 may for example be one RTCP feedback transmission interval as 2069 determined by the AVPF rules. 2071 The RTP media stream receiver did not realize that the RTP stream was 2072 resumed in time to stop yet another scheduled RESUME from being sent 2073 at time t9. This is however harmless since the RESUME PauseID is 2074 less than the valid one and will be ignored by the RTP media stream 2075 sender. It will also not cause any unwanted resume even if the 2076 stream was paused based on a PAUSE from some other receiver before 2077 receiving the RESUME, since the valid PauseID is now larger than the 2078 one in the stray RESUME and will only cause a REFUSE containing the 2079 new valid PauseID from the RTP media stream sender. 2081 +---------------+ +---------------+ 2082 | RTP Sender | | RTP Receiver | 2083 +---------------+ +---------------+ 2084 : t1: RTP data : 2085 | ------------------------------> | 2086 | t2: PAUSE(11) | 2087 | <------------------------------ | 2088 | | 2089 | < Can not pause RTP data > | 2090 | t3: REFUSE(11) | 2091 | ------------------------------> | 2092 | | 2093 | t4: RTP data | 2094 | ------------------------------> | 2095 : : 2097 Figure 16: Pause Request is Refused in Point-to-Point 2099 In Figure 16, the receiver requests to pause the sender, which 2100 refuses to pause due to some consideration local to the sender and 2101 responds with a REFUSE message. 2103 11.3. Point-to-multipoint using Mixer 2105 An RTP Mixer is an intermediate node connecting different transport- 2106 level clouds. The Mixer receives streams from different RTP sources, 2107 selects or combines them based on the application's needs and 2108 forwards the generated stream(s) to the destination. The Mixer 2109 typically puts its' own SSRC(s) in RTP data packets instead of the 2110 original source(s). 2112 The Mixer keeps track of all the media streams delivered to the Mixer 2113 and how they are currently used. In this example, it selects the 2114 video stream to deliver to the receiver R based on the voice activity 2115 of the media senders. The video stream will be delivered to R using 2116 M's SSRC and with an CSRC indicating the original source. 2118 Note that PauseID is not of any significance for the example and is 2119 therefore omitted in the description. 2121 +-----+ +-----+ +-----+ +-----+ 2122 | R | | M | | S1 | | S2 | 2123 +-----+ +-----| +-----+ +-----+ 2124 : : t1:RTP(S1) : : 2125 | t2:RTP(M:S1) |<-----------------| | 2126 |<-----------------| | | 2127 | | t3:RTP(S2) | | 2128 | |<------------------------------------| 2129 | | t4: PAUSE(S2) | | 2130 | |------------------------------------>| 2131 | | | t5: PAUSED(S2) | 2132 | |<------------------------------------| 2133 | | | | 2134 | | t6: RESUME(S2) | | 2135 | |------------------------------------>| 2136 | | | t7: RTP to M | 2137 | |<------------------------------------| 2138 | t8:RTP(M:S2) | | | 2139 |<-----------------| | | 2140 | | t9:PAUSE(S1) | | 2141 | |----------------->| | 2142 | | t10:PAUSED(S1) | | 2143 | |<-----------------| | 2144 | | | | 2145 : : : : 2147 Figure 17: Pause and Resume Operation for a Voice Activated Mixer 2149 The session starts at t1 with S1 being the most active speaker and 2150 thus being selected as the single video stream to be delivered to R 2151 (t2) using the Mixer SSRC but with S1 as CSRC (indicated after the 2152 colon in the figure). Then S2 joins the session at t3 and starts 2153 delivering media to the Mixer. As S2 has less voice activity then 2154 S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE 2155 request. At t5, S2 acknowledges with a PAUSED and at the same 2156 instant stops delivering RTP to the Mixer. At t6, the user at S2 2157 starts speaking and becomes the most active speaker and the Mixer 2158 decides to switch the video stream to S2, and therefore quickly sends 2159 a RESUME request to S2. At t7, S2 has received the RESUME request 2160 and acts on it by resuming RTP media delivery to M. When the media 2161 from t7 arrives at the Mixer, it switches this media into its SSRC 2162 (M) at t8 and changes the CSRC to S2. As S1 now becomes unused, the 2163 Mixer issues a PAUSE request to S1 at t9, which is acknowledged at 2164 t10 with a PAUSED and the RTP media stream from S1 stops being 2165 delivered. 2167 11.4. Point-to-multipoint using Translator 2169 A transport Translator in an RTP session forwards the message from 2170 one peer to all the others. Unlike Mixer, the Translator does not 2171 mix the streams or change the SSRC of the messages or RTP media. 2172 These examples are to show that the messages defined in this 2173 specification can be safely used also in a transport Translator case. 2174 The parentheses in the figures contains (Target SSRC, PauseID) 2175 information for the messages defined in this specification. 2177 +-------------+ +-------------+ +--------------+ 2178 | Sender(S) | | Translator | | Receiver(R) | 2179 +-------------+ +-------------| +--------------+ 2180 : t1: RTP(S) : : 2181 |------------------>| | 2182 | | t2: RTP (S) | 2183 | |------------------>| 2184 | | t3: PAUSE(S,3) | 2185 | |<------------------| 2186 | t4:PAUSE(S,3) | | 2187 |<------------------| | 2188 : < Sender waiting for possible RESUME> : 2189 | < RTP data paused > | 2190 | t5: PAUSED(S,3) | | 2191 |------------------>| | 2192 | | t6: PAUSED(S,3) | 2193 | |------------------>| 2194 : : : 2195 | | t7: RESUME(S,3) | 2196 | |<------------------| 2197 | t8: RESUME(S,3) | | 2198 |<------------------| | 2199 | t9: RTP (S) | | 2200 |------------------>| | 2201 | | t10: RTP (S) | 2202 | |------------------>| 2203 : : : 2205 Figure 18: Pause and Resume Operation Between Two Participants Using 2206 a Translator 2208 Figure 18 describes how a Translator can help the receiver in pausing 2209 and resuming the sender. The sender S sends RTP data to the receiver 2210 R through Translator, which just forwards the data without modifying 2211 the SSRCs. The receiver sends a PAUSE request to the sender, which 2212 in this example knows that there may be more receivers of the stream 2213 and waits a non-zero hold-off time to see if there is any other 2214 receiver that wants to receive the data, does not receive any 2215 disapproving RESUME, hence pauses itself and replies with PAUSED. 2216 Similarly the receiver resumes the sender by sending RESUME request 2217 through Translator. Since this describes only a single pause 2218 operation for a single media sender, all messages uses a single 2219 PauseID, in this example 3. 2221 +-----+ +-----+ +-----+ +-----+ 2222 | S | | T | | R1 | | R2 | 2223 +-----+ +-----| +-----+ +-----+ 2224 : t1:RTP(S) : : : 2225 |----------------->| | | 2226 | | t2:RTP(S) | | 2227 | |----------------->------------------>| 2228 | | t3:PAUSE(S,7) | | 2229 | |<-----------------| | 2230 | t4:PAUSE(S,7) | | | 2231 |<-----------------|------------------------------------>| 2232 | | | t5:RESUME(S,7) | 2233 | |<------------------------------------| 2234 | t6:RESUME(S,7) | | | 2235 |<-----------------| | | 2236 | | | 2237 | | | t7: PAUSE(S,8) | 2238 | |<------------------------------------| 2239 | t8:PAUSE(S,8) | | | 2240 |<-----------------| | | 2241 : : : : 2242 | < Pauses RTP Packet Stream > | | 2243 | t9:PAUSED(S,8) | | | 2244 |----------------->| | | 2245 | | t10:PAUSED(S,8) | | 2246 | |----------------->------------------>| 2247 : : : : 2248 | | t11:RESUME(S,8) | | 2249 | |<-----------------| | 2250 | t12:RESUME(S,8) | | | 2251 |<-----------------| | | 2252 | t13:RTP(S) | | | 2253 |----------------->| | | 2254 | | t14:RTP(S) | | 2255 | |----------------->------------------>| 2256 : : : : 2258 Figure 19: Pause and Resume Operation Between One Sender and Two 2259 Receivers Through Translator 2261 Figure 19 explains the pause and resume operations when a transport 2262 Translator is involved between a sender and two receivers in an RTP 2263 session. Each message exchange is represented by the time it 2264 happens. At time t1, Sender (S) starts sending media to the 2265 Translator, which is forwarded to R1 and R2 through the Translator, 2266 T. R1 and R2 receives RTP data from Translator at t2. At this point, 2267 both R1 and R2 will send RTCP Receiver Reports to S informing that 2268 they receive S's media stream. 2270 After some time (at t3), R1 chooses to pause the stream. On 2271 receiving the PAUSE request from R1 at t4, S knows that there are at 2272 least one receiver that may still want to receive the data and uses a 2273 non-zero hold-off period to wait for possible RESUME messages. R2 2274 did also receive the PAUSE request at time t4 and since it still 2275 wants to receive the stream, it sends a RESUME for it at time t5, 2276 which is forwarded to the sender S by the translator T. The sender S 2277 sees the RESUME at time t6 and continues to send data to T which 2278 forwards to both R1 and R2. At t7, the receiver R2 chooses to pause 2279 the stream by sending a PAUSE request with an updated PauseID. The 2280 sender S still knows that there are more than one receiver (R1 and 2281 R2) that may want the stream and again waits a non-zero hold-off 2282 time, after which and not having received any disapproving RESUME, it 2283 concludes that the stream must be paused. S now stops sending the 2284 stream and replies with PAUSED to R1 and R2. When any of the 2285 receivers (R1 or R2) chooses to resume the stream from S, in this 2286 example R1, it sends a RESUME request to the sender. The RTP sender 2287 immediately resumes the stream. 2289 Consider also an RTP session which includes one or more receivers, 2290 paused sender(s), and a Translator. Further assume that a new 2291 participant joins the session, which is not aware of the paused 2292 sender(s). On receiving knowledge about the newly joined 2293 participant, e.g. any RTP traffic or RTCP report (i.e. either SR or 2294 RR) from the newly joined participant, the paused sender(s) 2295 immediately sends PAUSED indications for the paused streams since 2296 there is now a receiver in the session that did not pause the 2297 sender(s) and may want to receive the streams. Having this 2298 information, the newly joined participant has the same possibility as 2299 any other participant to resume the paused streams. 2301 12. IANA Considerations 2303 As outlined in Section 8, this specification requests IANA to 2304 allocate 2306 1. The FMT number TBA1 to be allocated to the PAUSE and RESUME 2307 functionality from this specification. 2309 2. The 'pause' and 'paused' tags to be used with ccm under rtcp-fb 2310 AVPF attribute in SDP. 2312 3. The 'nowait' parameter to be used with the 'pause' and 'paused' 2313 tags in SDP. 2315 4. A registry listing registered values for 'pause' Types. 2317 5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the 2318 pause Type registry. 2320 13. Security Considerations 2322 This document extends the CCM [RFC5104] and defines new messages, 2323 i.e. PAUSE and RESUME. The exchange of these new messages MAY have 2324 some security implications, which need to be addressed by the user. 2325 Following are some important implications, 2327 1. Identity spoofing - An attacker can spoof him/herself as an 2328 authenticated user and can falsely pause or resume any source 2329 transmission. In order to prevent this type of attack, a strong 2330 authentication and integrity protection mechanism is needed. 2332 2. Denial of Service (DoS) - An attacker can falsely pause all 2333 source streams which MAY result in Denial of Service (DoS). An 2334 Authentication protocol may prevent this attack. 2336 3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP 2337 source is prone to a Man-in-Middle attack. Public key 2338 authentication may be used to prevent MiMT. 2340 14. Contributors 2342 Daniel Groendal contributed in the creation and writing of earlier 2343 versions of this specification. 2345 15. Acknowledgements 2347 Daniel Grondal made valuable contributions during the initial 2348 versions of this draft. 2350 16. References 2352 16.1. Normative References 2354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2355 Requirement Levels", BCP 14, RFC 2119, March 1997. 2357 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2358 Jacobson, "RTP: A Transport Protocol for Real-Time 2359 Applications", STD 64, RFC 3550, July 2003. 2361 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2362 "Extended RTP Profile for Real-time Transport Control 2363 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2364 2006. 2366 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 2367 "Codec Control Messages in the RTP Audio-Visual Profile 2368 with Feedback (AVPF)", RFC 5104, February 2008. 2370 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2371 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2373 16.2. Informative References 2375 [I-D.ietf-avtcore-rtp-topologies-update] 2376 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 2377 ietf-avtcore-rtp-topologies-update-01 (work in progress), 2378 October 2013. 2380 [I-D.ietf-avtext-rtp-grouping-taxonomy] 2381 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 2382 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 2383 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 2384 rtp-grouping-taxonomy-00 (work in progress), November 2385 2013. 2387 [I-D.ietf-rtcweb-use-cases-and-requirements] 2388 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 2389 Time Communication Use-cases and Requirements", draft- 2390 ietf-rtcweb-use-cases-and-requirements-14 (work in 2391 progress), February 2014. 2393 [I-D.lennox-mmusic-sdp-source-selection] 2394 Lennox, J. and H. Schulzrinne, "Mechanisms for Media 2395 Source Selection in the Session Description Protocol 2396 (SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work 2397 in progress), October 2012. 2399 [I-D.westerlund-avtcore-rtp-simulcast] 2400 Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP 2401 Sessions", draft-westerlund-avtcore-rtp-simulcast-03 (work 2402 in progress), October 2013. 2404 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 2405 Streaming Protocol (RTSP)", RFC 2326, April 1998. 2407 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2408 Announcement Protocol", RFC 2974, October 2000. 2410 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2411 A., Peterson, J., Sparks, R., Handley, M., and E. 2412 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2413 June 2002. 2415 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2416 with Session Description Protocol (SDP)", RFC 3264, June 2417 2002. 2419 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 2420 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 2421 3556, July 2003. 2423 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2424 Description Protocol", RFC 4566, July 2006. 2426 [RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, 2427 "Applying Signaling Compression (SigComp) to the Session 2428 Initiation Protocol (SIP)", RFC 5049, December 2007. 2430 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 2431 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 2432 UDP-Lite", RFC 5225, April 2008. 2434 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2435 Media Attributes in the Session Description Protocol 2436 (SDP)", RFC 5576, June 2009. 2438 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 2439 Initiated Connections in the Session Initiation Protocol 2440 (SIP)", RFC 5626, October 2009. 2442 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 2443 "RTP Payload Format for Scalable Video Coding", RFC 6190, 2444 May 2011. 2446 [TS25.308] 2447 3GPP, "High Speed Downlink Packet Access (HSDPA); Overall 2448 description; Stage 2", 3GPP TS 25.308 10.6.0, December 2449 2011, . 2451 [TS26.114] 2452 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 2453 telephony; Media handling and interaction", 3GPP TS 26.114 2454 10.7.0, June 2013, 2455 . 2457 [TS36.201] 2458 3GPP, "Evolved Universal Terrestrial Radio Access 2459 (E-UTRA); LTE physical layer; General description", 3GPP 2460 TS 36.201 10.0.0, December 2010, 2461 . 2463 Authors' Addresses 2465 Azam Akram 2466 Ericsson 2467 Farogatan 6 2468 SE - 164 80 Kista 2469 Sweden 2471 Phone: +46107142658 2472 Fax: +46107175550 2473 Email: muhammad.azam.akram@ericsson.com 2474 URI: www.ericsson.com 2476 Bo Burman 2477 Ericsson 2478 Farogatan 6 2479 SE - 164 80 Kista 2480 Sweden 2482 Phone: +46107141311 2483 Fax: +46107175550 2484 Email: bo.burman@ericsson.com 2485 URI: www.ericsson.com 2487 Roni Even 2488 Huawei Technologies 2489 Tel Aviv 2490 Israel 2492 Email: roni.even@mail01.huawei.com 2494 Magnus Westerlund 2495 Ericsson 2496 Farogatan 6 2497 SE- Kista 164 80 2498 Sweden 2500 Phone: +46107148287 2501 Email: magnus.westerlund@ericsson.com