draft-ietf-avtext-rtp-stream-pause-10.txt   rfc7728.txt 
Network Working Group B. Burman Internet Engineering Task Force (IETF) B. Burman
Internet-Draft A. Akram Request for Comments: 7728 A. Akram
Updates: 5104 (if approved) Ericsson Updates: 5104 Ericsson
Intended status: Standards Track R. Even Category: Standards Track R. Even
Expires: March 14, 2016 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
September 11, 2015 February 2016
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-10
Abstract Abstract
With the increased popularity of real-time multimedia applications, With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback resume incoming data from a sender by sending real-time feedback
messages when using Real-time Transport Protocol (RTP) for real time messages when using the Real-time Transport Protocol (RTP) for real-
data transport. This document extends the Codec Control Messages time data transport. This document extends the Codec Control Message
(CCM) RTP Control Protocol (RTCP) feedback package by explicitly (CCM) RTP Control Protocol (RTCP) feedback package by explicitly
allowing and describing specific use of existing CCM messages and allowing and describing specific use of existing CCMs and adding a
adding a group of new real-time feedback messages used to pause and group of new real-time feedback messages used to pause and resume RTP
resume RTP data streams. This document updates RFC 5104. data streams. This document updates RFC 5104.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 14, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7728.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 9
3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9 3.3. RTP Mixer to Media Sender in Point to Multipoint . . . . 10
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 11
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 3.5. Media Receiver to Media Sender across RTP Mixer . . . . . 11
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11 4.1. Real-Time Nature . . . . . . . . . . . . . . . . . . . . 12
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 12
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 13
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 14
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 14
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 14
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 16
5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 16 5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 17
5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 17 5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 18
5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 18 5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 19
5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19 5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 20
6. Participant States . . . . . . . . . . . . . . . . . . . . . 20 6. Participant States . . . . . . . . . . . . . . . . . . . . . 22
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 22
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 23
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 22 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 24
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 23 6.3.2. SSRC Time-Out . . . . . . . . . . . . . . . . . . . . 24
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 23 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 24
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 24 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 26
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 27 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 31 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 32
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36 9.1. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 37
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 39
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 40
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54
A.1. Modifications Between Version -09 and -10 . . . . . . . . 54
A.2. Modifications Between Version -08 and -09 . . . . . . . . 54
A.3. Modifications Between Version -07 and -08 . . . . . . . . 55
A.4. Modifications Between Version -06 and -07 . . . . . . . . 56
A.5. Modifications Between Version -05 and -06 . . . . . . . . 57
A.6. Modifications Between Version -04 and -05 . . . . . . . . 58
A.7. Modifications Between Version -03 and -04 . . . . . . . . 58
A.8. Modifications Between Version -02 and -03 . . . . . . . . 58
A.9. Modifications Between Version -01 and -02 . . . . . . . . 59
A.10. Modifications Between Version -00 and -01 . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 40
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 41
10.3. Point to Multipoint Using Mixer . . . . . . . . . . . . 45
10.4. Point to Multipoint Using Translator . . . . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
13.1. Normative References . . . . . . . . . . . . . . . . . . 52
13.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
As real-time communication attracts more people, more applications As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example. are created; multimedia conversation applications is one example.
Multimedia conversation further exists in many forms, for example, Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers. controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its Multimedia conferencing may involve many participants; each has its
own preferences for the communication session, not only at the start own preferences for the communication session, not only at the start
but also during the session. This document describes several but also during the session. This document describes several
scenarios in multimedia communication where a conferencing node or scenarios in multimedia communication where a conferencing node or
participant chooses to temporarily pause an incoming RTP [RFC3550] participant chooses to temporarily pause an incoming RTP [RFC3550]
stream and later resume it when needed. The receiver does not need stream and later resume it when needed. The receiver does not need
to terminate or inactivate the RTP session and start all over again to terminate or inactivate the RTP session and start all over again
by negotiating the session parameters, for example using SIP by negotiating the session parameters, for example, using SIP
[RFC3261] with SDP [RFC4566] Offer/Answer [RFC3264]. [RFC3261] with the Session Description Protocol (SDP) [RFC4566]
offer/answer [RFC3264].
Centralized nodes, like RTP Mixers or Multipoint Control Units (MCU), Centralized nodes, like RTP Mixers or Multipoint Control Units (MCUs)
which either use logic based on voice activity, other measurements, that use either logic based on voice activity, other measurements, or
or user input could reduce the resources consumed in both the sender user input could reduce the resources consumed in both the sender and
and the network by temporarily pausing the RTP streams that aren't the network by temporarily pausing the RTP streams that aren't
required by the RTP Mixer. If the number of conference participants required by the RTP Mixer. If the number of conference participants
are greater than what the conference logic has chosen to present are greater than what the conference logic has chosen to present
simultaneously to receiving participants, some participant RTP simultaneously to receiving participants, some participant RTP
streams sent to the RTP Mixer may not need to be forwarded to any streams sent to the RTP Mixer may not need to be forwarded to any
other participant. Those RTP streams could then be temporarily other participant. Those RTP streams could then be temporarily
paused. This becomes especially useful when the media sources are paused. This becomes especially useful when the media sources are
provided in multiple encoding versions (Simulcast) provided in multiple encoding versions (Simulcast) [SDP-SIMULCAST] or
[I-D.ietf-mmusic-sdp-simulcast] or with Multi-Session Transmission with Multi-Session Transmission (MST) of scalable encoding such as
(MST) of scalable encoding such as SVC [RFC6190]. There may be some Scalable Video Coding (SVC) [RFC6190]. There may be some of the
of the defined encodings or combination of scalable layers that are defined encodings or a combination of scalable layers that are not
not used or cannot be used all of the time. As an example, a used or cannot be used all of the time. As an example, a centralized
centralized node may choose to pause such unused RTP streams without node may choose to pause such unused RTP streams without being
being explicitly requested to do so, maybe due to temporarily limited explicitly requested to do so, maybe due to temporarily limited
network or processing resources. It may then also send an explicit network or processing resources. It may then also send an explicit
indication that the streams are paused. indication that the streams are paused.
As the set of RTP streams required at any given point in time is As the set of RTP streams required at any given point in time is
highly dynamic in such scenarios, using the out-of-band signaling highly dynamic in such scenarios, using the out-of-band signaling
channel for pausing, and even more importantly resuming, an RTP channel for pausing, and even more importantly resuming, an RTP
stream is difficult due to the performance requirements. Instead, stream is difficult due to the performance requirements. Instead,
the pause and resume signaling should be in the media plane and go the pause and resume signaling should be in the media plane and go
directly between the affected nodes. When using RTP [RFC3550] for directly between the affected nodes. When using RTP [RFC3550] for
media transport, using the Extended RTP Profile for Real-time media transport, using "Extended RTP Profile for Real-time Transport
Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] appears
appears appropriate. No currently existing RTCP feedback message appropriate. No currently existing RTCP feedback message explicitly
explicitly supports pausing and resuming an incoming RTP stream. As supports pausing and resuming an incoming RTP stream. As this
this affects the generation of packets and may even allow the affects the generation of packets and may even allow the encoding
encoding process to be paused, the functionality appears to match process to be paused, the functionality appears to match Codec
Codec Control Messages in the RTP Audio-Visual Profile with Feedback Control Messages (CCMs) in the RTP Audio-Visual Profile with Feedback
(AVPF) [RFC5104]. This document defines the solution as a Codec (AVPF) [RFC5104]. This document defines the solution as a CCM
Control Message (CCM) extension. extension.
The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is
used by video conferencing systems for flow control. It is desirable used by video conferencing systems for flow control. It is desirable
to be able to use that method with a bitrate value of zero for pause, to be able to use that method with a bitrate value of zero for pause,
whenever possible. This specification updates RFC 5104 to add the whenever possible. This specification updates RFC 5104 by adding the
new Pause and Resume semantics to the TMMBR/TMMBN messages. new pause and resume semantics to the TMMBR and Temporary Maximum
Media Bitrate Notification (TMMBN) messages.
2. Definitions 2. Definitions
2.1. Abbreviations 2.1. Abbreviations
AVPF: Audio-Visual Profile with Feedback (RFC 4585) AVPF: Audio-Visual Profile with Feedback (RFC 4585)
CCM: Codec Control Messages (RFC 5104)
CNAME: Canonical Name (RTCP SDES) CCM: Codec Control Message (RFC 5104)
CSRC: Contributing Source (RTP) CNAME: Canonical Name (RTCP Source Description)
FCI: Feedback Control Information (AVPF) CSRC: Contributing Source (RTP)
FIR: Full Intra Refresh (CCM) FCI: Feedback Control Information (AVPF)
FMT: Feedback Message Type (AVPF) FIR: Full Intra Refresh (CCM)
MCU: Multipoint Control Unit FMT: Feedback Message Type (AVPF)
MCU: Multipoint Control Unit
MTU: Maximum Transfer Unit MTU: Maximum Transfer Unit
PT: Payload Type (RTP) PT: Payload Type (RTP)
RTP: Real-time Transport Protocol (RFC 3550) RTP: Real-time Transport Protocol (RFC 3550)
RTCP: RTP Control Protocol (RFC 3550) RTCP: RTP Control Protocol (RFC 3550)
RTCP RR: RTCP Receiver Report RTCP RR: RTCP Receiver Report
RTCP SR: RTCP Sender Report RTCP SR: RTCP Sender Report
SDP: Session Description Protocol (RFC 4566) SDP: Session Description Protocol (RFC 4566)
SIP: Session Initiation Protocol (RFC 3261)
SSRC: Synchronization Source (RTP) SIP: Session Initiation Protocol (RFC 3261)
SVC: Scalable Video Coding SSRC: Synchronization Source (RTP)
TMMBR: Temporary Maximum Media Bitrate Request (CCM) SVC: Scalable Video Coding
TMMBN: Temporary Maximum Media Bitrate Notification (CCM) TMMBR: Temporary Maximum Media Bitrate Request (CCM)
UA: User Agent (SIP) TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
UDP: User Datagram Protocol (RFC 768) UA: User Agent (SIP)
UDP: User Datagram Protocol (RFC 768)
2.2. Terminology 2.2. Terminology
In addition to the following, the definitions from RTP [RFC3550], In addition to the following, the definitions from RTP [RFC3550],
AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy [RFC7656] also apply
[I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document. in this document.
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback Feedback Messages: CCM [RFC5104] categorized different RTCP feedback
messages into four types, Request, Command, Indication and messages into four types: Request, Command, Indication, and
Notification. This document places the PAUSE and RESUME messages Notification. This document places the PAUSE and RESUME messages
into Request category, PAUSED as Indication and REFUSED as into the Request category, PAUSED as an Indication, and REFUSED as
Notification. a Notification.
PAUSE: Request from an RTP stream receiver to pause a stream PAUSE: Request from an RTP stream receiver to pause a stream
RESUME: Request from an RTP stream receiver to resume a paused RESUME: Request from an RTP stream receiver to resume a paused
stream stream
PAUSED: Indication from an RTP stream sender that a stream is PAUSED: Indication from an RTP stream sender that a stream is
paused paused
REFUSED: Notification from an RTP stream sender that a PAUSE or REFUSED: Notification from an RTP stream sender that a PAUSE or
RESUME request will not be honored RESUME request will not be honored
Mixer: The intermediate RTP node which receives an RTP stream from Mixer: The intermediate RTP node that receives an RTP stream from
different endpoints, combines them to make one RTP stream and different endpoints, combines them to make one RTP stream, and
forwards to destinations, in the sense described in Topo-Mixer of forwards them to destinations, in the sense described for Topo-
RTP Topologies [I-D.ietf-avtcore-rtp-topologies-update]. Mixer in "RTP Topologies" [RFC7667].
Participant: A member which is part of an RTP session, acting as Participant: A member that is part of an RTP session, acting as the
receiver, sender or both. receiver, sender, or both.
Paused sender: An RTP stream sender that has stopped its Paused sender: An RTP stream sender that has stopped its
transmission, i.e. no other participant receives its RTP transmission, i.e., no other participant receives its RTP
transmission, either based on having received a PAUSE request, transmission, based on having received either a PAUSE request,
defined in this specification, or based on a local decision. defined in this specification, or a local decision.
Pausing receiver: An RTP stream receiver which sends a PAUSE Pausing receiver: An RTP stream receiver that sends a PAUSE request,
request, defined in this specification, to other participant(s). defined in this specification, to another participant(s).
Stream: Used as a short term for RTP stream, unless otherwise noted. Stream: Used as a short term for RTP stream, unless otherwise noted.
Stream receiver: Short for RTP stream receiver; the RTP entity Stream receiver: Short for RTP stream receiver; the RTP entity
responsible for receiving an RTP stream, usually a Media responsible for receiving an RTP stream, usually a Media
Depacketizer. Depacketizer.
Stream sender: Short for RTP stream sender; the RTP entity Stream sender: Short for RTP stream sender; the RTP entity
responsible for creating an RTP stream, usually a Media responsible for creating an RTP stream, usually a Media
Packetizer. Packetizer.
skipping to change at page 7, line 32 skipping to change at page 8, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Use Cases 3. Use Cases
This section discusses the main use cases for RTP stream pause and This section discusses the main use cases for RTP stream pause and
resume. resume.
RTCWEB WG's use case and requirements document [RFC7478] defines the The RTCWEB WG's use case and requirements document [RFC7478] defines
following API requirements in Appendix A, used also by W3C WebRTC WG: the following API requirements in Appendix A, which is also used by
the W3C WebRTC WG:
A8 The Web API must provide means for the web application to mute/ A8 The web API must provide means for the web application to mute/
unmute a stream or stream component(s). When a stream is sent to unmute a stream or stream component(s). When a stream is sent to
a peer mute, status must be preserved in the stream received by a peer, mute status must be preserved in the stream received by
the peer. the peer.
A9 The Web API must provide means for the web application to cease A9 The web API must provide means for the web application to cease
the sending of a stream to a peer. the sending of a stream to a peer.
This document provides means to optimize transport usage by stop This document provides means to optimize transport usage by stopping
sending muted streams and start sending again when unmuting. It is the sending of muted streams and starting the sending of streams
here assumed that "mute" above can be taken to apply also to other again when unmuted. Here, it is assumed that "mute" above can be
media than audio. At the time of publication for this specification, taken to apply also to media other than audio. At the time of
RTCWEB did not specify any pause / resume functionality. publication for this specification, the RTCWEB WG did not specify any
pause/resume functionality.
3.1. Point to Point 3.1. Point to Point
This is the most basic use case with an RTP session containing two This is the most basic use case with an RTP session containing two
Endpoints. Each Endpoint sends one or more streams. endpoints. Each endpoint sends one or more streams.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Figure 1: Point to Point
The usage of RTP stream pause in this use case is to temporarily halt The usage of RTP stream pause in this use case is to temporarily halt
delivery of streams that the sender provides but the receiver does delivery of streams that the sender provides but the receiver does
not currently use. This can for example be due to minimized not currently use. This can, for example, be due to minimized
applications where the video stream is not actually shown on any applications where the video stream is not actually shown on any
display, and neither is it used in any other way, such as being display, or it is not used in any other way, such as being recorded.
recorded.
In this case, since there is only a single receiver of the stream, In this case, since there is only a single receiver of the stream,
pausing or resuming a stream does not impact anyone else than the pausing or resuming a stream does not impact anyone else other than
sender and the single receiver of that stream. the sender and the single receiver of that stream.
3.2. RTP Mixer to Media Sender 3.2. RTP Mixer to Media Sender
One of the most commonly used topologies in centralized conferencing One of the most commonly used topologies in centralized conferencing
is based on the RTP Mixer [I-D.ietf-avtcore-rtp-topologies-update]. is based on the RTP Mixer [RFC7667]. The main reason for this is
The main reason for this is that it provides a very consistent view that it provides a very consistent view of the RTP session towards
of the RTP session towards each participant. That is accomplished each participant. That is accomplished through the Mixer originating
through the Mixer originating its own streams, identified by distinct its own streams, identified by distinct SSRC values, and any RTP
SSRC values, and any RTP streams sent to the participants will be streams sent to the participants will be sent using those SSRC
sent using those SSRC values. If the Mixer wants to identify the values. If the Mixer wants to identify the underlying media sources
underlying media sources for its conceptual streams, it can identify for its conceptual streams, it can identify them using CSRC. The
them using CSRC. The stream the Mixer provides can be an actual mix stream the Mixer provides can be an actual mix of multiple media
of multiple media sources, but it might also be switching received sources, but it might also be switching received streams as described
streams as described in Sections 3.6-3.8 of in Sections 3.6 - 3.8 of "RTP Topologies" [RFC7667].
[I-D.ietf-avtcore-rtp-topologies-update].
+---+ +-----------+ +---+ +---+ +-----------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +-----------+ +---+ +---+ +-----------+ +---+
Figure 2: RTP Mixer in Unicast-only Figure 2: RTP Mixer in Unicast Only
Which streams from clients B, C and D that are delivered to a given Which streams from clients B, C, and D that are delivered to a given
receiver, A, can depend on several things. It can either be the RTP receiver, A, can depend on several things:
Mixer's own logic and measurements such as voice activity on the
incoming audio streams. It can be that the number of sent media o The RTP Mixer's own logic and measurements, such as voice activity
sources exceed what is reasonable to present simultaneously at any on the incoming audio streams.
given receiver. It can also be a human controlling the conference
that determines how the media should be mixed; this would be more o The number of sent media sources exceed what is reasonable to
common in lecture or similar applications where regular listeners may present simultaneously at any given receiver.
be prevented from breaking into the session unless approved by the
moderator. The streams may also be part of a Simulcast o A human controlling the conference that determines how the media
[I-D.ietf-mmusic-sdp-simulcast] or scalable encoded (for Multi- should be mixed. This would be more common in lecture or similar
Session Transmission) [RFC6190], thus providing multiple versions applications where regular listeners may be prevented from
that can be delivered by the RTP stream sender. These examples breaking into the session unless approved by the moderator.
indicate that there are numerous reasons why a particular stream
would not currently be in use, but must be available for use at very o The streams may also be part of a Simulcast [SDP-SIMULCAST] or
short notice if any dynamic event occurs that causes a different scalable encoded (for Multi-Session Transmission) [RFC6190], thus
stream selection to be done in the Mixer. providing multiple versions that can be delivered by the RTP
stream sender.
These examples indicate that there are numerous reasons why a
particular stream would not currently be in use but must be available
for use at very short notice if any dynamic event occurs that causes
a different stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could Because of this, it would be highly beneficial if the Mixer could
request the RTP stream sender to pause a particular stream. The request the RTP stream sender to pause a particular stream. The
Mixer also needs to be able to request the RTP stream sender to Mixer also needs to be able to request the RTP stream sender to
resume delivery with minimal delay. resume delivery with minimal delay.
In some cases, especially when the Mixer sends multiple RTP streams In some cases, especially when the Mixer sends multiple RTP streams
per receiving client, there may be situations that makes it desirable per receiving client, there may be situations that make it desirable
for the Mixer to pause some of its sent RTP streams, even without for the Mixer to pause some of its sent RTP streams, even without
being explicitly asked to do so by the receiving client. Such being explicitly asked to do so by the receiving client. Such
situations can for example be caused by a temporary lack of available situations can, for example, be caused by a temporary lack of
Mixer network or processing resources. An RTP stream receiver that available Mixer network or processing resources. An RTP stream
no longer receives an RTP stream could interpret this as an error receiver that no longer receives an RTP stream could interpret this
condition and try to take action to re-establish the RTP stream. as an error condition and try to take action to re-establish the RTP
Such action would likely be undesirable if the RTP stream was in fact stream. Such action would likely be undesirable if the RTP stream
deliberately paused by the Mixer. Undesirable RTP stream receiver was in fact deliberately paused by the Mixer. Undesirable RTP stream
actions could be avoided if the Mixer is able to explicitly indicate receiver actions could be avoided if the Mixer is able to explicitly
that an RTP stream is deliberately paused. indicate that an RTP stream is deliberately paused.
Just as for point-to-point (Section 3.1), there is only a single Just as for point to point (Section 3.1), there is only a single
receiver of the stream, the RTP Mixer, and pausing or resuming a receiver of the stream, the RTP Mixer, and pausing or resuming a
stream does not affect anyone else than the sender and single stream does not affect anyone else other than the sender and single
receiver of that stream. receiver of that stream.
3.3. RTP Mixer to Media Sender in Point-to-Multipoint 3.3. RTP Mixer to Media Sender in Point to Multipoint
This use case is similar to the previous section, however the RTP This use case is similar to the previous section; however, the RTP
Mixer is involved in three domains that need to be separated; the Mixer is involved in three domains that need to be separated: the
Multicast Network (including participants A and C), participant B, Multicast Network (including participants A and C), participant B,
and participant D. The difference from above is that A and C share a and participant D. The difference from above is that A and C share a
multicast domain, which is depicted below. multicast domain, which is depicted below.
+-----+ +-----+
+---+ / \ +-----------+ +---+ +---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B | | A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+ +---+ / Multi- \ | | +---+
+ Cast +->| Mixer | + cast +->| Mixer |
+---+ \ Network / | | +---+ +---+ \ Network / | | +---+
| C |<---\ / | |<---->| D | | C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+ +---+ \ / +-----------+ +---+
+-----+ +-----+
Figure 3: RTP Mixer in Point-to-Multipoint Figure 3: RTP Mixer in Point to Multipoint
If the RTP Mixer pauses a stream from A, it will not only pause the If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself, but will also stop the stream from arriving to stream towards itself but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should C, which C is heavily impacted by, might not approve of, and should
thus have a say on. thus have a say on.
If the Mixer resumes a paused stream from A, it will be resumed also If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested it can simply ignore towards C. In this case, if C is not interested, it can simply
the stream and is not impacted as much as above. ignore the stream and is not impacted as much as above.
In this use case there are several receivers of a stream and the In this use case, there are several receivers of a stream, and the
Mixer must take special care so as not to pause a stream that is Mixer must take special care so as not to pause a stream that is
still wanted by some receivers. still wanted by some receivers.
3.4. Media Receiver to RTP Mixer 3.4. Media Receiver to RTP Mixer
In this use case, the direction of the request to pause is the In this use case, the direction of the request to pause is the
opposite compared to the two previous use cases. An Endpoint in opposite compared to the two previous use cases. An endpoint in
Figure 2 could potentially request to pause the delivery of a given Figure 2 could potentially request to pause the delivery of a given
stream. Possible reasons include the ones in the point to point case stream. Possible reasons include those in the point-to-point case
(Section 3.1) above. (Section 3.1) above.
When the RTP Mixer is only connected to individual unicast paths, the When the RTP Mixer is only connected to individual unicast paths, the
use case and any considerations are identical to the point to point use case and any considerations are identical to the point-to-point
use case. use case.
However, when the Endpoint requesting stream pause is connected to However, when the endpoint requesting stream pause is connected to
the RTP Mixer through a multicast network, such as A or C in the RTP Mixer through a multicast network, such as A or C in
Figure 3, the use case instead becomes identical to the one in Figure 3, the use case instead becomes identical to the one in
Section 3.3, only with reverse direction of the streams and pause/ Section 3.3, only with reverse direction of the streams and pause/
resume requests. resume requests.
3.5. Media Receiver to Media Sender Across RTP Mixer 3.5. Media Receiver to Media Sender across RTP Mixer
An Endpoint, like A in Figure 2, could potentially request to pause An endpoint, like A in Figure 2, could potentially request to pause
the delivery of a given stream, like one of B's, over any of the the delivery of a given stream, like one of B's, over any of the
SSRCs used by the Mixer by sending a pause request for the CSRC SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the stream. However, the authors are of the opinion that identifying the stream. However, the authors are of the opinion that
this is not a suitable solution, for several reasons: this is not a suitable solution for several reasons:
1. The Mixer might not include CSRC in its stream indications. 1. The Mixer might not include CSRC in its stream indications.
2. An Endpoint cannot rely on the CSRC to correctly identify the 2. An endpoint cannot rely on the CSRC to correctly identify the
stream to be paused when the delivered media is some type of mix. stream to be paused when the delivered media is some type of mix.
A more elaborate stream identification solution is needed to A more elaborate stream identification solution is needed to
support this in the general case. support this in the general case.
3. The Endpoint cannot determine if a given stream is still needed 3. The endpoint cannot determine if a given stream is still needed
by the RTP Mixer to deliver to another session participant. by the RTP Mixer to deliver to another session participant.
Due to the above reasons, we exclude this use case from further Due to the above reasons, we exclude this use case from further
consideration. consideration.
4. Design Considerations 4. Design Considerations
This section describes the requirements that this specification needs This section describes the requirements that this specification needs
to meet. to meet.
4.1. Real-time Nature 4.1. Real-Time Nature
The first section (Section 1) of this specification describes some The first section (Section 1) of this specification describes some
possible reasons why a receiver may pause an RTP sender. Pausing and possible reasons why a receiver may pause an RTP sender. Pausing and
resuming is time-dependent, i.e. a receiver may choose to pause an resuming is time dependent, i.e., a receiver may choose to pause an
RTP stream for a certain duration, after which the receiver may want RTP stream for a certain duration, after which the receiver may want
the sender to resume. This time dependency means that the messages the sender to resume. This time dependency means that the messages
related to pause and resume must be transmitted to the sender in a related to pause and resume must be transmitted to the sender in a
timely fashion in order for them to be purposeful. The pause timely fashion in order for them to be purposeful. The pause
operation is arguably not as time critical as the resume operation, operation is arguably not as time critical as the resume operation,
since it mainly provides a reduction of resource usage. Timely since it mainly provides a reduction of resource usage. Timely
handling of the resume operation is however likely to directly impact handling of the resume operation is, however, likely to directly
the end-user's perceived quality experience, since it affects the impact the end-user's perceived quality experience, since it affects
availability of media that the user expects to receive more or less the availability of media that the user expects to receive more or
instantly. It may also be highly desirable for a receiver to quickly less instantly. It may also be highly desirable for a receiver to
learn that an RTP stream is intentionally paused on the RTP sender's quickly learn that an RTP stream is intentionally paused on the RTP
own behalf. sender's own behalf.
4.2. Message Direction 4.2. Message Direction
It is the responsibility of an RTP stream receiver that wants to It is the responsibility of an RTP stream receiver that wants to
pause or resume a stream from the sender(s) to transmit PAUSE and pause or resume a stream from the sender(s) to transmit PAUSE and
RESUME messages. An RTP stream sender that wants to pause itself can RESUME messages. An RTP stream sender that wants to pause itself can
often simply do it, but sometimes this will adversely affect the often simply do it, but sometimes this will adversely affect the
receiver and an explicit indication that the RTP stream is paused may receiver and an explicit indication that the RTP stream is paused may
then help. Any indication that an RTP stream is paused is the then help. Any indication that an RTP stream is paused is the
responsibility of the RTP stream sender and may in some cases not responsibility of the RTP stream sender and may in some cases not
even be needed by the stream receiver. even be needed by the stream receiver.
4.3. Apply to Individual Sources 4.3. Apply to Individual Sources
The PAUSE and RESUME messages apply to single RTP streams identified The PAUSE and RESUME messages apply to single RTP streams identified
by their SSRC, which means the receiver targets the sender's SSRC in by their SSRC, which means the receiver targets the sender's SSRC in
the PAUSE and RESUME requests. If a paused sender starts sending the PAUSE and RESUME requests. If a paused sender starts sending
with a new SSRC, the receivers will need to send a new PAUSE request with a new SSRC, the receivers will need to send a new PAUSE request
in order to pause it. PAUSED indications refer to a single one of in order to pause it. PAUSED indications refer to a single one of
the sender's own, paused SSRC. the sender's own paused SSRC.
4.4. Consensus 4.4. Consensus
An RTP stream sender should not pause an SSRC that some receiver An RTP stream sender should not pause an SSRC that some receiver
still wishes to receive. still wishes to receive.
The reason is that in RTP topologies where the stream is shared The reason is that in RTP topologies where the stream is shared
between multiple receivers, a single receiver on that shared network between multiple receivers, a single receiver on that shared network
must not single-handedly cause the stream to be paused without must not single-handedly cause the stream to be paused without
letting all other receivers to voice their opinions on whether or not letting all other receivers voice their opinions on whether or not
the stream should be paused. Such shared networks can for example be the stream should be paused. Such shared networks can, for example,
multicast, a mesh with a joint RTP session, or a transport Translator be multicast, a mesh with a joint RTP session, or a transport
based network. A consequence of this is that a newly joining Translator-based network. A consequence of this is that a newly
receiver firstly needs to learn the existence of paused streams, and joining receiver first needs to learn the existence of paused streams
secondly should be able to resume any paused stream. A newly joining and secondly should be able to resume any paused stream. A newly
receiver can for example be detected through an RTCP Receiver Report joining receiver can, for example, be detected through an RTCP
containing both a new SSRC and a CNAME that does not already occur in Receiver Report containing both a new SSRC and a CNAME that does not
the session. Any single receiver wanting to resume a stream should already occur in the session. Any single receiver wanting to resume
also cause it to be resumed. An important exception to this is when a stream should also cause it to be resumed. An important exception
the RTP stream sender is aware of conditions that makes it desirable to this is when the RTP stream sender is aware of conditions that
or even necessitates to pause the RTP stream on its own behalf, make it desirable or even necessary to pause the RTP stream on its
without being explicitly asked to do so. Such local consideration in own behalf, without being explicitly asked to do so. Such local
the RTP sender takes precedence over RTP receiver wishes to receive consideration in the RTP sender takes precedence over RTP receiver
the stream. wishes to receive the stream.
4.5. Message Acknowledgments 4.5. Message Acknowledgments
RTP and RTCP does not guarantee reliable data transmission. It uses RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower layer transport protocol can provide. whatever assurance the lower-layer transport protocol can provide.
However, this is commonly UDP that provides no reliability However, this is commonly UDP that provides no reliability
guarantees. Thus it is possible that a PAUSE and/or RESUME message guarantees. Thus, it is possible that a PAUSE and/or RESUME message
transmitted from an RTP Endpoint does not reach its destination, i.e. transmitted from an RTP endpoint does not reach its destination,
the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP i.e., the targeted RTP stream sender. When PAUSE or RESUME reaches
stream sender and are effective, i.e., an active RTP stream sender the RTP stream sender and is effective, i.e., an active RTP stream
pauses, or a resuming RTP stream sender have media data to transmit, sender pauses or a resuming RTP stream sender has media data to
it is immediately seen from the arrival or non-arrival of RTP packets transmit, it is immediately seen from the arrival or non-arrival of
for that RTP stream. Thus, no explicit acknowledgments are required RTP packets for that RTP stream. Thus, no explicit acknowledgments
in this case. are required in this case.
In some cases when a PAUSE or RESUME message reaches the RTP stream In some cases, when a PAUSE or RESUME message reaches the RTP stream
sender, it will not be able to pause or resume the stream due to some sender, it will not be able to pause or resume the stream due to some
local consideration, for example lack of data to transmit. In this local consideration, for example, lack of data to transmit. In this
error condition, a negative acknowledgment may be needed to avoid error condition, a negative acknowledgment may be needed to avoid
unnecessary retransmission of requests (Section 4.6). unnecessary retransmission of requests (Section 4.6).
4.6. Request Retransmission 4.6. Request Retransmission
When the stream is not affected as expected by a PAUSE or RESUME When the stream is not affected as expected by a PAUSE or RESUME
request, the request may have been lost and the sender of the request request, the request may have been lost and the sender of the request
will need to retransmit it. The retransmission should take the round will need to retransmit it. The retransmission should take the
trip time into account, and will also need to take the normal RTCP round-trip time into account, and will also need to take the normal
bandwidth and timing rules applicable to the RTP session into RTCP bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback. account, when scheduling retransmission of feedback.
When it comes to resume requests or unsolicited paused indications When it comes to resume requests or unsolicited paused indications
that are more time critical, the best performance may be achieved by that are more time critical, the best performance may be achieved by
repeating the message as often as possible until a sufficient number repeating the message as often as possible until a sufficient number
have been sent to reach a high probability of message delivery, or at have been sent to reach a high probability of message delivery or at
an explicit indication that the message was delivered. For resume an explicit indication that the message was delivered. For resume
requests, such explicit indication can be delivery of the RTP stream requests, such explicit indication can be delivery of the RTP stream
being requested to be resumed. being requested to be resumed.
4.7. Sequence Numbering 4.7. Sequence Numbering
A PAUSE request message will need to have a sequence number to A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps separate retransmissions from new requests. A retransmission keeps
the sequence number unchanged, while it is incremented every time a the sequence number unchanged, while it is incremented every time a
new PAUSE request is transmitted that is not a retransmission of a new PAUSE request is transmitted that is not a retransmission of a
previous request. previous request.
Since RESUME always takes precedence over PAUSE and are even allowed Since RESUME always takes precedence over PAUSE and is even allowed
to avoid pausing a stream, there is a need to keep strict ordering of to avoid pausing a stream, there is a need to keep strict ordering of
PAUSE and RESUME. Thus, RESUME needs to share sequence number space PAUSE and RESUME. Thus, RESUME needs to share sequence number space
with PAUSE and implicitly references which PAUSE it refers to. For with PAUSE and implicitly reference which PAUSE it refers to. For
the same reasons, the explicit PAUSED indication also needs to share the same reasons, the explicit PAUSED indication also needs to share
sequence number space with PAUSE and RESUME. sequence number space with PAUSE and RESUME.
4.8. Relation to Other Solutions 4.8. Relation to Other Solutions
A performance comparison between SIP/SDP and RTCP signaling A performance comparison between SIP/SDP and RTCP signaling
technologies was made and included in draft versions of this technologies was made and included in draft versions of this
specification. Using SIP and SDP to carry pause and resume specification. Using SIP and SDP to carry pause and resume
information means that it will need to traverse the entire signaling information means that they will need to traverse the entire
path to reach the signaling destination (either the remote Endpoint signaling path to reach the signaling destination (either the remote
or the entity controlling the RTP Mixer), across any signaling endpoint or the entity controlling the RTP Mixer) across any
proxies that potentially also has to process the SDP content to signaling proxies that potentially also have to process the SDP
determine if they are expected to act on it. The amount of bandwidth content to determine if they are expected to act on it. The amount
required for a SIP/SDP-based signaling solution is in the order of at of bandwidth required for a signaling solution based on SIP/SDP is in
least 10 times more than an RTCP-based solution. Especially for UA the order of at least 10 times more than an RTCP-based solution.
sitting on mobile wireless access, this will risk introducing delays Especially for a UA sitting on mobile wireless access, this will risk
that are too long (Section 4.1) to provide a good user experience, introducing delays that are too long (Section 4.1) to provide a good
and the bandwidth cost may also be considered infeasible compared to user experience, and the bandwidth cost may also be considered
an RTCP-based solution. RTCP data is sent through the media path, infeasible compared to an RTCP-based solution. RTCP data sent
which is likely shorter (contains fewer intermediate nodes) than the through the media path, which is likely shorter (contains fewer
signaling path, may anyway have to traverse a few intermediate nodes. intermediate nodes) than the signaling path, may have to traverse a
The amount of processing and buffering required in intermediate nodes few intermediate nodes anyway. The amount of processing and
to forward those RTCP messages is however believed to be buffering required in intermediate nodes to forward those RTCP
significantly less than for intermediate nodes in the signaling path. messages is, however, believed to be significantly less than for
Based on those considerations, RTCP is chosen as signaling protocol intermediate nodes in the signaling path. Based on those
for the pause and resume functionality. considerations, RTCP is chosen as the signaling protocol for the
pause and resume functionality.
5. Solution Overview 5. Solution Overview
The proposed solution implements PAUSE and RESUME functionality based The proposed solution implements pause and resume functionality based
on sending AVPF RTCP feedback messages from any RTP session on sending AVPF RTCP feedback messages from any RTP session
participant that wants to pause or resume a stream targeted at the participant that wants to pause or resume a stream targeted at the
stream sender, as identified by the sender SSRC. stream sender, as identified by the sender SSRC.
This solution re-uses CCM TMMBR and TMMBN [RFC5104] to the extent This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent
possible, and defines a small set of new RTCP feedback messages where possible and defines a small set of new RTCP feedback messages where
new semantics is needed. new semantics is needed.
A single Feedback message specification is used to implement the new A single feedback message specification is used to implement the new
messages. The message consists of a number of Feedback Control messages. The message consists of a number of Feedback Control
Information (FCI) blocks, where each block can be a PAUSE request, a Information (FCI) blocks, where each block can be a PAUSE request, a
RESUME request, PAUSED indication, a REFUSED notification, or an RESUME request, a PAUSED indication, a REFUSED notification, or an
extension to this specification. This structure allows a single extension to this specification. This structure allows a single
feedback message to handle pause functionality on a number of feedback message to handle pause functionality on a number of
streams. streams.
The PAUSED functionality is also defined in such a way that it can be The PAUSED functionality is also defined in such a way that it can be
used standalone by the RTP stream sender to indicate a local decision used as a standalone by the RTP stream sender to indicate a local
to pause, and inform any receiver of the fact that halting media decision to pause, and it can inform any receiver of the fact that
delivery is deliberate and which RTP packet was the last transmitted. halting media delivery is deliberate and which RTP packet was the
last transmitted.
Special considerations that apply when using TMMBR/TMMBN for pause Special considerations that apply when using TMMBR/TMMBN for pause
and resume purposes are described in Section 5.6. This specification and resume purposes are described in Section 5.6. This specification
applies to both the new messages defined in herein as well as their applies to both the new messages defined herein as well as their
TMMBR/TMMBN counterparts, except when explicitly stated otherwise. TMMBR/TMMBN counterparts, except when explicitly stated otherwise.
An obvious exception are any reference to the message parameters that An obvious exception is any reference to the message parameters that
are only available in the messages defined here. For example, any are only available in the messages defined here. For example, any
reference to PAUSE in the text below is equally applicable to TMMBR reference to PAUSE in the text below is equally applicable to
0, and any reference to PAUSED is equally applicable to TMMBN 0. TMMBR 0, and any reference to PAUSED is equally applicable to TMMBN
Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the 0. Therefore, and for brevity, TMMBR/TMMBN will not be mentioned in
text, unless there is specific reason to do so. the text, unless there is specific reason to do so.
This section is intended to be explanatory and therefore This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification. instead be found in other parts of this specification.
5.1. Expressing Capability 5.1. Expressing Capability
An Endpoint can use an extension to CCM SDP signaling to declare An endpoint can use an extension to CCM SDP signaling to declare
capability to understand the messages defined in this specification. capability to understand the messages defined in this specification.
Capability to understand only a subset of messages is possible, to Capability to understand only a subset of messages is possible, to
support partial implementation, which is specifically believed to be support partial implementation, which is specifically believed to be
feasible for the RTP Mixer to Media Sender use case (Section 3.2). feasible for the 'RTP Mixer to Media Sender' use case (Section 3.2).
In that use case, only the RTP Mixer has capability to request the In that use case, only the RTP Mixer has capability to request the
Media Sender to pause or resume. Consequently, in that same use case media sender to pause or resume. Consequently, in that same use
only the Media Sender has capability to pause and resume its sent case, only the media sender has capability to pause and resume its
streams based on requests from the RTP Mixer. Allowing for partial sent streams based on requests from the RTP Mixer. Allowing for
implementation of this specification is not believed to hamper partial implementation of this specification is not believed to
interoperability, as long as the subsets are well defined and hamper interoperability, as long as the subsets are well defined and
describe a consistent functionality, including a description of how a describe a consistent functionality, including a description of how a
more capable implementation must perform fallback. more capable implementation must perform fallback.
For the case when TMMBR/TMMBN are used for pause and resume purposes, For the case when TMMBR/TMMBN are used for pause and resume purposes,
it is possible to explicitly express joint support for TMMBR and it is possible to explicitly express joint support for TMMBR and
TMMBN, but not for TMMBN only. TMMBN, but not for TMMBN only.
5.2. PauseID 5.2. PauseID
All messages defined in this specification (Section 8) contain a All messages defined in this specification (Section 8) contain a
PauseID, satisfying the design consideration on sequence numbering PauseID, satisfying the design consideration on sequence numbering
(Section 4.7). This PauseID is scoped by and thus a property of the (Section 4.7). This PauseID is scoped by and thus a property of the
targeted RTP stream (SSRC), not only a sequence number for individual targeted RTP stream (SSRC) and is not only a sequence number for
messages. Instead, it numbers an entire "pause and resume operation" individual messages. Instead, it numbers an entire "pause and resume
for the RTP stream, typically keeping PauseID constant for multiple, operation" for the RTP stream, typically keeping PauseID constant for
related messages. The PauseID value used during such operation is multiple, related messages. The PauseID value used during such
called the current PauseID. A new "pause and resume operation" is operation is called the current PauseID. A new "pause and resume
defined to start when the RTP stream sender resumes the RTP stream operation" is defined to start when the RTP stream sender resumes the
after it was being paused. The current PauseID is then incremented RTP stream after it was being paused. The current PauseID is then
by one, in modulo arithmetic. In the subsequent descriptions below, incremented by one in modulo arithmetic. In the subsequent
it is sometimes necessary to refer to PauseID values that were descriptions below, it is sometimes necessary to refer to PauseID
already used as current PauseID, which is denoted as past PauseID. values that were already used as the current PauseID, which is
It should be noted that since PauseID uses modulo arithmetic, a past denoted as the past PauseID. It should be noted that since PauseID
PauseID may have a larger value than the current PauseID. Since uses modulo arithmetic, a past PauseID may have a larger value than
PauseID uses modulo arithmetic, it is also useful to define what the current PauseID. Since PauseID uses modulo arithmetic, it is
PauseID values that are considered "past", to clearly separate it also useful to define what PauseID values are considered "past" to
from what could be considered "future" PauseID values. Half of the clearly separate it from what could be considered "future" PauseID
entire PauseID value range is chosen to represent past PauseID, while values. Half of the entire PauseID value range is chosen to
a quarter of the PauseID value range is chosen to represent future represent a past PauseID, while a quarter of the PauseID value range
values. The remaining quarter of the PauseID value range is is chosen to represent future values. The remaining quarter of the
intentionally left undefined in that respect. PauseID value range is intentionally left undefined in that respect.
5.3. Requesting to Pause 5.3. Requesting to Pause
An RTP stream receiver can choose to send a PAUSE request at any An RTP stream receiver can choose to send a PAUSE request at any
time, subject to AVPF timing rules. time, subject to AVPF timing rules.
The PAUSE request contains the current PauseID (Section 5.2). The PAUSE request contains the current PauseID (Section 5.2).
When a non-paused RTP stream sender receives the PAUSE request, it When a non-paused RTP stream sender receives the PAUSE request, it
continues to send the RTP stream while waiting for some time to allow continues to send the RTP stream while waiting for some time to allow
other RTP stream receivers in the same RTP session that saw this other RTP stream receivers in the same RTP session that saw this
PAUSE request to disapprove by sending a RESUME (Section 5.5) for the PAUSE request to disapprove by sending a RESUME (Section 5.5) for the
same stream and with the same current PauseID as in the PAUSE being same stream and with the same current PauseID as in the PAUSE being
disapproved. If such disapproving RESUME arrives at the RTP stream disapproved. If such a disapproving RESUME arrives at the RTP stream
sender during the hold-off period before the stream is paused, the sender during the hold-off period before the stream is paused, the
pause is not performed. In point-to-point configurations, the hold- pause is not performed. In point-to-point configurations, the hold-
off period may be set to zero. Using a hold-off period of zero is off period may be set to zero. Using a hold-off period of zero is
also appropriate when using TMMBR 0 and in line with the semantics also appropriate when using TMMBR 0 and is in line with the semantics
for that message. for that message.
If the RTP stream sender receives further PAUSE requests with the If the RTP stream sender receives further PAUSE requests with the
current PauseID while waiting as described above, those additional current PauseID while waiting as described above, those additional
requests are ignored. requests are ignored.
If the PAUSE request is lost before it reaches the RTP stream sender, If the PAUSE request is lost before it reaches the RTP stream sender,
it will be discovered by the RTP stream receiver because it continues it will be discovered by the RTP stream receiver because it continues
to receive the RTP stream. It will also not see any PAUSED to receive the RTP stream. It will also not see any PAUSED
indication (Section 5.4) for the stream. The same condition can be indication (Section 5.4) for the stream. The same condition can be
caused by the RTP stream sender having received a disapproving RESUME caused by the RTP stream sender having received a disapproving RESUME
from a stream receiver A for a PAUSE request sent by a stream sender from stream receiver A for a PAUSE request sent by stream sender B,
B, but that the PAUSE sender (B) did not receive the RESUME (from A) except that the PAUSE sender (B) did not receive the RESUME (from A)
and may instead think that the PAUSE was lost. In both cases, a and may instead think that the PAUSE was lost. In both cases, a
PAUSE request can be re-transmitted using the same current PauseID. PAUSE request can be retransmitted using the same current PauseID.
If using TMMBR 0, the request MAY be re-transmitted when the If using TMMBR 0, the request MAY be retransmitted when the requester
requester fails to receive a TMMBN 0 confirmation. fails to receive a TMMBN 0 confirmation.
If the pending stream pause is aborted due to a disapproving RESUME, If the pending stream pause is aborted due to a disapproving RESUME,
the pause and resume operation for that PauseID is concluded, the the pause and resume operation for that PauseID is concluded, the
current PauseID is updated, and any new PAUSE must therefore use the current PauseID is updated, and any new PAUSE must therefore use the
new current PauseID to be effective. new current PauseID to be effective.
An RTP stream sender receiving a PAUSE not using the current PauseID An RTP stream sender receiving a PAUSE not using the current PauseID
informs the RTP stream receiver sending the ineffective PAUSE of this informs the RTP stream receiver sending the ineffective PAUSE of this
condition by sending a REFUSED notification that contains the current condition by sending a REFUSED notification that contains the current
PauseID value. PauseID value.
A situation where an ineffective PauseID is chosen can appear when a A situation where an ineffective PauseID is chosen can appear when a
new RTP stream receiver joins a session and wants to PAUSE a stream, new RTP stream receiver joins a session and wants to PAUSE a stream
but does not yet know the current PauseID to use. The REFUSED but does not yet know the current PauseID to use. The REFUSED
notification will then provide sufficient information to create a notification will then provide sufficient information to create a
valid PAUSE. The required extra signaling round-trip is not valid PAUSE. The required extra signaling round trip is not
considered harmful, since it is assumed that pausing a stream is not considered harmful, since it is assumed that pausing a stream is not
time-critical (Section 4.1). time critical (Section 4.1).
There may be local considerations making it impossible or infeasible There may be local considerations making it impossible or infeasible
to pause the stream, and the RTP stream sender can then respond with to pause the stream, and the RTP stream sender can then respond with
a REFUSED. In this case, if the used current PauseID would otherwise a REFUSED. In this case, if the used current PauseID would otherwise
have been effective, REFUSED contains the same current PauseID as in have been effective, REFUSED contains the same current PauseID as in
the PAUSE request. Note that when using TMMBR 0 as PAUSE, that the PAUSE request. Note that when using TMMBR 0 as PAUSE, that
request cannot be refused (TMMBN > 0) due to the existing restriction request cannot be refused (TMMBN > 0) due to the existing restriction
in section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current in Section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current
bounding set, and the fact that a TMMBR 0 will always be the most bounding set, and the fact that a TMMBR 0 will always be the most
restrictive point in any bounding set, regardless of bounding set restrictive point in any bounding set, regardless of the bounding set
overhead value. overhead value.
If the RTP stream sender receives several identical PAUSE for an RTP If the RTP stream sender receives several identical PAUSE requests
stream that was already at least once responded with REFUSED and the for an RTP stream that was already responded to at least once with
condition causing REFUSED remains, those additional REFUSED should be REFUSED and the condition causing REFUSED remains, those additional
sent with regular RTCP timing. A single REFUSED can respond to REFUSED notifications should be sent with regular RTCP timing. A
several identical PAUSE requests. single REFUSED can respond to several identical PAUSE requests.
5.4. Media Sender Pausing 5.4. Media Sender Pausing
An RTP stream sender can choose to pause the stream at any time. An RTP stream sender can choose to pause the stream at any time.
This can either be as a result of receiving a PAUSE, or be based on This can be either a result of receiving a PAUSE or based on some
some local sender consideration. When it does, it sends a PAUSED local sender consideration. When it does, it sends a PAUSED
indication, containing the current PauseID. Note that current indication, containing the current PauseID. Note that the current
PauseID in an unsolicited PAUSED (without having received a PAUSE), PauseID in an unsolicited PAUSED (without having received a PAUSE) is
is incremented compared to previously sent PAUSED. It also sends the incremented compared to a previously sent PAUSED. It also sends the
PAUSED indication in the next two regular RTCP reports, given that PAUSED indication in the next two regular RTCP reports, given that
the pause condition is then still effective. the pause condition is then still effective.
There is no reply to a PAUSED indication; it is simply an explicit There is no reply to a PAUSED indication; it is simply an explicit
indication of the fact that an RTP stream is paused. This can be indication of the fact that an RTP stream is paused. This can be
helpful for the RTP stream receiver, for example to quickly helpful for the RTP stream receiver, for example, to quickly
understand that transmission is deliberately and temporarily understand that transmission is deliberately and temporarily
suspended and no specific corrective action is needed. suspended and no specific corrective action is needed.
The RTP stream sender may want to apply some local consideration to The RTP stream sender may want to apply some local consideration to
exactly when the RTP stream is paused, for example completing some exactly when the RTP stream is paused, for example, completing some
media unit or a forward error correction block, before pausing the media unit or a forward error correction block, before pausing the
stream. stream.
The PAUSED indication also contains information about the RTP The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective. extended highest sequence number when the pause became effective.
This provides RTP stream receivers with firsthand information This provides RTP stream receivers with firsthand information that
allowing them to know whether they lost any packets just before the allows them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP stream paused or when the stream is resumed again. This allows RTP
stream receivers to quickly and safely take into account that the stream receivers to quickly and safely take into account that the
stream is paused, in for example retransmission or congestion control stream is paused in, for example, retransmission or congestion
algorithms. control algorithms.
If the RTP stream sender receives PAUSE requests with the current If the RTP stream sender receives PAUSE requests with the current
PauseID while the stream is already paused, those requests are PauseID while the stream is already paused, those requests are
ignored. ignored.
As long as the stream is being paused, the PAUSED indication MAY be As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP Sender Report (SR) or Receiver sent together with any regular RTCP Sender Report (SR) or Receiver
Report (RR). Including PAUSED in this way allows RTP stream Report (RR). Including PAUSED in this way allows RTP stream
receivers joining while the stream is paused to quickly know that receivers to join while the stream is paused and to quickly know that
there is a paused stream, what the last sent extended RTP sequence there is a paused stream, what the last sent extended RTP sequence
number was, and what the current PauseID is to be able to construct number is, and what the current PauseID is, which enables them to
valid PAUSE and RESUME requests at a later stage. construct valid PAUSE and RESUME requests at a later stage.
When the RTP stream sender learns that a new Endpoint has joined the When the RTP stream sender learns that a new endpoint has joined the
RTP session, for example by a new SSRC and a CNAME that was not RTP session, for example, by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in for all its paused streams at its earliest opportunity. In addition,
addition continue to include PAUSED indications in at least two it should continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
5.5. Requesting to Resume 5.5. Requesting to Resume
An RTP stream receiver can request the RTP stream sender to resume a An RTP stream receiver can request the RTP stream sender to resume a
stream with a RESUME request at any time, subject to AVPF timing stream with a RESUME request at any time, subject to AVPF timing
rules. The RTP stream receiver must include the current PauseID in rules. The RTP stream receiver must include the current PauseID in
the RESUME request for it to be effective. the RESUME request for it to be effective.
A pausing RTP stream sender that receives a RESUME including the A pausing RTP stream sender that receives a RESUME including the
current PauseID resumes the stream at the earliest opportunity. current PauseID resumes the stream at the earliest opportunity.
Receiving RESUME requests for a stream that is not paused does not Receiving RESUME requests for a stream that is not paused does not
require any action and can be ignored. require any action and can be ignored.
There may be local considerations at the RTP stream sender, for There may be local considerations at the RTP stream sender, for
example that the media device is not ready, making it temporarily example, that the media device is not ready, making it temporarily
impossible to resume the stream at that point in time, and the RTP impossible to resume the stream at that point in time, and the RTP
stream sender can then respond with a REFUSED containing the current stream sender can then respond with a REFUSED containing the current
PauseID. When receiving such REFUSED with a current PauseID PauseID. When receiving such REFUSED with a current PauseID
identical to the one in the sent RESUME, RTP stream receivers should identical to the one in the sent RESUME, RTP stream receivers should
avoid sending further RESUME requests for some reasonable amount of avoid sending further RESUME requests for some reasonable amount of
time, to allow the condition to clear. An RTP stream sender having time to allow the condition to clear. An RTP stream sender having
sent a REFUSED SHOULD resume the stream through local considerations sent a REFUSED SHOULD resume the stream through local considerations
(see below) when the condition that caused the REFUSED is no longer (see below) when the condition that caused the REFUSED is no longer
true. true.
If the RTP stream sender receives several identical RESUME for an RTP If the RTP stream sender receives several identical RESUME requests
stream that was already at least once responded with REFUSED and the for an RTP stream that was already at least once responded to with
condition causing REFUSED remains, those additional REFUSED should be REFUSED and the condition causing REFUSED remains, those additional
sent with regular RTCP timing. A single REFUSED can respond to REFUSED notifications should be sent with regular RTCP timing. A
several identical RESUME requests. single REFUSED can respond to several identical RESUME requests.
A pausing RTP stream sender can apply local considerations and can A pausing RTP stream sender can apply local considerations and can
resume a paused RTP stream at any time. If TMMBR 0 was used to pause resume a paused RTP stream at any time. If TMMBR 0 was used to pause
the RTP stream, resumption is prevented by protocol, even if the RTP the RTP stream, resumption is prevented by protocol, even if the RTP
sender would like to resume due to local considerations. If TMMBR/ sender would like to resume due to local considerations. If TMMBR/
TMMBN signaling is used, if the RTP stream is paused due to local TMMBN signaling is used, the RTP stream is paused due to local
considerations (Section 5.4), and the RTP stream sender thus owns the considerations (Section 5.4), and the RTP stream sender thus owns the
TMMBN bounding set, the RTP stream can be resumed due to local TMMBN bounding set, the RTP stream can be resumed due to local
considerations. considerations.
When resuming a paused stream, especially for media that makes use of When resuming a paused stream, especially for media that makes use of
temporal redundancy between samples such as video, it may not be temporal redundancy between samples such as video, it may not be
appropriate to use such temporal dependency in the encoding between appropriate to use such temporal dependency in the encoding between
samples taken before the pause and at the time instant the stream is samples taken before the pause and at the time instant the stream is
resumed. Should such temporal dependency between media samples resumed. Should such temporal dependency between media samples
before and after the media was paused be used by the RTP stream before and after the media was paused be used by the RTP stream
skipping to change at page 19, line 51 skipping to change at page 20, line 45
when resuming, and if the RTP stream receiver did not save any sample when resuming, and if the RTP stream receiver did not save any sample
from before the pause, the RTP stream receiver can use a FIR request from before the pause, the RTP stream receiver can use a FIR request
[RFC5104] to explicitly ask for a sample without temporal dependency [RFC5104] to explicitly ask for a sample without temporal dependency
(for video a so-called intra picture), even at the same time as (for video a so-called intra picture), even at the same time as
sending the RESUME. sending the RESUME.
5.6. TMMBR/TMMBN Considerations 5.6. TMMBR/TMMBN Considerations
As stated above, TMMBR/TMMBN may be used to provide pause and resume As stated above, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or point to point, TMMBR/TMMBN cannot safely be used for pause or
resume. This use is expected to be mainly for interworking with resume. This use is expected to be mainly for interworking with
implementations that don't support the messages defined in this implementations that don't support the messages defined in this
specification (Section 8), but make use of TMMBR/TMMBN to achieve a specification (Section 8) but make use of TMMBR/TMMBN to achieve a
similar effect. similar effect.
This is a brief summary of what functionality is provided when using This is a brief summary of what functionality is provided when using
TMMBR/TMMBN: TMMBR/TMMBN:
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
off period to wait for RESUME before pausing the RTP stream. off period to wait for RESUME before pausing the RTP stream.
TMMBR >0: Corresponds to RESUME when the RTP stream was previously TMMBR > 0: Corresponds to RESUME when the RTP stream was previously
paused with TMMBR 0. Since there is only a single RTP stream paused with TMMBR 0. Since there is only a single RTP stream
receiver, there is no need for the RTP stream sender to delay receiver, there is no need for the RTP stream sender to delay
resuming the stream until after sending TMMBN >0, or to apply the resuming the stream until after sending TMMBN > 0 or to apply the
hold-off period specified in [RFC5104] before increasing the hold-off period specified in [RFC5104] before increasing the
bitrate from zero. The bitrate value used when resuming after bitrate from zero. The bitrate value used when resuming after
pausing with TMMBR 0 is either according to known limitations, or pausing with TMMBR 0 is either according to known limitations or
based on starting a stream with the configured maximum for the based on starting a stream with the configured maximum for the
stream or session, for example given by b-parameter in SDP. stream or session, for example, given by "b=" line in SDP.
TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with
TMMBR 0, but may, just as PAUSED, also be used unsolicited. An TMMBR 0 but may, just as PAUSED, also be used unsolicited. An
unsolicited RTP stream pause based on local sender considerations unsolicited RTP stream pause based on local sender considerations
uses the RTP stream's own SSRC as TMMBR restriction owner in the uses the RTP stream's own SSRC as the TMMBR restriction owner in
TMMBN message bounding set. Also corresponds to a REFUSED the TMMBN message bounding set. It also corresponds to a REFUSED
notification when a stream is requested to be resumed with TMMBR notification when a stream is requested to be resumed with
>0, thus resulting in the stream sender becoming the owner of the TMMBR > 0, thus resulting in the stream sender becoming the owner
bounding set in the TMMBN message. of the bounding set in the TMMBN message.
TMMBN >0: Cannot be used as REFUSED notification when a stream is TMMBN > 0: Cannot be used as a REFUSED notification when a stream is
requested to be paused with TMMBR 0, for reasons stated in requested to be paused with TMMBR 0, for reasons stated in
Section 5.3. Section 5.3.
6. Participant States 6. Participant States
This document introduces three new states for a stream in an RTP This document introduces three new states for a stream in an RTP
sender, according to the figure and sub-sections below. Any sender, according to the figure and subsections below. Any
references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL references to PAUSE, PAUSED, RESUME, and REFUSED in this section
be taken to apply to the extent possible also when TMMBR/TMMBN are SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
used (Section 5.6) for this functionality. are used (Section 5.6) for this functionality.
+------------------------------------------------------+ +------------------------------------------------------+
| Received RESUME | | Received RESUME |
v | v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+ +---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused | | Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | | | |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+ +---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision | ^ | | PAUSE decision |
| | v | | | v |
| | PAUSE decision +---------+ PAUSE decision | | | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+ | +------------------>| Local |<--------------------+
+-------------------------| Paused | +-------------------------| Paused |
RESUME decision +---------+ RESUME decision +---------+
Figure 4: RTP Pause States in Sender Figure 4: RTP Pause States in Sender
6.1. Playing State 6.1. Playing State
This state is not new, but is the normal media sending state from This state is not new but is the normal media sending state from
[RFC3550]. When entering the state, the current PauseID MUST be [RFC3550]. When entering the state, the current PauseID MUST be
incremented by one in modulo arithmetic. The RTP sequence number for incremented by one in modulo arithmetic. The RTP sequence number for
the first packet sent after a pause SHALL be incremented by one the first packet sent after a pause SHALL be incremented by one
compared to the highest RTP sequence number sent before the pause. compared to the highest RTP sequence number sent before the pause.
The first RTP Time Stamp for the first packet sent after a pause The first RTP timestamp for the first packet sent after a pause
SHOULD be set according to capture times at the source, meaning the SHOULD be set according to capture times at the source, meaning the
RTP Time Stamp difference compared to before the pause reflects the RTP timestamp difference compared to before the pause reflects the
time the RTP stream was paused. time the RTP stream was paused.
6.2. Pausing State 6.2. Pausing State
In this state, the RTP stream sender has received at least one PAUSE In this state, the RTP stream sender has received at least one PAUSE
message for the stream in question. The RTP stream sender SHALL wait message for the stream in question. The RTP stream sender SHALL wait
during a hold-off period for the possible reception of RESUME during a hold-off period for the possible reception of RESUME
messages for the RTP stream being paused before actually pausing RTP messages for the RTP stream being paused before actually pausing RTP
stream transmission. The hold-off period to wait SHALL be long stream transmission. The hold-off period to wait SHALL be long
enough to allow another RTP stream receiver to respond to the PAUSE enough to allow another RTP stream receiver to respond to the PAUSE
with a RESUME, if it determines that it would not like to see the with a RESUME, if it determines that it would not like to see the
stream paused. This hold-off period is determined by the formula: stream paused. This hold-off period is determined by the formula:
2 * RTT + T_dither_max, 2 * RTT + T_dither_max,
where RTT is the longest round trip known to the RTP stream sender where RTT is the longest round trip known to the RTP stream sender
and T_dither_max is defined in section 3.4 of [RFC4585]. The hold- and T_dither_max is defined in Section 3.4 of [RFC4585]. The hold-
off period MAY be set to 0 by some signaling (Section 9) means when off period MAY be set to 0 by some signaling (Section 9) means when
it can be determined that there is only a single receiver, for it can be determined that there is only a single receiver, for
example in point-to-point or some unicast situations. example, in point to point or some unicast situations.
If the RTP stream sender has set the hold-off period to 0 and If the RTP stream sender has set the hold-off period to 0 and
receives information that it was an incorrect decision and that there receives information that it was an incorrect decision and that there
are in fact several receivers of the stream, it MUST change the hold- are in fact several receivers of the stream, it MUST change the hold-
off to instead be based on the above formula. off period to be based on the above formula instead.
An RTP stream sender SHOULD use the following criteria to determine An RTP stream sender SHOULD use the following criteria to determine
if there is only a single receiver, unless it has explicit and more if there is only a single receiver, unless it has explicit and more
reliable information: reliable information:
o Observing only a single CNAME across all received SSRCs (CNAMEs o Observing only a single CNAME across all received SSRCs (CNAMEs
for received CSRCs are insignificant), or for received CSRCs are insignificant), or
o If RTCP reporting groups o If RTCP reporting groups [MULTI-STREAM-OPT] is used, observing
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] is used, only a single, endpoint external RTCP reporting group.
observing only a single, endpoint external RTCP reporting group.
6.3. Paused State 6.3. Paused State
An RTP stream is in paused state when the sender pauses its An RTP stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the hold- transmission after receiving at least one PAUSE message and the hold-
off period has passed without receiving any RESUME message for that off period has passed without receiving any RESUME message for that
stream. Pausing transmission SHOULD only be done when reaching an stream. Pausing transmission SHOULD only be done when reaching an
appropriate place to pause in the stream, like a media boundary that appropriate place to pause in the stream, like a media boundary that
avoids a media receiver to trigger repair or concealment actions. avoids a media receiver to trigger repair or concealment actions.
When entering the state, the RTP stream sender SHALL send a PAUSED When entering the state, the RTP stream sender SHALL send a PAUSED
indication to all known RTP stream receivers, and SHALL also repeat indication to all known RTP stream receivers, and SHALL also repeat
PAUSED in the next two regular RTCP reports, as long as it is then PAUSED in the next two regular RTCP reports, as long as it is then
still in paused state. still in paused state.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
Following sub-sections discusses some potential issues when an RTP The following subsections discuss some potential issues when an RTP
sender goes into paused state. These conditions are also valid if an sender goes into paused state. These conditions are also valid if an
RTP Translator is used in the communication. When an RTP Mixer RTP Translator is used in the communication. When an RTP Mixer
implementing this specification is involved between the participants implementing this specification is involved between the participants
(which forwards the stream by marking the RTP data with its own (which forwards the stream by marking the RTP data with its own
SSRC), it SHALL be a responsibility of the Mixer to control sending SSRC), it SHALL be a responsibility of the Mixer to control sending
PAUSE and RESUME requests to the sender. The below conditions also PAUSE and RESUME requests to the sender. The below conditions also
apply to the sender and receiver parts of the RTP Mixer, apply to the sender and receiver parts of the RTP Mixer,
respectively. respectively.
6.3.1. RTCP BYE Message 6.3.1. RTCP BYE Message
When a participant leaves the RTP session, it sends an RTCP BYE When a participant leaves the RTP session, it sends an RTCP BYE
message. In addition to the semantics described in section 6.3.4 and message. In addition to the semantics described in Sections 6.3.4
6.3.7 of RTP [RFC3550], following two conditions MUST also be and 6.3.7 of RTP [RFC3550], the following two conditions MUST also be
considered when an RTP participant sends an RTCP BYE message, considered when an RTP participant sends an RTCP BYE message:
o If a paused sender sends an RTCP BYE message, receivers observing o If a paused sender sends an RTCP BYE message, receivers observing
this SHALL NOT send further PAUSE or RESUME requests to it. this SHALL NOT send further PAUSE or RESUME requests to it.
o Since a sender pauses its transmission on receiving the PAUSE o Since a sender pauses its transmission on receiving the PAUSE
requests from any receiver in a session, the sender MUST keep requests from any receiver in a session, the sender MUST keep
record of which receiver that caused the RTP stream to pause. If record of which receiver caused the RTP stream to pause. If that
that receiver sends an RTCP BYE message observed by the sender, receiver sends an RTCP BYE message observed by the sender, the
the sender SHALL resume the RTP stream. No receivers that were in sender SHALL resume the RTP stream. No receivers that were in the
the RTP session when the stream was paused objected that the RTP session when the stream was paused objected that the stream
stream was paused, but if there were so far undetected receivers was paused, but if there were so far undetected receivers added to
added to the session during pause, those may not have learned the session during pause, those may not have learned about the
about the existence of the paused stream, either because there was existence of the paused stream because either there was no PAUSED
no PAUSED sent for the paused RTP stream or those receivers did sent for the paused RTP stream or those receivers did not support
not support PAUSED. Resuming the stream when the pausing party PAUSED. Resuming the stream when the pausing party leaves the RTP
leaves the RTP session allows those potentially undetected session allows those potentially undetected receivers to learn
receivers to learn that the stream exists. that the stream exists.
6.3.2. SSRC Time-out 6.3.2. SSRC Time-Out
Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP
participant. Every RTP participant maintains a sender and receiver participant. Every RTP participant maintains a sender and receiver
list in a session. If a participant does not get any RTP or RTCP list in a session. If a participant does not get any RTP or RTCP
packets from some other participant for the last five RTCP reporting packets from some other participant for the last five RTCP reporting
intervals it removes that participant from the receiver list. Any intervals, it removes that participant from the receiver list. Any
streams that were paused by that removed participant SSRC SHALL be streams that were paused by that removed participant SSRC SHALL be
resumed. resumed.
6.4. Local Paused State 6.4. Local Paused State
This state can be entered at any time, based on local decision from This state can be entered at any time, based on local decision from
the RTP stream sender. Pausing transmission SHOULD only be done when the RTP stream sender. Pausing transmission SHOULD only be done when
reaching an appropriate place to pause in the stream, like a media reaching an appropriate place to pause in the stream, like a media
boundary that avoids a media receiver to trigger repair or boundary that avoids a media receiver to trigger repair or
concealment actions. concealment actions.
As with Paused State (Section 6.3), the RTP stream sender SHALL send As with paused state (Section 6.3), the RTP stream sender SHALL send
a PAUSED indication to all known RTP stream receivers, when entering a PAUSED indication to all known RTP stream receivers, when entering
the state, unless the stream was already in paused state the state, unless the stream was already in paused state
(Section 6.3). Such PAUSED indication SHALL be repeated a sufficient (Section 6.3). Such PAUSED indication SHALL be repeated a sufficient
number of times to reach a high probability that the message is number of times to reach a high probability that the message is
correctly delivered, stopping such repetition whenever leaving the correctly delivered, stopping such repetition whenever leaving the
state. state.
When using TMMBN 0 as PAUSED indication and when already in paused When using TMMBN 0 as a PAUSED indication and when already in paused
state, the actions when entering local paused state depends on the state, the actions when entering local paused state depends on the
bounding set overhead value in the received TMMBR 0 that caused the bounding set overhead value in the received TMMBR 0 that caused the
paused state, and the bounding set overhead value used in (the RTP paused state and the bounding set overhead value used in (the RTP
stream sender's own) TMMBN 0: stream sender's own) TMMBN 0:
TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL
NOT send any new TMMBN 0 replacing that active (more restrictive) NOT send any new TMMBN 0 replacing that active (more restrictive)
bounding set, even if entering local paused state. bounding set, even if entering local paused state.
TMMBN 0 overhead > TMMBR 0 overhead: The RTP stream sender SHALL TMMBN 0 overhead > TMMBR 0 overhead: The RTP stream sender SHALL
send TMMBN 0 with itself in the TMMBN bounding set when entering send TMMBN 0 with itself in the TMMBN bounding set when entering
local paused state. local paused state.
The case above when using TMMBN 0 as PAUSED indication, being in The case above, when using TMMBN 0 as a PAUSED indication, being in
local paused state, and having received a TMMBR 0 with a bounding set local paused state, and having received a TMMBR 0 with a bounding set
overhead value greater than the value the RTP stream sender would overhead value greater than the value the RTP stream sender would
itself use in a TMMBN 0 requires further consideration and is for itself use in a TMMBN 0, requires further consideration and is for
clarity henceforth referred to as "restricted local paused state". clarity henceforth referred to as "restricted local paused state".
As indicated in Figure 4, local paused state has higher precedence As indicated in Figure 4, local paused state has higher precedence
than paused state (Section 6.3) and RESUME messages alone cannot than paused state (Section 6.3), and RESUME messages alone cannot
resume a paused RTP stream as long as the local decision still resume a paused RTP stream as long as the local decision still
applies. An RTP stream sender in local paused state is responsible applies. An RTP stream sender in local paused state is responsible
for leaving the state whenever the conditions that caused the for leaving the state whenever the conditions that caused the
decision to enter the state no longer apply. decision to enter the state no longer apply.
If the RTP stream sender is in restricted local paused state, it If the RTP stream sender is in restricted local paused state, it
cannot leave that state until the TMMBR 0 limit causing the state is cannot leave that state until the TMMBR 0 limit causing the state is
removed by a TMMBR >0 (RESUME). If the RTP stream sender then needs removed by a TMMBR > 0 (RESUME). If the RTP stream sender then needs
to stay in local paused state due to local considerations, it MAY to stay in local paused state due to local considerations, it MAY
continue pausing the RTP stream by entering local paused state and continue pausing the RTP stream by entering local paused state and
MUST then act accordingly, including sending a TMMBN 0 with itself in MUST then act accordingly, including sending a TMMBN 0 with itself in
the bounding set. the bounding set.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
When leaving the local paused state, the stream state SHALL become When leaving the local paused state, the stream state SHALL become
Playing, regardless whether or not there were any RTP stream Playing, regardless of whether or not there were any RTP stream
receivers that sent PAUSE for that stream during the local paused receivers that sent PAUSE for that stream during the local paused
state, effectively clearing the RTP stream sender's memory for that state, effectively clearing the RTP stream sender's memory for that
stream. stream.
7. Message Format 7. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP
feedback messages, i.e. Transport layer, Payload-specific, and feedback messages, i.e., transport-layer, payload-specific, and
Application layer feedback messages. This document defines a new application-layer feedback messages. This document defines a new
Transport layer feedback message, which is further sub-typed into transport-layer feedback message, which is further subtyped into
either a PAUSE request, a RESUME request, a PAUSED indication, or a either a PAUSE request, a RESUME request, a PAUSED indication, or a
REFUSED notification. REFUSED notification.
The Transport layer feedback messages are identified by having the The transport-layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This
Transport layer feedback message, containing one or more of the sub- transport-layer feedback message, containing one or more of the
typed messages, is henceforth referred to as the PAUSE-RESUME subtyped messages, is henceforth referred to as the PAUSE-RESUME
message. The specific FCI format is identified by a Feedback Message message. The specific FCI format is identified by a Feedback Message
Type (FMT) value in common packet header for feedback message defined Type (FMT) value in a common packet header for the feedback message
in section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport defined in Section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME
feedback message FCI is identified by FMT value = TBA1. transport-layer feedback message FCI is identified by FMT value = 9.
The Common Packet Format for Feedback Messages defined by AVPF The Common Packet Format for feedback messages defined by AVPF
[RFC4585] is: [RFC4585] is:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length | |V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 5: AVPF Common Feedback Message Packet Format Figure 5: AVPF Common Feedback Message Packet Format
For the PAUSE-RESUME message defined in this memo, the following For the PAUSE-RESUME message defined in this memo, the following
interpretations of the packet fields apply: interpretations of the packet fields apply:
FMT: The FMT value identifying the PAUSE-RESUME FCI: TBA1 FMT: The FMT value identifying the PAUSE-RESUME FCI: 9
PT: Payload Type = 205 (RTPFB) PT: Payload Type = 205 (RTPFB)
Length: As defined by AVPF, i.e. the length of this packet in 32-bit Length: As defined by AVPF, i.e., the length of this packet in
words minus one, including the header and any padding. 32-bit words minus one, including the header and any padding.
SSRC of packet sender: The SSRC of the RTP session participant SSRC of packet sender: The SSRC of the RTP session participant
sending the messages in the FCI. Note, for Endpoints that have sending the messages in the FCI. Note, for endpoints that have
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to multiple SSRCs in an RTP session, any of its SSRCs MAY be used to
send any of the pause message types. send any of the pause message types.
SSRC of media source: Not used, SHALL be set to 0. The FCI SSRC of media source: Not used; SHALL be set to 0. The FCI
identifies the SSRC the message is targeted for. identifies the SSRC the message is targeted for.
The Feedback Control Information (FCI) field consists of one or more The FCI field consists of one or more PAUSE, RESUME, PAUSED, or
PAUSE, RESUME, PAUSED, REFUSED, or any future extension. These REFUSED messages or any future extension. These messages have the
messages have the following FCI format: following FCI format:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC | | Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID | | Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific : : Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Syntax of FCI Entry in the PAUSE and RESUME message Figure 6: Syntax of FCI Entry in the PAUSE and RESUME Message
The FCI fields have the following definitions: The FCI fields have the following definitions:
Target SSRC (32 bits): For a PAUSE-RESUME message, this value is the Target SSRC (32 bits): For a PAUSE-RESUME message, this value is the
SSRC that the request is intended for. For PAUSED, it MUST be the SSRC that the request is intended for. For PAUSED, it MUST be the
SSRC being paused. If pausing is the result of a PAUSE request, SSRC being paused. If pausing is the result of a PAUSE request,
the value in PAUSED is effectively the same as Target SSRC in a the value in PAUSED is effectively the same as Target SSRC in a
related PAUSE request. For REFUSED, it MUST be the Target SSRC of related PAUSE request. For REFUSED, it MUST be the Target SSRC of
the PAUSE or RESUME request that cannot change state. A CSRC MUST the PAUSE or RESUME request that cannot change state. A CSRC MUST
NOT be used as a target as the interpretation of such a request is NOT be used as a target as the interpretation of such a request is
unclear. unclear.
Type (4 bits): The pause feedback type. The values defined in this Type (4 bits): The pause feedback type. The values defined in this
specification are as follows, specification are as follows:
0: PAUSE request message. 0: PAUSE request message.
1: RESUME request message. 1: RESUME request message.
2: PAUSED indication message. 2: PAUSED indication message.
3: REFUSED notification message. 3: REFUSED notification message.
4-15: Reserved for future use. FCI fields with these Type values 4-15: Reserved for future use. FCI fields with these Type values
SHALL be ignored on reception by receivers and MUST NOT be used SHALL be ignored on reception by receivers and MUST NOT be used
by senders implementing this specification. by senders implementing this specification.
Res: (4 bits): Type specific reserved. SHALL be ignored by Res: (4 bits): Type Specific reserved. It SHALL be ignored by
receivers implementing this specification and MUST be set to 0 by receivers implementing this specification and MUST be set to 0 by
senders implementing this specification. senders implementing this specification.
Parameter Len: (8 bits): Length of the Type Specific field in 32-bit Parameter Len (8 bits): Length of the Type Specific field in 32-bit
words. MAY be 0. words. MAY be 0.
PauseID (16 bits): Message sequence identification, as described in PauseID (16 bits): Message sequence identification, as described in
Section 5.2. SHALL be incremented by one modulo 2^16 for each new Section 5.2. SHALL be incremented by one modulo 2^16 for each new
PAUSE message, unless the message is re-transmitted. The initial PAUSE message, unless the message is retransmitted. The initial
value SHOULD be 0. The PauseID is scoped by the Target SSRC, value SHOULD be 0. The PauseID is scoped by the Target SSRC,
meaning that PAUSE, RESUME, and PAUSED messages therefore share meaning that PAUSE, RESUME, and PAUSED messages therefore share
the same PauseID space for a specific Target SSRC. the same PauseID space for a specific Target SSRC.
Type Specific: (variable): Defined per pause feedback Type. MAY be Type Specific (variable): Defined per pause feedback type. MAY be
empty. A receiver implementing this specification MUST be able to empty. A receiver implementing this specification MUST be able to
skip and ignore any unknown Type Specific data, even for Type skip and ignore any unknown Type Specific data, even for Type
values defined in this specification. values defined in this specification.
8. Message Details 8. Message Details
This section contains detailed explanations of each message defined This section contains detailed explanations of each message defined
in this specification. All transmissions of requests and indications in this specification. All transmissions of requests and indications
are governed by the transmission rules as defined by Section 8.5. are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSED in this section Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN SHALL be taken to apply to the extent possible and also when TMMBR/
are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be TMMBN are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY
used instead of the messages defined in this specification when the be used instead of the messages defined in this specification when
effective topology is point-to-point. This use is expected to be the effective topology is point to point. This use is expected to be
mainly for interworking with implementations that don't support the mainly for interworking with implementations that don't support the
messages defined in this specification, but make use of TMMBR/TMMBN messages defined in this specification but make use of TMMBR/TMMBN to
to achieve a similar effect. If either sender or receiver learns achieve a similar effect. If either sender or receiver learns that
that the topology is not point-to-point, TMMBR/TMMBN MUST NOT be used the topology is not point to point, TMMBR/TMMBN MUST NOT be used for
for pause/resume functionality. If the messages defined in this pause/resume functionality. If the messages defined in this
specification are supported in addition to TMMBR/TMMBN by all specification are supported in addition to TMMBR/TMMBN by all
involved parties, pause/resume signaling MUST use messages from this involved parties, pause/resume signaling MUST use messages from this
specification. If the topology is not point-to-point and the specification. If the topology is not point to point and the
messages defined in this specification are not supported, pause/ messages defined in this specification are not supported, pause/
resume functionality with TMMBR/TMMBN MUST NOT be used. resume functionality with TMMBR/TMMBN MUST NOT be used.
For the scope of this specification, a past PauseID (Section 5.2) is For the scope of this specification, a past PauseID (Section 5.2) is
defined as having a value between and including (PauseID - 2^15) MOD defined as having a value between and including (PauseID - 2^15) MOD
2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator. 2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator.
Similarly, a future PauseID is defined as having a value between and Similarly, a future PauseID is defined as having a value between and
including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. It
Future PauseID is intentionally not defined as the entire range that is intentional that future PauseID is not defined as the entire range
was not already defined as past PauseID. The remaining range of outside that of past PauseID. The remaining range of PauseID is
PauseID is simply "not current". simply "not current".
8.1. PAUSE 8.1. PAUSE
An RTP stream receiver MAY schedule PAUSE for transmission at any An RTP stream receiver MAY schedule PAUSE for transmission at any
time. time.
PAUSE has no defined Type Specific parameters. PAUSE has no defined Type Specific parameters.
PauseID SHOULD be the current PauseID, as indicated by PAUSED PauseID SHOULD be the current PauseID, as indicated by PAUSED
(Section 8.2),REFUSED (Section 8.4), or implicitly determined by (Section 8.2), REFUSED (Section 8.4), or implicitly determined by
previously received PAUSE or RESUME (Section 8.3) requests. A previously received PAUSE or RESUME (Section 8.3) requests. A
randomly chosen PauseID MAY be used if it was not possible to randomly chosen PauseID MAY be used if it was not possible to
retrieve current PauseID information, in which case the PAUSE will retrieve current PauseID information, in which case the PAUSE will
either succeed, or the current PauseID can be found in the returned either succeed or the current PauseID can be found in the returned
REFUSED (Section 8.4). REFUSED (Section 8.4).
It can be noted that as a result of what is described in Section 6.1, It can be noted that as a result of what is described in Section 6.1,
PauseID is incremented by one, in modulo arithmetic, for each PAUSE PauseID is incremented by one, in modulo arithmetic, for each PAUSE
request that is not a retransmission, compared to what was used in request that is not a retransmission, compared to what was used in
the last PAUSED indication sent by the media sender. PauseID in the the last PAUSED indication sent by the media sender. PauseID in the
message is supposed to match current PauseID at the RTP stream message is supposed to match current PauseID at the RTP stream
sender. sender.
If an RTP stream receiver that sent a PAUSE with a certain PauseID If an RTP stream receiver that sent a PAUSE with a certain PauseID
for a target SSRC receives a RESUME or a REFUSED with the same for a Target SSRC receives a RESUME or a REFUSED with the same
PauseID for the same target SSRC, it is RECOMMENDED that it refrains PauseID for the same Target SSRC, it is RECOMMENDED that it refrains
from scheduling further PAUSE requests for some appropriate time. from scheduling further PAUSE requests for some appropriate time.
This is because the RESUME indicates that there are other receivers This is because the RESUME indicates that there are other receivers
that still wishes to receive the stream, and the REFUSED indicates that still wish to receive the stream, and the REFUSED indicates that
that the RTP stream sender is currently not able to pause the stream. the RTP stream sender is currently not able to pause the stream.
What is an appropriate time can vary from application to application What is an appropriate time can vary from application to application
and will also depend on the importance of achieving the bandwidth and will also depend on the importance of achieving the bandwidth
saving, but 2-5 regular RTCP intervals is expected to be appropriate. saving, but 2-5 regular RTCP intervals is expected to be appropriate.
If the targeted RTP stream does not pause, if no PAUSED indication If the targeted RTP stream does not pause, if no PAUSED indication
with a future PauseID compared to the one used in PAUSE is received, with a future PauseID compared to the one used in PAUSE is received,
and if no REFUSED with the current or a future PauseID is received and if no REFUSED with the current or a future PauseID is received
within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for
retransmission, using the same current PauseID. RTT is the observed retransmission, using the same current PauseID. RTT is the observed
round-trip to the RTP stream sender and T_dither_max is defined in round trip to the RTP stream sender, and T_dither_max is defined in
section 3.4 of [RFC4585]. Section 3.4 of [RFC4585]. An RTP stream receiver in a bi-directional
RTP communication will generally have an RTT estimate to the RTP
stream sender, e.g., from RTCP SR/RR as described in Section 6.4 of
When an RTP stream sender in Playing State (Section 6.1) receives a [RFC3550]. However, RTP stream receivers that don't send any RTP
streams will lack an RTT estimate unless they use additional
mechanisms, such as the "Receiver Reference Time Report Block" part
of RTCP XR [RFC3611]. RTP stream receivers that lack an RTT estimate
to the sender SHOULD use 500 ms as the default value.
When an RTP stream sender in playing state (Section 6.1) receives a
PAUSE with the current PauseID, and unless local considerations PAUSE with the current PauseID, and unless local considerations
currently makes it impossible to pause the stream, it SHALL enter currently make it impossible to pause the stream, it SHALL enter
Pausing State (Section 6.2) and act accordingly. pausing state (Section 6.2) and act accordingly.
If an RTP stream sender receives a PAUSE with the current PauseID If an RTP stream sender receives a PAUSE with the current PauseID
while in Pausing, Paused (Section 6.3) or Local Paused (Section 6.4) while in pausing, paused (Section 6.3), or local paused (Section 6.4)
States, the received PAUSE SHALL be ignored. states, the received PAUSE SHALL be ignored.
8.2. PAUSED 8.2. PAUSED
The PAUSED indication, if supported, MUST be sent whenever entering The PAUSED indication, if supported, MUST be sent whenever entering
Paused State (Section 6.3) or Local Paused State (Section 6.4). paused state (Section 6.3) or local paused state (Section 6.4).
PauseID in the PAUSED message MUST contain the current PauseID that PauseID in the PAUSED message MUST contain the current PauseID that
can be included in a subsequent RESUME (Section 8.3). For Local can be included in a subsequent RESUME (Section 8.3). For local
Paused State, this means that PauseID in the message is the current paused state, this means that PauseID in the message is the current
PauseID, just as if the RTP stream sender had sent a PAUSE to itself. PauseID, just as if the RTP stream sender had sent a PAUSE to itself.
PAUSED SHALL contain a fixed-length 32-bit parameter at the start of PAUSED SHALL contain a fixed-length 32-bit parameter at the start of
the Type Specific field with the RTP extended highest sequence number the Type Specific field with the extended RTP sequence number of the
(Section 6.4.1 of [RFC3550]) valid when the RTP stream was paused. last RTP packet sent before the RTP stream was paused, in the same
format as the extended highest sequence number received
(Section 6.4.1 of [RFC3550]).
After having entered Paused or Local Paused State and thus having After having entered paused or local paused state and thus having
sent PAUSED once, PAUSED MUST also be included in (at least) the next sent PAUSED once, PAUSED MUST also be included in (at least) the next
two regular RTCP reports, given that the pause condition is then two regular RTCP reports, given that the pause condition is then
still effective. still effective.
PAUSED indications MAY be retransmitted, subject to transmission PAUSED indications MAY be retransmitted, subject to transmission
rules (Section 8.5), to increase the probability that the message rules (Section 8.5), to increase the probability that the message
reaches the receiver in a timely fashion. This can be especially reaches the receiver in a timely fashion. This can be especially
important when entering Local Paused State. The number of important when entering local paused state. The number of
repetitions to use could be tuned to observed loss rate and desired repetitions to use could be tuned to observed loss rate and desired
loss probability, for example based on RTCP reports received from the loss probability, for example, based on RTCP reports received from
intended message target. the intended message target.
While remaining in Paused or Local Paused States, PAUSED MAY be While remaining in paused or local paused states, PAUSED MAY be
included in all compound RTCP reports, as long as the negotiated RTCP included in all compound RTCP reports, as long as the negotiated RTCP
bandwidth is not exceeded. bandwidth is not exceeded.
When in Paused or Local Paused States, whenever the RTP stream sender When in paused or local paused states, whenever the RTP stream sender
learns that there are Endpoints that did not previously receive the learns that there are endpoints that did not previously receive the
stream, for example by RTCP reports with an SSRC and a CNAME that was stream, for example, by RTCP reports with an SSRC and a CNAME that
not previously seen in the RTP session, it is RECOMMENDED to send were not previously seen in the RTP session, it is RECOMMENDED to
PAUSED at the earliest opportunity and also to include it in (at send PAUSED at the earliest opportunity and also to include it in (at
least) the next two regular RTCP reports, given that the pause least) the next two regular RTCP reports, given that the pause
condition is then still effective. condition is then still effective.
8.3. RESUME 8.3. RESUME
An RTP stream receiver MAY schedule RESUME for transmission whenever An RTP stream receiver MAY schedule RESUME for transmission whenever
it wishes to resume a paused stream, or to disapprove a stream from it wishes to resume a paused stream or disapprove a stream from being
being paused. paused.
PauseID SHOULD be the current PauseID, as indicated by PAUSED PauseID SHOULD be the current PauseID, as indicated by PAUSED
(Section 8.2) or implicitly determined by previously received PAUSE (Section 8.2) or implicitly determined by previously received PAUSE
(Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve current PauseID information, used if it was not possible to retrieve current PauseID information,
in which case the RESUME will either succeed, or the current PauseID in which case the RESUME will either succeed or the current PauseID
can be found in a returned REFUSED (Section 8.4). can be found in a returned REFUSED (Section 8.4).
If an RTP stream receiver that sent a RESUME with a certain PauseID If an RTP stream receiver that sent a RESUME with a certain PauseID
receives a REFUSED with the same PauseID, it is RECOMMENDED that it receives a REFUSED with the same PauseID, it is RECOMMENDED that it
refrains from scheduling further RESUME requests for some appropriate refrains from scheduling further RESUME requests for some appropriate
time since the REFUSE indicates that it is currently not possible to time since the REFUSE indicates that it is currently not possible to
resume the stream. What is an appropriate time can vary from resume the stream. What is an appropriate time can vary from
application to application and will also depend on the importance of application to application and will also depend on the importance of
resuming the stream, but 1-2 regular RTCP intervals is expected to be resuming the stream, but 1-2 regular RTCP intervals is expected to be
appropriate. appropriate.
RESUME requests MAY be retransmitted, subject to transmission rules RESUME requests MAY be retransmitted, subject to transmission rules
(Section 8.5), to increase the probability that the message reaches (Section 8.5), to increase the probability that the message reaches
the receiver in a timely fashion. The number of repetitions to use the receiver in a timely fashion. The number of repetitions to use
could be tuned to observed loss rate and desired loss probability, could be tuned to observed loss rate and desired loss probability,
for example based on RTCP reports received from the intended message for example, based on RTCP reports received from the intended message
target. Such retransmission SHOULD stop as soon as RTP packets from target. Such retransmission SHOULD stop as soon as RTP packets from
the targeted stream are received, or a REFUSED with the current the targeted stream are received or when a REFUSED with the current
PauseID for the targeted RTP stream is received. PauseID for the targeted RTP stream is received.
RESUME has no defined Type Specific parameters. RESUME has no defined Type Specific parameters.
When an RTP stream sender in Pausing (Section 6.2), Paused When an RTP stream sender in pausing (Section 6.2), paused
(Section 6.3) or Local Paused State (Section 6.4) receives a RESUME (Section 6.3), or local paused state (Section 6.4) receives a RESUME
with the current PauseID, and unless local considerations currently with the current PauseID, and unless local considerations currently
makes it impossible to resume the stream, it SHALL enter Playing make it impossible to resume the stream, it SHALL enter playing state
State (Section 6.1) and act accordingly. If the RTP stream sender is (Section 6.1) and act accordingly. If the RTP stream sender is
incapable of honoring a RESUME request with the current PauseID, or incapable of honoring a RESUME request with the current PauseID, or
if it receives a RESUME request with a PauseID that is not the if it receives a RESUME request with a PauseID that is not the
current PauseID while in Paused or Pausing state, the RTP stream current PauseID while in paused or pausing state, the RTP stream
sender SHALL schedule a REFUSED message for transmission as specified sender SHALL schedule a REFUSED message for transmission as specified
below. below.
If an RTP stream sender in Playing State receives a RESUME containing If an RTP stream sender in playing state receives a RESUME containing
either the current PauseID or a past PauseID, the received RESUME either the current PauseID or a past PauseID, the received RESUME
SHALL be ignored. SHALL be ignored.
8.4. REFUSED 8.4. REFUSED
If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME
(Section 8.3) request containing the current PauseID, where the (Section 8.3) request containing the current PauseID, where the
requested action cannot be fulfilled by the RTP stream sender due to requested action cannot be fulfilled by the RTP stream sender due to
some local consideration, it SHALL schedule transmission of a REFUSED some local consideration, it SHALL schedule transmission of a REFUSED
notification containing the current PauseID from the rejected notification containing the current PauseID from the rejected
request. request.
REFUSED has no defined Type Specific parameters. REFUSED has no defined Type Specific parameters.
If an RTP stream sender receives a PAUSE or RESUME request with a If an RTP stream sender receives a PAUSE or RESUME request with a
PauseID that is not the current PauseID, it SHALL schedule a REFUSED PauseID that is not the current PauseID, it SHALL schedule a REFUSED
notification containing the current PauseID, except if the RTP stream notification containing the current PauseID, except if the RTP stream
sender is in Playing State and receives a RESUME with a past PauseID, sender is in playing state and receives a RESUME with a past PauseID,
in which case the RESUME SHALL be ignored. in which case the RESUME SHALL be ignored.
If several PAUSE or RESUME that would render identical REFUSED If several PAUSE or RESUME requests that would render identical
notifications are received before the scheduled REFUSED is sent, REFUSED notifications are received before the scheduled REFUSED is
duplicate REFUSED MUST NOT be scheduled for transmission. This sent, duplicate REFUSED notifications MUST NOT be scheduled for
effectively lets a single REFUSED respond to several ineffective transmission. This effectively lets a single REFUSED respond to
PAUSE or RESUME requests. several ineffective PAUSE or RESUME requests.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSED containing the same PauseID as in the request receives a REFUSED containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSED to clear. For PAUSE, time to allow the condition that caused REFUSED to clear. For PAUSE,
an appropriate time is suggested in Section 8.1. For RESUME, an an appropriate time is suggested in Section 8.1. For RESUME, an
appropriate time is suggested in Section 8.3. appropriate time is suggested in Section 8.3.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSED containing a PauseID different from the request receives a REFUSED containing a PauseID different from the request
MAY schedule another request using the PauseID from the REFUSED MAY schedule another request using the PauseID from the REFUSED
notification. notification.
8.5. Transmission Rules 8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and specification MUST follow the normal AVPF-defined timing rules and
depends on the session's mode of operation. depend on the session's mode of operation.
All messages defined in this specification, as well as TMMBR/TMMBN All messages defined in this specification, as well as TMMBR/TMMBN
used for pause/resume purposes (Section 5.6), can use either Regular, used for pause/resume purposes (Section 5.6), can use either Regular,
Early or Immediate timings, but should make a trade-off between Early, or Immediate timings but should make a trade-off between
timely transmission (Section 4.1) and RTCP bandwidth consumption. timely transmission (Section 4.1) and RTCP bandwidth consumption.
This can be achieved by taking the following into consideration: This can be achieved by taking the following into consideration:
o It is recommended that PAUSE use Early or Immediate timing, except o It is recommended that PAUSE use Early or Immediate timing, except
for retransmissions where RTCP bandwidth can motivate the use of for retransmissions where RTCP bandwidth can motivate the use of
Regular timing. Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID is o The first transmission of PAUSED for each (non-wrapped) PauseID is
recommended to be sent with Immediate or Early timing, to stop recommended to be sent with Immediate or Early timing to stop
unnecessary repetitions of PAUSE. It is recommended that unnecessary repetitions of PAUSE. It is recommended that
subsequent transmissions of PAUSED for that PauseID use Regular subsequent transmissions of PAUSED for that PauseID use Regular
timing, to avoid that multiple PAUSE requests cause excessive timing to avoid excessive PAUSED RTCP bandwidth caused by multiple
PAUSED RTCP bandwidth. PAUSE requests.
o It is recommended that unsolicited PAUSED (sent when entering o It is recommended that unsolicited PAUSED (sent when entering
Local Paused State (Section 6.4)) always use Immediate or Early local paused state (Section 6.4)) always use Immediate or Early
timing, until PAUSED for that PauseID is considered delivered at timing, until PAUSED for that PauseID is considered delivered at
least once to all receivers of the paused RTP stream, to avoid least once to all receivers of the paused RTP stream, to avoid RTP
that RTP stream receivers take unnecessary corrective action when stream receivers that take unnecessary corrective action when the
the RTP stream is no longer received, after which it is RTP stream is no longer received, after which it is recommended
recommended that PAUSE uses Regular timing (as for PAUSED that PAUSE uses Regular timing (as for PAUSED triggered by PAUSE
triggered by PAUSE above). above).
o RESUME is often time-critical and it is recommended that it always o RESUME is often time critical, and it is recommended that it
uses Immediate or Early timing. always uses Immediate or Early timing.
o The first transmission of REFUSED for each (non-wrapped) PauseID o The first transmission of REFUSED for each (non-wrapped) PauseID
is recommended to be sent with Immediate or Early timing, to stop is recommended to be sent with Immediate or Early timing to stop
unnecessary repetitions of PAUSE or RESUME. It is recommended unnecessary repetitions of PAUSE or RESUME. It is recommended
that subsequent REFUSED for that PauseID use Regular timing, to that subsequent REFUSED notifications for that PauseID use Regular
avoid that multiple unreasonable requests cause excessive REFUSED timing to avoid excessive REFUSED RTCP bandwidth caused by
RTCP bandwidth. multiple unreasonable requests.
9. Signaling 9. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to the "rtcp-fb" attribute defined in Section 4 of AVPF [RFC4585] to
include the request for pause and resume. This specification follows include the request for pause and resume. This specification follows
all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an
rtcp-fb attribute relating to payload type in a session description. "rtcp-fb" attribute relating to the payload type in a session
description.
This specification defines a new parameter "pause" to the "ccm" This specification defines a new parameter "pause" to the "ccm"
feedback value defined in CCM [RFC5104], representing the capability feedback value defined in CCM [RFC5104], representing the capability
to understand the RTCP feedback message and all of the defined FCIs to understand the RTCP feedback message and all of the defined FCIs
of PAUSE, RESUME, PAUSED and REFUSED. of PAUSE, RESUME, PAUSED, and REFUSED.
Note: When TMMBR 0 / TMMBN 0 are used to implement pause and Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
resume functionality (with the restrictions described in this resume functionality (with the restrictions described in this
specification), signaling rtcp-fb attribute with ccm tmmbr specification), signaling the "rtcp-fb" attribute with the "ccm"
parameter is sufficient and no further signaling is necessary. and "tmmbr" parameters is sufficient and no further signaling is
There is however no guarantee that TMMBR/TMMBN implementations necessary. There is, however, no guarantee that TMMBR/TMMBN
pre-dating this specification work exactly as described here when implementations predating this specification work exactly as
used with a bitrate value of 0. described here when used with a bitrate value of 0.
The "pause" parameter has two optional attributes, "nowait" and The "pause" parameter has two optional attributes, which are "nowait"
"config": and "config":
o "nowait" indicates that the hold-off period defined in Section 6.2 o "nowait" indicates that the hold-off period defined in Section 6.2
can be set to 0, reducing the latency before the stream can be can be set to 0, reducing the latency before the stream can be
paused after receiving a PAUSE request. This condition occurs paused after receiving a PAUSE request. This condition occurs
when there will only be a single receiver per direction in the RTP when there will only be a single receiver per direction in the RTP
session, for example in point-to-point sessions. It is also session, for example, in point-to-point sessions. It is also
possible to use in scenarios using unidirectional media. The possible to use in scenarios using unidirectional media. The
conditions that allow "nowait" to be set (Section 6.2) also conditions that allow "nowait" to be set (Section 6.2) also
indicate that it would be possible to use CCM TMMBR/TMMBN as indicate that it would be possible to use CCM TMMBR/TMMBN as
pause/resume signaling. pause/resume signaling.
o "config" allows for partial implementation of this specification o "config" allows for partial implementation of this specification
according to the different roles in the use cases section according to the different roles in the use-cases section
(Section 3), and takes a value that describes what sub-set is (Section 3) and takes a value that describes what subset is
implemented: implemented:
1 Full implementation of this specification. This is the default 1 Full implementation of this specification. This is the default
configuration. A missing config attribute MUST be treated configuration. A missing "config" pause attribute MUST be
equivalent to providing a config value of 1. treated equivalent to providing a "config" value of 1.
2 The implementation intends to send PAUSE and RESUME requests 2 The implementation intends to send PAUSE and RESUME requests
for received RTP streams and is thus also capable of receiving for received RTP streams and is thus also capable of receiving
PAUSED and REFUSED. It does not support receiving PAUSE and PAUSED and REFUSED. It does not support receiving PAUSE and
RESUME requests, but may pause sent RTP streams due to local RESUME requests, but it may pause sent RTP streams due to local
considerations and then intends to send PAUSED for them. considerations and then intend to send PAUSED for them.
3 The implementation supports receiving PAUSE and RESUME requests 3 The implementation supports receiving PAUSE and RESUME requests
targeted for RTP streams it sends. It will send PAUSED and targeted for RTP streams it sends. It will send PAUSED and
REFUSED as needed. The node will not send any PAUSE and RESUME REFUSED as needed. The node will not send any PAUSE and RESUME
requests, but supports and desires receiving PAUSED if received requests but supports and desires receiving PAUSED if received
RTP streams are paused. RTP streams are paused.
4 The implementation intends to send PAUSE and RESUME requests 4 The implementation intends to send PAUSE and RESUME requests
for received RTP streams and is thus also capable of receiving for received RTP streams and is thus also capable of receiving
PAUSED and REFUSED. It cannot pause any RTP streams it sends, PAUSED and REFUSED. It cannot pause any RTP streams it sends,
and thus does not support receiving PAUSE and RESUME requests, and thus does not support receiving PAUSE and RESUME requests,
and also does not support sending PAUSED indications. and it also does not support sending PAUSED indications.
5 The implementation supports receiving PAUSE and RESUME requests 5 The implementation supports receiving PAUSE and RESUME requests
targeted for RTP streams it sends. It will send PAUSED and targeted for RTP streams it sends. It will send PAUSED and
REFUSED as needed. It does not support sending PAUSE and REFUSED as needed. It does not support sending PAUSE and
RESUME requests to pause received RTP streams, and also does RESUME requests to pause received RTP streams, and it also does
not support receiving PAUSED indications. not support receiving PAUSED indications.
6 The implementation supports sent and received RTP streams being 6 The implementation supports sent and received RTP streams being
paused due to local considerations, and thus supports sending paused due to local considerations and thus supports sending
and receiving PAUSED indications. and receiving PAUSED indications.
7 The implementation supports and desires to receive PAUSED 7 The implementation supports and desires to receive PAUSED
indications for received RTP streams, but does not pause or indications for received RTP streams but does not pause or send
send PAUSED indications for sent RTP streams. It does not PAUSED indications for sent RTP streams. It does not support
support any other messages defined in this specification. any other messages defined in this specification.
8 The implementation supports pausing sent RTP streams and 8 The implementation supports pausing sent RTP streams and
sending PAUSED indications for them, but does not support sending PAUSED indications for them but does not support
receiving PAUSED indications for received RTP streams. It does receiving PAUSED indications for received RTP streams. It does
not support any other messages defined in this specification. not support any other messages defined in this specification.
All implementers of this specification are encouraged to include full All implementers of this specification are encouraged to include full
support for all messages (config=1), but it is recognized that this support for all messages ("config=1"), but it is recognized that this
is sometimes not meaningful for implementations operating in an is sometimes not meaningful for implementations operating in an
environment where only parts of the functionality provided by this environment where only parts of the functionality provided by this
specification are needed. The above defined "config" functionality specification are needed. The above defined "config" functionality
sub-sets provide a trade-off between completeness and the need for subsets provide a trade-off between completeness and the need for
implementation interoperability, achieving at least a level of implementation interoperability, achieving at least a level of
functionality corresponding to what is desired by the least capable functionality corresponding to what is desired by the least-capable
party when used as specified here. Implementation of any other party when used as specified here. Implementing any functionality
functionality sub-sets of this specification than the above defined subsets other than those defined above is NOT RECOMMENDED.
is NOT RECOMMENDED.
When signaling a config value other than 1, an implementation MUST When signaling a "config" value other than 1, an implementation MUST
ignore non-supported messages on reception, and SHOULD omit sending ignore non-supported messages on reception and SHOULD omit sending
messages not supported by the remote peer. One example where is can messages not supported by the remote peer. One example where it can
be motivated to send messages that some receivers do not support, is be motivated to send messages that some receivers do not support is
when there are multiple message receivers with different message when there are multiple message receivers with different message
support (different config values). That approach avoids that the support (different "config" values). That approach avoids letting
least capable receiver limits the functionality provided to others. the least-capable receiver limit the functionality provided to
The below table summarizes per-message send and receive support for others. The below table summarizes per-message send and receive
the different config attribute values ("X" indicating support and "-" support for the different "config" pause attribute values ("X"
indicating non-support): indicating support and "-" indicating non-support):
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| # | Send | Receive | | # | Send | Receive |
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X | | 1 | X X X X | X X X X |
| 2 | X X X - | - - X X | | 2 | X X X - | - - X X |
| 3 | - - X X | X X X - | | 3 | - - X X | X X X - |
| 4 | X X - - | - - X X | | 4 | X X - - | - - X X |
| 5 | - - X X | X X - - | | 5 | - - X X | X X - - |
| 6 | - - X - | - - X - | | 6 | - - X - | - - X - |
| 7 | - - - - | - - X - | | 7 | - - - - | - - X - |
| 8 | - - X - | - - - - | | 8 | - - X - | - - - - |
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
Figure 7: Supported messages for different config values Figure 7: Supported Messages for Different "config" Values
In the above description of partial implementations, config=2 and 4 In the above description of partial implementations, "config" values
correspond to the RTP Mixer in the RTP Mixer to Media Sender use case 2 and 4 correspond to the RTP Mixer in the 'RTP Mixer to Media
(Section 3.2), and config=3 and 5 correspond to the Media Sender in Sender' use case (Section 3.2), and "config" values 3 and 5
that same use case. For that use case, it should be clear that an correspond to the media sender in that same use case. For that use
RTP Mixer implementing only config=3 or 5 will not provide a working case, it should be clear that an RTP Mixer implementing only "config"
solution. Similarly, for that use case, a Media Sender implementing values 3 or 5 will not provide a working solution. Similarly, for
only config=2 or 4 will not provide a working solution. Both the RTP that use case, a media sender implementing only "config" values 2 or
Mixer and the Media Sender will of course work when implementing the 4 will not provide a working solution. Both the RTP Mixer and the
full set of messages, corresponding to config=1. media sender will of course work when implementing the full set of
messages, corresponding to "config=1".
A partial implementation is not suitable for pause / resume support A partial implementation is not suitable for pause/resume support
between cascaded RTP Mixers, but would require support corresponding between cascaded RTP Mixers, but it would require support
to config=1 between such RTP Mixers. This is because an RTP Mixer is corresponding to "config=1" between such RTP Mixers. This is because
then also Media Sender towards the other RTP Mixer, requiring support an RTP Mixer is then also a media sender towards the other RTP Mixer,
for the union of config=2 and 3 or config=4 and 5, which effectively requiring support for the union of "config" values 2 and 3 or
becomes config=1. "config" values 4 and 5, which effectively becomes "config=1".
As can be seen from Figure 7 above, config=2 and 3 differ from As can be seen from Figure 7 above, "config" values 2 and 3 differ
config=4 and 5 only in that in the latter, the PAUSE / RESUME message from "config" values 4 and 5 only in that in the latter, the PAUSE/
sender (e.g. the RTP Mixer side) does not support local pause RESUME message sender (e.g., the RTP Mixer side) does not support
(Section 6.4) for any of its own streams and therefore also does not local pause (Section 6.4) for any of its own streams and therefore
support sending PAUSED. also does not support sending PAUSED.
Partial implementations that only support local pause functionality Partial implementations that only support local pause functionality
can declare this capability through config=6-8. can declare this capability through "config" values 6-8.
Viable fallback rules between different config are described in Viable fallback rules between different "config" values are described
Section 9.1 and Figure 9. in Section 9.1 and Figure 9.
This is the resulting ABNF [RFC5234], extending existing ABNF in This is the resulting ABNF [RFC5234], extending the existing ABNF in
section 7.1 of CCM [RFC5104]: Section 7.1 of CCM [RFC5104]:
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr) rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
pause-attr = pause-config ; partial message support pause-attr = pause-config ; partial message support
/ "nowait" ; no hold-off / "nowait" ; no hold-off period
/ byte-string ; for future extensions / byte-string ; for future extensions
pause-config = "config=" pause-config-value pause-config = "config=" pause-config-value
pause-config-value = 1*2DIGIT pause-config-value = 1*2DIGIT
; byte-string as defined in RFC 4566 ; byte-string as defined in RFC 4566
Figure 8: ABNF Figure 8: ABNF
An endpoint implementing this specification and using SDP to signal An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate the new "pause" parameter with ccm capability SHOULD indicate the new "pause" parameter with "ccm"
signaling, but MAY instead use existing ccm tmmbr signaling [RFC5104] signaling but MAY instead use existing "ccm tmmbr" signaling
if the limitations in functionality when using TMMBR/TMMBN as [RFC5104] if the limitations in functionality when using TMMBR/TMMBN
described in this specification (Section 5.6) are considered as described in this specification (Section 5.6) are considered
acceptable. In that case, no partial message support is possible. acceptable. In that case, no partial message support is possible.
The messages from this specification (Section 8) SHOULD NOT be used The messages from this specification (Section 8) SHOULD NOT be used
towards receivers that did not declare capability to receive those towards receivers that did not declare capability to receive those
messages. messages.
The pause functionality can normally be expected to work The pause functionality can normally be expected to work
independently of the payload type. However, there might exist independently of the payload type. However, there might exist
situations where an endpoint needs to restrict or at least configure situations where an endpoint needs to restrict or at least configure
the capabilities differently depending on the payload type carrying the capabilities differently depending on the payload type carrying
the media stream. Reasons for this might relate to capabilities to the media stream. Reasons for this might relate to capabilities to
correctly handle media boundaries and avoid any pause or resume correctly handle media boundaries and avoid any pause or resume
operation to occur where it would leave a receiver or decoder with no operation to occur where it would leave a receiver or decoder with no
choice than to attempt to repair or discard the media received just choice than to attempt to repair or discard the media received just
prior to or at the point of resuming. prior to or at the point of resuming.
There MUST NOT be more than one "a=rtcp-fb" line with "pause" There MUST NOT be more than one "a=rtcp-fb" line with "pause"
applicable to a single payload type in the SDP, unless the additional applicable to a single payload type in the SDP, unless the additional
line uses "*" as payload type, in which case "*" SHALL be interpreted line uses "*" as the payload type, in which case "*" SHALL be
as applicable to all listed payload types that do not have an interpreted as applicable to all listed payload types that do not
explicit "pause" specification. The "config" pause attribute MUST have an explicit "pause" specification. The "config" pause attribute
NOT appear more than once for each "pause" CCM parameter. The MUST NOT appear more than once for each "pause" CCM parameter. The
"nowait" pause attribute MUST NOT appear more than once for each "nowait" pause attribute MUST NOT appear more than once for each
"pause" CCM parameter. "pause" CCM parameter.
9.1. Offer-Answer Use 9.1. Offer/Answer Use
An offerer implementing this specification needs to include "pause" An offerer implementing this specification needs to include the
CCM parameter with suitable configuration attribute ("config") in the "pause" CCM parameter with a suitable configuration attribute
SDP, according to what messages it intends to send and desires to ("config") in the SDP, according to what messages it intends to send
receive in the session. and desires to receive in the session.
In SDP offer/answer, the "config" attribute and its message In SDP offer/answer, the "config" pause attribute and its message
directions are interpreted based on the agent providing the SDP. The directions are interpreted based on the agent providing the SDP. The
offerer is described in an offer, and the answerer is described in an offerer is described in an offer, and the answerer is described in an
answer. answer.
An answerer receiving an offer with a "pause" CCM line and a config An answerer receiving an offer with a "pause" CCM line and a "config"
attribute with a certain value, describing a certain capability to pause attribute with a certain value, describing a certain capability
send and receive messages, MAY change the config attribute value in to send and receive messages, MAY change the "config" pause attribute
the answer to another configuration. The permitted answers are value in the answer to another configuration. The permitted answers
listed in the below table. are listed in the below table.
SDP Offer config value | Permitted SDP Answer config values SDP Offer "config" value | Permitted SDP Answer "config" values
-----------------------+----------------------------------- -------------------------+-------------------------------------
1 | 1, 2, 3, 4, 5, 6, 7, 8 1 | 1, 2, 3, 4, 5, 6, 7, 8
2 | 3, 4, 5, 6, 7, 8 2 | 3, 4, 5, 6, 7, 8
3 | 2, 4, 5, 6, 7, 8 3 | 2, 4, 5, 6, 7, 8
4 | 5, 6, 7, 8 4 | 5, 6, 7, 8
5 | 4, 6, 7, 8 5 | 4, 6, 7, 8
6 | 6, 7, 8 6 | 6, 7, 8
7 | 8 7 | 8
8 | 7 8 | 7
Figure 9: Config values in Offer/Answer Figure 9: "config" Values in Offer/Answer
An offer or answer omitting the config attribute, MUST be interpreted An offer or answer omitting the "config" pause attribute MUST be
as equivalent to config=1. Implementations of this specification interpreted as equivalent to "config=1". Implementations of this
MUST NOT use any other config values than the ones defined above in specification MUST NOT use any "config" values other than those
an offer or answer, and MUST remove the "pause" CCM line in the defined above in an offer or answer and MUST remove the "pause" CCM
answer when receiving an offer with a config value it does not line in the answer when receiving an offer with a "config" value it
understand. In all cases the answerer MAY also completely remove any does not understand. In all cases, the answerer MAY also completely
"pause" CCM line to indicate that it does not understand or desire to remove any "pause" CCM line to indicate that it does not understand
use any pause functionality for the affected payload types. or desire to use any pause functionality for the affected payload
types.
If the offerer believes that itself and the intended answerer are If the offerer believes that itself and the intended answerer are
likely the only Endpoints in the RTP session, it MAY include the likely the only endpoints in the RTP session, it MAY include the
"nowait" attribute on the "pause" line in the offer. If an answerer "nowait" pause attribute on the "pause" line in the offer. If an
receives the "nowait" attribute on the "pause" line in the SDP, and answerer receives the "nowait" pause attribute on the "pause" line in
if it has information that the offerer and itself are not the only the SDP, and if it has information that the offerer and itself are
Endpoints in the RTP session, it MUST NOT include any "nowait" not the only endpoints in the RTP session, it MUST NOT include any
attribute on its "pause" line in the SDP answer. The answerer MUST "nowait" pause attribute on its "pause" line in the SDP answer. The
NOT add "nowait" on the "pause" line in the answer unless it is answerer MUST NOT add "nowait" on the "pause" line in the answer
present on the "pause" line in the offer. If both offer and answer unless it is present on the "pause" line in the offer. If both offer
contained a "nowait" parameter, then the hold-off period is and answer contain a "nowait" pause attribute, then the hold-off
configured to 0 at both offerer and answerer. period is configured to 0 at both the offerer and answerer.
Unknown pause attributes MUST be ignored in the offer and MUST then Unknown pause attributes MUST be ignored in the offer and MUST then
be omitted from the answer. be omitted from the answer.
If both "pause" and "tmmbr" are present in the offer, both MAY be If both "pause" and "tmmbr" are present in the offer, both MAY be
included also in the answer, in which case TMMBR/TMMBN MUST NOT be included also in the answer, in which case TMMBR/TMMBN MUST NOT be
used for pause/resume purposes (with a bitrate value of 0), to avoid used for pause/resume purposes (with a bitrate value of 0), to avoid
signaling ambiguity. signaling ambiguity.
9.2. Declarative Use 9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP the SDP. This has implications on the interpretation of the SDP
signaling extensions defined in this specification. signaling extensions defined in this specification.
First, the "config" attribute and its message directions are First, the "config" pause attribute and its message directions are
interpreted based on the node receiving the SDP, and describes the interpreted based on the node receiving the SDP, and it describes the
RECOMMENDED level of operation. If the joining client does not RECOMMENDED level of operation. If the joining client does not
support the indicated config value, some RTP session stream support the indicated "config" value, some RTP session stream
optimizations may not be possible in that some RTP streams will not optimizations may not be possible in that some RTP streams will not
be paused by the joining client, and/or the joining client may not be be paused by the joining client, and/or the joining client may not be
able to resume and receive wanted streams because they are paused. able to resume and receive wanted streams because they are paused.
Second, the "nowait" parameter, if included, is followed as Second, the "nowait" pause attribute, if included, is followed as
specified. It is the responsibility of the declarative SDP sender to specified. It is the responsibility of the declarative SDP sender to
determine if a configured node will participate in a session that determine if a configured node will participate in a session that
will be point to point, based on the usage. For example, a will be point to point, based on the usage. For example, a
conference client being configured for an any source multicast conference client being configured for an any source multicast
session using SAP [RFC2974] will not be in a point to point session, session using the Session Announcement Protocol (SAP) [RFC2974] will
thus "nowait" cannot be included. An RTSP [RFC2326] client receiving not be in a point-to-point session, thus "nowait" cannot be included.
a declarative SDP may very well be in a point to point session, A Real-Time Streaming Protocol (RTSP) [RFC2326] client receiving a
declarative SDP may very well be in a point-to-point session,
although it is highly doubtful that an RTSP client would need to although it is highly doubtful that an RTSP client would need to
support this specification, considering the inherent PAUSE support in support this specification, considering the inherent PAUSE support in
RTSP. RTSP.
Unknown pause attributes MUST be ignored. Unknown pause attributes MUST be ignored.
If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
NOT be used for pause/resume purposes (with a bitrate value of 0), to NOT be used for pause/resume purposes (with a bitrate value of 0) to
avoid signaling ambiguity. avoid signaling ambiguity.
10. Examples 10. Examples
The following examples shows use of PAUSE and RESUME messages, The following examples show use of PAUSE and RESUME messages,
including use of offer-answer: including use of offer/answer:
1. Offer-Answer
2. Point-to-Point session 1. Offer/Answer
3. Point-to-Multipoint using Mixer 2. Point-to-Point Session
4. Point-to-Multipoint using Relay 3. Point to Multipoint using Mixer
4. Point to Multipoint using Relay
10.1. Offer-Answer 10.1. Offer/Answer
The below figures contains an example how to show support for pausing The below figures contain an example of how to show support for
and resuming the streams, as well as indicating whether or not the pausing and resuming the streams, as well as indicating whether or
hold-off period can be set to 0. not the hold-off period can be set to 0.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media s=Pausing Media
t=0 0 t=0 0
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99 m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000 a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
Figure 10: SDP Offer With Pause and Resume Capability Figure 10: SDP Offer with Pause and Resume Capability
The offerer supports all of the messages defined in this The offerer supports all of the messages defined in this
specification, leaving out the optional config attribute. The specification, leaving out the optional "config" pause attribute.
offerer also believes that it will be the sole receiver of the The offerer also believes that it will be the sole receiver of the
answerer's stream as well as that the answerer will be the sole answerer's stream as well as that the answerer will be the sole
receiver of the offerer's stream and thus includes the "nowait" sub- receiver of the offerer's stream and thus includes the "nowait" pause
parameter for the "pause" parameter. attribute for the "pause" parameter.
This is the SDP answer: This is the SDP answer:
v=0 v=0
o=bob 293847192 293847192 IN IP4 bob.example.com o=bob 293847192 293847192 IN IP4 bob.example.com
s=- s=-
t=0 0 t=0 0
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98 m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause config=2 a=rtcp-fb:98 ccm pause config=2
Figure 11: SDP Answer With Pause and Resume Capability Figure 11: SDP Answer with Pause and Resume Capability
The answerer will not allow its sent streams to be paused or resumed The answerer will not allow its sent streams to be paused or resumed
and thus restricts the answer to indicate config=2. It also supports and thus restricts the answer to indicate "config=2". It also
pausing its own RTP streams due to local considerations, which is why supports pausing its own RTP streams due to local considerations,
config=2 is chosen rather than config=4. The answerer somehow knows which is why "config=2" is chosen rather than "config=4". The
that it will not be a point-to-point RTP session and has therefore answerer somehow knows that it will not be a point-to-point RTP
removed "nowait" from the "pause" line, meaning that the offerer must session and has therefore removed "nowait" from the "pause" line,
use a non-zero hold-off period when being requested to pause the meaning that the offerer must use a non-zero hold-off period when
stream. being requested to pause the stream.
When using TMMBR 0 / TMMBN 0 to achieve pause and resume When using TMMBR 0 / TMMBN 0 to achieve pause and resume
functionality, there are no differences in SDP compared to CCM functionality, there are no differences in SDP compared to CCM
[RFC5104] and therefore no such examples are included here. [RFC5104]; therefore, no such examples are included here.
10.2. Point-to-Point Session 10.2. Point-to-Point Session
This is the most basic scenario, which involves two participants, This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off period before pausing a transmission accordingly. The hold-off period before pausing a
stream is 0. stream is 0.
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 40, line 36 skipping to change at page 41, line 40
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: PAUSE(4) | | t6: PAUSE(4) |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t7: PAUSED(4) | | t7: PAUSED(4) |
| -------------------------------> | | -------------------------------> |
: : : :
Figure 12: Pause and Resume Operation in Point-to-Point Figure 12: Pause and Resume Operation in Point to Point
Figure 12 shows the basic pause and resume operation in Point-to- Figure 12 shows the basic pause and resume operation in a
Point scenario. At time t1, an RTP sender sends data to a receiver. point-to-point scenario. At time t1, an RTP sender sends data to a
At time t2, the RTP receiver requests the sender to pause the stream, receiver. At time t2, the RTP receiver requests the sender to pause
using PauseID 3 (which it knew since before in this example). The the stream, using PauseID 3 (which it knew since before in this
sender pauses the data and replies with a PAUSED containing the same example). The sender pauses the data and replies with a PAUSED
PauseID. Some time later (at time t4) the receiver requests the containing the same PauseID. Some time later (at time t4), the
sender to resume, which resumes its transmission. The next PAUSE, receiver requests the sender to resume, which resumes its
sent at time t6, contains an updated PauseID (4), with a transmission. The next PAUSE, sent at time t6, contains an updated
corresponding PAUSED being sent at time t7. PauseID (4), with a corresponding PAUSED being sent at time t7.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| -------------------------------> | | -------------------------------> |
| t2: TMMBR 0 | | t2: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t3: TMMBN 0 | | t3: TMMBN 0 |
skipping to change at page 41, line 28 skipping to change at page 42, line 28
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: TMMBR 0 | | t6: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t7: TMMBN 0 | | t7: TMMBN 0 |
| -------------------------------> | | -------------------------------> |
: : : :
Figure 13: TMMBR Pause and Resume in Point-to-Point Figure 13: TMMBR Pause and Resume in Point to Point
Figure 13 describes the same point-to-point scenario as above, but Figure 13 describes the same point-to-point scenario as above, but
using TMMBR/TMMBN signaling. using TMMBR/TMMBN signaling.
+---------------+ +----------------+ +---------------+ +----------------+
| RTP Sender A | | RTP Receiver B | | RTP Sender A | | RTP Receiver B |
+---------------+ +----------------+ +---------------+ +----------------+
: t1: RTP data : : t1: RTP data :
| -------------------------------> | | -------------------------------> |
| < RTP data paused > | | < RTP data paused > |
skipping to change at page 42, line 28 skipping to change at page 43, line 28
: < Some time passes > : : < Some time passes > :
| t5: TMMBN {B:0} | | t5: TMMBN {B:0} |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: TMMBR 80000 | | t6: TMMBR 80000 |
| <------------------------------- | | <------------------------------- |
| t7: RTP data | | t7: RTP data |
| -------------------------------> | | -------------------------------> |
: : : :
Figure 14: Unsolicited PAUSED using TMMBN Figure 14: Unsolicited PAUSED Using TMMBN
Figure 14 describes the case when an RTP stream sender (A) chooses to Figure 14 describes the case when an RTP stream sender (A) chooses to
pause an RTP stream due to local considerations. Both the RTP stream pause an RTP stream due to local considerations. Both A and the RTP
sender (A) and the RTP stream receiver (B) use TMMBR/TMMBN signaling stream receiver (B) use TMMBR/TMMBN signaling for pause/resume
for pause/resume purposes. A decides to pause the RTP stream at time purposes. A decides to pause the RTP stream at time t2 and uses
t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN TMMBN 0 to signal PAUSED, including itself in the TMMBN bounding set.
bounding set. At time t3, despite the fact that the RTP stream is At time t3, despite the fact that the RTP stream is still paused, B
still paused, B decides that it is no longer interested to receive decides that it is no longer interested in receiving the RTP stream
the RTP stream and signals PAUSE by sending a TMMBR 0. As a result and signals PAUSE by sending a TMMBR 0. As a result of that, the
of that, the bounding set now contains both A and B, and A sends out bounding set now contains both A and B, and A sends out a new TMMBN
a new TMMBN reflecting that. After a while, at time t5, the local reflecting that. After a while, at time t5, the local considerations
considerations that caused A to pause the RTP stream no longer apply, that caused A to pause the RTP stream no longer apply, causing it to
causing it to remove itself from the bounding set and to send a new remove itself from the bounding set and to send a new TMMBN
TMMBN indicating this. At time t6, B decides that it is now indicating this. At time t6, B decides that it is now interested in
interested to receive the RTP stream again and signals RESUME by receiving the RTP stream again and signals RESUME by sending a TMMBR
sending a TMMBR containing a bitrate value greater than 0, causing A containing a bitrate value greater than 0, causing A to resume
to resume sending RTP data. sending RTP data.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| ------------------------------------> | | ------------------------------------> |
| t2: PAUSE(7), lost | | t2: PAUSE(7), lost |
| <---X-------------- | | <---X-------------- |
| | | |
| t3: RTP data | | t3: RTP data |
| ------------------------------------> | | ------------------------------------> |
: : : :
| <Timeout, still receiving data> | | < Time-out, still receiving data > |
| t4: PAUSE(7) | | t4: PAUSE(7) |
| <------------------------------------ | | <------------------------------------ |
| < RTP data paused > | | < RTP data paused > |
| t5: PAUSED(7) | | t5: PAUSED(7) |
| ------------------------------------> | | ------------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: RESUME(7), lost | | t6: RESUME(7), lost |
| <---X-------------- | | <---X-------------- |
| t7: RESUME(7) | | t7: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
| t8: RTP data | | t8: RTP data |
| ------------------------------------> | | ------------------------------------> |
| t9: RESUME(7) | | t9: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
: : : :
Figure 15: Pause and Resume Operation With Messages Lost Figure 15: Pause and Resume Operation with Messages Lost
Figure 15 describes what happens if a PAUSE message from an RTP Figure 15 describes what happens if a PAUSE message from an RTP
stream receiver does not reach the RTP stream sender. After sending stream receiver does not reach the RTP stream sender. After sending
a PAUSE message, the RTP stream receiver waits for a time-out to a PAUSE message, the RTP stream receiver waits for a time-out to
detect if the RTP stream sender has paused the data transmission or detect if the RTP stream sender has paused the data transmission or
has sent PAUSED indication according to the rules discussed in has sent a PAUSED indication according to the rules discussed in
Section 6.3. As the PAUSE message is lost on the way (at time t2), Section 6.3. As the PAUSE message is lost on the way (at time t2),
RTP data continues to reach to the RTP stream receiver. When the RTP data continues to reach to the RTP stream receiver. When the
timer expires, the RTP stream receiver schedules a retransmission of timer expires, the RTP stream receiver schedules a retransmission of
the PAUSE message, which is sent at time t4. If the PAUSE message the PAUSE message, which is sent at time t4. If the PAUSE message
now reaches the RTP stream sender, it pauses the RTP stream and now reaches the RTP stream sender, it pauses the RTP stream and
replies with PAUSED. replies with PAUSED.
At time t6, the RTP stream receiver wishes to resume the stream again At time t6, the RTP stream receiver wishes to resume the stream again
and sends a RESUME, which is lost. This does not cause any severe and sends a RESUME, which is lost. This does not cause any severe
effect, since there is no requirement to wait until further RESUME effect, since there is no requirement to wait until further RESUME
are sent and another RESUME are sent already at time t7, which now requests are sent, and another RESUME is sent already at time t7,
reaches the RTP stream sender that consequently resumes the stream at which now reaches the RTP stream sender that consequently resumes the
time t8. The time interval between t6 and t7 can vary, but may for stream at time t8. The time interval between t6 and t7 can vary but
example be one RTCP feedback transmission interval as determined by may, for example, be one RTCP feedback transmission interval as
the AVPF rules. determined by the AVPF rules.
The RTP stream receiver did not realize that the RTP stream was The RTP stream receiver did not realize that the RTP stream was
resumed in time to stop yet another scheduled RESUME from being sent resumed in time to stop yet another scheduled RESUME from being sent
at time t9. This is however harmless since RESUME contains a past at time t9. This is, however, harmless since RESUME contains a past
PauseID and will be ignored by the RTP stream sender. It will also PauseID and will be ignored by the RTP stream sender. It will also
not cause any unwanted resume even if the stream was paused again not cause the RTP stream to be resumed even if the stream was paused
based on a PAUSE from some other receiver before receiving the again based on a PAUSE from some other receiver before receiving the
RESUME, since the current PauseID was updated compared to the one in RESUME, since the current PauseID was updated compared to the one in
the stray RESUME, which contains a past PauseID and will be ignored the stray RESUME, which contains a past PauseID and will be ignored
by the RTP stream sender. by the RTP stream sender.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| ------------------------------> | | ------------------------------> |
| t2: PAUSE(11) | | t2: PAUSE(11) |
| <------------------------------ | | <------------------------------ |
| | | |
| < Can not pause RTP data > | | < Cannot pause RTP data > |
| t3: REFUSED(11) | | t3: REFUSED(11) |
| ------------------------------> | | ------------------------------> |
| | | |
| t4: RTP data | | t4: RTP data |
| ------------------------------> | | ------------------------------> |
: : : :
Figure 16: Pause Request is Refused in Point-to-Point Figure 16: Pause Request is Refused in Point to Point
In Figure 16, the receiver requests to pause the sender, which In Figure 16, the receiver requests to pause the sender, which
refuses to pause due to some consideration local to the sender and refuses to pause due to some consideration local to the sender and
responds with a REFUSED message. responds with a REFUSED message.
10.3. Point-to-Multipoint using Mixer 10.3. Point to Multipoint Using Mixer
An RTP Mixer is an intermediate node connecting different transport- An RTP Mixer is an intermediate node connecting different transport-
level clouds. The Mixer receives streams from different RTP sources, level clouds. The Mixer receives streams from different RTP sources,
selects or combines them based on the application's needs and selects or combines them based on the application's needs, and
forwards the generated stream(s) to the destination. The Mixer forwards the generated stream(s) to the destination. The Mixer
typically puts its' own SSRC(s) in RTP data packets instead of the typically puts its own SSRC(s) in RTP data packets instead of the
original source(s). original source(s).
The Mixer keeps track of all the streams delivered to the Mixer and The Mixer keeps track of all the streams delivered to the Mixer and
how they are currently used. In this example, it selects the video how they are currently used. In this example, Mixer (M) selects the
stream to deliver to the receiver R based on the voice activity of video stream to deliver to the RTP stream receiver (R) based on the
the RTP stream senders. The video stream will be delivered to R voice activity of the RTP stream senders (S1 and S2). The video
using M's SSRC and with an CSRC indicating the original source. stream will be delivered to R using M's SSRC and with a CSRC
indicating the original source.
Note that PauseID is not of any significance for the example and is Note that PauseID is not of any significance for the example and is
therefore omitted in the description. therefore omitted in the description.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 | | R | | M | | S1 | | S2 |
+-----+ +-----| +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
: : t1:RTP(S1) : : : : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| | | t2:RTP(M:S1) |<-----------------| |
|<-----------------| | | |<-----------------| | |
| | t3:RTP(S2) | | | | t3:RTP(S2) | |
| |<------------------------------------| | |<------------------------------------|
| | t4: PAUSE(S2) | | | | t4: PAUSE(S2) | |
| |------------------------------------>| | |------------------------------------>|
| | | t5: PAUSED(S2) | | | | t5: PAUSED(S2) |
| |<------------------------------------| | |<------------------------------------|
| | | <S2:No RTP to M> | | | | <S2:No RTP to M> |
| | t6: RESUME(S2) | | | | t6: RESUME(S2) | |
| |------------------------------------>| | |------------------------------------>|
| | | t7: RTP to M | | | | t7: RTP to M |
| |<------------------------------------| | |<------------------------------------|
| t8:RTP(M:S2) | | | | t8:RTP(M:S2) | | |
|<-----------------| | | |<-----------------| | |
| | t9:PAUSE(S1) | | | | t9:PAUSE(S1) | |
| |----------------->| | | |----------------->| |
| | t10:PAUSED(S1) | | | | t10:PAUSED(S1) | |
| |<-----------------| | | |<-----------------| |
| | <S1:No RTP to M> | | | | <S1:No RTP to M> | |
: : : : : : : :
Figure 17: Pause and Resume Operation for a Voice Activated Mixer Figure 17: Pause and Resume Operation for a Voice-Activated Mixer
The session starts at t1 with S1 being the most active speaker and The session starts at t1 with S1 being the most active speaker and
thus being selected as the single video stream to be delivered to R thus being selected as the single video stream to be delivered to R
(t2) using the Mixer SSRC but with S1 as CSRC (indicated after the (t2) using M's SSRC but with S1 as the CSRC (indicated after the
colon in the figure). Then S2 joins the session at t3 and starts colon in the figure). Then S2 joins the session at t3 and starts
delivering an RTP stream to the Mixer. As S2 has less voice activity delivering an RTP stream to M. As S2 has less voice activity then
then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE S1, M decides to pause S2 at t4 by sending S2 a PAUSE request. At
request. At t5, S2 acknowledges with a PAUSED and at the same t5, S2 acknowledges with PAUSED and at the same instant stops
instant stops delivering RTP to the Mixer. At t6, the user at S2 delivering RTP to M. At t6, the user at S2 starts speaking and
starts speaking and becomes the most active speaker and the Mixer becomes the most active speaker and M decides to switch the video
decides to switch the video stream to S2, and therefore quickly sends stream to S2 and therefore quickly sends a RESUME request to S2. At
a RESUME request to S2. At t7, S2 has received the RESUME request t7, S2 has received the RESUME request and acts on it by resuming RTP
and acts on it by resuming RTP stream delivery to M. When the RTP stream delivery to M. When the RTP stream from t7 arrives at M, it
stream from t7 arrives at the Mixer, it switches this RTP stream into switches this RTP stream into its SSRC (M) at t8 and changes the CSRC
its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes to S2. As S1 now becomes unused, M issues a PAUSE request to S1 at
unused, the Mixer issues a PAUSE request to S1 at t9, which is t9, which is acknowledged at t10 with PAUSED, and the RTP stream from
acknowledged at t10 with a PAUSED and the RTP stream from S1 stops S1 stops being delivered.
being delivered.
10.4. Point-to-Multipoint using Translator 10.4. Point to Multipoint Using Translator
A transport Relay in an RTP session forwards the message from one A transport Relay in an RTP session forwards the message from one
peer to all the others. Unlike Mixer, the Relay does not mix the peer to all the others. Unlike Mixer, the Relay does not mix the
streams or change the SSRC of the messages or RTP media. These streams or change the SSRC of the messages or RTP media. These
examples are to show that the messages defined in this specification examples are to show that the messages defined in this specification
can be safely used also in a transport Relay case. The parentheses can be safely used also in a transport Relay case. The parentheses
in the figures contains (Target SSRC, PauseID) information for the in the figures contains (Target SSRC, PauseID) information for the
messages defined in this specification. messages defined in this specification.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Sender(S) | | Relay | | Receiver(R) | | Sender(S) | | Relay | | Receiver(R) |
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
: t1: RTP(S) : : : t1: RTP(S) : :
|------------------>| | |------------------>| |
| | t2: RTP (S) | | | t2: RTP (S) |
| |------------------>| | |------------------>|
| | t3: PAUSE(S,3) | | | t3: PAUSE(S,3) |
| |<------------------| | |<------------------|
| t4:PAUSE(S,3) | | | t4:PAUSE(S,3) | |
|<------------------| | |<------------------| |
: < Sender waiting for possible RESUME> : : <Sender waiting for possible RESUME> :
| < RTP data paused > | | < RTP data paused > |
| t5: PAUSED(S,3) | | | t5: PAUSED(S,3) | |
|------------------>| | |------------------>| |
| | t6: PAUSED(S,3) | | | t6: PAUSED(S,3) |
| |------------------>| | |------------------>|
: : : : : :
| | t7: RESUME(S,3) | | | t7: RESUME(S,3) |
| |<------------------| | |<------------------|
| t8: RESUME(S,3) | | | t8: RESUME(S,3) | |
|<------------------| | |<------------------| |
| t9: RTP (S) | | | t9: RTP (S) | |
|------------------>| | |------------------>| |
| | t10: RTP (S) | | | t10: RTP (S) |
| |------------------>| | |------------------>|
: : : : : :
Figure 18: Pause and Resume Operation Between Two Participants Using Figure 18: Pause and Resume Operation between Two Participants Using
a Relay a Relay
Figure 18 describes how a Relay can help the receiver in pausing and Figure 18 describes how a Relay can help the receiver (R) in pausing
resuming the sender. The sender S sends RTP data to the receiver R and resuming the sender (S). S sends RTP data to R through the
through Relay, which just forwards the data without modifying the Relay, which just forwards the data without modifying the SSRCs. R
SSRCs. The receiver sends a PAUSE request to the sender, which in sends a PAUSE request to S which, in this example, knows that there
this example knows that there may be more receivers of the stream and may be more receivers of the stream and waits a non-zero hold-off
waits a non-zero hold-off period to see if there is any other period to see if there is any other receiver that wants to receive
receiver that wants to receive the data, does not receive any the data, and when no disapproving RESUME messages are received, it
disapproving RESUME, hence pauses itself and replies with PAUSED. pauses itself and replies with PAUSED. Similarly R resumes S by
Similarly the receiver resumes the sender by sending RESUME request sending a RESUME request through the Relay. Since this describes
through Relay. Since this describes only a single pause and resume only a single pause and resume operation for a single RTP stream
operation for a single RTP stream sender, all messages uses a single sender, all messages use a single PauseID; in this example, it's
PauseID, in this example 3. three.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| S | | Rel | | R1 | | R2 | | S | | Rel | | R1 | | R2 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
: t1:RTP(S) : : : : t1:RTP(S) : : :
|----------------->| | | |----------------->| | |
| | t2:RTP(S) | | | | t2:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
| | t3:PAUSE(S,7) | | | | t3:PAUSE(S,7) | |
| |<-----------------| | | |<-----------------| |
| t4:PAUSE(S,7) | | | | t4:PAUSE(S,7) | | |
|<-----------------|------------------------------------>| |<-----------------|------------------------------------>|
| | | t5:RESUME(S,7) | | | | t5:RESUME(S,7) |
| |<------------------------------------| | |<------------------------------------|
| t6:RESUME(S,7) | | | | t6:RESUME(S,7) | | |
|<-----------------|----------------->| | |<-----------------|----------------->| |
| |<RTP stream continues to R1 and R2> | | | <RTP stream continues to R1 and R2> |
| | | t7: PAUSE(S,8) | | | | t7: PAUSE(S,8) |
| |<------------------------------------| | |<------------------------------------|
| t8:PAUSE(S,8) | | | | t8:PAUSE(S,8) | | |
|<-----------------|----------------->| | |<-----------------|----------------->| |
: : : : : : : :
| < Pauses RTP Stream > | | | < Pauses RTP stream > | |
| t9:PAUSED(S,8) | | | | t9:PAUSED(S,8) | | |
|----------------->| | | |----------------->| | |
| | t10:PAUSED(S,8) | | | | t10:PAUSED(S,8) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
| | t11:RESUME(S,8) | | | | t11:RESUME(S,8) | |
| |<-----------------| | | |<-----------------| |
| t12:RESUME(S,8) | | | | t12:RESUME(S,8) | | |
|<-----------------|------------------------------------>| |<-----------------|------------------------------------>|
| t13:RTP(S) | | | | t13:RTP(S) | | |
|----------------->| | | |----------------->| | |
| | t14:RTP(S) | | | | t14:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
Figure 19: Pause and Resume Operation Between One Sender and Two Figure 19: Pause and Resume Operation between One Sender and Two
Receivers Through Relay Receivers through Relay
Figure 19 explains the pause and resume operations when a transport Figure 19 explains the pause and resume operations when a transport
Relay is involved between a sender and two receivers in an RTP Relay (Rel) is involved between a sender (S) and two receivers (R1
session. Each message exchange is represented by the time it and R2) in an RTP session. Each message exchange is represented by
happens. At time t1, Sender (S) starts sending an RTP stream to the the time it happens. At time t1, S starts sending an RTP stream to
Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and Rel, which forwards it to R1 and R2. R1 and R2 receives RTP data
R2 receives RTP data from Relay at t2. At this point, both R1 and R2 from Rel at t2. At this point, both R1 and R2 will send RTCP
will send RTCP Receiver Reports to S informing that they receive S's Receiver Reports to S informing that they received S's stream.
stream.
After some time (at t3), R1 chooses to pause the stream. On After some time (at t3), R1 chooses to pause the stream. On
receiving the PAUSE request from R1 at t4, S knows that there are at receiving the PAUSE request from R1 at t4, S knows that there is at
least one receiver that may still want to receive the data and uses a least one receiver that may still want to receive the data and uses a
non-zero hold-off period to wait for possible RESUME messages. R2 non-zero hold-off period to wait for possible RESUME messages. R2
did also receive the PAUSE request at time t4 and since it still did also receive the PAUSE request at time t4 and since it still
wants to receive the stream, it sends a RESUME for it at time t5, wants to receive the stream, it sends a RESUME for it at time t5,
which is forwarded to the sender S by the Relay. The sender S sees which is forwarded to sender S by Rel. S sees the RESUME at time t6
the RESUME at time t6 and continues to send data to Relay which and continues to send data to Rel, which forwards it to both R1 and
forwards to both R1 and R2. At t7, the receiver R2 chooses to pause R2. At t7, R2 chooses to pause the stream by sending a PAUSE request
the stream by sending a PAUSE request with an updated PauseID. The with an updated PauseID. S still knows that there is more than one
sender S still knows that there are more than one receiver (R1 and receiver (R1 and R2) that may want the stream and again waits a non-
R2) that may want the stream and again waits a non-zero hold-off zero hold-off period, after which, and not having received any
period, after which and not having received any disapproving RESUME, disapproving RESUME messages, it concludes that the stream must be
it concludes that the stream must be paused. S now stops sending the paused. S now stops sending the stream and replies with PAUSED to R1
stream and replies with PAUSED to R1 and R2. When any of the and R2. When any of the receivers (R1 or R2) choose to resume the
receivers (R1 or R2) chooses to resume the stream from S, in this stream from S, in this example R1, it sends a RESUME request to S
example R1, it sends a RESUME request to the sender (also seen by (also seen by R2). S immediately resumes the stream.
R2). The RTP sender immediately resumes the stream.
Consider also an RTP session which includes one or more receivers, Consider also an RTP session that includes one or more receivers,
paused sender(s), and a Relay. Further assume that a new participant paused sender(s), and a Relay. Further assume that a new participant
joins the session, which is not aware of the paused sender(s). On joins the session, which is not aware of the paused sender(s). On
receiving knowledge about the newly joined participant, e.g. any RTP receiving knowledge about the newly joined participant, e.g., any RTP
traffic or RTCP report (i.e. either SR or RR) from the newly joined traffic or RTCP report (i.e., either SR or RR) from the newly joined
participant, the paused sender(s) immediately sends PAUSED participant, the paused sender(s) immediately sends PAUSED
indications for the paused streams since there is now a receiver in indications for the paused streams since there is now a receiver in
the session that did not pause the sender(s) and may want to receive the session that did not pause the sender(s) and may want to receive
the streams. Having this information, the newly joined participant the streams. Having this information, the newly joined participant
has the same possibility as any other participant to resume the has the same possibility as any other participant to resume the
paused streams. paused streams.
11. IANA Considerations 11. IANA Considerations
This specification requests the following registrations from IANA: Per this specification, IANA has made the following registrations:
1. A new value for media stream pause / resume to be registered with 1. A new value for media stream pause/resume has been registered in
IANA in the "FMT Values for RTPFB Payload Types" registry located the "FMT Values for RTPFB Payload Types" registry located at the
at the time of publication at: http://www.iana.org/assignments/ time of publication at: <http://www.iana.org/assignments/rtp-
rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8 parameters>
Value: TBA1 Value: 9
Name: PAUSE-RESUME Name: PAUSE-RESUME
Long Name: Media Pause / Resume Long Name: Media Pause/Resume
Reference: This RFC
Reference: RFC 7728
2. A new value "pause" to be registered with IANA in the "Codec 2. A new value "pause" to be registered with IANA in the "Codec
Control Messages" registry located at the time of publication at: Control Messages" registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters/sdp- <http://www.iana.org/assignments/sdp-parameters>
parameters.xhtml#sdp-parameters-19
Value Name: pause Value Name: pause
Long Name: Media Pause / Resume Long Name: Media Pause/Resume
Usable with: ccm Usable with: ccm
Reference: This RFC Reference: RFC 7728
12. Security Considerations 12. Security Considerations
This document extends the CCM [RFC5104] and defines new messages, This document extends CCM [RFC5104] and defines new messages, i.e.,
i.e. PAUSE, RESUME, PAUSED, and REFUSED. The exchange of these new PAUSE, RESUME, PAUSED, and REFUSED. The exchange of these new
messages have some security implications, which need to be addressed messages has some security implications, which need to be addressed
by the user. by the user.
The messages defined in this specification can have substantial The messages defined in this specification can have a substantial
impact on the perceived media quality if used in a malicious way. impact on the perceived media quality if used in a malicious way.
First of all, there is the risk for Denial of Service (DoS) on any First of all, there is the risk for Denial of Service (DoS) on any
RTP session that uses the PAUSE-RESUME functionality. By injecting RTP session that uses the PAUSE-RESUME functionality. By injecting
one or more PAUSE requests into the RTP session, an attacker can one or more PAUSE requests into the RTP session, an attacker can
potentially prevent any media from flowing, especially when the hold- potentially prevent any media from flowing, especially when the hold-
off period is zero. The injection of PAUSE messages is quite simple, off period is zero. The injection of PAUSE messages is quite simple,
requiring knowledge of the SSRC and the PauseID. This information is requiring knowledge of the SSRC and the PauseID. This information is
visible to an on-path attacker unless RTCP messages are encrypted. visible to an on-path attacker unless RTCP messages are encrypted.
Even off-path attacks are possible as signalling messages often carry Even off-path attacks are possible as signaling messages often carry
the SSRC value, while the 16-bit PauseID have to be guessed or tried. the SSRC value, while the 16-bit PauseID has to be guessed or tried.
The way of protecting the RTP session from these injections is to The way of protecting the RTP session from these injections is to
perform source authentication combined with message integrity, to perform source authentication combined with message integrity to
prevent other than intended session participants from sending these prevent other than intended session participants from sending these
messages. The security solution should provide replay protection. messages. The security solution should provide replay protection.
Otherwise, if a session is long-lived enough for the PauseID value to Otherwise, if a session is long lived enough for the PauseID value to
wrap, an attacker could replay old messages at the appropriate time wrap, an attacker could replay old messages at the appropriate time
to influence the media sender state. There exist several different to influence the media sender state. There exist several different
choices for securing RTP sessions to prevent this type of attack. choices for securing RTP sessions to prevent this type of attack.
SRTP is the most common, but also other methods exist as discussed in The Secure Real-time Transport Protocol (SRTP) is the most common,
"Options for Securing RTP Sessions" [RFC7201]. but also other methods exist as discussed in "Options for Securing
RTP Sessions" [RFC7201].
Most of the methods for securing RTP however do not provide source Most of the methods for securing RTP, however, do not provide source
authentication of each individual participant in a multi-party use authentication of each individual participant in a multiparty use
case. In case one of the session participants is malicious, it can case. In case one of the session participants is malicious, it can
wreck significant havoc within the RTP session and similarly cause a wreck significant havoc within the RTP session and similarly cause a
DoS on the RTP session from within. That damage can also be DoS on the RTP session from within. That damage can also be
attempted to be obfuscated by having the attacker impersonate other attempted to be obfuscated by having the attacker impersonate other
endpoints within the session. These attacks can be mitigated by endpoints within the session. These attacks can be mitigated by
using a solution that provides true source authentication of all using a solution that provides true source authentication of all
participants' RTCP packets. However, that has other implications. participants' RTCP packets. However, that has other implications.
For multi-party sessions including a middlebox, that middlebox is For multiparty sessions including a middlebox, that middlebox is
RECOMMENDED to perform checks on all forwarded RTCP packets so that RECOMMENDED to perform checks on all forwarded RTCP packets so that
each participant only uses its set of SSRCs, to prevent the attacker each participant only uses its set of SSRCs to prevent the attacker
utilizing another participant's SSRCs. An attacker that can send a from utilizing another participant's SSRCs. An attacker that can
PAUSE request that does not reach any other participants than the send a PAUSE request that does not reach any participants other than
media sender can cause a stream to be paused without providing the media sender can cause a stream to be paused without providing
opportunity for opposition. This is mitigated in multi-party opportunity for opposition. This is mitigated in multiparty
topologies that ensure that requests are seen by all or most of the topologies that ensure that requests are seen by all or most of the
RTP session participants, enabling these participants to send RESUME. RTP session participants, enabling these participants to send a
In topologies with middleboxes that consume and process PAUSE RESUME. In topologies with middleboxes that consume and process
requests, the middlebox can also mitigate such behavior as it will PAUSE requests, the middlebox can also mitigate such behavior as it
commonly not generate or forward a PAUSE message if it knows of will commonly not generate or forward a PAUSE message if it knows of
another participant having use for the media stream. another participant having use for the media stream.
The above text has been focused on using the PAUSE message as the The above text has been focused on using the PAUSE message as the
tool for malicious impact on the RTP session. That is because of the tool for malicious impact on the RTP session. That is because of the
greater impact from denying users access to RTP media streams. In greater impact from denying users access to RTP media streams. In
contrast, if an attacker attempts to use RESUME in a malicious contrast, if an attacker attempts to use RESUME in a malicious
purpose, it will result in that the media streams are delivered. purpose, it will result in the media streams being delivered.
However, such an attack basically prevents the use the Pause and However, such an attack basically prevents the use of the pause and
Resume functionality. Thus, potentially forcing a reduction of the resume functionality. Thus, it potentially forces a reduction of the
media quality due to limitation in available resources, like media quality due to limitation in available resources, like
bandwidth that must be shared. bandwidth that must be shared.
The session establishment signalling is also a potential venue of The session establishment signaling is also a potential venue of
attack, as that can be used to prevent the enabling of Pause and attack, as that can be used to prevent the enabling of pause and
Resume functionality by modifying the signalling messages. The above resume functionality by modifying the signaling messages. The above
mitigation of attacks based on source authentication also requires mitigation of attacks based on source authentication also requires
the signalling system to securely handle identities, and assert that the signaling system to securely handle identities and assert that
only the intended identities are allowed into the RTP session and only the intended identities are allowed into the RTP session and
provided the relevant security contexts. provided with the relevant security contexts.
13. Contributors
Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/
Answer.
14. Acknowledgements
Daniel Grondal made valuable contributions during the initial
versions of this draft. The authors would also like to thank Emil
Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer
Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
review comments.
15. References 13. References
15.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 53, line 17 skipping to change at page 53, line 11
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, Control Protocol (RTCP) Flows", RFC 6263,
DOI 10.17487/RFC6263, June 2011, DOI 10.17487/RFC6263, June 2011,
<http://www.rfc-editor.org/info/rfc6263>. <http://www.rfc-editor.org/info/rfc6263>.
15.2. Informative References 13.2. Informative References
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [MULTI-STREAM-OPT]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work Work in Progress, draft-ietf-avtcore-rtp-multi-stream-
in progress), July 2015. optimisation-11, December 2015.
[I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015.
[I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-01 (work in progress), July 2015.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998, DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>. <http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>. October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
DOI 10.17487/RFC6190, May 2011, DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>. <http://www.rfc-editor.org/info/rfc6190>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>. <http://www.rfc-editor.org/info/rfc7478>.
Appendix A. Changes From Earlier Versions [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
NOTE TO RFC EDITOR: Please remove this section prior to publication. for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
A.1. Modifications Between Version -09 and -10 <http://www.rfc-editor.org/info/rfc7656>.
Changes based on AD review of changes:
o Editorial rewordings in Security Consideration
A.2. Modifications Between Version -08 and -09
Changes based on IETF last call and IESG comments.
o Expanded some acronyms on first usage.
o Clarified why this document updated RFC 5104.
o Removed some unused abbreviations.
o Clarified when TMMBR/TMMBN is expected to be used in Section 5.6.
o Mandate using SHALL repetition of PAUSED indications in
Section 6.4.
o Removed paragraph in Section 8.4 on PauseID and REFUSED as being
redundant.
o Transmission rules in Section 8.5 was reworded and stoped using
RFC 2119 terms, instead uses recommendations and lists
motivations.
o In Section 9 (Signalling) it was clarified that one SHOULD only
send messages supported by receivers, but provide example of cases
when one may still send messages not supported by every receiver
of that message. Also clarified that TMMBR/TMMBN for pause is
monolithic in capability.
o Security consideration was updated to consider replay attacks.
o Security consideration was updated to describe the mitigation
against malicous RTP session participants in multi-party cases
that seeing all messages provide.
A.3. Modifications Between Version -07 and -08
Changes based on IESG AD Evaluation.
o Moved the mentioning of RTCWEB RFC7478 API requirements out from
3.1 to section 3, adding a couple of clarifying sentences.
o Highlighted that the use case in section 3.4 deals with a
different direction of the pause request than the previous use
cases.
o Added text on partial capability and interoperability to section
5.1.
o Added an overview explanation of PauseID as a new section 5.2, and
moved a few sentences on PauseID from other 5.x sections in there.
o Changed all occurrences of "available" and "valid" PauseID to the
more clear "current" PauseID, and re-phrased sentences involving
that to become more clear.
o Changed all occurrences of "smaller" and "larger" PauseID to
"past" and "future", respectively, to better align with "current".
o Removed an incorrect sentence in 5.2 about when it is not feasible
to send repeated PAUSE.
o Changed a few capitalized words that could be taken as normative
text from section 5, which is intended to be a non-normative
description.
o Added some explanatory text on why RTP stream is resumed when the
stream receiver that paused the stream leaves the RTP session to
last bullet in 6.3.1.
o Added caption to Figure 5.
o Moved the detailed description on what PauseID ranges are defined
as "past" and "future" before section 8.1, instead of having it in
section 8.1, and added a comment on the "not current" part of the
value range.
o Added text in section 8.1 on appropriate time to wait between
sending PAUSE, when the first PAUSE was rejected by a RESUME or a
REFUSED.
o Added text in section 8.3 on appropriate time to wait between
sending RESUME, when the first RESUME was rejected by a REFUSED.
o Added text in section 8.4 on time to wait before sending the
REFUSED request again, referencing sections 8.1 and 8.3.
o Added a couple of paragraphs in section 9 on partial capability
and interoperability, including a description on when different
config values are expected to be useful, and when they are not.
o Added arrows in Figure 19 to highlight that the Relay sends out
all received messages to all receivers, not only the first PAUSE
message.
o Changed references to RFC3264 and RFC4566 to be normative.
o Updated ietf-rtcweb-use-cases-and-requirements reference to be
RFC7478.
o Editorial improvements and clarifications.
A.4. Modifications Between Version -06 and -07
o Completely rewrote the Security Consideration section.
o Aligned text such that REFUSED is always referred to as a
notification, not indication.
o Added and changed text in several places, clarifying the case when
TMMBR/TMMBN bounding set overhead value matters, related to
whether local RTP stream sender or remote RTP stream receiver owns
the TMMBR 0 restriction, and the consequences this has on pause/
resume logic.
o Moved text on when to stop media stream transmission from when
receiving PAUSE and entering pausing state, to when entering
paused or local paused states.
o Added text on how to determine if there is a single receiver or
not, aligned with what is specified in draft-ietf-avtcore-multi-
stream, adding a reference to draft-ietf-avtcore-multi-stream-
optimisation to be able to use a single RTCP reporting group as
one criteria.
o Added clarifying text on repeating PAUSED and RESUME messages only
as long as remaining in the relevant state.
o Clarified that it is the RTP stream sender's responsibility to
leave local paused state when the condition causing that state is
no longer true.
o Added text to better allow for extensions to this specification,
since there is already some text on extensions.
o Corrected and amended ABNF to make CCM pause parameters order-
independent, allow for a larger config pause attribute value
range, and added corresponding text to handle that additional
flexibility.
o Added SDP rules on how to handle unknown pause attribute values.
o Clarified how to handle an SDP with both "ccm pause" and "ccm
tmmbr".
o Changed from "Translator" to "Relay" in examples, to make it
clearer in relation to the updated topologies draft.
o Editorial improvements.
A.5. Modifications Between Version -05 and -06
o Clarified in Message Details section for PAUSED that
retransmission of the message can be used to increase the
probability that the message reaches the receiver in a timely
fashion, and also added text that says the number of repetitions
can be tuned to observed loss rate and the desired loss
probability. Also removed Editor's notes on potential ACK for
unsolicited PAUSED, since the issue is solved by the above.
o In the same section as above, added that PAUSED may be included in
all compound RTCP reports, as long as the negotiated RTCP
bandwidth is not exceeded.
o In Message Details section for RESUME, added text on
retransmission similar to the one mentioned for PAUSED above.
Also included text that says such retransmission SHOULD stop as
soon as RTP packets or a REFUSED with a valid PauseID from the
targeted stream are received.
o Changed simulcast reference, since that draft was moved from
AVTCORE to MMUSIC and made WG draft.
o Changed End Point to Endpoint to reflect change in RTP Grouping
Taxonomy draft.
o Editorial improvements.
A.6. Modifications Between Version -04 and -05
o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and
timing of unsolicited PAUSED, to improve the message timeliness
and probability of reception.
A.7. Modifications Between Version -03 and -04
o Change of Copyright boilerplate
A.8. Modifications Between Version -02 and -03
o Changed the section on SDP signaling to be more explicit and clear
in what is supported, replacing the 'paused' parameter and the
'dir' attribute with a 'config' parameter that can take a value,
and an explicit listing of what each value means.
o Added a sentence in section on paused state (Section 6.3) that
pause must not affect RTP keepalive.
o Replaced REFUSE message name with REFUSED throughout, to better
indicate that it is not a command but a notification.
o Added text in a few places, clarifying that PAUSED message may be
used unsolicited due to RTP sender local considerations, and also
clarified the interaction between this usage and an RTP stream
receiver pausing the stream. Also added an example describing
this case.
o Clarified that when TMMBN 0 is used as PAUSED message, and when
sent unsolicited due to RTP sender local considerations, the TMMBN
message includes the RTP stream sender itself as part of the
bounding set.
o Clarified that there is no reply to a PAUSED indication.
o Improved the IANA section.
o Editorial improvements.
A.9. Modifications Between Version -01 and -02
o Replaced most text on relation with other signaling technologies [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
in previous section 5 with a single, summarizing paragraph, as DOI 10.17487/RFC7667, November 2015,
discussed at IETF 90 in Toronto, and placed it as the last sub- <http://www.rfc-editor.org/info/rfc7667>.
section of section 4 (design considerations).
o Removed unused references. [SDP-SIMULCAST]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", Work in
Progress, draft-ietf-mmusic-sdp-simulcast-04, February
2016.
A.10. Modifications Between Version -00 and -01 Acknowledgments
o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE Daniel Grondal made valuable contributions during the initial
signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0 versions of this document. The authors would also like to thank Emil
Ivov, Christian Groves, David Mandelberg, Meral Shirazipour, Spencer
Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
review comments.
o Improved alignment with RTP Taxonomy draft, including the change Contributors
of Packet Stream to RTP Stream
o Editorial improvements Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed
significantly to the SDP "config" pause attribute and its use in
offer/answer.
Authors' Addresses Authors' Addresses
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
Azam Akram Azam Akram
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107142658 Phone: +46107142658
Email: muhammad.azam.akram@ericsson.com Email: akram.muhammadazam@gmail.com
URI: www.ericsson.com URI: www.ericsson.com
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
skipping to change at page 60, line 14 skipping to change at page 55, line 35
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE- 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107148287 Phone: +46107148287
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 348 change blocks. 
1109 lines changed or deleted 873 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/