draft-ietf-avtext-rtp-stream-pause-00.txt   draft-ietf-avtext-rtp-stream-pause-01.txt 
Network Working Group A. Akram Network Working Group B. Burman
Internet-Draft B. Burman 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: November 17, 2014 Huawei Technologies Expires: January 5, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
May 16, 2014 July 4, 2014
RTP Media Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-00 draft-ietf-avtext-rtp-stream-pause-01
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 November 17, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 38 skipping to change at page 2, line 38
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . 9
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 11 4.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12 4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12
5. Relation to Other Solutions . . . . . . . . . . . . . . . . . 12 5. Relation to Other Solutions . . . . . . . . . . . . . . . . . 12
5.1. Signaling Technology Performance Comparison . . . . . . . 12 5.1. Signaling Technology Performance Comparison . . . . . . . 12
5.2. CCM TMMBR / TMMBN . . . . . . . . . . . . . . . . . . . . 20 5.2. CCM TMMBR / TMMBN . . . . . . . . . . . . . . . . . . . . 20
5.3. SDP "inactive" Attribute . . . . . . . . . . . . . . . . 21 5.3. SDP "inactive" Attribute . . . . . . . . . . . . . . . . 21
5.4. Media Source Selection in SDP . . . . . . . . . . . . . . 21 5.4. Media Source Selection in SDP . . . . . . . . . . . . . . 21
5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22 5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22
6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 22 6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Expressing Capability . . . . . . . . . . . . . . . . . . 23 6.1. Expressing Capability . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 19 skipping to change at page 3, line 19
7.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 29 7.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 29
7.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 29 7.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 29
7.4. Local Paused State . . . . . . . . . . . . . . . . . . . 30 7.4. Local Paused State . . . . . . . . . . . . . . . . . . . 30
8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 30 8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 30
9. Message Details . . . . . . . . . . . . . . . . . . . . . . . 32 9. Message Details . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 36 9.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 36
10. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 39 10.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 39
10.2. Declarative Use . . . . . . . . . . . . . . . . . . . . 40 10.2. Declarative Use . . . . . . . . . . . . . . . . . . . . 40
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 41 11.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 42 11.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 42
11.3. Point-to-multipoint using Mixer . . . . . . . . . . . . 45 11.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 45
11.4. Point-to-multipoint using Translator . . . . . . . . . . 47 11.4. Point-to-Multipoint using Translator . . . . . . . . . . 47
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 13. Security Considerations . . . . . . . . . . . . . . . . . . . 51
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
16.1. Normative References . . . . . . . . . . . . . . . . . . 51 16.1. Normative References . . . . . . . . . . . . . . . . . . 51
16.2. Informative References . . . . . . . . . . . . . . . . . 52 16.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54
A.1. Modifications Between Version -00 and -01 . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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]
media stream from a specific source and later resume it when needed. stream and later resume it when needed. The receiver does not need
The receiver does not need to terminate or inactivate the RTP session to terminate or inactivate the RTP session and start all over again
and start all over again by negotiating the session parameters, for by negotiating the session parameters, for example using SIP
example using SIP [RFC3261] with SDP Offer/Answer [RFC3264]. [RFC3261] with SDP 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 media sender and the reduce the resources consumed in both the sender and the network by
network by temporarily pausing the media streams that aren't required temporarily pausing the RTP streams that aren't required by the RTP
by the RTP Mixer. If the number of conference participants are Mixer. If the number of conference participants are greater than
greater than what the conference logic has chosen to present what the conference logic has chosen to present simultaneously to
simultaneously to receiving participants, some participant media receiving participants, some participant RTP streams sent to the RTP
streams sent to the RTP Mixer may not need to be forwarded to any Mixer may not need to be forwarded to any other participant. Those
other participant. Those media streams could then be temporarily RTP streams could then be temporarily paused. This becomes
paused. This becomes especially useful when the media sources are especially useful when the media sources are provided in multiple
provided in multiple encoding versions (Simulcast) encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast]
[I-D.westerlund-avtcore-rtp-simulcast] or with Multi-Session or with Multi-Session Transmission (MST) of scalable encoding such as
Transmission (MST) of scalable encoding such as SVC [RFC6190]. There SVC [RFC6190]. There may be some of the defined encodings or
may be some of the defined encodings or combination of scalable combination of scalable layers that are not used all of the time.
layers that are not used all of the time.
As the media streams required at any given point in time is highly As the RTP streams required at any given point in time is highly
dynamic in such scenarios, using the out-of-band signalling channel dynamic in such scenarios, using the out-of-band signaling channel
for pausing, and even more importantly resuming, a media stream is for pausing, and even more importantly resuming, an RTP stream is
difficult due to the performance requirements. Instead, the pause difficult due to the performance requirements. Instead, the pause
and resume signalling should be in the media plane and go directly and resume signaling should be in the media plane and go directly
between the affected nodes. When using RTP [RFC3550] for media between the affected nodes. When using RTP [RFC3550] for media
transport, using Extended RTP Profile for Real-time Transport Control transport, using Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears
appropriate. No currently existing RTCP feedback message explicitly appropriate. No currently existing RTCP feedback message explicitly
supports pausing and resuming an incoming media stream. As this supports pausing and resuming an incoming RTP stream. As this
affects the generation of packets and may even allow the encoding affects the generation of packets and may even allow the encoding
process to be paused, the functionality appears to match Codec process to be paused, the functionality appears to match Codec
Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
[RFC5104] and it is proposed to define the solution as a Codec [RFC5104] and it is proposed to define 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
and resume, whenever possible. and resume, whenever possible.
skipping to change at page 5, line 26 skipping to change at page 5, line 28
LTE: Long-Term Evolution (3GPP) LTE: Long-Term Evolution (3GPP)
MCU: Multipoint Control Unit MCU: Multipoint Control Unit
MTU: Maximum Transfer Unit MTU: Maximum Transfer Unit
PT: Payload Type (RTP) PT: Payload Type (RTP)
RTP: Real-time Transport Protocol (RFC 3550) RTP: Real-time Transport Protocol (RFC 3550)
RTCP: Real-time Transport Control Protocol (RFC 3550) RTCP: RTP Control Protocol (RFC 3550)
RTCP RR: RTCP Receiver Report RTCP RR: RTCP Receiver Report
SDP: Session Description Protocol (RFC 4566) SDP: Session Description Protocol (RFC 4566)
SGW: Signaling Gateway SGW: Signaling Gateway
SIP: Session Initiation Protocol (RFC 3261) SIP: Session Initiation Protocol (RFC 3261)
SSRC: Synchronization Source (RTP) SSRC: Synchronization Source (RTP)
skipping to change at page 6, line 17 skipping to change at page 6, line 17
In addition to following, the definitions from RTP [RFC3550], AVPF In addition to following, the definitions from RTP [RFC3550], AVPF
[RFC4585], CCM [RFC5104], and RTP Taxonomy [RFC4585], CCM [RFC5104], and RTP Taxonomy
[I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document. [I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document.
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback Feedback Messages: CCM [RFC5104] categorized different RTCP feedback
messages into four types, Request, Command, Indication and messages into four types, Request, Command, Indication and
Notification. This document places the PAUSE and RESUME messages Notification. This document places the PAUSE and RESUME messages
into Request category, PAUSED as Indication and REFUSE as into Request category, PAUSED as Indication and REFUSE as
Notification. Notification.
PAUSE Request from a media receiver to pause a stream PAUSE Request from an RTP stream receiver to pause a stream
RESUME Request from a media receiver to resume a paused stream
PAUSED Indication from a media sender that a stream is paused
REFUSE Notification from a media sender that a PAUSE or RESUME
request will not be honored
Acknowledgement: The confirmation from receiver to sender that the RESUME Request from an RTP stream receiver to resume a paused
message has been received. stream
Sender: The RTP entity that sends an RTP Packet Stream. PAUSED Indication from an RTP stream sender that a stream is
paused
Receiver: The RTP entity that receives an RTP Packet Stream. REFUSE Notification from an RTP stream sender that a PAUSE or
RESUME request will not be honored
Mixer: The intermediate RTP node which receives a Packet Stream from Mixer: The intermediate RTP node which receives an RTP stream from
different nodes, combines them to make one stream and forwards to different end points, combines them to make one RTP stream and
destinations, in the sense described in Topo-Mixer of RTP forwards to destinations, in the sense described in Topo-Mixer of
Topologies [I-D.ietf-avtcore-rtp-topologies-update]. RTP Topologies [I-D.ietf-avtcore-rtp-topologies-update].
Participant: A member which is part of an RTP session, acting as Participant: A member which is part of an RTP session, acting as
receiver, sender or both. receiver, sender or both.
Paused Sender: An RTP sender that has stopped its transmission, i.e. Paused sender: An RTP stream sender that has stopped its
no other participant receives its RTP transmission, either based transmission, i.e. no other participant receives its RTP
on having received a PAUSE request, defined in this specification, transmission, either based on having received a PAUSE request,
or based on a local decision. defined in this specification, or based on a local decision.
Pausing Receiver: An RTP receiver which sends a PAUSE request, Pausing receiver: An RTP stream receiver which sends a PAUSE
defined in this specification, to other participant(s). request, defined in this specification, to other participant(s).
Stream: Used as a short term for Source Packet Stream, unless Stream: Used as a short term for RTP stream, unless otherwise noted.
otherwise noted.
Stream receiver: Short for RTP stream receiver; the RTP entity
responsible for receiving an RTP stream, usually a Media
Depacketizer.
Stream sender: Short for RTP stream sender; the RTP entity
responsible for creating an RTP stream, usually a Media
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 media stream pause and This section discusses the main use cases for RTP stream pause and
resume. resume.
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
end-points. Each end-point sends one or more streams. End Points. Each End Point sends one or more streams.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Figure 1: Point to Point
The usage of media stream pause in this use case is to temporarily The usage of RTP stream pause in this use case is to temporarily halt
halt media delivery of streams that the sender provides but the delivery of streams that the sender provides but the receiver does
receiver does not currently use. This can for example be due to not currently use. This can for example be due to minimized
minimized applications where the video stream is not actually shown applications where the video stream is not actually shown on any
on any display, and neither is it used in any other way, such as display, and neither is it used in any other way, such as being
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 RTCWEB WG's use case and requirements document
[I-D.ietf-rtcweb-use-cases-and-requirements] defines the following [I-D.ietf-rtcweb-use-cases-and-requirements] defines the following
API requirements in Appendix A, used also by W3C WebRTC WG: API requirements in Appendix A, used also by W3C WebRTC WG:
A8 The Web API must provide means for the web application to mute/ A8 The Web API must provide means for the web application to mute/
skipping to change at page 8, line 12 skipping to change at page 8, line 12
This memo provides means to optimize transport usage by stop sending This memo provides means to optimize transport usage by stop sending
muted streams and start sending again when unmuting. 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 SSRC,
and any media sent to the participants will be sent using those and any RTP streams sent to the participants will be sent using those
SSRCs. If the Mixer wants to identify the underlying Media Sources SSRCs. If the Mixer wants to identify the underlying media sources
for its' conceptual streams, it can identify them using CSRC. The for its' conceptual streams, it can identify them using CSRC. The
stream the Mixer provides can be an actual media mix of multiple stream the Mixer provides can be an actual mix of multiple media
Media Sources, but it might also be switching received streams as sources, but it might also be switching received streams as described
described in Sections 3.6-3.8 of in Sections 3.6-3.8 of [I-D.ietf-avtcore-rtp-topologies-update].
[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 that are delivered to a given receiver, A, can depend
on several things. It can either be the RTP Mixer's own logic and on several things. It can either be the RTP Mixer's own logic and
measurements such as voice activity on the incoming audio streams. measurements such as voice activity on the incoming audio streams.
It can be that the number of sent Media Sources exceed what is It can be that the number of sent media sources exceed what is
reasonable to present simultaneously at any given receiver. It can reasonable to present simultaneously at any given receiver. It can
also be a human controlling the conference that determines how the also be a human controlling the conference that determines how the
media should be mixed; this would be more common in lecture or media should be mixed; this would be more common in lecture or
similar applications where regular listeners may be prevented from similar applications where regular listeners may be prevented from
breaking into the session unless approved by the moderator. The breaking into the session unless approved by the moderator. The
streams may also be part of a Simulcast streams may also be part of a Simulcast
[I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for [I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for
Multi-Stream Transmission) [RFC6190], thus providing multiple Multi-Stream Transmission) [RFC6190], thus providing multiple
versions that can be delivered by the media sender. These examples versions that can be delivered by the RTP stream sender. These
indicate that there are numerous reasons why a particular stream examples indicate that there are numerous reasons why a particular
would not currently be in use, but must be available for use at very stream would not currently be in use, but must be available for use
short notice if any dynamic event occurs that causes a different at very short notice if any dynamic event occurs that causes a
stream selection to be done in the Mixer. different stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could Because of this, it would be highly beneficial if the Mixer could
request to pause a particular stream from being delivered to it. It request to pause a particular stream from being delivered to it. It
also needs to be able to resume delivery with minimal delay. also needs to be able to resume delivery with minimal delay.
Just as for point-to-point (Section 3.1), there is only a single Just as for point-to-point (Section 3.1), there is only a single
receiver of the stream, the RTP Mixer, and pausing or resuming a receiver of the stream, the RTP Mixer, and pausing or resuming a
stream does not affect anyone else than the sender and single stream does not affect anyone else than the sender and single
receiver of that stream. receiver of that stream.
3.3. RTP Mixer to Media Sender in Point-to-Multipoint 3.3. RTP Mixer to Media Sender in Point-to-Multipoint
This use case is similar to the previous section, however the RTP This use case is similar to the previous section, however the RTP
Mixer is involved in three domains that need to be separated; the Mixer is involved in three domains that need to be separated; the
Multicast Network (including participants A and C), participant B, Multicast Network (including participants A and C), participant B,
and participant D. The difference from above is that A and C share a and participant D. The difference from above is that A and C share a
multicast domain, which is depicted below. multicast domain, which is depicted below.
+-----+ +-----+
+---+ / \ +-----------+ +---+ +---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B | | A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+ +---+ / Multi- \ | | +---+
+ Cast +->| Mixer | + Cast +->| Mixer |
+---+ \ Network / | | +---+ +---+ \ Network / | | +---+
| C |<---\ / | |<---->| D | | C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+ +---+ \ / +-----------+ +---+
+-----+ +-----+
Figure 3: RTP Mixer in Point-to-Multipoint Figure 3: RTP Mixer in Point-to-Multipoint
If the RTP Mixer pauses a stream from A, it will not only pause the If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself, but will also stop the stream from arriving to stream towards itself, but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should C, which C is heavily impacted by, might not approve of, and should
thus have a say on. thus have a say on.
If the Mixer resumes a paused stream from A, it will be resumed also If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested it can simply ignore towards C. In this case, if C is not interested it can simply 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 end-point in Figure 2 could potentially request to pause the An End Point in Figure 2 could potentially request to pause the
delivery of a given media stream. Possible reasons include the ones delivery of a given stream. Possible reasons include the ones in the
in the point to point case (Section 3.1) above. 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 end-point requesting media stream pause is However, when the End Point requesting stream pause is connected to
connected to the RTP Mixer through a multicast network, such as A or the RTP Mixer through a multicast network, such as A or C in
C in Figure 3, the use case instead becomes identical to the one in Figure 3, the use case instead becomes identical to the one in
Section 3.3, only with reverse direction of the streams and pause/ Section 3.3, only with reverse direction of the streams and pause/
resume requests. resume requests.
3.5. Media Receiver to Media Sender Across RTP Mixer 3.5. Media Receiver to Media Sender Across RTP Mixer
An end-point, like A in Figure 2, could potentially request to pause An End Point, like A in Figure 2, could potentially request to pause
the delivery of a given media stream, like one of B's, over any of the delivery of a given stream, like one of B's, over any of the
the SSRCs used by the Mixer by sending a pause request for the CSRC SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the media stream. However, the authors are of the identifying the stream. However, the authors are of the opinion that
opinion that this is not a suitable solution, for several reasons: this is not a suitable solution, for several reasons:
1. The Mixer might not include CSRC in it's stream indications. 1. The Mixer might not include CSRC in it's stream indications.
2. An end-point cannot rely on the CSRC to correctly identify the 2. An End Point cannot rely on the CSRC to correctly identify the
media stream to be paused when the delivered media is some type stream to be paused when the delivered media is some type of mix.
of mix. A more elaborate media stream identification solution is A more elaborate stream identification solution is needed to
needed to support this in the general case. support this in the general case.
3. The end-point cannot determine if a given media stream is still 3. The End Point cannot determine if a given stream is still needed
needed by the RTP Mixer to deliver to another session by the RTP Mixer to deliver to another session participant.
participant.
Due to the above reasons, we exclude this use case from further Due to the above reasons, we exclude this use case from further
consideration. consideration.
4. Design Considerations 4. Design Considerations
This section describes the requirements that this specification needs This section describes the requirements that this specification needs
to meet. to meet.
4.1. Real-time Nature 4.1. Real-time Nature
skipping to change at page 11, line 7 skipping to change at page 11, line 7
related to pause and resume must be transmitted to the sender in related to pause and resume must be transmitted to the sender in
real-time in order for them to be purposeful. The pause operation is real-time in order for them to be purposeful. The pause operation is
arguably not very time critical since it mainly provides a reduction arguably not very time critical since it mainly provides a reduction
of resource usage. Timely handling of the resume operation is of resource usage. Timely handling of the resume operation is
however likely to directly impact the end-user's perceived quality however likely to directly impact the end-user's perceived quality
experience, since it affects the availability of media that the user experience, since it affects the availability of media that the user
expects to receive more or less instantly. expects to receive more or less instantly.
4.2. Message Direction 4.2. Message Direction
It is the responsibility of a media receiver, who wants to pause or It is the responsibility of an RTP stream receiver, who wants to
resume a media stream from the sender(s), to transmit PAUSE and pause or resume a stream from the sender(s), to transmit PAUSE and
RESUME messages. A media sender who likes to pause itself, can RESUME messages. An RTP stream sender who likes to pause itself, can
simply do it. Any indication that an RTP media stream is paused is simply do it. Any indication that an RTP stream is paused is the
the responsibility of the RTP media stream sender and may in some responsibility of the RTP stream sender and may in some cases not
cases not even be needed by the media 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 media streams The PAUSE and RESUME messages apply to single RTP streams identified
identified by their SSRC, which means the receiver targets the by their SSRC, which means the receiver targets the sender's SSRC in
sender's SSRC in the PAUSE and RESUME requests. If a paused sender the PAUSE and RESUME requests. If a paused sender starts sending
starts sending with a new SSRC, the receivers will need to send a new with a new SSRC, the receivers will need to send a new PAUSE request
PAUSE request in order to pause it. PAUSED indications refer to a in order to pause it. PAUSED indications refer to a single one of
single one of the sender's own, paused SSRC. the sender's own, paused SSRC.
4.4. Consensus 4.4. Consensus
An RTP media stream sender should not pause an SSRC that some An RTP stream sender should not pause an SSRC that some receiver
receiver still wishes to receive. The reason is that in RTP still wishes to receive. The reason is that in RTP topologies where
topologies where the media stream is shared between multiple the stream is shared between multiple receivers, a single receiver on
receivers, a single receiver on that shared network, independent of that shared network, independent of it being multicast, a mesh with
it being multicast, a mesh with joint RTP session or a transport joint RTP session or a transport Translator based, must not single-
Translator based, must not single-handedly cause the media stream to handedly cause the stream to be paused without letting all other
be paused without letting all other receivers to voice their opinions receivers to voice their opinions on whether or not the stream should
on whether or not the stream should be paused. A consequence of this be paused. A consequence of this is that a newly joining receiver,
is that a newly joining receiver, for example indicated by an RTCP for example indicated by an RTCP Receiver Report containing both a
Receiver Report containing both a new SSRC and a CNAME that does not new SSRC and a CNAME that does not already occur in the session,
already occur in the session, firstly needs to learn the existence of firstly needs to learn the existence of paused streams, and secondly
paused streams, and secondly should be able to resume any paused should be able to resume any paused stream. Any single receiver
stream. Any single receiver wanting to resume a stream should also wanting to resume a stream should also cause it to be resumed.
cause it to be resumed.
4.5. Acknowledgements 4.5. 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 end-point does not reach its destination, transmitted from an RTP End Point does not reach its destination,
i.e. the targeted RTP media stream sender. When PAUSE or RESUME i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches
reaches the RTP media stream sender and are effective, i.e., an the RTP stream sender and are effective, i.e., an active RTP stream
active media sender pauses, or a resuming have media data to sender pauses, or a resuming RTP stream sender have media data to
transmit, it is immediately seen from the arrival or non-arrival of transmit, it is immediately seen from the arrival or non-arrival of
RTP packets for that RTP media stream. Thus, no explicit RTP packets for that RTP stream. Thus, no explicit acknowledgments
acknowledgements are required in this case. are required in this case.
In some cases when a PAUSE or RESUME message reaches the media 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. This
error condition, a negative acknowledgement, 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. Retransmitting Requests 4.6. Retransmitting Requests
When the media stream is not affected as expected by a PAUSE or When the stream is not affected as expected by a PAUSE or RESUME
RESUME request, the request may have been lost and the sender of the request, the request may have been lost and the sender of the request
request will need to retransmit it. The retransmission should take will need to retransmit it. The retransmission should take the round
the round trip time into account, and will also need to take the trip time into account, and will also need to take the normal RTCP
normal RTCP bandwidth and timing rules applicable to the RTP session bandwidth and timing rules applicable to the RTP session into
into account, when scheduling retransmission of feedback. account, when scheduling retransmission of feedback.
When it comes to resume requests that are more time critical, the When it comes to resume requests that are more time critical, the
best resume performance may be achieved by repeating the request as best resume performance may be achieved by repeating the request as
often as possible until a sufficient number have been sent to reach a often as possible until a sufficient number have been sent to reach a
high probability of request delivery, or the media stream gets high probability of request delivery, or the stream gets delivered.
delivered.
4.7. Sequence Numbering 4.7. Sequence Numbering
A PAUSE request message will need to have a sequence number to A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps separate retransmissions from new requests. A retransmission keeps
the sequence number unchanged, while it is incremented every time a the sequence number unchanged, while it is incremented every time a
new PAUSE request is transmitted that is not a retransmission of a new PAUSE request is transmitted that is not a retransmission of a
previous request. previous request.
Since RESUME always takes precedence over PAUSE and are even allowed Since RESUME always takes precedence over PAUSE and are even allowed
skipping to change at page 14, line 26 skipping to change at page 14, line 26
uplink. uplink.
o Media server (MCU) to wireless UA, including a single wireless o Media server (MCU) to wireless UA, including a single wireless
downlink. downlink.
The reason to include separate results for wireless uplink and The reason to include separate results for wireless uplink and
downlink is that delay times can differ significantly. downlink is that delay times can differ significantly.
The targeted topology is outlined in the following figure. The targeted topology is outlined in the following figure.
Provider A's network . Provider B's network Provider A's network . Provider B's network
. .
+-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+ +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+
|Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy| |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy|
+-----+ +------+ +-------+ . +-------+ +-----+ +-----+ +------+ +-------+ . +-------+ +-----+
^ ^ . ^ ^ ^ . ^
| | SIP/H.248 . | | | SIP/H.248 . |
| v . | | v . |
SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP | SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP |
| | MCU |<---->| BGW A |<--.-->| BGW B | | | | MCU |<---->| BGW A |<--.-->| BGW B | |
| +-----+ +-------+ . +-------+ | | +-----+ +-------+ . +-------+ |
v ^ . ^ v v ^ . ^ v
+------+ / RTCP . \ RTCP +------+ +------+ / RTCP . \ RTCP +------+
| UA A |<---+ . +------>| UA B | | UA A |<---+ . +------>| UA B |
+------+ . +------+ +------+ . +------+
Figure 4: Comparison Signaling Topology Figure 4: Comparison Signaling Topology
In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS
is an Application Server, MCU is a Multipoint Conference Unit, SGW a is an Application Server, MCU is a Multipoint Conference Unit, SGW a
Signaling GateWay, and BGW a media Border GateWay. Signaling GateWay, and BGW a media Border GateWay.
It can be noted that when either one or both UAs use call forwarding It can be noted that when either one or both UAs use call forwarding
or have roamed into yet another provider's network, several more or have roamed into yet another provider's network, several more
signaling path nodes and a few more media path nodes could be signaling path nodes and a few more media path nodes could be
skipping to change at page 16, line 4 skipping to change at page 16, line 4
These assumptions are used for RTCP signaling: These assumptions are used for RTCP signaling:
o A minimal compound RTCP feedback packet is used, including one SR o A minimal compound RTCP feedback packet is used, including one SR
and one SDES with only the CNAME item present, with the addition and one SDES with only the CNAME item present, with the addition
of the feedback message outlined in Section 8. of the feedback message outlined in Section 8.
o RTCP bandwidth is chosen based on a 200 kbit/s session, which is o RTCP bandwidth is chosen based on a 200 kbit/s session, which is
considered to be a low bandwidth for media that would be worth considered to be a low bandwidth for media that would be worth
pausing, and using the default 5% of this for RTCP traffic results pausing, and using the default 5% of this for RTCP traffic results
in 10 kbit/s. This low bandwidth makes RTCP scheduling delays be a in 10 kbit/s. This low bandwidth makes RTCP scheduling delays be
significant factor in the unfavorable case. a significant factor in the unfavorable case.
o Since there are random delay factors in RTCP transmission, the o Since there are random delay factors in RTCP transmission, the
expected, most probable value is used in the estimates. expected, most probable value is used in the estimates.
o The mobile wireless access channel used for RTCP will always be o The mobile wireless access channel used for RTCP will always be
active, that is there will be sufficient data to send at any time active, that is there will be sufficient data to send at any time
such that the radio channel will never have to be re-established. such that the radio channel will never have to be re-established.
This is considered reasonable since it is assumed that the same This is considered reasonable since it is assumed that the same
channel is not only used for the messages defined in this channel is not only used for the messages defined in this
specification, but also for other RTP and RTCP data. specification, but also for other RTP and RTCP data.
skipping to change at page 16, line 27 skipping to change at page 16, line 27
o Favorable case: o Favorable case:
* It is assumed that AVPF Early or Immediate mode can always be * It is assumed that AVPF Early or Immediate mode can always be
used for the signaling described in this specification, since used for the signaling described in this specification, since
such signaling will be small in size and only occur such signaling will be small in size and only occur
occasionally in RTCP time scale. occasionally in RTCP time scale.
* Early mode does not use dithering of send times (T_dither_max * Early mode does not use dithering of send times (T_dither_max
is set to 0), that is, sender and receiver of the message are is set to 0), that is, sender and receiver of the message are
connected point-to-point. It can be noted that in case of a connected point-to-point. It can be noted that in case of a
multiparty session where multiple end-points can see each multiparty session where multiple End Points can see each
others' messages, and unless the number of end-points is very others' messages, and unless the number of End Points is very
large, it is very unlikely that more than a single end-point large, it is very unlikely that more than a single End Point
has the desire to send the same message (defined in this has the desire to send the same message (defined in this
specification) as another end-point, and at almost exactly the specification) as another End Point, and at almost exactly the
same time. It is therefore arguably not very meaningful for same time. It is therefore arguably not very meaningful for
messages in this specification to try to do feedback messages in this specification to try to do feedback
suppression by using a non-zero T_dither_max, even in suppression by using a non-zero T_dither_max, even in
multiparty sessions, but AVPF does not allow for any exemption multiparty sessions, but AVPF does not allow for any exemption
from that rule. from that rule.
* Reduced-size RTCP is used, which is considered appropriate for * Reduced-size RTCP is used, which is considered appropriate for
the type of messages defined in this specification. the type of messages defined in this specification.
* RTP/RTCP header compression [RFC5225] is not used, not even on * RTP/RTCP header compression [RFC5225] is not used, not even on
skipping to change at page 20, line 12 skipping to change at page 20, line 12
active, and some very minimal amount of extra data transmission. The active, and some very minimal amount of extra data transmission. The
large SIP messages can to some extent be reduced by SIP SigComp large SIP messages can to some extent be reduced by SIP SigComp
[RFC5049]. It may however prove harder to reduce delays that comes [RFC5049]. It may however prove harder to reduce delays that comes
from forwarding the SDP many times between different signaling nodes. from forwarding the SDP many times between different signaling nodes.
For RTCP, the major delays comes from low RTCP bandwidth and not For RTCP, the major delays comes from low RTCP bandwidth and not
being able to use Immediate or Early mode, including use of timer re- being able to use Immediate or Early mode, including use of timer re-
consideration. UAs and network nodes can explicitly allocate an consideration. UAs and network nodes can explicitly allocate an
appropriate amount of RTCP bandwidth through use of the b=RS and b=RR appropriate amount of RTCP bandwidth through use of the b=RS and b=RR
RTCP bandwidth SDP attributes [RFC3556]. For RTP media streams of RTCP bandwidth SDP attributes [RFC3556]. For RTP streams of higher
higher bandwidth than the 200 kbit/s used in this comparison, which bandwidth than the 200 kbit/s used in this comparison, which will be
will be even more interesting to pause, RTCP bandwidth will per even more interesting to pause, RTCP bandwidth will per default also
default also be higher, significantly reducing the signaling delays. be higher, significantly reducing the signaling delays. For example,
For example, using a 1000 kbit/s media stream instead of a 200 kbit/s using a 1000 kbit/s stream instead of a 200 kbit/s stream will reduce
stream will reduce the unfavorable RTCP delays from 260 ms to 115 ms the unfavorable RTCP delays from 260 ms to 115 ms for Wireless-
for Wireless-Wireless, from 225 ms to 80 ms for Wireless-MCU, and Wireless, from 225 ms to 80 ms for Wireless-MCU, and from 230 ms to
from 230 ms to 80 ms for MCU-Wireless. 80 ms for MCU-Wireless.
5.2. CCM TMMBR / TMMBN 5.2. CCM TMMBR / TMMBN
The Codec Control Messages specification [RFC5104] contains two The Codec Control Messages specification [RFC5104] contains two
messages, Temporary Maximum Media Bitrate Request (TMMBR) and messages, Temporary Maximum Media Bitrate Request (TMMBR) and
Temporary Maximum Media Bitrate Notification (TMMBN), which could Temporary Maximum Media Bitrate Notification (TMMBN), which could
provide some of the necessary functionality. TMMBR with a bitrate provide some of the necessary functionality. TMMBR with a bitrate
value of 0 could effectively constitute a PAUSE request and TMMBN 0 value of 0 could effectively constitute a PAUSE request and TMMBN 0
could effectively be a PAUSED indication, and there are already could effectively be a PAUSED indication, and there are already
implementations making use of TMMBR 0 in this way. It is possible to implementations making use of TMMBR 0 in this way. It is possible to
signal per SSRC (Section 4.3) and using the media path for signaling signal per SSRC (Section 4.3) and using the media path for signaling
(AVPF) [RFC4585] will in most cases provide the shortest achievable (AVPF) [RFC4585] will in most cases provide the shortest achievable
signaling delay (Section 4.1). However, in some cases the defined signaling delay (Section 4.1). However, in some cases the defined
semantics for TMMBR differ from what is required for PAUSE. semantics for TMMBR differ from what is required for PAUSE.
When there is only a single receiver of a media stream, TMMBR 0 and When there is only a single receiver of a stream, TMMBR 0 and PAUSE
PAUSE are effectively identical. are effectively identical.
When there are several receivers of the same media stream, the stream When there are several receivers of the same stream, the stream must
must not be paused until there are no receiver that desires to not be paused until there are no receiver that desires to receive it
receive it (Section 4.4), for example there is no disapproving RESUME (Section 4.4), for example there is no disapproving RESUME for a
for a PAUSE. In the presence of several simultaneous receivers, the PAUSE. In the presence of several simultaneous receivers, the TMMBR
TMMBR semantics is the opposite; the first media receiver that sends semantics is the opposite; the first RTP stream receiver that sends
TMMBR 0 will pause the stream for all receivers. TMMBR 0 will pause the stream for all receivers.
When there is only a single receiver of a media stream that is When there is only a single receiver of a stream that is paused,
paused, TMMBR with a bitrate greater than 0 can effectively function TMMBR with a bitrate greater than 0 can effectively function as a
as a RESUME, resuming the media stream immediately as needed RESUME, resuming the stream immediately as needed (Section 4.4).
(Section 4.4).
For the case of multiple simultaneous receivers, TMMBR specifies to For the case of multiple simultaneous receivers, TMMBR specifies to
use a guard period when increasing the bandwidth. In this case, use a guard period when increasing the bandwidth. In this case,
TMMBR/TMMBN semantics (Section 4.2.1.2 of [RFC5104]) requires a media TMMBR/TMMBN semantics (Section 4.2.1.2 of [RFC5104]) requires an RTP
sender to wait 2*RTT+T_dither_max after having sent a TMMBN, stream sender to wait 2*RTT+T_dither_max after having sent a TMMBN,
indicating the intention to increase the bandwidth, before it indicating the intention to increase the bandwidth, before it
actually increases its bandwidth usage. The RTT is specified to be actually increases its bandwidth usage. The RTT is specified to be
the longest the media sender knows in the RTP session. So, there is the longest the RTP stream sender knows in the RTP session. So,
both the delay between the media sender receiving the TMMBR until it there is both the delay between the RTP stream sender receiving the
can send a TMMBN, and the above delay for the guard period before the TMMBR until it can send a TMMBN, and the above delay for the guard
media sender are allowed to resume transmission. This delay before period before the RTP stream sender is allowed to resume
resuming transmission is the most time critical operation in this transmission. This delay before resuming transmission is the most
solution, making use of TMMBR as RESUME according to the defined time critical operation in this solution, making use of TMMBR as
semantics infeasible in practice when there are multiple simultaneous RESUME according to the defined semantics infeasible in practice when
media stream receivers. there are multiple simultaneous stream receivers.
5.3. SDP "inactive" Attribute 5.3. SDP "inactive" Attribute
In SDP [RFC4566], an "inactive" attribute is defined on media level In SDP [RFC4566], an "inactive" attribute is defined on media level
and session level. The attribute is intended to be used to put media and session level. The attribute is intended to be used to put media
"on hold", either at the beginning of a session or as a result of "on hold", either at the beginning of a session or as a result of
session re-negotiation [RFC3264], for example using SIP re-INVITE session re-negotiation [RFC3264], for example using SIP re-INVITE
[RFC3261], possibly in combination with ITU-T H.248 media gateway [RFC3261], possibly in combination with ITU-T H.248 media gateway
control. control.
This attribute is only possible to specify with media level This attribute is only possible to specify with media level
resolution, is not possible to signal per individual media stream resolution, is not possible to signal per individual stream (SSRC)
(SSRC) (Section 4.3), and is thus not usable for RTP sessions (Section 4.3), and is thus not usable for RTP sessions containing
containing more than a single SSRC. more than a single SSRC.
There is a per-ssrc attribute defined in [RFC5576], but that does There is a per-ssrc attribute defined in [RFC5576], but that does
currently not allow to set an individual stream (SSRC) inactive. currently not allow to set an individual stream (SSRC) inactive.
Using "inactive" does thus not provide sufficient functionality for Using "inactive" does thus not provide sufficient functionality for
the purpose of this specification. the purpose of this specification.
5.4. Media Source Selection in SDP 5.4. Media Source Selection in SDP
There is a draft that selects sources based on SDP There is a draft that selects sources based on SDP
[I-D.lennox-mmusic-sdp-source-selection] information. It builds on [I-D.lennox-mmusic-sdp-source-selection] information. It builds on
the per-ssrc attribute [RFC5576] discussed above (Section 5.3). the per-ssrc attribute [RFC5576] discussed above (Section 5.3).
The semantics differ between selecting a Media Source and pause / The semantics differ between selecting a media source and pause /
resume for a stream in topologies other than point-to-point. For resume for a stream in topologies other than point-to-point. For
example, in RTP Receiver to Mixer (Section 3.4), pausing a stream example, in RTP Receiver to Mixer (Section 3.4), pausing a stream
(SSRC) from the mixer should stop it being received altogether, while (SSRC) from the mixer should stop it being received altogether, while
excluding a stream (CSRC) from the mix would just avoid that specific excluding a stream (CSRC) from the mix would just avoid that specific
Media Source being included in the stream from the mixer. There is a media source being included in the stream from the mixer. There is a
similar difference between resuming a stream (SSRC) from the mixer similar difference between resuming a stream (SSRC) from the mixer
and allowing a Media Source (CSRC) to be included in the mix again. and allowing a media source (CSRC) to be included in the mix again.
This suffers from a lack of functionality for consensus (Section 4.4) This suffers from a lack of functionality for consensus (Section 4.4)
and would likely also suffer from lower real-time performance and would likely also suffer from lower real-time performance
(Section 4.1). (Section 4.1).
5.5. Conclusion 5.5. Conclusion
As can be seen from Section 5.1, using SIP and SDP to carry pause and As can be seen from Section 5.1, using SIP and SDP to carry pause and
resume information means that it will need to traverse the entire resume information means that it will need to traverse the entire
signaling path to reach the signaling destination (either the remote signaling path to reach the signaling destination (either the remote
end-point or the entity controlling the RTP Mixer), across any End Point or the entity controlling the RTP Mixer), across any
signaling proxies that potentially also has to process the SDP signaling proxies that potentially also has to process the SDP
content to determine if they are expected to act on it. The amount content to determine if they are expected to act on it. The amount
of bandwidth required for a SIP/SDP-based signaling solution is in of bandwidth required for a SIP/SDP-based signaling solution is in
the order of at least 10 times more than an RTCP-based solution. the order of at least 10 times more than an RTCP-based solution.
Especially for UA sitting on mobile wireless access, this will risk Especially for UA sitting on mobile wireless access, this will risk
introducing delays that are too long (Section 4.1) to provide a good introducing delays that are too long (Section 4.1) to provide a good
user experience, and the bandwidth cost may also be considered user experience, and the bandwidth cost may also be considered
infeasible compared to an RTCP-based solution. infeasible compared to an RTCP-based solution.
skipping to change at page 22, line 34 skipping to change at page 22, line 32
path, which is likely shorter (contains fewer intermediate nodes) path, which is likely shorter (contains fewer intermediate nodes)
than the signaling path but may anyway have to traverse a few than the signaling path but may anyway have to traverse a few
intermediate nodes. The amount of processing and buffering required intermediate nodes. The amount of processing and buffering required
in intermediate nodes to forward those RTCP messages is however in intermediate nodes to forward those RTCP messages is however
believed to be significantly less than for intermediate nodes in the believed to be significantly less than for intermediate nodes in the
signaling path. signaling path.
Based on those reasons, RTCP is proposed as signaling protocol for Based on those reasons, RTCP is proposed as signaling protocol for
the pause and resume functionality. Much of the wanted functionality the pause and resume functionality. Much of the wanted functionality
can in a point-to-point case be achieved with the existing TMMBR/ can in a point-to-point case be achieved with the existing TMMBR/
TMMBN CCM messages [RFC5104], but they cannot be used when the media TMMBN CCM messages [RFC5104], but they cannot be used when the stream
stream is sent to multiple simultaneous receivers. is sent to multiple simultaneous receivers.
6. Solution Overview 6. 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 media stream targeted at participant that wants to pause or resume a stream targeted at the
the media 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 It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent
possible, and to define a small set of new RTCP feedback messages possible, and to define a small set of new RTCP feedback messages
where new semantics is needed. Considerations that that apply when where new semantics is needed. Considerations that apply when using
using TMMBR/TMMBN for pause and resume purposes are also described. TMMBR/TMMBN for pause and resume purposes are also described.
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 REFUSE response, or an extension RESUME request, PAUSED indication, a REFUSE response, or an extension
to this specification. This structure allows a single feedback to this specification. This structure allows a single feedback
message to handle pause functionality on a number of media streams. message to handle pause functionality on a number of 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 media sender to indicate a local decision to used standalone by the RTP stream sender to indicate a local decision
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.
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.
6.1. Expressing Capability 6.1. Expressing Capability
An end-point can use an extension to CCM SDP signaling to declare An End Point 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 PAUSED indication is defined separately from Capability to understand PAUSED indication is defined separately from
the others to support partial implementation, which is specifically the others to support partial implementation, which is specifically
believed to be feasible for the RTP Mixer to Media Sender use case believed to be feasible for the RTP Mixer to Media Sender use case
(Section 3.2). (Section 3.2).
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.
6.2. Requesting to Pause 6.2. Requesting to Pause
An RTP media stream receiver can choose to request PAUSE at any time, An RTP stream receiver can choose to request PAUSE at any time,
subject to AVPF timing rules. This also applies when using TMMBR 0 subject to AVPF timing rules. This also applies when using TMMBR 0
in the point-to-point case. in the point-to-point case.
The PAUSE request contains a PauseID, which is incremented by one (in The PAUSE request contains a PauseID, which is incremented by one (in
modulo arithmetic) with each PAUSE request that is not a re- modulo arithmetic) with each PAUSE request that is not a re-
transmission. The PauseID is scoped by and thus a property of the transmission. The PauseID is scoped by and thus a property of the
targeted RTP media stream (SSRC). targeted RTP stream (SSRC).
When a non-paused RTP media stream sender receives the PAUSE request, When a non-paused RTP stream sender receives the PAUSE request, it
it continues to send media while waiting for some time to allow other continues to send the RTP stream while waiting for some time to allow
RTP media 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 6.4) for the PAUSE request to disapprove by sending a RESUME (Section 6.4) for the
same stream and with the same PauseID as in the disapproved PAUSE. same stream and with the same PauseID as in the disapproved PAUSE.
If such disapproving RESUME arrives at the RTP media stream sender If such disapproving RESUME arrives at the RTP stream sender during
during the wait period before the stream is paused, the pause is not the wait period before the stream is paused, the pause is not
performed. In point-to-point configurations, the wait period may be performed. In point-to-point configurations, the wait period may be
set to zero. Using a wait period of zero is also appropriate when set to zero. Using a wait period of zero is also appropriate when
using TMMBR 0 and in line with the semantics for that message. using TMMBR 0 and in line with the semantics for that message.
If the RTP media stream sender receives further PAUSE requests with If the RTP stream sender receives further PAUSE requests with the
the available PauseID while waiting as described above, those available PauseID while waiting as described above, those additional
additional requests are ignored. requests are ignored.
If the PAUSE request or TMMBR 0 is lost before it reaches the RTP If the PAUSE request or TMMBR 0 is lost before it reaches the RTP
media stream sender, it will be discovered by the RTP media stream stream sender, it will be discovered by the RTP stream receiver
receiver because it continues to receive the RTP media stream. It because it continues to receive the RTP stream. It will also not see
will also not see any PAUSED indication (Section 6.3) or TMMBN 0 for any PAUSED indication (Section 6.3) or TMMBN 0 for the stream. The
the stream. The same condition can be caused by the RTP media stream same condition can be caused by the RTP stream sender having received
sender having received a disapproving RESUME from a media stream a disapproving RESUME from a stream receiver A for a PAUSE request
receiver A for a PAUSE request sent by a media stream sender B, but sent by a stream sender B, but that the PAUSE sender (B) did not
that the PAUSE sender (B) did not receive the RESUME (from A) and may receive the RESUME (from A) and may instead think that the PAUSE was
instead think that the PAUSE was lost. In both cases, a PAUSE lost. In both cases, a PAUSE request can be re-transmitted using the
request can be re-transmitted using the same PauseID. If using TMMBR same PauseID. If using TMMBR 0 the request MAY be re-transmitted
0 the request MAY be re-transmitted when the requestor fails to when the requester fails to receive a TMMBN 0 confirmation.
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 PauseID from the disapproved PAUSE is invalidated by the RESUME
and any new PAUSE must use an incremented PauseID (in modulo and any new PAUSE must use an incremented PauseID (in modulo
arithmetic) to be effective. arithmetic) to be effective.
An RTP media stream sender receiving a PAUSE not using the available An RTP stream sender receiving a PAUSE not using the available
PauseID informs the RTP media stream receiver sending the ineffective PauseID informs the RTP stream receiver sending the ineffective PAUSE
PAUSE of this condition by sending a REFUSE response that contains of this condition by sending a REFUSE response that contains the next
the next available PauseID value. This REFUSE also informs the RTP available PauseID value. This REFUSE also informs the RTP stream
media stream receiver that it is probably not feasible to send receiver that it is probably not feasible to send another PAUSE for
another PAUSE for some time, not even with the available PauseID, some time, not even with the available PauseID, since there are other
since there are other RTP media stream receivers that wish to receive RTP stream receivers that wish to receive the stream.
the stream.
A similar situation where an ineffective PauseID is chosen can appear A similar situation where an ineffective PauseID is chosen can appear
when a new RTP media stream receiver joins a session and wants to when a new RTP stream receiver joins a session and wants to PAUSE a
PAUSE a stream, but does not yet know the available PauseID to use. stream, but does not yet know the available PauseID to use. The
The REFUSE response will then provide sufficient information to REFUSE response 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 media stream sender can then respond to pause the stream, and the RTP stream sender can then respond with
with a REFUSE. In this case, if the used PauseID would otherwise a REFUSE. In this case, if the used PauseID would otherwise have
have been effective, the REFUSE contains the same PauseID as in the been effective, the REFUSE contains the same PauseID as in the PAUSE
PAUSE request, and the PauseID is kept as available. request, and the PauseID is kept as available. Note that when using
TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to
the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN
SHALL contain the current bounding set, and the fact that a TMMBR 0
will always be the most restrictive point in any bounding set.
If the RTP media stream sender receives several identical PAUSE for If the RTP stream sender receives several identical PAUSE for an RTP
an RTP media stream that was already at least once responded with stream that was already at least once responded with REFUSE and the
REFUSE and the condition causing REFUSE remains, those additional condition causing REFUSE remains, those additional REFUSE should be
REFUSE should be sent with regular RTCP timing. A single REFUSE can sent with regular RTCP timing. A single REFUSE can respond to
respond to several identical PAUSE requests. several identical PAUSE requests.
6.3. Media Sender Pausing 6.3. Media Sender Pausing
An RTP media stream sender can choose to pause the stream at any An RTP stream sender can choose to pause the stream at any time.
time. This can either be as a result of receiving a PAUSE, or be This can either be as a result of receiving a PAUSE, or be based on
based on some local sender consideration. When it does, it sends a some local sender consideration. When it does, it sends a PAUSED
PAUSED indication, containing the available PauseID. If the stream indication, containing the available PauseID. If the stream was
was paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is
is said on PAUSED in the rest of this paragraph apply also to the use said on PAUSED in the rest of this paragraph apply also to the use of
of TMMBN 0, except for PAUSED message parameters. Note that PauseID TMMBN 0, except for PAUSED message parameters. Note that PauseID is
is incremented when pausing locally (without having received a incremented when pausing locally (without having received a PAUSE).
PAUSE). It also sends the PAUSED indication in the next two regular It also sends the PAUSED indication in the next two regular RTCP
RTCP reports, given that the pause condition is then still effective. reports, given that the pause condition is then still effective.
The RTP media stream sender may want to apply some local The RTP stream sender may want to apply some local consideration to
consideration to exactly when the stream is paused, for example exactly when the stream is paused, for example completing some media
completing some media unit or a forward error correction block, unit or a forward error correction block, before pausing the stream.
before pausing the stream.
The PAUSED indication also contains information about the RTP The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective. extended highest sequence number when the pause became effective.
This provides RTP media 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
media stream receivers to quickly and safely take into account that stream receivers to quickly and safely take into account that the
the stream is paused, in for example retransmission or congestion stream is paused, in for example retransmission or congestion control
control algorithms. algorithms.
If the RTP media stream sender receives PAUSE requests with the If the RTP stream sender receives PAUSE requests with the available
available PauseID while the stream is already paused, those requests PauseID while the stream is already paused, those requests are
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 media stream receivers joining while the stream this way allows RTP stream receivers joining while the stream is
is paused to quickly know that there is a paused stream, what the paused to quickly know that there is a paused stream, what the last
last sent extended RTP sequence number was, and what the next sent extended RTP sequence number was, and what the next available
available PauseID is to be able to construct valid PAUSE and RESUME PauseID is to be able to construct valid PAUSE and RESUME requests at
requests at a later stage. a later stage.
When the RTP media stream sender learns that a new end-point has When the RTP stream sender learns that a new End Point has joined the
joined the RTP session, for example by a new SSRC and a CNAME that RTP session, for example by a new SSRC and a CNAME that was not
was not previously seen in the RTP session, it should send PAUSED previously seen in the RTP session, it should send PAUSED indications
indications for all its paused streams at its earliest opportunity. for all its paused streams at its earliest opportunity. It should in
It should in addition continue to include PAUSED indications in at addition continue to include PAUSED indications in at least two
least two regular RTCP reports. regular RTCP reports.
6.4. Requesting to Resume 6.4. Requesting to Resume
An RTP media stream receiver can request to resume a stream with a An RTP stream receiver can request to resume a stream with a RESUME
RESUME request at any time, subject to AVPF timing rules. If the request at any time, subject to AVPF timing rules. If the stream was
stream was paused with TMMBR 0, resuming the stream is made with paused with TMMBR 0, resuming the stream is made with TMMBR
TMMBR containing a bitrate value larger than 0. The bitrate value containing a bitrate value larger than 0. The bitrate value used
used when resuming after a PAUSE with TMMBR 0 is either according to when resuming after a PAUSE with TMMBR 0 is either according to known
known limitations, or the configured maximum for the stream or limitations, or the configured maximum for the stream or session.
session. What is said on RESUME in the rest of this paragraph apply What is said on RESUME in the rest of this paragraph apply also to
also to the use of TMMBR with a bitrate value larger than 0, except the use of TMMBR with a bitrate value larger than 0, except for
for RESUME message parameters. RESUME message parameters.
The RTP media stream receiver must include the available PauseID in The RTP stream receiver must include the available PauseID in the
the RESUME request for it to be effective. RESUME request for it to be effective.
A pausing RTP media stream sender that receives a RESUME including A pausing RTP stream sender that receives a RESUME including the
the correct available PauseID resumes the stream at the earliest correct available PauseID resumes the stream at the earliest
opportunity. Receiving RESUME requests for a stream that is not opportunity. Receiving RESUME requests for a stream that is not
paused does not require any action and can be ignored. paused does not require any action and can be ignored.
There may be local considerations, for example that the media device There may be local considerations, for example that the media device
is not ready, making it temporarily impossible to resume the stream is not ready, making it temporarily impossible to resume the stream
at that point in time, and the RTP media stream sender MAY then at that point in time, and the RTP stream sender MAY then respond
respond with a REFUSE containing the same PauseID as in the RESUME. with a REFUSE containing the same PauseID as in the RESUME. When
When receiving such REFUSE with a PauseID identical to the one in the receiving such REFUSE with a PauseID identical to the one in the sent
sent RESUME, RTP media stream receivers SHOULD then avoid sending RESUME, RTP stream receivers SHOULD then avoid sending further RESUME
further RESUME requests for some reasonable amount of time, to allow requests for some reasonable amount of time, to allow the condition
the condition to clear. to clear.
If the RTP media stream sender receives several identical RESUME for If the RTP stream sender receives several identical RESUME for an RTP
an RTP media stream that was already at least once responded with stream that was already at least once responded with REFUSE and the
REFUSE and the condition causing REFUSE remains, those additional condition causing REFUSE remains, those additional REFUSE should be
REFUSE should be sent with regular RTCP timing. A single REFUSE can sent with regular RTCP timing. A single REFUSE can respond to
respond to several identical RESUME requests. several identical RESUME requests.
When resuming a paused media stream, especially for media that makes When resuming a paused stream, especially for media that makes use of
use of temporal redundancy between samples such as video, the temporal redundancy between samples such as video, the temporal
temporal dependency between samples taken before the pause and at the dependency between samples taken before the pause and at the time
time instant the stream is resumed may not be appropriate to use in instant the stream is resumed may not be appropriate to use in the
the encoding. Should such temporal dependency between before and encoding. Should such temporal dependency between before and after
after the media was paused be used by the media sender, it requires the media was paused be used by the RTP stream sender, it requires
the media receiver to have saved the sample from before the pause for the RTP stream receiver to have saved the sample from before the
successful continued decoding when resuming. The use of this pause for successful continued decoding when resuming. The use of
temporal dependency is left up to the media sender. If temporal this temporal dependency is left up to the RTP stream sender. If
dependency is not used when media is resumed, the first encoded temporal dependency is not used when the RTP stream is resumed, the
sample after the pause will not contain any temporal dependency to first encoded sample after the pause will not contain any temporal
samples before the pause (for video it may be a so-called intra dependency to samples before the pause (for video it may be a so-
picture). If temporal dependency to before the pause is used by the called intra picture). If temporal dependency to before the pause is
media sender when resuming, and if the media receiver did not save used by the RTP stream sender when resuming, and if the RTP stream
any sample from before the pause, the media receiver can use a FIR receiver did not save any sample from before the pause, the RTP
request [RFC5104] to explicitly ask for a sample without temporal stream receiver can use a FIR request [RFC5104] to explicitly ask for
dependency (for video a so-called intra picture), even at the same a sample without temporal dependency (for video a so-called intra
time as sending the RESUME. picture), even at the same time as sending the RESUME.
6.5. TMMBR/TMMBN Considerations 6.5. TMMBR/TMMBN Considerations
As stated, TMMBR/TMMBN may be used to provide pause and resume As stated, 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-
off period to wait for RESUME before pausing the media stream. off period to wait for RESUME before pausing the stream.
TMMBR >0: Corresponds to RESUME when the media stream was previously TMMBR >0: Corresponds to RESUME when the stream was previously
paused with TMMBR 0. Since there is only a single media receiver, paused with TMMBR 0. Since there is only a single RTP stream
there is no need for the media sender to delay resuming the media receiver, there is no need for the RTP stream sender to delay
stream until after sending TMMBN >0, or to apply the hold-off resuming the stream until after sending TMMBN >0, or to apply the
period specified in [RFC5104] before increasing the bitrate from hold-off period specified in [RFC5104] before increasing the
zero. bitrate from zero.
TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE
indication when a media stream is requested to be resumed with indication when a stream is requested to be resumed with TMMBR >0.
TMMBR >0.
TMMBN >0: Corresponds to a REFUSE indication when a media stream is TMMBN >0: Cannot be used as REFUSE indication when a stream is
requested to be paused with TMMBR 0. requested to be paused with TMMBR 0, for reasons stated in
Section 6.2.
7. Participant States 7. Participant States
This document introduces three new states for a media stream in an This document introduces three new states for a stream in an RTP
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 REFUSE in this section SHALL references to PAUSE, PAUSED, RESUME and REFUSE 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 6.5) for this functionality. used (Section 6.5) 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 8: RTP Pause States Figure 8: RTP Pause States
7.1. Playing State 7.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 PauseID MUST be incremented
by one in modulo arithmetic. The RTP sequence number for the first by one in modulo arithmetic. The RTP sequence number for the first
packet sent after a pause SHALL be incremented by one compared to the packet sent after a pause SHALL be incremented by one compared to the
highest RTP sequence number sent before the pause. The first RTP highest RTP sequence number sent before the pause. The first RTP
Time Stamp for the first packet sent after a pause SHOULD be set Time Stamp for the first packet sent after a pause SHOULD be set
according to capture times at the source. according to capture times at the source.
7.2. Pausing State 7.2. Pausing State
In this state, the media 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 media 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 media stream being paused before actually messages for the RTP stream being paused before actually pausing RTP
pausing media transmission. The period to wait SHALL be long enough stream transmission. The period to wait SHALL be long enough to
to allow another media receiver to respond to the PAUSE with a allow another RTP stream receiver to respond to the PAUSE with a
RESUME, if it determines that it would not like to see the stream RESUME, if it determines that it would not like to see the stream
paused. This delay period (denoted by 'Hold-off period' in the paused. This delay period (denoted by 'Hold-off period' in the
figure) is determined by the formula: figure) is determined by the formula:
2 * RTT + T_dither_max, 2 * RTT + T_dither_max,
where RTT is the longest round trip known to the media sender and where RTT is the longest round trip known to the RTP stream sender
T_dither_max is defined in section 3.4 of [RFC4585]. The hold-off and T_dither_max is defined in section 3.4 of [RFC4585]. The hold-
period MAY be set to 0 by some signaling (Section 10) means when it off period MAY be set to 0 by some signaling (Section 10) means when
can be determined that there is only a single receiver, for example it can be determined that there is only a single receiver, for
in point-to-point or some unicast situations. example in point-to-point or some unicast situations.
If the RTP media stream sender has set the hold-off period to 0 and If the RTP stream sender has set the hold-off period to 0 and
receives information that it was an incorrect decision and that there receives information that it was an incorrect decision and that there
are in fact several receivers of the stream, for example by RTCP RR, are in fact several receivers of the stream, for example by RTCP RR,
it MUST change the hold-off to instead be based on the above formula. it MUST change the hold-off to instead be based on the above formula.
7.3. Paused State 7.3. Paused State
An RTP media stream is in paused state when the sender pauses its An RTP stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the hold- transmission after receiving at least one PAUSE message and the hold-
off period has passed without receiving any RESUME message for that off period has passed without receiving any RESUME message for that
stream. stream.
When entering the state, the media sender SHALL send a PAUSED When entering the state, the RTP stream sender SHALL send a PAUSED
indication to all known media receivers, and SHALL also repeat PAUSED indication to all known RTP stream receivers, and SHALL also repeat
in the next two regular RTCP reports. PAUSED in the next two regular RTCP reports.
Following sub-sections discusses some potential issues when an RTP Following sub-sections discusses some potential issues when an RTP
sender goes into paused state. These conditions are also valid if an sender goes into paused state. These conditions are also valid if an
RTP Translator is used in the communication. When an RTP Mixer RTP Translator is used in the communication. When an RTP Mixer
implementing this specification is involved between the participants implementing this specification is involved between the participants
(which forwards the stream by marking the RTP data with its own (which forwards the stream by marking the RTP data with its own
SSRC), it SHALL be a responsibility of the Mixer to control sending SSRC), it SHALL be a responsibility of the Mixer to control sending
PAUSE and RESUME requests to the sender. The below conditions also PAUSE and RESUME requests to the sender. The below conditions also
apply to the sender and receiver parts of the RTP Mixer, apply to the sender and receiver parts of the RTP Mixer,
respectively. respectively.
skipping to change at page 29, line 43 skipping to change at page 29, line 43
When a participant leaves the RTP session, it sends an RTCP BYE When a participant leaves the RTP session, it sends an RTCP BYE
message. In addition to the semantics described in section 6.3.4 and message. In addition to the semantics described in section 6.3.4 and
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 media stream to record of which receiver that caused the RTP stream to pause. If
pause. If that receiver sends an RTCP BYE message observed by the that receiver sends an RTCP BYE message observed by the sender,
sender, the sender SHALL resume the RTP media stream. the sender SHALL resume the RTP stream.
7.3.2. SSRC Time-out 7.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 SHALL be streams that were paused by that removed participant SHALL be
resumed. resumed.
7.4. Local Paused State 7.4. Local Paused State
This state can be entered at any time, based on local decision from This state can be entered at any time, based on local decision from
the media sender. As for Paused State (Section 7.3), the media the RTP stream sender. As for Paused State (Section 7.3), the RTP
sender SHALL send a PAUSED indication to all known media receivers, stream sender SHALL send a PAUSED indication to all known RTP stream
when entering the state, and repeat it in the next two regular RTCP receivers, when entering the state, and repeat it in the next two
reports. regular RTCP reports.
When leaving the state, the stream state SHALL become Playing, When leaving the state, the stream state SHALL become Playing,
regardless whether or not there were any media receivers that sent regardless whether or not there were any RTP stream receivers that
PAUSE for that stream, effectively clearing the media sender's memory sent PAUSE for that stream, effectively clearing the RTP stream
for that media stream. sender's memory for that stream.
8. Message Format 8. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP
feedback messages, i.e. Transport layer, Payload-specific, and feedback messages, i.e. Transport layer, Payload-specific, and
Application layer feedback messages. This document defines a new Application layer feedback messages. This document defines a new
Transport layer feedback message, this message is either a PAUSE Transport layer feedback message, this message is either a PAUSE
request, a RESUME request, or one of four different types of request, a RESUME request, or one of four different types of
acknowledgements in response to either PAUSE or RESUME requests. acknowledgments in response to either PAUSE or RESUME requests.
The Transport layer feedback messages are identified by having the The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The
PAUSE and RESUME messages are identified by Feedback Message Type PAUSE and RESUME messages are identified by Feedback Message Type
(FMT) value in common packet header for feedback message defined in (FMT) value in common packet header for feedback message defined in
section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport
feedback message is identified by the FMT value = TBA1. feedback message is identified by the FMT value = TBA1.
The Common Packet Format for Feedback Messages is defined by AVPF The Common Packet Format for Feedback Messages defined by AVPF
[RFC4585] is: [RFC4585] is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length | |V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
For the PAUSE and RESUME messages, the following interpretation of For the PAUSE and RESUME messages, the following interpretation of
the packet fields will be: the packet fields will be:
FMT: The FMT value identifying the PAUSE and RESUME message: TBA1 FMT: The FMT value identifying the PAUSE and RESUME message: 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.
SSRC of packet sender: The SSRC of the RTP session participant SSRC of packet sender: The SSRC of the RTP session participant
sending the messages in the FCI. Note, for end-points that have sending the messages in the FCI. Note, for End Points that have
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to multiple SSRCs in an RTP session, any of its SSRCs MAY be used to
send any of the pause message types. send any of the pause message types.
SSRC of media source: Not used, SHALL be set to 0. The FCI SSRC of media source: Not used, SHALL be set to 0. The FCI
identifies the SSRC the message is targeted for. identifies the SSRC the message is targeted for.
The Feedback Control Information (FCI) field consist of one or more The Feedback Control Information (FCI) field consist of one or more
PAUSE, RESUME, PAUSED, REFUSE, or any future extension. These PAUSE, RESUME, PAUSED, REFUSE, or any future extension. These
messages have the following FCI format: messages have the following FCI format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC | | Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID | | Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific : : Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Syntax of FCI Entry in the PAUSE and RESUME message Figure 9: 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 and RESUME messages, this value Target SSRC (32 bits): For a PAUSE and RESUME messages, this value
is the SSRC that the request is intended for. For PAUSED, it MUST is 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 be the SSRC being paused. If pausing is the result of a PAUSE
request, the value in PAUSED is effectively the same as Target request, the value in PAUSED is effectively the same as Target
SSRC in a related PAUSE request. For REFUSE, it MUST be the SSRC in a related PAUSE request. For REFUSE, it MUST be the
skipping to change at page 33, line 7 skipping to change at page 33, line 7
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, pause/
resume signaling MUST revert to use those instead. If the topology resume signaling MUST revert to use those instead. If the topology
is not point-to-point and the messages defined in this specification is not point-to-point and the messages defined in this specification
are not supported, pause/resume functionality with TMMBR/TMMBN MUST are not supported, pause/resume functionality with TMMBR/TMMBN MUST
NOT be used. NOT be used.
9.1. PAUSE 9.1. PAUSE
An RTP media stream receiver MAY schedule PAUSE for transmission at An RTP stream receiver MAY schedule PAUSE for transmission at any
any time. time.
PAUSE has no defined Type Specific parameters and Parameter Len MUST PAUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
PauseID SHOULD be the available PauseID, as indicated by PAUSED PauseID SHOULD be the available PauseID, as indicated by PAUSED
(Section 9.2) or implicitly determined by previously received PAUSE (Section 9.2) or implicitly determined by previously received PAUSE
or RESUME (Section 9.3) requests. A randomly chosen PauseID MAY be or RESUME (Section 9.3) 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 PauseID information, in which
case the PAUSE will either succeed, or the correct PauseID can be case the PAUSE will either succeed, or the correct PauseID can be
learnt from the returned REFUSE (Section 9.4). A PauseID that is found in the returned REFUSE (Section 9.4). A PauseID that is
matching the available PauseID is henceforth also called a valid matching the available PauseID is henceforth also called a valid
PauseID. PauseID.
PauseID needs to be incremented by one, in modulo arithmetic, for PauseID needs to be incremented by one, in modulo arithmetic, for
each PAUSE request that is not a retransmission, compared to what was 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 used in the last PAUSED indication sent by the media sender. This is
to ensure that the PauseID matches what is the current available to ensure that the PauseID matches what is the current available
PauseID at the media sender. The media sender increments what it PauseID at the RTP stream sender. The RTP stream sender increments
considers to be the available PauseID when entering Playing State what it considers to be the available PauseID when entering Playing
(Section 7.1). State (Section 7.1).
For the scope of this specification, a PauseID larger than the For the scope of this specification, a PauseID larger than the
current one is defined as having a value between and including current one is defined as having a value between and including
(PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is
the modulo operator. Similarly, a PauseID smaller than the current the modulo operator. Similarly, a PauseID smaller than the current
one is defined as having a value between and including (PauseID - one is defined as having a value between and including (PauseID -
2^15) MOD 2^16 and (PauseID - 1) MOD 2^16. 2^15) MOD 2^16 and (PauseID - 1) MOD 2^16.
If an RTP media stream receiver that sent a PAUSE with a certain If an RTP stream receiver that sent a PAUSE with a certain PauseID
PauseID receives a RESUME with the same PauseID, it is RECOMMENDED receives a RESUME with the same PauseID, it is RECOMMENDED that it
that it refrains from sending further PAUSE requests for some refrains from sending further PAUSE requests for some appropriate
appropriate time since the RESUME indicates that there are other time since the RESUME indicates that there are other receivers that
receivers that still wishes to receive the stream. still wishes to receive the stream.
If the targeted RTP media stream does not pause, if no PAUSED If the targeted RTP stream does not pause, if no PAUSED indication
indication with a larger PauseID than the one used in PAUSE, and if with a larger PauseID than the one used in PAUSE, and if no REFUSE is
no REFUSE is received within 2 * RTT + T_dither_max, the PAUSE MAY be received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled
scheduled for retransmission, using the same PauseID. RTT is the for retransmission, using the same PauseID. RTT is the observed
observed round-trip to the RTP media stream sender and T_dither_max round-trip to the RTP stream sender and T_dither_max is defined in
is defined in section 3.4 of [RFC4585]. section 3.4 of [RFC4585].
When an RTP media stream sender in Playing State (Section 7.1) When an RTP stream sender in Playing State (Section 7.1) receives a
receives a valid PAUSE, and unless local considerations currently valid PAUSE, and unless local considerations currently makes it
makes it impossible to pause the stream, it SHALL enter Pausing State impossible to pause the stream, it SHALL enter Pausing State
(Section 7.2) when reaching an appropriate place to pause in the (Section 7.2) when reaching an appropriate place to pause in the
media stream, and act accordingly. stream, and act accordingly.
If an RTP media stream sender receives a valid PAUSE while in If an RTP stream sender receives a valid PAUSE while in Pausing,
Pausing, Paused (Section 7.3) or Local Paused (Section 7.4) States, Paused (Section 7.3) or Local Paused (Section 7.4) States, the
the received PAUSE SHALL be ignored. received PAUSE SHALL be ignored.
9.2. PAUSED 9.2. PAUSED
The PAUSED indication MAY be sent either as a result of a valid PAUSE The PAUSED indication MAY be sent either as a result of a valid PAUSE
(Section 9.1) request, when entering Paused State (Section 7.3), or (Section 9.1) request, when entering Paused State (Section 7.3), or
based on a RTP media stream sender local decision, when entering based on a RTP stream sender local decision, when entering Local
Local Paused State (Section 7.4). Paused State (Section 7.4).
PauseID MUST contain the available, valid value to be included in a PauseID MUST contain the available, valid value to be included in a
subsequent RESUME (Section 9.3). subsequent RESUME (Section 9.3).
PAUSED SHALL contain a 32 bit parameter with the RTP extended highest PAUSED SHALL contain a 32 bit parameter with the RTP extended highest
sequence number valid when the RTP media stream was paused. sequence number valid when the RTP stream was paused. Parameter Len
Parameter Len MUST be set to 1. MUST be set to 1.
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 the next two sent PAUSED once, PAUSED MUST also be included in the next two
regular RTCP reports, given that the pause condition is then still regular RTCP reports, given that the pause condition is then still
effective. effective.
While remaining in Paused or Local Paused States, PAUSED MAY be While remaining in Paused or Local Paused States, PAUSED MAY be
included in all regular RTCP reports. included in all regular RTCP reports.
When in Paused or Local Paused States, It is RECOMMENDED to send When in Paused or Local Paused States, It is RECOMMENDED to send
PAUSED at the earliest opportunity and also to include it in the next PAUSED at the earliest opportunity and also to include it in the next
two regular RTCP reports, whenever the RTP media sender learns that two regular RTCP reports, whenever the RTP stream sender learns that
there are end-points that did not previously receive the stream, for there are End Points that did not previously receive the stream, for
example by RTCP reports with an SSRC and a CNAME that was not example by RTCP reports with an SSRC and a CNAME that was not
previously seen in the RTP session. previously seen in the RTP session.
9.3. RESUME 9.3. RESUME
An RTP media stream receiver MAY schedule RESUME for transmission An RTP stream receiver MAY schedule RESUME for transmission whenever
whenever it wishes to resume a paused stream, or to disapprove a it wishes to resume a paused stream, or to disapprove a stream from
stream from being paused. being paused.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED PauseID SHOULD be the valid PauseID, as indicated by PAUSED
(Section 9.2) or implicitly determined by previously received PAUSE (Section 9.2) or implicitly determined by previously received PAUSE
(Section 9.1) or RESUME requests. A randomly chosen PauseID MAY be (Section 9.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 PauseID information, in which
case the RESUME will either succeed, or the correct PauseID can be case the RESUME will either succeed, or the correct PauseID can be
learnt from a returned REFUSE (Section 9.4). found in a returned REFUSE (Section 9.4).
RESUME has no defined Type Specific parameters and Parameter Len MUST RESUME has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
When an RTP media stream sender in Pausing (Section 7.2), Paused When an RTP stream sender in Pausing (Section 7.2), Paused
(Section 7.3) or Local Paused State (Section 7.4) receives a valid (Section 7.3) or Local Paused State (Section 7.4) receives a valid
RESUME, and unless local considerations currently makes it impossible RESUME, and unless local considerations currently makes it impossible
to resume the stream, it SHALL enter Playing State (Section 7.1) and to resume the stream, it SHALL enter Playing State (Section 7.1) and
act accordingly. If the RTP media stream sender is incapable of act accordingly. If the RTP stream sender is incapable of honoring
honoring the RESUME request with a valid PauseID, or receives a the RESUME request with a valid PauseID, or receives a RESUME request
RESUME request with an invalid PauseID while in Paused or Pausing with an invalid PauseID while in Paused or Pausing state, the RTP
state, the RTP media stream sender sends a REFUSE message as stream sender sends a REFUSE message as specified below.
specified below.
If an RTP media stream sender in Playing State receives a RESUME If an RTP stream sender in Playing State receives a RESUME containing
containing either a valid PauseID or a PauseID that is less than the either a valid PauseID or a PauseID that is less than the valid
valid PauseID, the received RESUME SHALL be ignored. PauseID, the received RESUME SHALL be ignored.
9.4. REFUSE 9.4. REFUSE
REFUSE has no defined Type Specific parameters and Parameter Len MUST REFUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
If an RTP media sender receives a valid PAUSE (Section 9.1) or RESUME If an RTP stream sender receives a valid PAUSE (Section 9.1) or
(Section 9.3) request that cannot be fulfilled by the sender due to RESUME (Section 9.3) request that cannot be fulfilled by the sender
some local consideration, it SHALL schedule transmission of a REFUSE due to some local consideration, it SHALL schedule transmission of a
indication containing the valid PauseID from the rejected request. REFUSE indication containing the valid PauseID from the rejected
request.
If an RTP media stream sender receives PAUSE or RESUME requests with If an RTP stream sender receives PAUSE or RESUME requests with a non-
a non-valid PauseID it SHALL schedule a REFUSE response containing valid PauseID it SHALL schedule a REFUSE response containing the
the available, valid PauseID, except if the RTP media stream sender available, valid PauseID, except if the RTP stream sender is in
is in Playing State and receives a RESUME with a PauseID less than Playing State and receives a RESUME with a PauseID less than the
the valid one, in which case the RESUME SHALL be ignored. valid one, in which case the RESUME SHALL be ignored.
If several PAUSE or RESUME that would render identical REFUSE If several PAUSE or RESUME that would render identical REFUSE
responses are received before the scheduled REFUSE is sent, duplicate responses are received before the scheduled REFUSE is sent, duplicate
REFUSE MUST NOT be scheduled for transmission. This effectively lets REFUSE MUST NOT be scheduled for transmission. This effectively lets
a single REFUSE respond to several invalid PAUSE or RESUME requests. a single REFUSE respond to several invalid PAUSE or RESUME requests.
If REFUSE containing a certain PauseID was already sent and yet more If REFUSE containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSE PAUSE or RESUME messages are received that require additional REFUSE
with that specific PauseID to be scheduled, and unless the PauseID with that specific PauseID to be scheduled, and unless the PauseID
number space has wrapped since REFUSE was last sent with that number space has wrapped since REFUSE was last sent with that
PauseID, further REFUSE messages with that PauseID SHOULD be sent in PauseID, further REFUSE messages with that PauseID SHOULD be sent in
regular RTCP reports. regular RTCP reports.
An RTP media stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing the same PauseID as in the request receives a REFUSE 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 REFUSE to clear. time to allow the condition that caused REFUSE to clear.
An RTP media stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing a PauseID different from the request MAY receives a REFUSE containing a PauseID different from the request MAY
schedule another request using the PauseID from the REFUSE schedule another request using the PauseID from the REFUSE
indication. indication.
9.5. Transmission Rules 9.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.
skipping to change at page 36, line 34 skipping to change at page 36, line 34
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. PAUSED for that PauseID SHOULD use Regular timing.
o RESUME SHOULD always use Immediate or Early timing. o RESUME SHOULD always use Immediate or Early timing.
o The first transmission of REFUSE for each (non-wrapped) PauseID o The first transmission of REFUSE 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
REFUSE for that PauseID SHOULD use Regular timing. REFUSE for that PauseID SHOULD use Regular timing.
10. Signalling 10. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to
include the request for pause and resume. Like AVPF [RFC4585] and include the request for pause and resume. Like AVPF [RFC4585] and
CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at
media level and it MUST NOT be used at session level. This media level and it MUST NOT be used at session level. This
specification follows all the rules defined in AVPF for rtcp-fb specification follows all the rules defined in AVPF for rtcp-fb
attribute relating to payload type in a session description. attribute relating to payload type in a session description.
skipping to change at page 37, line 12 skipping to change at page 37, line 12
This specification defines two new parameters to the "ccm" feedback This specification defines two new parameters to the "ccm" feedback
value defined in CCM [RFC5104], "pause" and "paused". value defined in CCM [RFC5104], "pause" and "paused".
o "pause" represents the capability to understand the RTCP feedback o "pause" represents the capability to understand the RTCP feedback
message and all of the defined FCIs of PAUSE, RESUME, PAUSED and message and all of the defined FCIs of PAUSE, RESUME, PAUSED and
REFUSE. A direction sub-parameter is used to determine if a given REFUSE. A direction sub-parameter is used to determine if a given
node desires to issue PAUSE or RESUME requests, can respond to node desires to issue PAUSE or RESUME requests, can respond to
PAUSE or RESUME requests, or both. PAUSE or RESUME requests, or both.
o "paused" represents the functionality of supporting the playing o "paused" represents the functionality of supporting the playing
and local paused states and generate PAUSED FCI when a media and local paused states and generate PAUSED FCI when a stream
stream delivery is paused. A direction sub-parameter is used to delivery is paused. A direction sub-parameter is used to
determine if a given node desires to receive these indications, determine if a given node desires to receive these indications,
intends to send them, or both. intends to send them, or both.
The reason for this separation is to make it possible for partial The reason for this separation is to make it possible for partial
implementation of this specification, according to the different implementation of this specification, according to the different
roles in the use cases section (Section 3). roles in the use cases section (Section 3).
A sub-parameter named "nowait", indicating that the hold-off time A sub-parameter named "nowait", indicating that the hold-off time
defined in Section 7.2 can be set to 0, reducing the latency before defined in Section 7.2 can be set to 0, reducing the latency before
the media stream can paused after receiving a PAUSE request. This the stream can paused after receiving a PAUSE request. This
condition occurs when there will be only a single receiver per condition occurs when there will be only a single receiver per
direction in the RTP session, for example in point-to-point sessions. direction in the RTP session, for example in point-to-point sessions.
It is also possible to use in scenarios using unidirectional media. It is also possible to use in scenarios using unidirectional media.
The conditions that allow "nowait" to be set also indicate that it The conditions that allow "nowait" to be set also indicate that it
would be possible to use CCM TMMBR/TMMBN as pause/resume signaling. would be possible to use CCM TMMBR/TMMBN as pause/resume signaling.
A sub-parameter named "dir" is used to indicate in which directions a A sub-parameter named "dir" is used to indicate in which directions a
given node will use the pause or paused functionality. The node given node will use the pause or paused functionality. The node
being configured or issuing an offer or an answer uses the being configured or issuing an offer or an answer uses the
directionality in the following way. Note that pause and paused have directionality in the following way. Note that pause and paused have
separate and different definitions. separate and different definitions.
Direction ("dir") values for "pause" is defined as follows: Direction ("dir") values for "pause" is defined as follows:
sendonly: The node intends to send PAUSE and RESUME requests for sendonly: The node intends to send PAUSE and RESUME requests for
other nodes' media streams and is thus also capable of receiving other nodes' streams and is thus also capable of receiving PAUSED
PAUSED and REFUSE. It will not support receiving PAUSE and RESUME and REFUSE. It will not support receiving PAUSE and RESUME
requests. requests.
recvonly: The node supports receiving PAUSE and RESUME requests recvonly: The node supports receiving PAUSE and RESUME requests
targeted for media streams sent by the node. It will send PAUSED targeted for streams sent by the node. It will send PAUSED and
and REFUSE as needed. The node will not send any PAUSE and RESUME REFUSE as needed. The node will not send any PAUSE and RESUME
requests. requests.
sendrecv: The node supports receiving PAUSE and RESUME requests sendrecv: The node supports receiving PAUSE and RESUME requests
targeted for media streams sent by the node. The node intends to targeted for streams sent by the node. The node intends to send
send PAUSE and RESUME requests for other nodes' media streams. PAUSE and RESUME requests for other nodes' streams. Thus the node
Thus the node is capable of sending and receiving all types of is capable of sending and receiving all types of pause messages.
pause messages. This is the default value. If the "dir"
parameter is omitted, it MUST be interpreted to represent this This is the default value. If the "dir" parameter is omitted, it
value. MUST be interpreted to represent this value.
Direction values for "paused" is defined as follows: Direction values for "paused" is defined as follows:
sendonly: The node intends to send PAUSED indications whenever it sendonly: The node intends to send PAUSED indications whenever it
pauses media delivery in any of its media streams. It has no need pauses RTP stream delivery in any of its streams. It has no need
to receive PAUSED indications itself. to receive PAUSED indications itself.
recvonly: The node desires to receive PAUSED indications whenever recvonly: The node desires to receive PAUSED indications whenever
any media stream sent by another node is paused. It does not any stream sent by another node is paused. It does not intend to
intend to send any PAUSED indications. send any PAUSED indications.
sendrecv: The nodes desires to receive PAUSED indications and sendrecv: The nodes desires to receive PAUSED indications and
intends to send PAUSED indications whenever any media stream is intends to send PAUSED indications whenever any stream is paused.
paused. This is the default value. If the "dir" parameter is This is the default value. If the "dir" parameter is omitted, it
omitted, it MUST be interpreted to represent this value. MUST be interpreted to represent this value.
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)
/ SP "paused" *(SP paused-attr) / SP "paused" *(SP paused-attr)
pause-attr = direction pause-attr = direction
/ "nowait" / "nowait"
/ token ; for future extensions / token ; for future extensions
paused-attr = direction paused-attr = direction
skipping to change at page 39, line 28 skipping to change at page 39, line 28
functionalities. The "pause" and "paused" functionalities are functionalities. The "pause" and "paused" functionalities are
negotiated independently, although the "paused" functionality is part negotiated independently, although the "paused" functionality is part
of the "pause" functionality. As a result, an answerer MAY remove of the "pause" functionality. As a result, an answerer MAY remove
"pause" or "paused" lines from the SDP depending on the agreed mode "pause" or "paused" lines from the SDP depending on the agreed mode
of functionality. of functionality.
In offer/answer, the "dir" parameter is interpreted based on the In offer/answer, the "dir" parameter is interpreted based on the
agent providing the SDP. The node described in the offer is the agent providing the SDP. The node described in the offer is the
offerer, and the answerer is described in an answer. In other words, offerer, and the answerer is described in an answer. In other words,
an offer for "paused dir=sendonly" means that the offerer intends to an offer for "paused dir=sendonly" means that the offerer intends to
send PAUSED indications whenever it pauses media delivery in any of send PAUSED indications whenever it pauses RTP stream delivery in any
its media streams. of its streams.
An answerer receiving an offer with a "pause" parameter with An answerer receiving an offer with a "pause" parameter with
dir=sendrecv MAY remove the pause line in its answer, respond with dir=sendrecv MAY remove the pause line in its answer, respond with
pause keeping sendrecv for full bi-directionality, or it may change pause keeping sendrecv for full bi-directionality, or it may change
dir value to either sendonly or recvonly based on its capabilities dir value to either sendonly or recvonly based on its capabilities
and desired functionality. An offer with a "pause" parameter with and desired functionality. An offer with a "pause" parameter with
dir=sendonly or dir=recvonly is either completely removed or accepted dir=sendonly or dir=recvonly is either completely removed or accepted
with reverse directionality, i.e. sendonly becomes recvonly or with reverse directionality, i.e. sendonly becomes recvonly or
recvonly becomes sendonly. recvonly becomes sendonly.
An answer receiving an offer with "paused" has the same choices as An answer receiving an offer with "paused" has the same choices as
for "pause" above. It should be noted that the directionality of for "pause" above. It should be noted that the directionality of
pause is the inverse of media direction, while the directionality of pause is the inverse of RTP stream direction, while the
paused is the same as the media direction. directionality of paused is the same as the RTP stream direction.
If the offerer believes that itself and the intended answerer are If the offerer believes that itself and the intended answerer are
likely the only end-points in the RTP session, it MAY include the likely the only End Points in the RTP session, it MAY include the
"nowait" sub-parameter on the "pause" line in the offer. If an "nowait" sub-parameter on the "pause" line in the offer. If an
answerer receives the "nowait" sub-parameter on the "pause" line in answerer receives the "nowait" sub-parameter on the "pause" line in
the SDP, and if it has information that the offerer and itself are the SDP, and if it has information that the offerer and itself are
not the only end-points in the RTP session, it MUST NOT include any not the only End Points in the RTP session, it MUST NOT include any
"nowait" sub-parameter on its "pause" line in the SDP answer. The "nowait" sub-parameter on its "pause" line in the SDP answer. The
answerer MUST NOT add "nowait" on the "pause" line in the answer answerer MUST NOT add "nowait" on the "pause" line in the answer
unless it is present on the "paused" line in the offer. If both unless it is present on the "paused" line in the offer. If both
offer and answer contained a "nowait" parameter, then the hold-off offer and answer contained a "nowait" parameter, then the hold-off
time is configured to 0 at both offerer and answerer. time is configured to 0 at both offerer and answerer.
10.2. Declarative Use 10.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP the SDP. This has implications on the interpretation of the SDP
signalling extensions defined in this draft. First, it is normally signaling extensions defined in this draft. First, it is normally
only necessary to include either "pause" or "paused" parameter to only necessary to include either "pause" or "paused" parameter to
indicate the level of functionality the node should use in this RTP indicate the level of functionality the node should use in this RTP
session. Including both is only necessary if some implementations session. Including both is only necessary if some implementations
only understands "paused" and some other can understand both. Thus only understands "paused" and some other can understand both. Thus
indicating both means use pause if you understand it, and if you only indicating both means use pause if you understand it, and if you only
understand paused, use that. understand paused, use that.
The "dir" directionality parameter indicates how the configured node The "dir" directionality parameter indicates how the configured node
should behave. For example "pause" with sendonly: should behave. For example "pause" with sendonly:
sendonly: The node intends to send PAUSE and RESUME requests for sendonly: The node intends to send PAUSE and RESUME requests for
other nodes' media streams and is thus also capable of receiving other nodes' streams and is thus also capable of receiving PAUSED
PAUSED and REFUSE. It will not support receiving PAUSE and RESUME and REFUSE. It will not support receiving PAUSE and RESUME
requests. requests.
In this example, the configured node should send PAUSE and RESUME In this example, the configured node should send PAUSE and RESUME
requests if has reason for it. It does not need to respond to any requests if has reason for it. It does not need to respond to any
PAUSE or RESUME requests as that is not supported. PAUSE or RESUME requests as that is not supported.
The "nowait" parameter, if included, is followed as specified. It is The "nowait" parameter, if included, is followed as specified. It is
the responsibility of the declarative SDP sender to determine if a the responsibility of the declarative SDP sender to determine if a
configured node will participate in a session that will be point to configured node will participate in a session that will be point to
point, based on the usage. For example, a conference client being point, based on the usage. For example, a conference client being
skipping to change at page 41, line 4 skipping to change at page 41, line 4
specification, considering the inherent PAUSE support in RTSP. specification, considering the inherent PAUSE support in RTSP.
11. Examples 11. Examples
The following examples shows use of PAUSE and RESUME messages, The following examples shows use of PAUSE and RESUME messages,
including use of offer-answer: including use of offer-answer:
1. Offer-Answer 1. Offer-Answer
2. Point-to-Point session 2. Point-to-Point session
3. Point-to-multipoint using Mixer 3. Point-to-Multipoint using Mixer
4. Point-to-multipoint using Translator 4. Point-to-Multipoint using Translator
11.1. Offer-Answer 11.1. Offer-Answer
The below figures contains an example how to show support for pausing The below figures contains an example how to show support for pausing
and resuming the streams, as well as indicating whether or not the and resuming the streams, as well as indicating whether or not the
hold-off period can be set to 0. hold-off period can be set to 0.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media s=Pausing Media
skipping to change at page 42, line 23 skipping to change at page 42, line 23
[RFC5104] and therefore no such examples are included here. [RFC5104] and therefore no such examples are included here.
11.2. Point-to-Point Session 11.2. Point-to-Point Session
This is the most basic scenario, which involves two participants, This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off time before pausing a stream transmission accordingly. The hold-off time before pausing a stream
is 0. is 0.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| -------------------------------> | | -------------------------------> |
| t2: PAUSE(3) | | t2: PAUSE(3) |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t3: PAUSED(3) | | t3: PAUSED(3) |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t4: RESUME(3) | | t4: RESUME(3) |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: PAUSE(4) | | t6: PAUSE(4) |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
: : : :
Figure 13: Pause and Resume Operation in Point-to-Point Figure 13: Pause and Resume Operation in Point-to-Point
Figure 13 shows the basic pause and resume operation in Point-to- Figure 13 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). sent at time t6, contains an updated PauseID (4).
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| -------------------------------> | | -------------------------------> |
| t2: TMMBR 0 | | t2: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t3: TMMBN 0 | | t3: TMMBN 0 |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t4: TMMBR 150000 | | t4: TMMBR 150000 |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: TMMBR 0 | | t6: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
: : : :
Figure 14: TMMBR Pause and Resume in Point-to-Point Figure 14: TMMBR Pause and Resume in Point-to-Point
Figure 14 describes the same point-to-point scenario as above, but Figure 14 describes the same point-to-point scenario as above, but
using TMMBR/TMMBN signaling. using TMMBR/TMMBN signaling.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| ------------------------------------> | | ------------------------------------> |
| t2: PAUSE(7), lost | | t2: PAUSE(7), lost |
| <---X-------------- | | <---X-------------- |
| | | |
| t3: RTP data | | t3: RTP data |
| ------------------------------------> | | ------------------------------------> |
: : : :
| <Timeout, still receiving data> | | <Timeout, still receiving data> |
| t4: PAUSE(7) | | t4: PAUSE(7) |
| <------------------------------------ | | <------------------------------------ |
| < RTP data paused > | | < RTP data paused > |
| t5: PAUSED(7) | | t5: PAUSED(7) |
| ------------------------------------> | | ------------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: RESUME(7), lost | | t6: RESUME(7), lost |
| <---X-------------- | | <---X-------------- |
| t7: RESUME(7) | | t7: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
| t8: RTP data | | t8: RTP data |
| ------------------------------------> | | ------------------------------------> |
| t9: RESUME(7) | | t9: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
: : : :
Figure 15: Pause and Resume Operation With Messages Lost Figure 15: Pause and Resume Operation With Messages Lost
Figure 15 describes what happens if a PAUSE message from an RTP media Figure 15 describes what happens if a PAUSE message from an RTP
stream receiver does not reach the RTP media stream sender. After stream receiver does not reach the RTP stream sender. After sending
sending a PAUSE message, the RTP media stream receiver waits for a a PAUSE message, the RTP stream receiver waits for a time-out to
time-out to detect if the RTP media stream sender has paused the data detect if the RTP stream sender has paused the data transmission or
transmission or has sent PAUSED indication according to the rules has sent PAUSED indication according to the rules discussed in
discussed in Section 7.3. As the PAUSE message is lost on the way Section 7.3. As the PAUSE message is lost on the way (at time t2),
(at time t2), RTP data continues to reach to the RTP media stream RTP data continues to reach to the RTP stream receiver. When the
receiver. When the timer expires, the RTP media stream receiver timer expires, the RTP stream receiver schedules a retransmission of
schedules a retransmission of the PAUSE message, which is sent at the PAUSE message, which is sent at time t4. If the PAUSE message
time t4. If the PAUSE message now reaches the RTP media stream now reaches the RTP stream sender, it pauses the RTP stream and
sender, it pauses the RTP media stream and replies with PAUSED. replies with PAUSED.
At time t6, the RTP media stream receiver wishes to resume the stream At time t6, the RTP stream receiver wishes to resume the stream again
again and sends a RESUME, which is lost. This does not cause any and sends a RESUME, which is lost. This does not cause any severe
severe effect, since there is no requirement to wait until further effect, since there is no requirement to wait until further RESUME
RESUME are sent and another RESUME are sent already at time t7, which are sent and another RESUME are sent already at time t7, which now
now reaches the RTP media stream sender that consequently resumes the reaches the RTP stream sender that consequently resumes the stream at
stream at time t8. The time interval between t6 and t7 can vary, but time t8. The time interval between t6 and t7 can vary, but may for
may for example be one RTCP feedback transmission interval as example be one RTCP feedback transmission interval as determined by
determined by the AVPF rules. the AVPF rules.
The RTP media 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 the RESUME PauseID is
less than the valid one and will be ignored by the RTP media stream less than the valid one and will be ignored by the RTP stream sender.
sender. It will also not cause any unwanted resume even if the It will also not cause any unwanted resume even if the stream was
stream was paused based on a PAUSE from some other receiver before paused based on a PAUSE from some other receiver before receiving the
receiving the RESUME, since the valid PauseID is now larger than the RESUME, since the valid PauseID is now larger than the one in the
one in the stray RESUME and will only cause a REFUSE containing the stray RESUME and will only cause a REFUSE containing the new valid
new valid PauseID from the RTP media stream sender. PauseID from 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: REFUSE(11) | | t3: REFUSE(11) |
| ------------------------------> | | ------------------------------> |
| | | |
| t4: RTP data | | t4: RTP data |
| ------------------------------> | | ------------------------------> |
: : : :
Figure 16: Pause Request is Refused in Point-to-Point Figure 16: Pause Request is Refused in Point-to-Point
In Figure 16, the receiver requests to pause the sender, which In Figure 16, the receiver requests to pause the sender, which
refuses to pause due to some consideration local to the sender and refuses to pause due to some consideration local to the sender and
responds with a REFUSE message. responds with a REFUSE message.
11.3. Point-to-multipoint using Mixer 11.3. Point-to-Multipoint using Mixer
An RTP Mixer is an intermediate node connecting different transport- An RTP Mixer is an intermediate node connecting different transport-
level clouds. The Mixer receives streams from different RTP sources, level clouds. The Mixer receives streams from different RTP sources,
selects or combines them based on the application's needs and selects or combines them based on the application's needs and
forwards the generated stream(s) to the destination. The Mixer forwards the generated stream(s) to the destination. The Mixer
typically puts its' own SSRC(s) in RTP data packets instead of the typically puts its' own SSRC(s) in RTP data packets instead of the
original source(s). original source(s).
The Mixer keeps track of all the media streams delivered to the Mixer The Mixer keeps track of all the streams delivered to the Mixer and
and how they are currently used. In this example, it selects the how they are currently used. In this example, it selects the video
video stream to deliver to the receiver R based on the voice activity stream to deliver to the receiver R based on the voice activity of
of the media senders. The video stream will be delivered to R using the RTP stream senders. The video stream will be delivered to R
M's SSRC and with an CSRC indicating the original source. using M's SSRC and with an CSRC indicating the original source.
Note that PauseID is not of any significance for the example and is Note that PauseID is not of any significance for the example and is
therefore omitted in the description. therefore omitted in the description.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 | | R | | M | | S1 | | S2 |
+-----+ +-----| +-----+ +-----+ +-----+ +-----| +-----+ +-----+
: : t1:RTP(S1) : : : : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| | | t2:RTP(M:S1) |<-----------------| |
|<-----------------| | | |<-----------------| | |
skipping to change at page 46, line 43 skipping to change at page 46, line 43
| |<-----------------| | | |<-----------------| |
| | <S1:No RTP to M> | | | | <S1:No RTP to M> | |
: : : : : : : :
Figure 17: Pause and Resume Operation for a Voice Activated Mixer Figure 17: Pause and Resume Operation for a Voice Activated Mixer
The session starts at t1 with S1 being the most active speaker and The session starts at t1 with S1 being the most active speaker and
thus being selected as the single video stream to be delivered to R thus being selected as the single video stream to be delivered to R
(t2) using the Mixer SSRC but with S1 as CSRC (indicated after the (t2) using 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 media to the Mixer. As S2 has less voice activity then delivering an RTP stream to the Mixer. As S2 has less voice activity
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
decides to switch the video stream to S2, and therefore quickly sends decides to switch the video stream to S2, and therefore quickly sends
a RESUME request to S2. At t7, S2 has received the RESUME request a RESUME request to S2. At t7, S2 has received the RESUME request
and acts on it by resuming RTP media delivery to M. When the media and acts on it by resuming RTP stream delivery to M. When the RTP
from t7 arrives at the Mixer, it switches this media into its SSRC stream from t7 arrives at the Mixer, it switches this RTP stream into
(M) at t8 and changes the CSRC to S2. As S1 now becomes unused, the its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes
Mixer issues a PAUSE request to S1 at t9, which is acknowledged at unused, the Mixer issues a PAUSE request to S1 at t9, which is
t10 with a PAUSED and the RTP media stream from S1 stops being acknowledged at t10 with a PAUSED and the RTP stream from S1 stops
delivered. being delivered.
11.4. Point-to-multipoint using Translator 11.4. Point-to-Multipoint using Translator
A transport Translator in an RTP session forwards the message from A transport Translator in an RTP session forwards the message from
one peer to all the others. Unlike Mixer, the Translator does not one peer to all the others. Unlike Mixer, the Translator does not
mix the streams or change the SSRC of the messages or RTP media. mix the streams or change the SSRC of the messages or RTP media.
These examples are to show that the messages defined in this These examples are to show that the messages defined in this
specification can be safely used also in a transport Translator case. specification can be safely used also in a transport Translator case.
The parentheses in the figures contains (Target SSRC, PauseID) The parentheses in the figures contains (Target SSRC, PauseID)
information for the messages defined in this specification. information for the messages defined in this specification.
+-------------+ +-------------+ +--------------+ +-------------+ +-------------+ +--------------+
| Sender(S) | | Translator | | Receiver(R) | | Sender(S) | | Translator | | Receiver(R) |
+-------------+ +-------------| +--------------+ +-------------+ +-------------| +--------------+
: t1: RTP(S) : : : t1: RTP(S) : :
|------------------>| | |------------------>| |
| | t2: RTP (S) | | | t2: RTP (S) |
| |------------------>| | |------------------>|
| | t3: PAUSE(S,3) | | | t3: PAUSE(S,3) |
| |<------------------| | |<------------------|
| t4:PAUSE(S,3) | | | t4:PAUSE(S,3) | |
|<------------------| | |<------------------| |
: < Sender waiting for possible RESUME> : : < Sender waiting for possible RESUME> :
| < RTP data paused > | | < RTP data paused > |
| t5: PAUSED(S,3) | | | t5: PAUSED(S,3) | |
|------------------>| | |------------------>| |
| | t6: PAUSED(S,3) | | | t6: PAUSED(S,3) |
| |------------------>| | |------------------>|
: : : : : :
| | t7: RESUME(S,3) | | | t7: RESUME(S,3) |
| |<------------------| | |<------------------|
| t8: RESUME(S,3) | | | t8: RESUME(S,3) | |
|<------------------| | |<------------------| |
| t9: RTP (S) | | | t9: RTP (S) | |
|------------------>| | |------------------>| |
| | t10: RTP (S) | | | t10: RTP (S) |
| |------------------>| | |------------------>|
: : : : : :
Figure 18: Pause and Resume Operation Between Two Participants Using Figure 18: Pause and Resume Operation Between Two Participants Using
a Translator a Translator
Figure 18 describes how a Translator can help the receiver in pausing Figure 18 describes how a Translator can help the receiver in pausing
and resuming the sender. The sender S sends RTP data to the receiver and resuming the sender. The sender S sends RTP data to the receiver
R through Translator, which just forwards the data without modifying R through Translator, which just forwards the data without modifying
the SSRCs. The receiver sends a PAUSE request to the sender, which the SSRCs. The receiver sends a PAUSE request to the sender, which
in this example knows that there may be more receivers of the stream in this example knows that there may be more receivers of the stream
and waits a non-zero hold-off time to see if there is any other and waits a non-zero hold-off time 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 Translator. Since this describes only a single pause through Translator. Since this describes only a single pause
operation for a single media sender, all messages uses a single operation for a single RTP stream sender, all messages uses a single
PauseID, in this example 3. PauseID, in this example 3.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| S | | T | | R1 | | R2 | | S | | T | | 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 Packet Stream > | | | < Pauses RTP Stream > | |
| t9:PAUSED(S,8) | | | | t9:PAUSED(S,8) | | |
|----------------->| | | |----------------->| | |
| | t10:PAUSED(S,8) | | | | t10:PAUSED(S,8) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
| | t11:RESUME(S,8) | | | | t11:RESUME(S,8) | |
| |<-----------------| | | |<-----------------| |
| t12:RESUME(S,8) | | | | t12:RESUME(S,8) | | |
|<-----------------| | | |<-----------------| | |
| t13:RTP(S) | | | | t13:RTP(S) | | |
|----------------->| | | |----------------->| | |
| | t14:RTP(S) | | | | t14:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
Figure 19: Pause and Resume Operation Between One Sender and Two Figure 19: Pause and Resume Operation Between One Sender and Two
Receivers Through Translator Receivers Through Translator
Figure 19 explains the pause and resume operations when a transport Figure 19 explains the pause and resume operations when a transport
Translator is involved between a sender and two receivers in an RTP Translator 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 media to the happens. At time t1, Sender (S) starts sending an RTP stream to the
Translator, which is forwarded to R1 and R2 through the Translator, Translator, which is forwarded to R1 and R2 through the Translator,
T. R1 and R2 receives RTP data from Translator at t2. At this point, T. R1 and R2 receives RTP data from Translator at t2. At this
both R1 and R2 will send RTCP Receiver Reports to S informing that point, both R1 and R2 will send RTCP Receiver Reports to S informing
they receive S's media stream. that they receive S's 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
least one receiver that may still want to receive the data and uses a least one receiver that may still want to receive the data and uses a
non-zero hold-off period to wait for possible RESUME messages. R2 non-zero hold-off period to wait for possible RESUME messages. R2
did also receive the PAUSE request at time t4 and since it still did also receive the PAUSE request at time t4 and since it still
wants to receive the stream, it sends a RESUME for it at time t5, wants to receive the stream, it sends a RESUME for it at time t5,
which is forwarded to the sender S by the translator T. The sender S which is forwarded to the sender S by the translator T. The sender S
sees the RESUME at time t6 and continues to send data to T which sees the RESUME at time t6 and continues to send data to T 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
time, after which and not having received any disapproving RESUME, it time, after which and not having received any disapproving RESUME, it
concludes that the stream must be paused. S now stops sending the 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. The RTP sender
skipping to change at page 51, line 13 skipping to change at page 51, line 13
tags in SDP. tags in SDP.
4. A registry listing registered values for 'pause' Types. 4. A registry listing registered values for 'pause' Types.
5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the 5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the
pause Type registry. pause Type registry.
13. Security Considerations 13. Security Considerations
This document extends the CCM [RFC5104] and defines new messages, This document extends the CCM [RFC5104] and defines new messages,
i.e. PAUSE and RESUME. The exchange of these new messages MAY have i.e. PAUSE and RESUME. The exchange of these new messages MAY have
some security implications, which need to be addressed by the user. some security implications, which need to be addressed by the user.
Following are some important implications, Following are some important implications,
1. Identity spoofing - An attacker can spoof him/herself as an 1. Identity spoofing - An attacker can spoof him/herself as an
authenticated user and can falsely pause or resume any source authenticated user and can falsely pause or resume any source
transmission. In order to prevent this type of attack, a strong transmission. In order to prevent this type of attack, a strong
authentication and integrity protection mechanism is needed. authentication and integrity protection mechanism is needed.
2. Denial of Service (DoS) - An attacker can falsely pause all 2. Denial of Service (DoS) - An attacker can falsely pause all
source streams which MAY result in Denial of Service (DoS). An source streams which MAY result in Denial of Service (DoS). An
Authentication protocol may prevent this attack. Authentication protocol may prevent this attack.
3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP 3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP
source is prone to a Man-in-Middle attack. Public key source is prone to a Man-in-Middle attack. Public key
authentication may be used to prevent MiMT. authentication may be used to prevent MiMT.
14. Contributors 14. Contributors
Daniel Groendal contributed in the creation and writing of earlier Daniel Grondal contributed in the creation and writing of earlier
versions of this specification. versions of this specification.
15. Acknowledgements 15. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. versions of this draft.
16. References 16. References
16.1. Normative References 16.1. Normative References
skipping to change at page 52, line 21 skipping to change at page 52, line 21
"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
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
16.2. Informative References 16.2. Informative References
[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-01 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
October 2013. May 2014.
[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., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-01 (work in progress), February rtp-grouping-taxonomy-01 (work in progress), February
2014. 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
skipping to change at page 54, line 11 skipping to change at page 54, line 11
telephony; Media handling and interaction", 3GPP TS 26.114 telephony; Media handling and interaction", 3GPP TS 26.114
10.7.0, June 2013, 10.7.0, June 2013,
<http://www.3gpp.org/ftp/Specs/html-info/26114.htm>. <http://www.3gpp.org/ftp/Specs/html-info/26114.htm>.
[TS36.201] [TS36.201]
3GPP, "Evolved Universal Terrestrial Radio Access 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); LTE physical layer; General description", 3GPP (E-UTRA); LTE physical layer; General description", 3GPP
TS 36.201 10.0.0, December 2010, TS 36.201 10.0.0, December 2010,
<http://www.3gpp.org/ftp/Specs/html-info/36201.htm>. <http://www.3gpp.org/ftp/Specs/html-info/36201.htm>.
Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between Version -00 and -01
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
o Improved alignment with RTP Taxonomy draft, including the change
of Packet Stream to RTP Stream
o Editorial improvements
Authors' Addresses Authors' Addresses
Azam Akram Bo Burman
Ericsson Ericsson
Farogatan 6 Kistavagen 25
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107142658 Phone: +46107141311
Fax: +46107175550 Email: bo.burman@ericsson.com
Email: muhammad.azam.akram@ericsson.com
URI: www.ericsson.com URI: www.ericsson.com
Bo Burman Azam Akram
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107141311 Phone: +46107142658
Fax: +46107175550 Email: muhammad.azam.akram@ericsson.com
Email: bo.burman@ericsson.com
URI: www.ericsson.com URI: www.ericsson.com
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
 End of changes. 181 change blocks. 
709 lines changed or deleted 719 lines changed or added

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