draft-ietf-avtext-rtp-stream-pause-07.txt   draft-ietf-avtext-rtp-stream-pause-08.txt 
Network Working Group B. Burman Network Working Group B. Burman
Internet-Draft A. Akram Internet-Draft A. Akram
Updates: 5104 (if approved) Ericsson Updates: 5104 (if approved) Ericsson
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: September 10, 2015 Huawei Technologies Expires: January 4, 2016 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
March 9, 2015 July 3, 2015
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-07 draft-ietf-avtext-rtp-stream-pause-08
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 Real-time Transport Protocol (RTP) for real time
data transport. This document extends the Codec Control Messages data transport. This document extends the Codec Control Messages
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on January 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 11
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 13
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 14
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15
5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15 5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16 5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 16
5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 18 5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 17
5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19 5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 18
5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 20
6. Participant States . . . . . . . . . . . . . . . . . . . . . 20 6. Participant States . . . . . . . . . . . . . . . . . . . . . 20
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 22 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 22
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 23
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 23
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 23 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 24
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 26 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 30 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 31
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 33 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 35 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 37 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 39
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 41 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 43 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 48 15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 49 15.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 50 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 53
A.1. Modifications Between Version -06 and -07 . . . . . . . . 50 A.1. Modifications Between Version -07 and -08 . . . . . . . . 53
A.2. Modifications Between Version -05 and -06 . . . . . . . . 51 A.2. Modifications Between Version -06 and -07 . . . . . . . . 55
A.3. Modifications Between Version -04 and -05 . . . . . . . . 52 A.3. Modifications Between Version -05 and -06 . . . . . . . . 56
A.4. Modifications Between Version -03 and -04 . . . . . . . . 52 A.4. Modifications Between Version -04 and -05 . . . . . . . . 56
A.5. Modifications Between Version -02 and -03 . . . . . . . . 52 A.5. Modifications Between Version -03 and -04 . . . . . . . . 56
A.6. Modifications Between Version -01 and -02 . . . . . . . . 53 A.6. Modifications Between Version -02 and -03 . . . . . . . . 57
A.7. Modifications Between Version -00 and -01 . . . . . . . . 53 A.7. Modifications Between Version -01 and -02 . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 A.8. Modifications Between Version -00 and -01 . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 being 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 Offer/Answer [RFC3264]. [RFC3261] with SDP [RFC4566] Offer/Answer [RFC3264].
Centralized nodes, like RTP Mixers or MCUs, which either uses logic Centralized nodes, like RTP Mixers or MCUs, which either uses logic
based on voice activity, other measurements, or user input could based on voice activity, other measurements, or user input could
reduce the resources consumed in both the sender and the network by reduce the resources consumed in both the sender and the network by
temporarily pausing the RTP streams that aren't required by the RTP temporarily pausing the RTP streams that aren't required by the RTP
Mixer. If the number of conference participants are greater than Mixer. If the number of conference participants are greater than
what the conference logic has chosen to present simultaneously to what the conference logic has chosen to present simultaneously to
receiving participants, some participant RTP streams sent to the RTP receiving participants, some participant RTP streams sent to the RTP
Mixer may not need to be forwarded to any other participant. Those Mixer may not need to be forwarded to any other participant. Those
RTP streams could then be temporarily paused. This becomes RTP streams could then be temporarily paused. This becomes
especially useful when the media sources are provided in multiple especially useful when the media sources are provided in multiple
encoding versions (Simulcast) [I-D.ietf-mmusic-sdp-simulcast] or with encoding versions (Simulcast) [I-D.ietf-mmusic-sdp-simulcast] or with
Multi-Session Transmission (MST) of scalable encoding such as SVC Multi-Session Transmission (MST) of scalable encoding such as SVC
[RFC6190]. There may be some of the defined encodings or combination [RFC6190]. There may be some of the defined encodings or combination
of scalable layers that are not used or cannot be used all of the of scalable layers that are not used or cannot be used all of the
time, for example due to temporarily limited network or processing time. As an example, a centralized node may choose to pause such
resources, and a centralized node may choose to pause such RTP unused RTP streams without being explicitly requested to do so, maybe
streams without being requested to do so, but anyway send an explicit due to temporarily limited network or processing resources. It may
indication that the stream is paused. then also send an explicit indication that the streams are paused.
As the RTP streams required at any given point in time is highly As the set of RTP streams required at any given point in time is
dynamic in such scenarios, using the out-of-band signaling channel highly dynamic in such scenarios, using the out-of-band signaling
for pausing, and even more importantly resuming, an RTP stream is channel for pausing, and even more importantly resuming, an RTP
difficult due to the performance requirements. Instead, the pause stream is difficult due to the performance requirements. Instead,
and resume signaling should be in the media plane and go directly the pause and resume signaling should be in the media plane and go
between the affected nodes. When using RTP [RFC3550] for media directly between the affected nodes. When using RTP [RFC3550] for
transport, using Extended RTP Profile for Real-time Transport Control media transport, using the Extended RTP Profile for Real-time
Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585]
appropriate. No currently existing RTCP feedback message explicitly appears appropriate. No currently existing RTCP feedback message
supports pausing and resuming an incoming RTP stream. As this explicitly supports pausing and resuming an incoming RTP stream. As
affects the generation of packets and may even allow the encoding this affects the generation of packets and may even allow the
process to be paused, the functionality appears to match Codec encoding process to be paused, the functionality appears to match
Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Codec Control Messages in the RTP Audio-Visual Profile with Feedback
[RFC5104] and it is proposed to define the solution as a Codec (AVPF) [RFC5104]. This document defines the solution as a Codec
Control Message (CCM) extension. Control Message (CCM) 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. whenever possible.
2. Definitions 2. Definitions
2.1. Abbreviations 2.1. Abbreviations
skipping to change at page 7, line 29 skipping to change at page 7, line 29
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.
2.3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
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
following API requirements in Appendix A, used also by W3C WebRTC WG:
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
a peer mute, status must be preserved in the stream received by
the peer.
A9 The Web API must provide means for the web application to cease
the sending of a stream to a peer.
This document provides means to optimize transport usage by stop
sending muted streams and start sending again when unmuting. It is
here assumed that "mute" above can be taken to apply also to other
media than audio. At the time of publication for this specification,
RTCWEB 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
skipping to change at page 8, line 11 skipping to change at page 8, line 29
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, and neither is it 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 than the
sender and the single receiver of that stream. sender and the single receiver of that stream.
RTCWEB WG's use case and requirements document
[I-D.ietf-rtcweb-use-cases-and-requirements] defines the following
API requirements in Appendix A, used also by W3C WebRTC WG:
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
a peer mute status must be preserved in the stream received by the
peer.
A9 The Web API must provide means for the web application to cease
the sending of a stream to a peer.
This memo provides means to optimize transport usage by stop sending
muted streams and start sending again when unmuting.
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 [I-D.ietf-avtcore-rtp-topologies-update].
The main reason for this is that it provides a very consistent view The main reason for this is that it provides a very consistent view
of the RTP session towards each participant. That is accomplished of the RTP session towards each participant. That is accomplished
through the Mixer originating its' own streams, identified by SSRC, through the Mixer originating its own streams, identified by distinct
and any RTP streams sent to the participants will be sent using those SSRC values, and any RTP streams sent to the participants will be
SSRCs. If the Mixer wants to identify the underlying media sources sent using those SSRC values. If the Mixer wants to identify the
for its' conceptual streams, it can identify them using CSRC. The underlying media sources for its conceptual streams, it can identify
stream the Mixer provides can be an actual mix of multiple media them using CSRC. The stream the Mixer provides can be an actual mix
sources, but it might also be switching received streams as described of multiple media sources, but it might also be switching received
in Sections 3.6-3.8 of [I-D.ietf-avtcore-rtp-topologies-update]. streams as described in Sections 3.6-3.8 of
[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 that are delivered to a given receiver, A, can depend Which streams from clients B, C and D that are delivered to a given
on several things. It can either be the RTP Mixer's own logic and receiver, A, can depend on several things. It can either be the RTP
measurements such as voice activity on the incoming audio streams. Mixer's own logic and measurements such as voice activity on the
It can be that the number of sent media sources exceed what is incoming audio streams. It can be that the number of sent media
reasonable to present simultaneously at any given receiver. It can sources exceed what is reasonable to present simultaneously at any
also be a human controlling the conference that determines how the given receiver. It can also be a human controlling the conference
media should be mixed; this would be more common in lecture or that determines how the media should be mixed; this would be more
similar applications where regular listeners may be prevented from common in lecture or similar applications where regular listeners may
breaking into the session unless approved by the moderator. The be prevented from breaking into the session unless approved by the
streams may also be part of a Simulcast moderator. The streams may also be part of a Simulcast
[I-D.ietf-mmusic-sdp-simulcast] or scalable encoded (for Multi- [I-D.ietf-mmusic-sdp-simulcast] or scalable encoded (for Multi-
Session Transmission) [RFC6190], thus providing multiple versions Session Transmission) [RFC6190], thus providing multiple versions
that can be delivered by the RTP stream sender. These examples that can be delivered by the RTP stream sender. These examples
indicate that there are numerous reasons why a particular stream indicate that there are numerous reasons why a particular stream
would not currently be in use, but must be available for use at very 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 short notice if any dynamic event occurs that causes a different
stream selection to be done in the Mixer. 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 to pause a particular stream from being delivered to it. It request the RTP stream sender to pause a particular stream. The
also needs to be able to resume delivery with minimal delay. Mixer also needs to be able to request the RTP stream sender to
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 makes it desirable
to 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 available
Mixer network or processing resources. An RTP stream receiver that Mixer network or processing resources. An RTP stream receiver that
no longer receives an RTP stream could interpret this as an error no longer receives an RTP stream could interpret this as an error
condition and try to take action to re-establish the RTP stream. condition and try to take action to re-establish the RTP stream.
Such action would likely be undesirable if the RTP stream was in fact Such action would likely be undesirable if the RTP stream was in fact
deliberately paused by the Mixer. Undesirable RTP stream receiver deliberately paused by the Mixer. Undesirable RTP stream receiver
actions could be avoided if the Mixer is able to explicitly indicate actions could be avoided if the Mixer is able to explicitly indicate
that an RTP stream is deliberately paused. that an RTP stream is deliberately paused.
skipping to change at page 10, line 32 skipping to change at page 10, line 42
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 ignore
the stream and is not impacted as much as above. the stream and is not impacted as much as above.
In this use case there are several receivers of a stream and special In this use case there are several receivers of a stream and special
care must be taken as not to pause a stream that is still wanted by care must be taken as not to pause a stream that is still wanted by
some receivers. some receivers.
3.4. Media Receiver to RTP Mixer 3.4. Media Receiver to RTP Mixer
An Endpoint in Figure 2 could potentially request to pause the In this use case, the direction of the request to pause is the
delivery of a given stream. Possible reasons include the ones in the opposite compared to the two previous use cases. An Endpoint in
point to point case (Section 3.1) above. Figure 2 could potentially request to pause the delivery of a given
stream. Possible reasons include the ones in the point to point case
(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.
skipping to change at page 11, line 30 skipping to change at page 11, line 44
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 related to pause and resume must be transmitted to the sender in a
real-time in order for them to be purposeful. The pause operation is timely fashion in order for them to be purposeful. The pause
arguably not very time critical since it mainly provides a reduction operation is arguably not as time critical as the resume operation,
of resource usage. Timely handling of the resume operation is since it mainly provides a reduction of resource usage. Timely
however likely to directly impact the end-user's perceived quality handling of the resume operation is however likely to directly impact
experience, since it affects the availability of media that the user the end-user's perceived quality experience, since it affects the
expects to receive more or less instantly. It may also be highly availability of media that the user expects to receive more or less
desirable for a receiver to quickly learn that an RTP stream is instantly. It may also be highly desirable for a receiver to quickly
intentionally paused on the RTP sender's own behalf. learn that an RTP stream is intentionally paused on the RTP sender's
own behalf.
4.2. Message Direction 4.2. Message Direction
It is the responsibility of an RTP stream receiver, who 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 who likes 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. The reason is that in RTP topologies where still wishes to receive.
the stream is shared between multiple receivers, a single receiver on
that shared network, independent of it being multicast, a mesh with The reason is that in RTP topologies where the stream is shared
joint RTP session or a transport Translator based, must not single- between multiple receivers, a single receiver on that shared network
handedly cause the stream to be paused without letting all other must not single-handedly cause the stream to be paused without
receivers to voice their opinions on whether or not the stream should letting all other receivers to voice their opinions on whether or not
be paused. A consequence of this is that a newly joining receiver, the stream should be paused. Such shared networks can for example be
for example indicated by an RTCP Receiver Report containing both a multicast, a mesh with a joint RTP session, or a transport Translator
new SSRC and a CNAME that does not already occur in the session, based network. A consequence of this is that a newly joining
firstly needs to learn the existence of paused streams, and secondly receiver firstly needs to learn the existence of paused streams, and
should be able to resume any paused stream. Any single receiver secondly should be able to resume any paused stream. A newly joining
wanting to resume a stream should also cause it to be resumed. An receiver can for example be detected through an RTCP Receiver Report
important exception to this is when the RTP stream sender is aware of containing both a new SSRC and a CNAME that does not already occur in
conditions that makes it desirable or even necessitates to pause the the session. Any single receiver wanting to resume a stream should
RTP stream on its own behalf, without being explicitly asked to do also cause it to be resumed. An important exception to this is when
so. Such local consideration in the RTP sender takes precedence over the RTP stream sender is aware of conditions that makes it desirable
RTP receiver wishes to receive the stream. or even necessitates to pause the RTP stream on its own behalf,
without being explicitly asked to do so. Such local consideration in
the RTP sender takes precedence over RTP receiver 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, i.e.
the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP
stream sender and are effective, i.e., an active RTP stream sender stream sender and are effective, i.e., an active RTP stream sender
pauses, or a resuming RTP stream sender have media data to transmit, pauses, or a resuming RTP stream sender have media data to transmit,
it is immediately seen from the arrival or non-arrival of RTP packets it is immediately seen from the arrival or non-arrival of RTP packets
for that RTP stream. Thus, no explicit acknowledgments are required for that RTP stream. Thus, no explicit acknowledgments are required
in this case. 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. 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 round
trip time into account, and will also need to take the normal RTCP trip time into account, and will also need to take the normal RTCP
bandwidth and timing rules applicable to the RTP session into bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback. account, when scheduling retransmission of feedback.
skipping to change at page 13, line 43 skipping to change at page 14, line 12
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 references 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 [RFC4566] 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 it will need to traverse the entire signaling
path to reach the signaling destination (either the remote Endpoint path to reach the signaling destination (either the remote Endpoint
or the entity controlling the RTP Mixer), across any signaling or the entity controlling the RTP Mixer), across any signaling
proxies that potentially also has to process the SDP content to proxies that potentially also has to process the SDP content to
determine if they are expected to act on it. The amount of bandwidth determine if they are expected to act on it. The amount of bandwidth
required for a SIP/SDP-based signaling solution is in the order of at required for a SIP/SDP-based signaling solution is in the order of at
least 10 times more than an RTCP-based solution. Especially for UA least 10 times more than an RTCP-based solution. Especially for UA
sitting on mobile wireless access, this will risk introducing delays sitting on mobile wireless access, this will risk introducing delays
that are too long (Section 4.1) to provide a good user experience, that are too long (Section 4.1) to provide a good user experience,
and the bandwidth cost may also be considered infeasible compared to and the bandwidth cost may also be considered infeasible compared to
skipping to change at page 14, line 22 skipping to change at page 14, line 39
Based on those considerations, RTCP is chosen as signaling protocol Based on those considerations, RTCP is chosen as signaling protocol
for the pause and resume functionality. 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.
It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent This solution re-uses CCM TMMBR and TMMBN [RFC5104] to the extent
possible, and to define a small set of new RTCP feedback messages possible, and defines a small set of new RTCP feedback messages where
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, 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 standalone by the RTP stream sender to indicate a local decision
to pause, and inform any receiver of the fact that halting media to pause, and inform any receiver of the fact that halting media
delivery is deliberate and which RTP packet was the last transmitted. 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.5. 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 in 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 are 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 TMMBR
0, and any reference to PAUSED is equally applicable to TMMBN 0. 0, and any reference to PAUSED is equally applicable to TMMBN 0.
Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the
text, unless there is specific reason to do so. 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
Media Sender to pause or resume. Consequently, in that same use case
only the Media Sender has capability to pause and resume its sent
streams based on requests from the RTP Mixer. Allowing for partial
implementation of this specification is not believed to hamper
interoperability, as long as the subsets are well defined and
describe a consistent functionality, including a description of how a
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. Requesting to Pause 5.2. PauseID
An RTP stream receiver can choose to request PAUSE at any time, All messages defined in this specification (Section 8) contain a
subject to AVPF timing rules. PauseID, satisfying the design consideration on sequence numbering
(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
messages. Instead, it numbers an entire "pause and resume operation"
for the RTP stream, typically keeping PauseID constant for multiple,
related messages. The PauseID value used during such operation is
called the current PauseID. A new "pause and resume operation" is
defined to start when the RTP stream sender resumes the RTP stream
after it was being paused. The current PauseID is then incremented
by one, in modulo arithmetic. In the subsequent descriptions below,
it is sometimes necessary to refer to PauseID values that were
already used as current PauseID, which is denoted as past PauseID.
It should be noted that since PauseID uses modulo arithmetic, a past
PauseID may have a larger value than the current PauseID. Since
PauseID uses modulo arithmetic, it is also useful to define what
PauseID values that are considered "past", to clearly separate it
from what could be considered "future" PauseID values. Half of the
entire PauseID value range is chosen to represent past PauseID, while
a quarter of the PauseID value range is chosen to represent future
values. The remaining quarter of the PauseID value range is
intentionally left undefined in that respect.
The PAUSE request contains a PauseID, which is incremented by one (in 5.3. Requesting to Pause
modulo arithmetic) with each PAUSE request that is not a re-
transmission. The PauseID is scoped by and thus a property of the An RTP stream receiver can choose to send a PAUSE request at any
targeted RTP stream (SSRC). time, subject to AVPF timing rules.
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.4) for the PAUSE request to disapprove by sending a RESUME (Section 5.5) for the
same stream and with the same PauseID as in the disapproved PAUSE. same stream and with the same current PauseID as in the PAUSE being
If such disapproving RESUME arrives at the RTP stream sender during disapproved. If such disapproving RESUME arrives at the RTP stream
the hold-off period before the stream is paused, the pause is not sender during the hold-off period before the stream is paused, the
performed. In point-to-point configurations, the hold-off period may pause is not performed. In point-to-point configurations, the hold-
be set to zero. Using a hold-off period of zero is also appropriate off period may be set to zero. Using a hold-off period of zero is
when using TMMBR 0 and in line with the semantics for that message. also appropriate when using TMMBR 0 and in line with the semantics
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
available 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.3) 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 a stream receiver A for a PAUSE request sent by a stream sender
B, but that the PAUSE sender (B) did not receive the RESUME (from A) B, but 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 PauseID. If using PAUSE request can be re-transmitted using the same current PauseID.
TMMBR 0 the request MAY be re-transmitted when the requester fails to If using TMMBR 0, the request MAY be re-transmitted when the
receive a TMMBN 0 confirmation. requester 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 PauseID from the disapproved PAUSE is invalidated by the RESUME the pause and resume operation for that PauseID is concluded, the
and any new PAUSE must use an incremented PauseID (in modulo current PauseID is updated, and any new PAUSE must therefore use the
arithmetic) to be effective. new current PauseID to be effective.
An RTP stream sender receiving a PAUSE not using the available An RTP stream sender receiving a PAUSE not using the current PauseID
PauseID informs the RTP stream receiver sending the ineffective PAUSE informs the RTP stream receiver sending the ineffective PAUSE of this
of this condition by sending a REFUSED notification that contains the condition by sending a REFUSED notification that contains the current
next available PauseID value. This REFUSED also informs the RTP PauseID value.
stream receiver that it is probably not feasible to send another
PAUSE for some time, not even with the available PauseID, since there
are other RTP stream receivers that wish to receive the stream.
A similar situation where an ineffective PauseID is chosen can appear A situation where an ineffective PauseID is chosen can appear when a
when a new RTP stream receiver joins a session and wants to PAUSE a new RTP stream receiver joins a session and wants to PAUSE a stream,
stream, but does not yet know the available PauseID to use. The but does not yet know the current PauseID to use. The REFUSED
REFUSED notification will then provide sufficient information to notification will then provide sufficient information to create a
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 PauseID would otherwise have a REFUSED. In this case, if the used current PauseID would otherwise
been effective, REFUSED contains the same PauseID as in the PAUSE have been effective, REFUSED contains the same current PauseID as in
request, and the PauseID is kept as available. Note that when using the PAUSE request. Note that when using TMMBR 0 as PAUSE, that
TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to request cannot be refused (TMMBN > 0) due to the existing restriction
the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN in section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current
shall contain the current bounding set, and the fact that a TMMBR 0 bounding set, and the fact that a TMMBR 0 will always be the most
will always be the most restrictive point in any bounding set, restrictive point in any bounding set, regardless of bounding set
regardless of 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 for an RTP
stream that was already at least once responded with REFUSED and the stream that was already at least once responded with REFUSED and the
condition causing REFUSED remains, those additional REFUSED should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSED can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical PAUSE requests. several identical PAUSE requests.
5.3. 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 either be as a result of receiving a PAUSE, or be based on
some local sender consideration. When it does, it sends a PAUSED some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. Note that PauseID is indication, containing the current PauseID. Note that current
incremented when sending an unsolicited PAUSED (without having PauseID in an unsolicited PAUSED (without having received a PAUSE),
received a PAUSE). It also sends the PAUSED indication in the next is incremented compared to previously sent PAUSED. It also sends the
two regular RTCP reports, given that the pause condition is then PAUSED indication in the next two regular RTCP reports, given that
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
skipping to change at page 17, line 30 skipping to change at page 18, line 27
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 first hand information This provides RTP stream receivers with first hand information
allowing them to know whether they lost any packets just before the allowing 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 control
algorithms. algorithms.
If the RTP stream sender receives PAUSE requests with the available 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 SR or RR. Including PAUSED in sent together with any regular RTCP SR or RR. Including PAUSED in
this way allows RTP stream receivers joining while the stream is this way allows RTP stream receivers joining while the stream is
paused to quickly know that there is a paused stream, what the last paused to quickly know that there is a paused stream, what the last
sent extended RTP sequence number was, and what the next available sent extended RTP sequence number was, and what the current PauseID
PauseID is to be able to construct valid PAUSE and RESUME requests at is to be able to construct valid PAUSE and RESUME requests at a later
a later stage. 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. It should in
addition continue to include PAUSED indications in at least two addition continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
5.4. Requesting to Resume 5.5. Requesting to Resume
An RTP stream receiver can request to resume a stream with a RESUME An RTP stream receiver can request the RTP stream sender to resume a
request at any time, subject to AVPF timing rules. The RTP stream stream with a RESUME request at any time, subject to AVPF timing
receiver must include the available PauseID in the RESUME request for rules. The RTP stream receiver must include the current PauseID in
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
correct available PauseID resumes the stream at the earliest current PauseID resumes the stream at the earliest opportunity.
opportunity. Receiving RESUME requests for a stream that is not Receiving RESUME requests for a stream that is not paused does 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 MAY then respond with a REFUSED containing the same stream sender can then respond with a REFUSED containing the current
PauseID as in the RESUME. When receiving such REFUSED with a 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
then avoid sending further RESUME requests for some reasonable amount avoid sending further RESUME requests for some reasonable amount of
of time, to allow the condition to clear. An RTP stream sender time, to allow the condition to clear. An RTP stream sender having
having sent a REFUSED SHOULD resume the stream through local sent a REFUSED SHOULD resume the stream through local considerations
considerations (see below) when the condition that caused the REFUSED (see below) when the condition that caused the REFUSED is no longer
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 for an RTP
stream that was already at least once responded with REFUSED and the stream that was already at least once responded with REFUSED and the
condition causing REFUSED remains, those additional REFUSED should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSED can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical RESUME requests. several identical RESUME requests.
A pausing RTP stream sender can apply local considerations and MAY 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, it cannot be resumed due to local considerations. If the RTP stream, resumption is prevented by protocol, even if the RTP
TMMBR/TMMBN signaling is used, if the RTP stream is paused due to sender would like to resume due to local considerations. If TMMBR/
local considerations (Section 5.3), and the RTP stream sender thus TMMBN signaling is used, if the RTP stream is paused due to local
owns the TMMBN bounding set, the RTP stream can also be resumed due considerations (Section 5.4), and the RTP stream sender thus owns the
to local considerations. TMMBN bounding set, the RTP stream can be resumed due to local
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, the temporal temporal redundancy between samples such as video, it may not be
dependency between samples taken before the pause and at the time appropriate to use such temporal dependency in the encoding between
instant the stream is resumed may not be appropriate to use in the samples taken before the pause and at the time instant the stream is
encoding. Should such temporal dependency between before and after resumed. Should such temporal dependency between media samples
the media was paused be used by the RTP stream sender, it requires before and after the media was paused be used by the RTP stream
the RTP stream receiver to have saved the sample from before the sender, it requires the RTP stream receiver to have saved the samples
pause for successful continued decoding when resuming. The use of from before the pause for successful continued decoding when
this temporal dependency is left up to the RTP stream sender. If resuming. The use of this temporal dependency of media samples from
temporal dependency is not used when the RTP stream is resumed, the before the pause is left up to the RTP stream sender. If temporal
first encoded sample after the pause will not contain any temporal dependency on samples from before the pause is not used when the RTP
dependency to samples before the pause (for video it may be a so- stream is resumed, the first encoded sample after the pause will not
called intra picture). If temporal dependency to before the pause is contain any temporal dependency on samples before the pause (for
used by the RTP stream sender when resuming, and if the RTP stream video it may be a so-called intra picture). If temporal dependency
receiver did not save any sample from before the pause, the RTP on samples from before the pause is used by the RTP stream sender
stream receiver can use a FIR request [RFC5104] to explicitly ask for when resuming, and if the RTP stream receiver did not save any sample
a sample without temporal dependency (for video a so-called intra from before the pause, the RTP stream receiver can use a FIR request
picture), even at the same time as sending the RESUME. [RFC5104] to explicitly ask for a sample without temporal dependency
(for video a so-called intra picture), even at the same time as
sending the RESUME.
5.5. 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. resume.
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-
skipping to change at page 19, line 47 skipping to change at page 20, line 43
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 TMMBR restriction owner in the
TMMBN message bounding set. Also corresponds to a REFUSED TMMBN message bounding set. 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 TMMBR
>0, thus resulting in the stream sender becoming the owner of the >0, thus resulting in the stream sender becoming the owner of the
bounding set in the TMMBN message. bounding set in the TMMBN message.
TMMBN >0: Cannot be used as REFUSED notification when a stream is TMMBN >0: Cannot be used as 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.2. 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 sub-sections below. Any
references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL
be taken to apply to the extent possible also when TMMBR/TMMBN are be taken to apply to the extent possible also when TMMBR/TMMBN are
used (Section 5.5) for this functionality. 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 Figure 4: RTP Pause States
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 PauseID MUST be incremented [RFC3550]. When entering the state, the current PauseID MUST be
by one in modulo arithmetic. The RTP sequence number for the first incremented by one in modulo arithmetic. The RTP sequence number for
packet sent after a pause SHALL be incremented by one compared to the the first packet sent after a pause SHALL be incremented by one
highest RTP sequence number sent before the pause. The first RTP compared to the highest RTP sequence number sent before the pause.
Time Stamp for the first packet sent after a pause SHOULD be set The first RTP Time Stamp for the first packet sent after a pause
according to capture times at the source, meaning the RTP Time Stamp SHOULD be set according to capture times at the source, meaning the
difference compared to before the pause reflects the time the RTP RTP Time Stamp difference compared to before the pause reflects the
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
skipping to change at page 22, line 21 skipping to change at page 23, line 14
6.3.7 of RTP [RFC3550], following two conditions MUST also be 6.3.7 of RTP [RFC3550], 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 that caused the RTP stream to pause. If
that receiver sends an RTCP BYE message observed by the sender, that receiver sends an RTCP BYE message observed by the sender,
the sender SHALL resume the RTP stream. the sender SHALL resume the RTP stream. No receivers that were in
the RTP session when the stream was paused objected that the
stream was paused, but if there were so far undetected receivers
added to the session during pause, those may not have learned
about the existence of the paused stream, either because there was
no PAUSED sent for the paused RTP stream or those receivers did
not support PAUSED. Resuming the stream when the pausing party
leaves the RTP session allows those potentially undetected
receivers to learn 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.
skipping to change at page 23, line 25 skipping to change at page 24, line 25
The case above when using TMMBN 0 as PAUSED indication, being in The case above when using TMMBN 0 as 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
to leave the state whenever the conditions that caused the decision for leaving the state whenever the conditions that caused the
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
skipping to change at page 24, line 31 skipping to change at page 25, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
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: TBA1
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 32-bit
words minus one, including the header and any padding. words minus one, including the header and any padding.
skipping to change at page 25, line 15 skipping to change at page 26, line 19
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 5: 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
skipping to change at page 25, line 50 skipping to change at page 27, line 8
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. 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. SHALL be PauseID (16 bits): Message sequence identification, as described in
incremented by one modulo 2^16 for each new PAUSE message, unless Section 5.2. SHALL be incremented by one modulo 2^16 for each new
the message is re-transmitted. The initial value SHOULD be 0. PAUSE message, unless the message is re-transmitted. The initial
The PauseID is scoped by the Target SSRC, meaning that PAUSE, value SHOULD be 0. The PauseID is scoped by the Target SSRC,
RESUME, and PAUSED messages therefore share the same PauseID space meaning that PAUSE, RESUME, and PAUSED messages therefore share
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 also when TMMBR/TMMBN
are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be
used instead of the messages defined in this specification when the used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver effective topology is point-to-point. If either sender or receiver
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
be used for pause/resume functionality. If the messages defined in be used for pause/resume functionality. If the messages defined in
this specification are supported in addition to TMMBR/TMMBN, pause/ this specification are supported in addition to TMMBR/TMMBN by all
resume signaling MUST use messages from this specification. If the involved parties, pause/resume signaling MUST use messages from this
topology is not point-to-point and the messages defined in this specification. If the topology is not point-to-point and the
specification are not supported, pause/resume functionality with messages defined in this specification are not supported, pause/
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
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.
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.
Future PauseID is intentionally not defined as the entire range that
was not already defined as past PauseID. The remaining range of
PauseID is 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 available 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),REFUSED (Section 8.4), or implicitly determined by
or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be previously received PAUSE or RESUME (Section 8.3) requests. A
used if it was not possible to retrieve PauseID information, in which randomly chosen PauseID MAY be used if it was not possible to
case the PAUSE will either succeed, or the correct PauseID can be retrieve current PauseID information, in which case the PAUSE will
found in the returned REFUSED (Section 8.4). A PauseID that is either succeed, or the current PauseID can be found in the returned
matching the available PauseID is henceforth also called a valid REFUSED (Section 8.4).
PauseID.
PauseID needs to be incremented by one, in modulo arithmetic, for
each PAUSE request that is not a retransmission, compared to what was
used in the last PAUSED indication sent by the media sender. This is
to ensure that the PauseID matches what is the current available
PauseID at the RTP stream sender. The RTP stream sender increments
what it considers to be the available PauseID when entering Playing
State (Section 6.1).
For the scope of this specification, a PauseID larger than the It can be noted that as a result of what is described in Section 6.1,
current one is defined as having a value between and including PauseID is incremented by one, in modulo arithmetic, for each PAUSE
(PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is request that is not a retransmission, compared to what was used in
the modulo operator. Similarly, a PauseID smaller than the current the last PAUSED indication sent by the media sender. PauseID in the
one is defined as having a value between and including (PauseID - message is supposed to match current PauseID at the RTP stream
2^15) MOD 2^16 and (PauseID - 1) MOD 2^16. 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
receives a RESUME with the same PauseID, it is RECOMMENDED that it for a target SSRC receives a RESUME or a REFUSED with the same
refrains from sending further PAUSE requests for some appropriate PauseID for the same target SSRC, it is RECOMMENDED that it refrains
time since the RESUME indicates that there are other receivers that from scheduling further PAUSE requests for some appropriate time.
still wishes to receive the stream. This is because the RESUME indicates that there are other receivers
that still wishes to receive the stream, and the REFUSED indicates
that the RTP stream sender is currently not able to pause the stream.
What is an appropriate time can vary from application to application
and will also depend on the importance of achieving the bandwidth
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 larger PauseID than the one used in PAUSE, and if no REFUSED with a future PauseID compared to the one used in PAUSE is received,
is received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled and if no REFUSED with the current or a future PauseID is received
for retransmission, using the same PauseID. RTT is the observed within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for
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].
When an RTP stream sender in Playing State (Section 6.1) receives a When an RTP stream sender in Playing State (Section 6.1) receives a
valid PAUSE, and unless local considerations currently makes it PAUSE with the current PauseID, and unless local considerations
impossible to pause the stream, it SHALL enter Pausing State currently makes it impossible to pause the stream, it SHALL enter
(Section 6.2) and act accordingly. Pausing State (Section 6.2) and act accordingly.
If an RTP stream sender receives a valid PAUSE while in Pausing, If an RTP stream sender receives a PAUSE with the current PauseID
Paused (Section 6.3) or Local Paused (Section 6.4) States, the while in Pausing, Paused (Section 6.3) or Local Paused (Section 6.4)
received PAUSE SHALL be ignored. States, the received PAUSE SHALL be ignored.
8.2. PAUSED 8.2. PAUSED
The PAUSED indication MUST be sent whenever entering Paused State The PAUSED indication, if supported, MUST be sent whenever entering
(Section 6.3) as a result of receiving a valid PAUSE (Section 8.1) Paused State (Section 6.3) or Local Paused State (Section 6.4).
request, or when entering Local Paused State (Section 6.4) based on a
RTP stream sender local decision.
PauseID MUST contain the available, valid value to be included in a PauseID in the PAUSED message MUST contain the current PauseID that
subsequent RESUME (Section 8.3). can be included in a subsequent RESUME (Section 8.3). For Local
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.
PAUSED SHALL contain a 32 bit parameter at the start of the Type PAUSED SHALL contain a fixed-length 32-bit parameter at the start of
Specific field with the RTP extended highest sequence number the Type Specific field with the RTP extended highest sequence number
(Section 6.4.1 of [RFC3550]) valid when the RTP stream was paused. (Section 6.4.1 of [RFC3550]) valid when the RTP stream was paused.
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
skipping to change at page 28, line 36 skipping to change at page 29, line 50
PAUSED at the earliest opportunity and also to include it in (at 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 to disapprove a stream from
being paused. being paused.
PauseID SHOULD be the valid 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 PauseID information, in which used if it was not possible to retrieve current PauseID information,
case the RESUME will either succeed, or the correct PauseID can be in which case the RESUME will either succeed, or the current PauseID
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
receives a REFUSED with the same PauseID, it is RECOMMENDED that it
refrains from scheduling further RESUME requests for some appropriate
time since the REFUSE indicates that it is currently not possible to
resume the stream. What is an appropriate time can vary from
application to application and will also depend on the importance of
resuming the stream, but 1-2 regular RTCP intervals is expected to be
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 a valid PauseID the targeted stream are received, or a REFUSED with the current
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 valid (Section 6.3) or Local Paused State (Section 6.4) receives a RESUME
RESUME, and unless local considerations currently makes it impossible with the current PauseID, and unless local considerations currently
to resume the stream, it SHALL enter Playing State (Section 6.1) and makes it impossible to resume the stream, it SHALL enter Playing
act accordingly. If the RTP stream sender is incapable of honoring State (Section 6.1) and act accordingly. If the RTP stream sender is
the RESUME request with a valid PauseID, or receives a RESUME request incapable of honoring a RESUME request with the current PauseID, or
with an invalid PauseID while in Paused or Pausing state, the RTP if it receives a RESUME request with a PauseID that is not the
stream sender schedules a REFUSED message for transmission as current PauseID while in Paused or Pausing state, the RTP stream
specified below. sender SHALL schedule a REFUSED message for transmission as specified
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 a valid PauseID or a PauseID that is less than the valid either the current PauseID or a past PauseID, the received RESUME
PauseID, the received RESUME SHALL be ignored. SHALL be ignored.
8.4. REFUSED 8.4. REFUSED
If an RTP stream sender receives a valid PAUSE (Section 8.1) or If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME
RESUME (Section 8.3) request that cannot be fulfilled by the RTP (Section 8.3) request containing the current PauseID, where the
stream sender due to some local consideration, it SHALL schedule requested action cannot be fulfilled by the RTP stream sender due to
transmission of a REFUSED notification containing the valid PauseID some local consideration, it SHALL schedule transmission of a REFUSED
from the rejected request. notification containing the current PauseID from the rejected
request.
REFUSED has no defined Type Specific parameters. REFUSED has no defined Type Specific parameters.
If an RTP stream sender receives PAUSE or RESUME requests with a non- If an RTP stream sender receives a PAUSE or RESUME request with a
valid PauseID it SHALL schedule a REFUSED notification containing the PauseID that is not the current PauseID, it SHALL schedule a REFUSED
available, valid PauseID, except if the RTP stream sender is in notification containing the current PauseID, except if the RTP stream
Playing State and receives a RESUME with a PauseID less than the sender is in Playing State and receives a RESUME with a past PauseID,
valid one, 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 that would render identical REFUSED
notifications are received before the scheduled REFUSED is sent, notifications are received before the scheduled REFUSED is sent,
duplicate REFUSED MUST NOT be scheduled for transmission. This duplicate REFUSED MUST NOT be scheduled for transmission. This
effectively lets a single REFUSED respond to several invalid PAUSE or effectively lets a single REFUSED respond to several ineffective
RESUME requests. PAUSE or RESUME requests.
If REFUSED containing a certain PauseID was already sent and yet more If REFUSED containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSED PAUSE or RESUME messages are received that require additional REFUSED
with that specific PauseID to be scheduled, and unless the PauseID with that specific PauseID to be scheduled, further REFUSED messages
number space has wrapped since REFUSED was last sent with that with that PauseID SHOULD be sent in regular RTCP reports. An
PauseID, further REFUSED messages with that PauseID SHOULD be sent in exception to the previous rule is when the stream was paused and
regular RTCP reports. resumed so many times that the PauseID number space has wrapped since
REFUSED was last sent with that PauseID.
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. time to allow the condition that caused REFUSED to clear. For PAUSE,
an appropriate time is suggested in Section 8.1. For RESUME, an
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. depends 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.5), MAY use either Regular, used for pause/resume purposes (Section 5.6), MAY use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, taking the following into consideration:
o PAUSE SHOULD use Early or Immediate timing, except for o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing. retransmissions that SHOULD use Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. Unsolicited PAUSED for that PauseID SHOULD use Regular timing. Unsolicited
PAUSED (sent when entering Local Paused State (Section 6.4)) PAUSED (sent when entering Local Paused State (Section 6.4))
SHOULD always use Immediate or Early timing, until PAUSED for that SHOULD always use Immediate or Early timing, until PAUSED for that
skipping to change at page 32, line 22 skipping to change at page 34, line 5
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 PAUSED indications for sent RTP streams. It does not send PAUSED indications for sent RTP streams. It does not
support any other messages defined in this specification. support 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
support for all messages (config=1), but it is recognized that this
is sometimes not meaningful for implementations operating in an
environment where only parts of the functionality provided by this
specification are needed. The above defined "config" functionality
sub-sets provide a trade-off between completeness and the need for
implementation interoperability, achieving at least a level of
functionality corresponding to what is desired by the least capable
party when used as specified here. Implementation of any other
functionality sub-sets of this specification than the above defined
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 MAY omit sending non- ignore non-supported messages on reception, and MAY omit sending non-
supported messages. The below table summarizes per-message send and supported messages. The below table summarizes per-message send and
receive support for the different config attribute values ("X" receive support for the different config attribute values ("X"
indicating support and "-" 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 6: 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
correspond to the RTP Mixer in the RTP Mixer to Media Sender use case
(Section 3.2), and config=3 and 5 correspond to the Media Sender in
that same use case. For that use case, it should be clear that an
RTP Mixer implementing only config=3 or 5 will not provide a working
solution. Similarly, for that use case, a Media Sender implementing
only config=2 or 4 will not provide a working solution. Both the RTP
Mixer and the 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
between cascaded RTP Mixers, but would require support corresponding
to config=1 between such RTP Mixers. This is because an RTP Mixer is
then also Media Sender towards the other RTP Mixer, requiring support
for the union of config=2 and 3 or config=4 and 5, which effectively
becomes config=1.
As can be seen from Figure 7 above, config=2 and 3 differ from
config=4 and 5 only in that in the latter, the PAUSE / RESUME message
sender (e.g. the RTP Mixer side) does not support local pause
(Section 6.4) for any of its own streams and therefore also does not
support sending PAUSED.
Partial implementations that only support local pause functionality
can declare this capability through config=6-8.
Viable fallback rules between different config are described in
Section 9.1 and Figure 9.
This is the resulting ABNF [RFC5234], extending existing ABNF in This is the resulting ABNF [RFC5234], extending 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
/ 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 7: 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 use existing ccm tmmbr signaling [RFC5104] if the signaling, but MAY instead use existing ccm tmmbr signaling [RFC5104]
limitations in functionality as described in this specification if the limitations in functionality when using TMMBR/TMMBN as
coming from such usage are considered acceptable. The messages from described in this specification (Section 5.6) are considered
this specification SHOULD NOT be used towards receivers that did not acceptable. The messages from this specification (Section 8) SHOULD
declare capability to receive those messages. NOT be used towards receivers that did not declare capability to
receive those messages.
The pause functionality can normally be expected to work independent The pause functionality can normally be expected to work
of the payload type. However, there might exist situations where an independently of the payload type. However, there might exist
endpoint likes to restrict or at least differently configure the situations where an endpoint needs to restrict or at least configure
capabilities depending on the payload type carrying the media stream. the capabilities differently depending on the payload type carrying
Reasons for this might relate to capabilities to correctly handle the media stream. Reasons for this might relate to capabilities to
media boundaries and avoid any pause or resume operation to occur correctly handle media boundaries and avoid any pause or resume
where it would leave a receiver or decoder with no choice than to operation to occur where it would leave a receiver or decoder with no
attempt to repair or discard the media received just prior to or at choice than to attempt to repair or discard the media received just
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 payload type, in which case "*" SHALL be interpreted
as applicable to all listed payload types that do not have an as applicable to all listed payload types that do not have an
explicit "pause" specification. The "config" pause attribute MUST explicit "pause" specification. The "config" pause attribute MUST
NOT appear more than once for each "pause" CCM parameter. The 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.
skipping to change at page 34, line 24 skipping to change at page 36, line 43
-----------------------+----------------------------------- -----------------------+-----------------------------------
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 8: 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 attribute, MUST be interpreted
as equivalent to config=1. Implementations of this specification as equivalent to config=1. Implementations of this specification
MUST NOT use any other config values than the ones defined above in MUST NOT use any other config values than the ones defined above in
an offer or answer, and MUST remove the "pause" CCM line in the an offer or answer, and MUST remove the "pause" CCM line in the
answer when receiving an offer with a config value it does not answer when receiving an offer with a config value it does not
understand. In all cases the answerer MAY also completely remove any understand. In all cases the answerer MAY also completely remove any
"pause" CCM line to indicate that it does not understand or desire to "pause" CCM line to indicate that it does not understand or desire to
use any pause functionality for the affected payload types. use any pause functionality for the affected payload types.
skipping to change at page 36, line 22 skipping to change at page 38, line 40
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 9: 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 attribute. The
offerer also believes that it will be the sole receiver of 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" sub-
parameter for the "pause" parameter. parameter 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 10: 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 supports
pausing its own RTP streams due to local considerations, which is why pausing its own RTP streams due to local considerations, which is why
config=2 is chosen rather than config=4. The answerer somehow knows config=2 is chosen rather than config=4. The answerer somehow knows
that it will not be a point-to-point RTP session and has therefore that it will not be a point-to-point RTP session and has therefore
removed "nowait" from the "pause" line, meaning that the offerer must removed "nowait" from the "pause" line, meaning that the offerer must
use a non-zero hold-off period when being requested to pause the use a non-zero hold-off period when being requested to pause the
stream. stream.
skipping to change at page 37, line 42 skipping to change at page 40, line 28
| 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 11: Pause and Resume Operation in Point-to-Point Figure 12: Pause and Resume Operation in Point-to-Point
Figure 11 shows the basic pause and resume operation in Point-to- Figure 12 shows the basic pause and resume operation in Point-to-
Point scenario. At time t1, an RTP sender sends data to a receiver. Point scenario. At time t1, an RTP sender sends data to a receiver.
At time t2, the RTP receiver requests the sender to pause the stream, At time t2, the RTP receiver requests the sender to pause the stream,
using PauseID 3 (which it knew since before in this example). The using PauseID 3 (which it knew since before in this example). The
sender pauses the data and replies with a PAUSED containing the same sender pauses the data and replies with a PAUSED containing the same
PauseID. Some time later (at time t4) the receiver requests the PauseID. Some time later (at time t4) the receiver requests the
sender to resume, which resumes its transmission. The next PAUSE, sender to resume, which resumes its transmission. The next PAUSE,
sent at time t6, contains an updated PauseID (4), with a sent at time t6, contains an updated PauseID (4), with a
corresponding PAUSED being sent at time t7. corresponding PAUSED being sent at time t7.
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 38, line 30 skipping to change at page 41, 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 12: TMMBR Pause and Resume in Point-to-Point Figure 13: TMMBR Pause and Resume in Point-to-Point
Figure 12 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 > |
| t2: TMMBN {A:0} | | t2: TMMBN {A:0} |
| -------------------------------> | | -------------------------------> |
skipping to change at page 39, line 28 skipping to change at page 42, 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 13: Unsolicited PAUSED using TMMBN Figure 14: Unsolicited PAUSED using TMMBN
Figure 13 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 the RTP stream
sender (A) and the RTP stream receiver (B) use TMMBR/TMMBN signaling sender (A) and the RTP stream receiver (B) use TMMBR/TMMBN signaling
for pause/resume purposes. A decides to pause the RTP stream at time for pause/resume purposes. A decides to pause the RTP stream at time
t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN
bounding set. At time t3, despite the fact that the RTP stream is bounding set. At time t3, despite the fact that the RTP stream is
still paused, B decides that it is no longer interested to receive still paused, B decides that it is no longer interested to receive
the RTP stream and signals PAUSE by sending a TMMBR 0. As a result the RTP stream and signals PAUSE by sending a TMMBR 0. As a result
of that, the bounding set now contains both A and B, and A sends out of that, the bounding set now contains both A and B, and A sends out
a new TMMBN reflecting that. After a while, at time t5, the local a new TMMBN reflecting that. After a while, at time t5, the local
considerations that caused A to pause the RTP stream no longer apply, considerations that caused A to pause the RTP stream no longer apply,
skipping to change at page 40, line 33 skipping to change at page 43, line 33
| 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 14: Pause and Resume Operation With Messages Lost Figure 15: Pause and Resume Operation With Messages Lost
Figure 14 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 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.
skipping to change at page 41, line 10 skipping to change at page 44, line 10
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 are sent and another RESUME are sent already at time t7, which now
reaches the RTP stream sender that consequently resumes the stream at reaches the RTP stream sender that consequently resumes the stream at
time t8. The time interval between t6 and t7 can vary, but may for time t8. The time interval between t6 and t7 can vary, but may for
example be one RTCP feedback transmission interval as determined by example be one RTCP feedback transmission interval as determined by
the AVPF rules. 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 the RESUME PauseID is at time t9. This is however harmless since RESUME contains a past
less than the valid one and will be ignored by the RTP stream sender. PauseID and will be ignored by the RTP stream sender. It will also
It will also not cause any unwanted resume even if the stream was not cause any unwanted resume even if the stream was paused again
paused based on a PAUSE from some other receiver before receiving the based on a PAUSE from some other receiver before receiving the
RESUME, since the valid PauseID is now larger than the one in the RESUME, since the current PauseID was updated compared to the one in
stray RESUME and will only cause a REFUSED containing the new valid the stray RESUME, which contains a past PauseID and will be ignored
PauseID from 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 > | | < Can not pause RTP data > |
| t3: REFUSED(11) | | t3: REFUSED(11) |
| ------------------------------> | | ------------------------------> |
| | | |
| t4: RTP data | | t4: RTP data |
| ------------------------------> | | ------------------------------> |
: : : :
Figure 15: Pause Request is Refused in Point-to-Point Figure 16: Pause Request is Refused in Point-to-Point
In Figure 15, 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
skipping to change at page 42, line 37 skipping to change at page 45, line 37
| |<------------------------------------| | |<------------------------------------|
| 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 16: 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 the Mixer SSRC but with S1 as 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 the Mixer. As S2 has less voice activity
then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE
request. At t5, S2 acknowledges with a PAUSED and at the same request. At t5, S2 acknowledges with a PAUSED and at the same
instant stops delivering RTP to the Mixer. At t6, the user at S2 instant stops delivering RTP to the Mixer. At t6, the user at S2
starts speaking and becomes the most active speaker and the Mixer starts speaking and becomes the most active speaker and the Mixer
skipping to change at page 43, line 48 skipping to change at page 46, line 48
| | 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 17: Pause and Resume Operation Between Two Participants Using Figure 18: Pause and Resume Operation Between Two Participants Using
a Relay a Relay
Figure 17 describes how a Relay can help the receiver in pausing and Figure 18 describes how a Relay can help the receiver in pausing and
resuming the sender. The sender S sends RTP data to the receiver R resuming the sender. The sender S sends RTP data to the receiver R
through Relay, which just forwards the data without modifying the through Relay, which just forwards the data without modifying the
SSRCs. The receiver sends a PAUSE request to the sender, which in SSRCs. The receiver sends a PAUSE request to the sender, which in
this example knows that there may be more receivers of the stream and this example knows that there may be more receivers of the stream and
waits a non-zero hold-off period to see if there is any other waits a non-zero hold-off period to see if there is any other
receiver that wants to receive the data, does not receive any receiver that wants to receive the data, does not receive any
disapproving RESUME, hence pauses itself and replies with PAUSED. disapproving RESUME, hence pauses itself and replies with PAUSED.
Similarly the receiver resumes the sender by sending RESUME request Similarly the receiver resumes the sender by sending RESUME request
through Relay. Since this describes only a single pause operation through Relay. Since this describes only a single pause and resume
for a single RTP stream sender, all messages uses a single PauseID, operation for a single RTP stream sender, all messages uses a single
in this example 3. PauseID, in this example 3.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| 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 18: 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 18 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 is involved between a sender and two receivers in an RTP
session. Each message exchange is represented by the time it session. Each message exchange is represented by the time it
happens. At time t1, Sender (S) starts sending an RTP stream to the happens. At time t1, Sender (S) starts sending an RTP stream to the
Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and
R2 receives RTP data from Relay at t2. At this point, both R1 and R2 R2 receives RTP data from Relay at t2. At this point, both R1 and R2
will send RTCP Receiver Reports to S informing that they receive S's will send RTCP Receiver Reports to S informing that they receive 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 are at
skipping to change at page 46, line 23 skipping to change at page 49, line 23
which is forwarded to the sender S by the Relay. The sender S sees which is forwarded to the sender S by the Relay. The sender S sees
the RESUME at time t6 and continues to send data to Relay which the RESUME at time t6 and continues to send data to Relay which
forwards to both R1 and R2. At t7, the receiver R2 chooses to pause forwards to both R1 and R2. At t7, the receiver R2 chooses to pause
the stream by sending a PAUSE request with an updated PauseID. The the stream by sending a PAUSE request with an updated PauseID. The
sender S still knows that there are more than one receiver (R1 and sender S still knows that there are more than one receiver (R1 and
R2) that may want the stream and again waits a non-zero hold-off R2) that may want the stream and again waits a non-zero hold-off
period, after which and not having received any disapproving RESUME, period, after which and not having received any disapproving RESUME,
it concludes that the stream must be paused. S now stops sending the it concludes that the stream must be paused. S now stops sending the
stream and replies with PAUSED to R1 and R2. When any of the stream and replies with PAUSED to R1 and R2. When any of the
receivers (R1 or R2) chooses to resume the stream from S, in this receivers (R1 or R2) chooses to resume the stream from S, in this
example R1, it sends a RESUME request to the sender. The RTP sender example R1, it sends a RESUME request to the sender (also seen by
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 which 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
skipping to change at page 47, line 45 skipping to change at page 50, line 45
Even off-path attacks are possible as signalling messages often carry Even off-path attacks are possible as signalling 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 have 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. There exist several different choices for securing RTP messages. There exist several different choices for securing RTP
sessions to prevent this type of attack. SRTP is the the most sessions to prevent this type of attack. SRTP is the the most
common, but also other methods exist as discussed in "Options for common, but also other methods exist as discussed in "Options for
Securing RTP Sessions" [RFC7201]. 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 multi-party use
case. In case one of the session participants is malicious, they 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
participant's 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 multi-party 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. utilizing another participant's SSRCs.
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 that the media streams are delivered.
skipping to change at page 48, line 39 skipping to change at page 51, line 39
13. Contributors 13. Contributors
Daniel Grondal contributed in the creation and writing of early Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/ significantly to the SDP config attribute and its use in Offer/
Answer. Answer.
14. Acknowledgements 14. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. Emil Ivov, Christian Groves and Bernard versions of this draft. The authors would also like to thank Emil
Aboba provided valuable review comments. Ivov, Christian Groves, Bernard Aboba, and Ben Campbell, who provided
valuable review comments.
15. References 15. References
15.1. Normative References 15.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 49, line 37 skipping to change at page 52, line 48
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
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-05 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
in progress), February 2015. in progress), February 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-06 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
March 2015. July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
"A Taxonomy of Grouping Semantics and Mechanisms for Real- B. Burman, "A Taxonomy of Semantics and Mechanisms for
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
rtp-grouping-taxonomy-06 (work in progress), March 2015. avtext-rtp-grouping-taxonomy-07 (work in progress), June
2015.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
simulcast-00 (work in progress), January 2015. mmusic-sdp-simulcast-00 (work in progress), January 2015.
[I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-16 (work in
progress), January 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, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[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,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[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,
May 2011. May 2011.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, April 2014.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478,
March 2015.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between Version -06 and -07 A.1. 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.2. Modifications Between Version -06 and -07
o Completely rewrote the Security Consideration section. o Completely rewrote the Security Consideration section.
o Aligned text such that REFUSED is always referred to as a o Aligned text such that REFUSED is always referred to as a
notification, not indication. notification, not indication.
o Added and changed text in several places, clarifying the case when o Added and changed text in several places, clarifying the case when
TMMBR/TMMBN bounding set overhead value matters, related to TMMBR/TMMBN bounding set overhead value matters, related to
whether local RTP stream sender or remote RTP stream receiver owns whether local RTP stream sender or remote RTP stream receiver owns
the TMMBR 0 restriction, and the consequences this has on pause/ the TMMBR 0 restriction, and the consequences this has on pause/
skipping to change at page 51, line 40 skipping to change at page 56, line 13
o Added SDP rules on how to handle unknown pause attribute values. 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 o Clarified how to handle an SDP with both "ccm pause" and "ccm
tmmbr". tmmbr".
o Changed from "Translator" to "Relay" in examples, to make it o Changed from "Translator" to "Relay" in examples, to make it
clearer in relation to the updated topologies draft. clearer in relation to the updated topologies draft.
o Editorial improvements. o Editorial improvements.
A.2. Modifications Between Version -05 and -06 A.3. Modifications Between Version -05 and -06
o Clarified in Message Details section for PAUSED that o Clarified in Message Details section for PAUSED that
retransmission of the message can be used to increase the retransmission of the message can be used to increase the
probability that the message reaches the receiver in a timely probability that the message reaches the receiver in a timely
fashion, and also added text that says the number of repetitions fashion, and also added text that says the number of repetitions
can be tuned to observed loss rate and the desired loss can be tuned to observed loss rate and the desired loss
probability. Also removed Editor's notes on potential ACK for probability. Also removed Editor's notes on potential ACK for
unsolicited PAUSED, since the issue is solved by the above. unsolicited PAUSED, since the issue is solved by the above.
o In the same section as above, added that PAUSED may be included in o In the same section as above, added that PAUSED may be included in
skipping to change at page 52, line 19 skipping to change at page 56, line 41
targeted stream are received. targeted stream are received.
o Changed simulcast reference, since that draft was moved from o Changed simulcast reference, since that draft was moved from
AVTCORE to MMUSIC and made WG draft. AVTCORE to MMUSIC and made WG draft.
o Changed End Point to Endpoint to reflect change in RTP Grouping o Changed End Point to Endpoint to reflect change in RTP Grouping
Taxonomy draft. Taxonomy draft.
o Editorial improvements. o Editorial improvements.
A.3. Modifications Between Version -04 and -05 A.4. Modifications Between Version -04 and -05
o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and 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 timing of unsolicited PAUSED, to improve the message timeliness
and probability of reception. and probability of reception.
A.4. Modifications Between Version -03 and -04 A.5. Modifications Between Version -03 and -04
o Change of Copyright boilerplate o Change of Copyright boilerplate
A.5. Modifications Between Version -02 and -03 A.6. Modifications Between Version -02 and -03
o Changed the section on SDP signaling to be more explicit and clear o Changed the section on SDP signaling to be more explicit and clear
in what is supported, replacing the 'paused' parameter and the in what is supported, replacing the 'paused' parameter and the
'dir' attribute with a 'config' parameter that can take a value, 'dir' attribute with a 'config' parameter that can take a value,
and an explicit listing of what each value means. and an explicit listing of what each value means.
o Added a sentence in section on paused state (Section 6.3) that o Added a sentence in section on paused state (Section 6.3) that
pause must not affect RTP keepalive. pause must not affect RTP keepalive.
o Replaced REFUSE message name with REFUSED throughout, to better o Replaced REFUSE message name with REFUSED throughout, to better
skipping to change at page 53, line 11 skipping to change at page 57, line 35
sent unsolicited due to RTP sender local considerations, the TMMBN sent unsolicited due to RTP sender local considerations, the TMMBN
message includes the RTP stream sender itself as part of the message includes the RTP stream sender itself as part of the
bounding set. bounding set.
o Clarified that there is no reply to a PAUSED indication. o Clarified that there is no reply to a PAUSED indication.
o Improved the IANA section. o Improved the IANA section.
o Editorial improvements. o Editorial improvements.
A.6. Modifications Between Version -01 and -02 A.7. Modifications Between Version -01 and -02
o Replaced most text on relation with other signaling technologies o Replaced most text on relation with other signaling technologies
in previous section 5 with a single, summarizing paragraph, as in previous section 5 with a single, summarizing paragraph, as
discussed at IETF 90 in Toronto, and placed it as the last sub- discussed at IETF 90 in Toronto, and placed it as the last sub-
section of section 4 (design considerations). section of section 4 (design considerations).
o Removed unused references. o Removed unused references.
A.7. Modifications Between Version -00 and -01 A.8. Modifications Between Version -00 and -01
o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE
signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0 signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0
o Improved alignment with RTP Taxonomy draft, including the change o Improved alignment with RTP Taxonomy draft, including the change
of Packet Stream to RTP Stream of Packet Stream to RTP Stream
o Editorial improvements o Editorial improvements
Authors' Addresses Authors' Addresses
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107141311
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
URI: www.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: muhammad.azam.akram@ericsson.com
URI: www.ericsson.com URI: www.ericsson.com
 End of changes. 134 change blocks. 
425 lines changed or deleted 606 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/