draft-ietf-avtext-rtp-stream-pause-02.txt   draft-ietf-avtext-rtp-stream-pause-03.txt 
Network Working Group B. Burman Network Working Group B. Burman
Internet-Draft A. Akram Internet-Draft A. Akram
Updates: 5104 (if approved) Ericsson Updates: 5104 (if approved) Ericsson
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 25, 2015 Huawei Technologies Expires: April 17, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
July 24, 2014 October 14, 2014
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-02 draft-ietf-avtext-rtp-stream-pause-03
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 January 25, 2015. This Internet-Draft will expire on April 17, 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 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 11
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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12
4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 12
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 12 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 13 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 13 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 14
5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 14 5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 14
5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 15 5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16
5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 16 5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 17
5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 17 5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 18
6. Participant States . . . . . . . . . . . . . . . . . . . . . 18 6. Participant States . . . . . . . . . . . . . . . . . . . . . 19
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 20 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 20 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 21
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 20 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 21
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 20 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 23 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 26 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 28
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 29 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 31
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 30 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 32
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 33 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 34
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 36 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 38
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 38 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 12. Security Considerations . . . . . . . . . . . . . . . . . . . 44
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
15.1. Normative References . . . . . . . . . . . . . . . . . . 42 15.1. Normative References . . . . . . . . . . . . . . . . . . 45
15.2. Informative References . . . . . . . . . . . . . . . . . 43 15.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 44 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 46
A.1. Modifications Between Version -01 and -02 . . . . . . . . 44 A.1. Modifications Between Version -02 and -03 . . . . . . . . 46
A.2. Modifications Between Version -00 and -01 . . . . . . . . 44 A.2. Modifications Between Version -01 and -02 . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Modifications Between Version -00 and -01 . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
temporarily pausing the RTP streams that aren't required by the RTP temporarily pausing the RTP streams that aren't required by the RTP
Mixer. If the number of conference participants are greater than Mixer. If the number of conference participants are greater than
what the conference logic has chosen to present simultaneously to what the conference logic has chosen to present simultaneously to
receiving participants, some participant RTP streams sent to the RTP receiving participants, some participant RTP streams sent to the RTP
Mixer may not need to be forwarded to any other participant. Those Mixer may not need to be forwarded to any other participant. Those
RTP streams could then be temporarily paused. This becomes RTP streams could then be temporarily paused. This becomes
especially useful when the media sources are provided in multiple especially useful when the media sources are provided in multiple
encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast] encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast]
or with Multi-Session Transmission (MST) of scalable encoding such as or with Multi-Session Transmission (MST) of scalable encoding such as
SVC [RFC6190]. There may be some of the defined encodings or SVC [RFC6190]. There may be some of the defined encodings or
combination of scalable layers that are not used all of the time. combination of scalable layers that are not used or cannot be used
all of the time, for example due to temporarily limited network or
processing resources, and a centralized node may choose to pause such
RTP streams without being requested to do so, but anyway send an
explicit indication that the stream is paused.
As the RTP 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 signaling channel dynamic in such scenarios, using the out-of-band signaling channel
for pausing, and even more importantly resuming, an RTP 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 signaling 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 RTP 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. whenever possible.
2. Definitions 2. Definitions
2.1. Abbreviations 2.1. Abbreviations
3GPP: 3rd Generation Partnership Project 3GPP: 3rd Generation Partnership Project
AVPF: Audio-Visual Profile with Feedback (RFC 4585) AVPF: Audio-Visual Profile with Feedback (RFC 4585)
BGW: Border Gateway BGW: Border Gateway
CCM: Codec Control Messages (RFC 5104) CCM: Codec Control Messages (RFC 5104)
CNAME: Canonical Name (RTCP SDES) CNAME: Canonical Name (RTCP SDES)
CSRC: Contributing Source (RTP) CSRC: Contributing Source (RTP)
FB: Feedback (AVPF) FB: Feedback (AVPF)
FCI: Feedback Control Information (AVPF) FCI: Feedback Control Information (AVPF)
FIR: Full Intra Refresh (CCM) FIR: Full Intra Refresh (CCM)
skipping to change at page 6, line 14 skipping to change at page 6, line 15
2.2. Terminology 2.2. Terminology
In addition to the following, the definitions from RTP [RFC3550], In addition to the following, the definitions from RTP [RFC3550],
AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy
[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 REFUSED as
Notification. Notification.
PAUSE Request from an RTP stream receiver to pause a stream PAUSE Request from an RTP stream receiver to pause a stream
RESUME Request from an RTP stream receiver to resume a paused RESUME Request from an RTP stream receiver to resume a paused
stream stream
PAUSED Indication from an RTP stream sender that a stream is PAUSED Indication from an RTP stream sender that a stream is
paused paused
REFUSE Notification from an RTP stream sender that a PAUSE or REFUSED Indication from an RTP stream sender that a PAUSE or
RESUME request will not be honored RESUME request will not be honored
Mixer: The intermediate RTP node which receives an RTP stream from Mixer: The intermediate RTP node which receives an RTP stream from
different end points, combines them to make one RTP stream and different end points, combines them to make one RTP stream and
forwards to destinations, in the sense described in Topo-Mixer of forwards to destinations, in the sense described in Topo-Mixer of
RTP 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.
skipping to change at page 8, line 40 skipping to change at page 8, line 43
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-Session Transmission) [RFC6190], thus providing multiple
versions that can be delivered by the RTP stream sender. These versions that can be delivered by the RTP stream sender. These
examples indicate that there are numerous reasons why a particular examples indicate that there are numerous reasons why a particular
stream would not currently be in use, but must be available for use stream would not currently be in use, but must be available for use
at very short notice if any dynamic event occurs that causes a at very short notice if any dynamic event occurs that causes a
different 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.
In some cases, especially when the Mixer sends multiple RTP streams
per receiving client, there may be situations that makes it desirable
to the Mixer to pause some of its sent RTP streams, even without
being explicitly asked to do so by the receiving client. Such
situations can for example be caused by a temporary lack of available
Mixer network or processing resources. An RTP stream receiver that
no longer receives an RTP stream could interpret this as an error
condition and try to take action to re-establish the RTP stream.
Such action would likely be undesirable if the RTP stream was in fact
deliberately paused by the Mixer. Undesirable RTP stream receiver
actions could be avoided if the Mixer is able to explicitly indicate
that an RTP stream is deliberately paused.
Just as for point-to-point (Section 3.1), there is only a single Just as for point-to-point (Section 3.1), there is only a single
receiver of the stream, the RTP Mixer, and pausing or resuming a receiver of the stream, the RTP Mixer, and pausing or resuming a
stream does not affect anyone else than the sender and single stream does not affect anyone else 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,
skipping to change at page 11, line 10 skipping to change at page 11, line 25
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 an RTP stream receiver, who wants to It is the responsibility of an RTP stream receiver, who wants to
pause or resume a stream from the sender(s), to transmit PAUSE and pause or resume a stream from the sender(s), to transmit PAUSE and
RESUME messages. An RTP stream sender who likes to pause itself, can RESUME messages. An RTP stream sender who likes to pause itself, can
simply do it. Any indication that an RTP stream is paused is the often simply do it, but sometimes this will adversely affect the
receiver and an explicit indication that the RTP stream is paused may
then help. Any indication that an RTP stream is paused is the
responsibility of the RTP stream sender and may in some cases not responsibility of the RTP stream sender and may in some cases not
even be needed by the stream receiver. even be needed by the stream receiver.
4.3. Apply to Individual Sources 4.3. Apply to Individual Sources
The PAUSE and RESUME messages apply to single RTP streams identified The PAUSE and RESUME messages apply to single RTP streams identified
by their SSRC, which means the receiver targets the sender's SSRC in by their SSRC, which means the receiver targets the sender's SSRC in
the PAUSE and RESUME requests. If a paused sender starts sending the PAUSE and RESUME requests. If a paused sender starts sending
with a new SSRC, the receivers will need to send a new PAUSE request with a new SSRC, the receivers will need to send a new PAUSE request
in order to pause it. PAUSED indications refer to a single one of in order to pause it. PAUSED indications refer to a single one of
skipping to change at page 11, line 37 skipping to change at page 12, line 5
the stream is shared between multiple receivers, a single receiver on the stream is shared between multiple receivers, a single receiver on
that shared network, independent of it being multicast, a mesh with that shared network, independent of it being multicast, a mesh with
joint RTP session or a transport Translator based, must not single- joint RTP session or a transport Translator based, must not single-
handedly cause the stream to be paused without letting all other handedly cause the stream to be paused without letting all other
receivers to voice their opinions on whether or not the stream should receivers to voice their opinions on whether or not the stream should
be paused. A consequence of this is that a newly joining receiver, be paused. A consequence of this is that a newly joining receiver,
for example indicated by an RTCP Receiver Report containing both a for example indicated by an RTCP Receiver Report containing both a
new SSRC and a CNAME that does not already occur in the session, new SSRC and a CNAME that does not already occur in the session,
firstly needs to learn the existence of paused streams, and secondly firstly needs to learn the existence of paused streams, and secondly
should be able to resume any paused stream. Any single receiver should be able to resume any paused stream. Any single receiver
wanting to resume a stream should also cause it to be resumed. wanting to resume a stream should also cause it to be resumed. An
important exception to this is when the RTP stream sender is aware of
conditions that makes it desirable or even necessitates to pause the
RTP stream on its own behalf, without being explicitly asked to do
so. Such local consideration in the RTP sender takes precedence over
RTP receiver wishes to receive the stream.
4.5. Acknowledgments 4.5. Message Acknowledgments
RTP and RTCP does not guarantee reliable data transmission. It uses RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower layer transport protocol can provide. whatever assurance the lower layer transport protocol can provide.
However, this is commonly UDP that provides no reliability However, this is commonly UDP that provides no reliability
guarantees. Thus it is possible that a PAUSE and/or RESUME message guarantees. Thus it is possible that a PAUSE and/or RESUME message
transmitted from an RTP End Point does not reach its destination, transmitted from an RTP End Point does not reach its destination,
i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches
the RTP stream sender and are effective, i.e., an active RTP stream the RTP stream sender and are effective, i.e., an active RTP stream
sender pauses, or a resuming RTP stream sender 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 stream. Thus, no explicit acknowledgments RTP packets for that RTP stream. Thus, no explicit acknowledgments
are required in this case. are required in this case.
In some cases when a PAUSE or RESUME message reaches the RTP stream In some cases when a PAUSE or RESUME message reaches the RTP stream
sender, it will not be able to pause or resume the stream due to some sender, it will not be able to pause or resume the stream due to some
local consideration, for example lack of data to transmit. This local consideration, for example lack of data to transmit. This
error condition, a negative acknowledgment, may be needed to avoid error condition, a negative acknowledgment, may be needed to avoid
unnecessary retransmission of requests (Section 4.6). unnecessary retransmission of requests (Section 4.6).
4.6. Retransmitting Requests 4.6. Request Retransmission
When the stream is not affected as expected by a PAUSE or RESUME When the stream is not affected as expected by a PAUSE or RESUME
request, the request may have been lost and the sender of the request request, the request may have been lost and the sender of the request
will need to retransmit it. The retransmission should take the round will need to retransmit it. The retransmission should take the round
trip time into account, and will also need to take the normal RTCP trip time into account, and will also need to take the normal RTCP
bandwidth and timing rules applicable to the RTP session into bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback. account, when scheduling retransmission of feedback.
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
skipping to change at page 13, line 24 skipping to change at page 13, line 47
5. Solution Overview 5. Solution Overview
The proposed solution implements PAUSE and RESUME functionality based The proposed solution implements PAUSE and RESUME functionality based
on sending AVPF RTCP feedback messages from any RTP session on sending AVPF RTCP feedback messages from any RTP session
participant that wants to pause or resume a stream targeted at the participant that wants to pause or resume a stream targeted at the
stream sender, as identified by the sender SSRC. stream sender, as identified by the sender SSRC.
It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent 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 apply when using where new semantics is needed.
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 REFUSED response, or an
to this specification. This structure allows a single feedback extension to this specification. This structure allows a single
message to handle pause functionality on a number of streams. feedback 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 RTP stream sender to indicate a local decision used standalone by the RTP stream sender to indicate a local decision
to pause, and inform any receiver of the fact that halting media to pause, and inform any receiver of the fact that halting media
delivery is deliberate and which RTP packet was the last transmitted. delivery is deliberate and which RTP packet was the last transmitted.
Special considerations that apply when using TMMBR/TMMBN for pause
and resume purposes are described in Section 5.5. This specification
applies to both the new messages defined in herein as well as their
TMMBR/TMMBN counterparts, except when explicitly stated otherwise.
An obvious exception are any reference to the message parameters that
are only available in the messages defined here. For example, any
reference to PAUSE in the text below is equally applicable to TMMBR
0, and any reference to PAUSED is equally applicable to TMMBN 0.
Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the
text, unless there is specific reason to do so.
This section is intended to be explanatory and therefore This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification. instead be found in other parts of this specification.
5.1. Expressing Capability 5.1. Expressing Capability
An 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 only a subset of messages is possible, to
the others to support partial implementation, which is specifically support partial implementation, which is specifically believed to be
believed to be feasible for the RTP Mixer to Media Sender use case 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.
5.2. Requesting to Pause 5.2. Requesting to Pause
An RTP 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.
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 stream (SSRC). targeted RTP stream (SSRC).
When a non-paused RTP stream sender receives the PAUSE request, it When a non-paused RTP stream sender receives the PAUSE request, it
continues to send the RTP stream while waiting for some time to allow continues to send the RTP stream while waiting for some time to allow
other RTP stream receivers in the same RTP session that saw this other RTP stream receivers in the same RTP session that saw this
PAUSE request to disapprove by sending a RESUME (Section 5.4) for the PAUSE request to disapprove by sending a RESUME (Section 5.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 stream sender during If such disapproving RESUME arrives at the RTP stream sender during
the wait period before the stream is paused, the pause is not the hold-off 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 hold-off period may
set to zero. Using a wait period of zero is also appropriate when be set to zero. Using a hold-off period of zero is also appropriate
using TMMBR 0 and in line with the semantics for that message. when using TMMBR 0 and in line with the semantics for that message.
If the RTP stream sender receives further PAUSE requests with the If the RTP stream sender receives further PAUSE requests with the
available PauseID while waiting as described above, those additional available PauseID while waiting as described above, those 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 is lost before it reaches the RTP stream sender,
stream sender, it will be discovered by the RTP stream receiver it will be discovered by the RTP stream receiver because it continues
because it continues to receive the RTP stream. It will also not see to receive the RTP stream. It will also not see any PAUSED
any PAUSED indication (Section 5.3) or TMMBN 0 for the stream. The indication (Section 5.3) for the stream. The same condition can be
same condition can be caused by the RTP stream sender having received caused by the RTP stream sender having received a disapproving RESUME
a disapproving RESUME from a stream receiver A for a PAUSE request from a stream receiver A for a PAUSE request sent by a stream sender
sent by a stream sender B, but that the PAUSE sender (B) did not B, but that the PAUSE sender (B) did not receive the RESUME (from A)
receive the RESUME (from A) and may instead think that the PAUSE was and may instead think that the PAUSE was lost. In both cases, a
lost. In both cases, a PAUSE request can be re-transmitted using the PAUSE request can be re-transmitted using the same PauseID. If using
same PauseID. If using TMMBR 0 the request MAY be re-transmitted TMMBR 0 the request MAY be re-transmitted when the requester 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 stream sender receiving a PAUSE not using the available An RTP stream sender receiving a PAUSE not using the available
PauseID informs the RTP stream receiver sending the ineffective PAUSE PauseID informs the RTP stream receiver sending the ineffective PAUSE
of this condition by sending a REFUSE response that contains the next of this condition by sending a REFUSED response that contains the
available PauseID value. This REFUSE also informs the RTP stream next available PauseID value. This REFUSED also informs the RTP
receiver that it is probably not feasible to send another PAUSE for stream receiver that it is probably not feasible to send another
some time, not even with the available PauseID, since there are other PAUSE for some time, not even with the available PauseID, since there
RTP stream receivers that wish to receive the stream. are other RTP stream receivers that wish to receive 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 stream receiver joins a session and wants to PAUSE a when a new RTP stream receiver joins a session and wants to PAUSE a
stream, but does not yet know the available PauseID to use. The stream, but does not yet know the available PauseID to use. The
REFUSE response will then provide sufficient information to create a REFUSED response will then provide sufficient information to create a
valid PAUSE. The required extra signaling round-trip is not valid PAUSE. The required extra signaling round-trip is not
considered harmful, since it is assumed that pausing a stream is not considered harmful, since it is assumed that pausing a stream is not
time-critical (Section 4.1). time-critical (Section 4.1).
There may be local considerations making it impossible or infeasible There may be local considerations making it impossible or infeasible
to pause the stream, and the RTP stream sender can then respond with to pause the stream, and the RTP stream sender can then respond with
a REFUSE. In this case, if the used PauseID would otherwise have a REFUSED. In this case, if the used PauseID would otherwise have
been effective, the REFUSE contains the same PauseID as in the PAUSE been effective, REFUSED contains the same PauseID as in the PAUSE
request, and the PauseID is kept as available. Note that when using 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 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 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 shall contain the current bounding set, and the fact that a TMMBR 0
will always be the most restrictive point in any bounding set. will always be the most restrictive point in any bounding set.
If the RTP stream sender receives several identical PAUSE for an RTP If the RTP stream sender receives several identical PAUSE for an RTP
stream that was already at least once responded with REFUSE and the stream that was already at least once responded with REFUSED and the
condition causing REFUSE remains, those additional REFUSE should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSE can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical PAUSE requests. several identical PAUSE requests.
5.3. Media Sender Pausing 5.3. Media Sender Pausing
An RTP stream sender can choose to pause the stream at any time. An RTP stream sender can choose to pause the stream at any time.
This can either be as a result of receiving a PAUSE, or be based on This can either be as a result of receiving a PAUSE, or be based on
some local sender consideration. When it does, it sends a PAUSED some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. If the stream was indication, containing the available PauseID. Note that PauseID is
paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is incremented when sending an unsolicited PAUSED (without having
said on PAUSED in the rest of this paragraph apply also to the use of received a PAUSE). It also sends the PAUSED indication in the next
TMMBN 0, except for PAUSED message parameters. Note that PauseID is two regular RTCP reports, given that the pause condition is then
incremented when pausing locally (without having received a PAUSE). still effective.
It also sends the PAUSED indication in the next two regular RTCP
reports, given that the pause condition is then still effective. There is no reply to a PAUSED indication; it is simply an explicit
indication of the fact that an RTP stream is paused. This can be
helpful for the RTP stream receiver, for example to understand that
transmission is deliberately and temporarily suspended and no
specific corrective action is needed.
The RTP stream sender may want to apply some local consideration to The RTP stream sender may want to apply some local consideration to
exactly when the stream is paused, for example completing some media exactly when the RTP stream is paused, for example completing some
unit or a forward error correction block, before pausing the stream. media unit or a forward error correction block, 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 stream receivers with first hand information This provides RTP stream receivers with first hand information
allowing them to know whether they lost any packets just before the allowing them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP stream paused or when the stream is resumed again. This allows RTP
stream receivers to quickly and safely take into account that the stream receivers to quickly and safely take into account that the
stream is paused, in for example retransmission or congestion control stream is paused, in for example retransmission or congestion control
algorithms. algorithms.
skipping to change at page 16, line 36 skipping to change at page 17, line 27
When the RTP stream sender learns that a new End Point has joined the When the RTP stream sender learns that a new End Point has joined the
RTP session, for example by a new SSRC and a CNAME that was not RTP session, for example by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in for all its paused streams at its earliest opportunity. It should in
addition continue to include PAUSED indications in at least two addition continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
5.4. Requesting to Resume 5.4. Requesting to Resume
An RTP stream receiver can request to resume a stream with a RESUME An RTP stream receiver can request to resume a stream with a RESUME
request at any time, subject to AVPF timing rules. If the stream was request at any time, subject to AVPF timing rules. The RTP stream
paused with TMMBR 0, resuming the stream is made with TMMBR receiver must include the available PauseID in the RESUME request for
containing a bitrate value larger than 0. The bitrate value used it to be effective.
when resuming after a PAUSE with TMMBR 0 is either according to known
limitations, or the configured maximum for the stream or session.
What is said on RESUME in the rest of this paragraph apply also to
the use of TMMBR with a bitrate value larger than 0, except for
RESUME message parameters.
The RTP stream receiver must include the available PauseID in the
RESUME request for it to be effective.
A pausing RTP stream sender that receives a RESUME including the A pausing RTP stream sender that receives a RESUME including the
correct available PauseID resumes the stream at the earliest 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 at the RTP stream sender, for
is not ready, making it temporarily impossible to resume the stream example that the media device is not ready, making it temporarily
at that point in time, and the RTP stream sender MAY then respond impossible to resume the stream at that point in time, and the RTP
with a REFUSE containing the same PauseID as in the RESUME. When stream sender MAY then respond with a REFUSED containing the same
receiving such REFUSE with a PauseID identical to the one in the sent PauseID as in the RESUME. When receiving such REFUSED with a PauseID
RESUME, RTP stream receivers SHOULD then avoid sending further RESUME identical to the one in the sent RESUME, RTP stream receivers SHOULD
requests for some reasonable amount of time, to allow the condition then avoid sending further RESUME requests for some reasonable amount
to clear. of time, to allow the condition to clear.
If the RTP stream sender receives several identical RESUME for an RTP If the RTP stream sender receives several identical RESUME for an RTP
stream that was already at least once responded with REFUSE and the stream that was already at least once responded with REFUSED and the
condition causing REFUSE remains, those additional REFUSE should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSE can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical RESUME requests. several identical RESUME requests.
A pausing RTP stream sender can apply local considerations and MAY
resume a paused RTP stream at any time. If TMMBR 0 was used to pause
the RTP stream, it cannot be resumed due to local considerations,
unless the RTP stream is paused only due to local considerations
(Section 5.3) and thus no RTP stream receiver has requested to pause
the stream with TMMBR 0.
When resuming a paused stream, especially for media that makes use of When resuming a paused stream, especially for media that makes use of
temporal redundancy between samples such as video, the temporal temporal redundancy between samples such as video, the temporal
dependency between samples taken before the pause and at the time dependency between samples taken before the pause and at the time
instant the stream is resumed may not be appropriate to use in the instant the stream is resumed may not be appropriate to use in the
encoding. Should such temporal dependency between before and after encoding. Should such temporal dependency between before and after
the media was paused be used by the RTP stream sender, it requires the media was paused be used by the RTP stream sender, it requires
the RTP stream receiver to have saved the sample from before the the RTP stream receiver to have saved the sample from before the
pause for successful continued decoding when resuming. The use of pause for successful continued decoding when resuming. The use of
this temporal dependency is left up to the RTP stream sender. If this temporal dependency is left up to the RTP stream sender. If
temporal dependency is not used when the RTP stream is resumed, the temporal dependency is not used when the RTP stream is resumed, the
skipping to change at page 17, line 41 skipping to change at page 18, line 30
dependency to samples before the pause (for video it may be a so- dependency to samples before the pause (for video it may be a so-
called intra picture). If temporal dependency to before the pause is called intra picture). If temporal dependency to before the pause is
used by the RTP stream sender when resuming, and if the RTP stream used by the RTP stream sender when resuming, and if the RTP stream
receiver did not save any sample from before the pause, the RTP receiver did not save any sample from before the pause, the RTP
stream receiver can use a FIR request [RFC5104] to explicitly ask for stream receiver can use a FIR request [RFC5104] to explicitly ask for
a sample without temporal dependency (for video a so-called intra a sample without temporal dependency (for video a so-called intra
picture), even at the same time as sending the RESUME. picture), even at the same time as sending the RESUME.
5.5. TMMBR/TMMBN Considerations 5.5. TMMBR/TMMBN Considerations
As stated, TMMBR/TMMBN may be used to provide pause and resume As stated above, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or point-to-point, TMMBR/TMMBN cannot safely be used for pause or
resume. resume.
This is a brief summary of what functionality is provided when using This is a brief summary of what functionality is provided when using
TMMBR/TMMBN: TMMBR/TMMBN:
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
off period to wait for RESUME before pausing the stream. off period to wait for RESUME before pausing the RTP stream.
TMMBR >0: Corresponds to RESUME when the stream was previously TMMBR >0: Corresponds to RESUME when the RTP stream was previously
paused with TMMBR 0. Since there is only a single RTP stream paused with TMMBR 0. Since there is only a single RTP stream
receiver, there is no need for the RTP stream sender to delay receiver, there is no need for the RTP stream sender to delay
resuming the stream until after sending TMMBN >0, or to apply the resuming the stream until after sending TMMBN >0, or to apply the
hold-off period specified in [RFC5104] before increasing the hold-off period specified in [RFC5104] before increasing the
bitrate from zero. bitrate from zero. The bitrate value used when resuming after
pausing with TMMBR 0 is either according to known limitations, or
based on starting a stream with the configured maximum for the
stream or session, for example given by b-parameter in SDP.
TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with
TMMBR 0, but may, just as PAUSED, also be used unsolicited. An
unsolicited RTP stream pause based on local sender considerations
uses the RTP stream's own SSRC as TMMBR restriction owner in the
TMMBN message bounding set. Also corresponds to a REFUSED
indication when a stream is requested to be resumed with TMMBR >0. indication when a stream is requested to be resumed with TMMBR >0.
TMMBN >0: Cannot be used as REFUSE indication when a stream is TMMBN >0: Cannot be used as REFUSED indication when a stream is
requested to be paused with TMMBR 0, for reasons stated in requested to be paused with TMMBR 0, for reasons stated in
Section 5.2. Section 5.2.
6. Participant States 6. Participant States
This document introduces three new states for a stream in an RTP This document introduces three new states for a stream in an RTP
sender, according to the figure and sub-sections below. Any sender, according to the figure and sub-sections below. Any
references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL
be taken to apply to the extent possible also when TMMBR/TMMBN are be taken to apply to the extent possible also when TMMBR/TMMBN are
used (Section 5.5) for this functionality. used (Section 5.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 +---------+ +--------+
skipping to change at page 18, line 51 skipping to change at page 19, line 48
Figure 4: RTP Pause States Figure 4: RTP Pause States
6.1. Playing State 6.1. Playing State
This state is not new, but is the normal media sending state from This state is not new, but is the normal media sending state from
[RFC3550]. When entering the state, the PauseID MUST be incremented [RFC3550]. When entering the state, the 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, meaning the RTP Time Stamp
difference compared to before the pause reflects the time the RTP
stream was paused.
6.2. Pausing State 6.2. Pausing State
In this state, the RTP stream sender has received at least one PAUSE In this state, the RTP stream sender has received at least one PAUSE
message for the stream in question. The RTP stream sender SHALL wait message for the stream in question. The RTP stream sender SHALL wait
during a hold-off period for the possible reception of RESUME during a hold-off period for the possible reception of RESUME
messages for the RTP stream being paused before actually pausing RTP messages for the RTP stream being paused before actually pausing RTP
stream transmission. The period to wait SHALL be long enough to stream transmission. The hold-off period to wait SHALL be long
allow another RTP stream receiver to respond to the PAUSE with a enough to allow another RTP stream receiver to respond to the PAUSE
RESUME, if it determines that it would not like to see the stream with a RESUME, if it determines that it would not like to see the
paused. This delay period (denoted by 'Hold-off period' in the stream paused. This hold-off period 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 RTP stream sender where RTT is the longest round trip known to the RTP stream sender
and T_dither_max is defined in section 3.4 of [RFC4585]. The hold- and T_dither_max is defined in section 3.4 of [RFC4585]. The hold-
off period MAY be set to 0 by some signaling (Section 9) means when off period MAY be set to 0 by some signaling (Section 9) means when
it can be determined that there is only a single receiver, for it can be determined that there is only a single receiver, for
example in point-to-point or some unicast situations. example in point-to-point or some unicast situations.
If the RTP stream sender has set the hold-off period to 0 and If the RTP stream sender has set the hold-off period to 0 and
skipping to change at page 19, line 41 skipping to change at page 20, line 40
An RTP stream is in paused state when the sender pauses its An RTP stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the hold- transmission after receiving at least one PAUSE message and the hold-
off period has passed without receiving any RESUME message for that off period has passed without receiving any RESUME message for that
stream. stream.
When entering the state, the RTP stream sender SHALL send a PAUSED When entering the state, the RTP stream sender SHALL send a PAUSED
indication to all known RTP stream receivers, and SHALL also repeat indication to all known RTP stream receivers, and SHALL also repeat
PAUSED in the next two regular RTCP reports. PAUSED in the next two regular RTCP reports.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream.
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 20, line 37 skipping to change at page 21, line 37
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.
6.4. Local Paused State 6.4. Local Paused State
This state can be entered at any time, based on local decision from This state can be entered at any time, based on local decision from
the RTP stream sender. As for Paused State (Section 6.3), the RTP the RTP stream sender. As for Paused State (Section 6.3), the RTP
stream sender SHALL send a PAUSED indication to all known RTP stream stream sender SHALL send a PAUSED indication to all known RTP stream
receivers, when entering the state, and repeat it in the next two receivers, when entering the state, and repeat it in the next two
regular RTCP reports. regular RTCP reports, unless the stream was already in paused state
(Section 6.3). When using TMMBN 0 as PAUSED indication, being in
paused state, and entering local paused state, the RTP stream sender
SHALL send TMMBN 0 with itself included in the TMMBN bounding set.
As indicated in Figure 4, this state has higher precedence than
paused state (Section 6.3) and RESUME messages alone cannot resume a
paused RTP stream as long as the local decision still applies.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream.
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 RTP stream receivers that regardless whether or not there were any RTP stream receivers that
sent PAUSE for that stream, effectively clearing the RTP stream sent PAUSE for that stream, effectively clearing the RTP stream
sender's memory for that stream. sender's memory for that stream. This does however not apply when
the stream was paused by a TMMBR 0, either before entering or during
the Local Paused State, in which case leaving Local Paused State just
removes the RTP sender from the TMMBN bounding set, and a new TMMBN
with the updated bounding set MUST be sent accordingly. The stream
state can become Playing only when there is no entry with a bitrate
value of 0 in the stream's bounding set.
7. Message Format 7. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP
feedback messages, i.e. Transport layer, Payload-specific, and feedback messages, i.e. Transport layer, Payload-specific, and
Application layer feedback messages. This document defines a new Application layer feedback messages. This document defines a new
Transport layer feedback message, 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
acknowledgments in response to either PAUSE or RESUME requests. acknowledgments in response to either PAUSE or RESUME requests.
skipping to change at page 21, line 46 skipping to change at page 23, line 14
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, REFUSED, 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 5: Syntax of FCI Entry in the PAUSE and RESUME message Figure 5: 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 REFUSED, it MUST be the
Target SSRC of the PAUSE or RESUME request that cannot change Target SSRC of the PAUSE or RESUME request that cannot change
state. A CSRC MUST NOT be used as a target as the interpretation state. A CSRC MUST NOT be used as a target as the interpretation
of such a request is unclear. of such a request is unclear.
Type (4 bits): The pause feedback type. The values defined in this Type (4 bits): The pause feedback type. The values defined in this
specification are as follows, specification are as follows,
0: PAUSE request message 0: PAUSE request message
1: RESUME request message 1: RESUME request message
2: PAUSED indication message 2: PAUSED indication message
3: REFUSE indication message 3: REFUSED indication message
4-15: Reserved for future use 4-15: Reserved for future use
Res: (4 bits): Type specific reserved. SHALL be ignored by Res: (4 bits): Type specific reserved. SHALL be ignored by
receivers implementing this specification and MUST be set to 0 by receivers implementing this specification and MUST be set to 0 by
senders implementing this specification. senders implementing this specification.
Parameter Len: (8 bits): Length of the Type Specific field in 32-bit Parameter Len: (8 bits): Length of the Type Specific field in 32-bit
words. MAY be 0. words. MAY be 0.
skipping to change at page 23, line 16 skipping to change at page 24, line 28
Type Specific: (variable): Defined per pause feedback Type. MAY be Type Specific: (variable): Defined per pause feedback Type. MAY be
empty. empty.
8. Message Details 8. Message Details
This section contains detailed explanations of each message defined This section contains detailed explanations of each message defined
in this specification. All transmissions of request and indications in this specification. All transmissions of request and indications
are governed by the transmission rules as defined by Section 8.5. are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSE in this section Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be
used instead of the messages defined in this specification when the used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver effective topology is point-to-point. If either sender or receiver
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
be used for pause/resume functionality. If the messages defined in be used for pause/resume functionality. If the messages defined in
this specification are supported in addition to TMMBR/TMMBN, pause/ this specification are supported in addition to TMMBR/TMMBN, pause/
resume signaling MUST revert to use those instead. If the topology resume signaling MUST use messages from this specification. If the
is not point-to-point and the messages defined in this specification topology is not point-to-point and the messages defined in this
are not supported, pause/resume functionality with TMMBR/TMMBN MUST specification are not supported, pause/resume functionality with
NOT be used. TMMBR/TMMBN MUST NOT be used.
8.1. PAUSE 8.1. PAUSE
An RTP stream receiver MAY schedule PAUSE for transmission at any An RTP stream receiver MAY schedule PAUSE for transmission at any
time. time.
PAUSE has no defined Type Specific parameters 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 8.2) or implicitly determined by previously received PAUSE (Section 8.2) or implicitly determined by previously received PAUSE
or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be or RESUME (Section 8.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
found in the returned REFUSE (Section 8.4). A PauseID that is found in the returned REFUSED (Section 8.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 RTP stream sender. The RTP stream sender increments PauseID at the RTP stream sender. The RTP stream sender increments
what it considers to be the available PauseID when entering Playing what it considers to be the available PauseID when entering Playing
State (Section 6.1). State (Section 6.1).
skipping to change at page 24, line 21 skipping to change at page 25, line 31
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 stream receiver that sent a PAUSE with a certain PauseID If an RTP stream receiver that sent a PAUSE with a certain PauseID
receives a RESUME with the same PauseID, it is RECOMMENDED that it receives a RESUME with the same PauseID, it is RECOMMENDED that it
refrains from sending further PAUSE requests for some appropriate refrains from sending further PAUSE requests for some appropriate
time since the RESUME indicates that there are other receivers that time since the RESUME indicates that there are other receivers that
still wishes to receive the stream. still wishes to receive the stream.
If the targeted RTP stream does not pause, if no PAUSED indication If the targeted RTP stream does not pause, if no PAUSED indication
with a larger PauseID than the one used in PAUSE, and if no REFUSE is with a larger PauseID than the one used in PAUSE, and if no REFUSED
received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled is received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled
for retransmission, using the same PauseID. RTT is the observed for retransmission, using the same PauseID. RTT is the observed
round-trip to the RTP stream sender and T_dither_max is defined in round-trip to the RTP stream sender and T_dither_max is defined in
section 3.4 of [RFC4585]. section 3.4 of [RFC4585].
When an RTP stream sender in Playing State (Section 6.1) receives a When an RTP stream sender in Playing State (Section 6.1) receives a
valid PAUSE, and unless local considerations currently makes it valid PAUSE, and unless local considerations currently makes it
impossible to pause the stream, it SHALL enter Pausing State impossible to pause the stream, it SHALL enter Pausing State
(Section 6.2) when reaching an appropriate place to pause in the (Section 6.2) when reaching an appropriate place to pause in the
stream, and act accordingly. stream, and act accordingly.
If an RTP stream sender receives a valid PAUSE while in Pausing, If an RTP stream sender receives a valid PAUSE while in Pausing,
Paused (Section 6.3) or Local Paused (Section 6.4) States, the Paused (Section 6.3) or Local Paused (Section 6.4) States, the
received PAUSE SHALL be ignored. received PAUSE SHALL be ignored.
8.2. PAUSED 8.2. PAUSED
The PAUSED indication MAY be sent either as a result of a valid PAUSE The PAUSED indication MUST be sent whenever entering Paused State
(Section 8.1) request, when entering Paused State (Section 6.3), or (Section 6.3) as a result of receiving a valid PAUSE (Section 8.1)
based on a RTP stream sender local decision, when entering Local request, or when entering Local Paused State (Section 6.4) based on a
Paused State (Section 6.4). RTP stream sender local decision.
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 8.3). subsequent RESUME (Section 8.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 stream was paused. Parameter Len sequence number valid when the RTP stream was paused. 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
skipping to change at page 25, line 31 skipping to change at page 26, line 40
An RTP stream receiver MAY schedule RESUME for transmission whenever An RTP stream receiver MAY schedule RESUME for transmission whenever
it wishes to resume a paused stream, or to disapprove a stream from it wishes to resume a paused stream, or to disapprove a stream from
being paused. being paused.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED PauseID SHOULD be the valid PauseID, as indicated by PAUSED
(Section 8.2) or implicitly determined by previously received PAUSE (Section 8.2) or implicitly determined by previously received PAUSE
(Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve PauseID information, in which used if it was not possible to retrieve 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
found in a returned REFUSE (Section 8.4). found in a returned REFUSED (Section 8.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 stream sender in Pausing (Section 6.2), Paused When an RTP stream sender in Pausing (Section 6.2), Paused
(Section 6.3) or Local Paused State (Section 6.4) receives a valid (Section 6.3) or Local Paused State (Section 6.4) receives a 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 6.1) and to resume the stream, it SHALL enter Playing State (Section 6.1) and
act accordingly. If the RTP stream sender is incapable of honoring act accordingly. If the RTP stream sender is incapable of honoring
the RESUME request with a valid PauseID, or receives a RESUME request the RESUME request with a valid PauseID, or receives a RESUME request
with an invalid PauseID while in Paused or Pausing state, the RTP with an invalid PauseID while in Paused or Pausing state, the RTP
stream sender sends a REFUSE message as specified below. stream sender sends a REFUSED message as specified below.
If an RTP stream sender in Playing State receives a RESUME containing If an RTP stream sender in Playing State receives a RESUME containing
either a valid PauseID or a PauseID that is less than the valid either a valid PauseID or a PauseID that is less than the valid
PauseID, the received RESUME SHALL be ignored. PauseID, the received RESUME SHALL be ignored.
8.4. REFUSE 8.4. REFUSED
REFUSE has no defined Type Specific parameters and Parameter Len MUST REFUSED has no defined Type Specific parameters and Parameter Len
be set to 0. MUST be set to 0.
If an RTP stream sender receives a valid PAUSE (Section 8.1) or If an RTP stream sender receives a valid PAUSE (Section 8.1) or
RESUME (Section 8.3) request that cannot be fulfilled by the sender RESUME (Section 8.3) request that cannot be fulfilled by the sender
due to some local consideration, it SHALL schedule transmission of a due to some local consideration, it SHALL schedule transmission of a
REFUSE indication containing the valid PauseID from the rejected REFUSED indication containing the valid PauseID from the rejected
request. request.
If an RTP stream sender receives PAUSE or RESUME requests with a non- If an RTP stream sender receives PAUSE or RESUME requests with a non-
valid PauseID it SHALL schedule a REFUSE response containing the valid PauseID it SHALL schedule a REFUSED response containing the
available, valid PauseID, except if the RTP stream sender is in available, valid PauseID, except if the RTP stream sender is in
Playing State and receives a RESUME with a PauseID less than the Playing State and receives a RESUME with a PauseID less than 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 REFUSED
responses are received before the scheduled REFUSE is sent, duplicate responses are received before the scheduled REFUSED is sent,
REFUSE MUST NOT be scheduled for transmission. This effectively lets duplicate REFUSED MUST NOT be scheduled for transmission. This
a single REFUSE respond to several invalid PAUSE or RESUME requests. effectively lets a single REFUSED respond to several invalid PAUSE or
RESUME requests.
If REFUSE containing a certain PauseID was already sent and yet more If REFUSED containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSE PAUSE or RESUME messages are received that require additional REFUSED
with that specific PauseID to be scheduled, and unless the PauseID with that specific PauseID to be scheduled, and unless the PauseID
number space has wrapped since REFUSE was last sent with that number space has wrapped since REFUSED was last sent with that
PauseID, further REFUSE messages with that PauseID SHOULD be sent in PauseID, further REFUSED messages with that PauseID SHOULD be sent in
regular RTCP reports. regular RTCP reports.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing the same PauseID as in the request receives a REFUSED containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSE to clear. time to allow the condition that caused REFUSED to clear.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing a PauseID different from the request MAY receives a REFUSED containing a PauseID different from the request
schedule another request using the PauseID from the REFUSE MAY schedule another request using the PauseID from the REFUSED
indication. indication.
8.5. Transmission Rules 8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation. depends on the session's mode of operation.
All messages defined in this specification MAY use either Regular, All messages defined in this specification, as well as TMMBR/TMMBN
used for pause/resume purposes (Section 5.5), MAY use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, taking the following into consideration:
o PAUSE SHOULD use Early or Immediate timing, except for o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing. retransmissions that SHOULD use Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. 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 REFUSED 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. REFUSED for that PauseID SHOULD use Regular timing.
9. Signaling 9. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to
include the request for pause and resume. Like AVPF [RFC4585] and include the request for pause and resume. This specification follows
CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an
media level and it MUST NOT be used at session level. This rtcp-fb attribute relating to payload type in a session description.
specification follows all the rules defined in AVPF for rtcp-fb
attribute relating to payload type in a session description. This specification defines a new parameter "pause" to the "ccm"
feedback value defined in CCM [RFC5104], representing the capability
to understand the RTCP feedback message and all of the defined FCIs
of PAUSE, RESUME, PAUSED and REFUSED.
Note: When TMMBR 0 / TMMBN 0 are used to implement pause and Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
resume functionality (with the restrictions described in this resume functionality (with the restrictions described in this
memo), signaling rtcp-fb attribute with ccm tmmbr parameter is specification), signaling rtcp-fb attribute with ccm tmmbr
sufficient and no further signaling is necessary. parameter is sufficient and no further signaling is necessary.
There is however no guarantee that TMMBR/TMMBN implementations
pre-dating this specification work exactly as described here when
used with a bitrate value of 0.
This specification defines two new parameters to the "ccm" feedback The "pause" parameter has two optional attributes, "nowait" and
value defined in CCM [RFC5104], "pause" and "paused". "config":
o "pause" represents the capability to understand the RTCP feedback o "nowait" indicates that the hold-off period defined in Section 6.2
message and all of the defined FCIs of PAUSE, RESUME, PAUSED and can be set to 0, reducing the latency before the stream can paused
REFUSE. A direction sub-parameter is used to determine if a given after receiving a PAUSE request. This condition occurs when there
node desires to issue PAUSE or RESUME requests, can respond to will be only a single receiver per direction in the RTP session,
PAUSE or RESUME requests, or both. for example in point-to-point sessions. It is also possible to
use in scenarios using unidirectional media. The conditions that
allow "nowait" to be set also indicate that it would be possible
to use CCM TMMBR/TMMBN as pause/resume signaling.
o "paused" represents the functionality of supporting the playing o "config" allows for partial implementation of this specification
and local paused states and generate PAUSED FCI when a stream according to the different roles in the use cases section
delivery is paused. A direction sub-parameter is used to (Section 3), and takes a value that describes what sub-set is
determine if a given node desires to receive these indications, implemented:
intends to send them, or both.
The reason for this separation is to make it possible for partial 1 Full implementation of this specification. This is the default
implementation of this specification, according to the different configuration. A missing config attribute MUST be treated
roles in the use cases section (Section 3). equivalent to providing a config value of 1.
A sub-parameter named "nowait", indicating that the hold-off time 2 The implementation intends to send PAUSE and RESUME requests
defined in Section 6.2 can be set to 0, reducing the latency before for received RTP streams and is thus also capable of receiving
the stream can paused after receiving a PAUSE request. This PAUSED and REFUSED. It does not support receiving PAUSE and
condition occurs when there will be only a single receiver per RESUME requests, but may pause sent RTP streams due to local
direction in the RTP session, for example in point-to-point sessions. considerations and then intends to send PAUSED for them.
It is also possible to use in scenarios using unidirectional media.
The conditions that allow "nowait" to be set also indicate that it
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 3 The implementation supports receiving PAUSE and RESUME requests
given node will use the pause or paused functionality. The node targeted for RTP streams it sends. It will send PAUSED and
being configured or issuing an offer or an answer uses the REFUSED as needed. The node will not send any PAUSE and RESUME
directionality in the following way. Note that pause and paused have requests, but supports and desires receiving PAUSED if received
separate and different definitions. RTP streams are paused.
Direction ("dir") values for "pause" is defined as follows: 4 The implementation intends to send PAUSE and RESUME requests
for received RTP streams and is thus also capable of receiving
PAUSED and REFUSED. It cannot pause any RTP streams it sends,
and thus does not support receiving PAUSE and RESUME requests,
and also does not support sending PAUSED indications.
sendonly: The node intends to send PAUSE and RESUME requests for 5 The implementation supports receiving PAUSE and RESUME requests
other nodes' streams and is thus also capable of receiving PAUSED targeted for RTP streams it sends. It will send PAUSED and
and REFUSE. It will not support receiving PAUSE and RESUME REFUSED as needed. It does not support sending PAUSE and
requests. RESUME requests to pause received RTP streams, and also does
not support receiving PAUSED indications.
recvonly: The node supports receiving PAUSE and RESUME requests 6 The implementation supports sent and received RTP streams being
targeted for streams sent by the node. It will send PAUSED and paused due to local considerations, and thus supports sending
REFUSE as needed. The node will not send any PAUSE and RESUME and receiving PAUSED indications.
requests.
sendrecv: The node supports receiving PAUSE and RESUME requests 7 The implementation supports and desires to receive PAUSED
targeted for streams sent by the node. The node intends to send indications for received RTP streams, but does not pause or
PAUSE and RESUME requests for other nodes' streams. Thus the node send PAUSED indications for sent RTP streams. It does not
is capable of sending and receiving all types of pause messages. support any other messages defined in this specification.
This is the default value. If the "dir" parameter is omitted, it
MUST be interpreted to represent this value.
Direction values for "paused" is defined as follows: 8 The implementation supports pausing sent RTP streams and
sending PAUSED indications for them, but does not support
receiving PAUSED indications for received RTP streams. It does
not support any other messages defined in this specification.
sendonly: The node intends to send PAUSED indications whenever it When signaling a config value other than 1, an implementation MAY
pauses RTP stream delivery in any of its streams. It has no need ignore non-supported messages on reception, and MAY omit sending non-
to receive PAUSED indications itself. supported messages. The below table summarizes per-message send and
receive support for the different config attribute values ("X"
indicating support and "-" indicating non-support):
recvonly: The node desires to receive PAUSED indications whenever +---+-----------------------------+-----------------------------+
any stream sent by another node is paused. It does not intend to | # | Send | Receive |
send any PAUSED indications. | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X |
| 2 | X X X - | - - X X |
| 3 | - - X X | X X X - |
| 4 | X X - - | - - X X |
| 5 | - - X X | X X - - |
| 6 | - - X - | - - X - |
| 7 | - - - - | - - X - |
| 8 | - - X - | - - - - |
+---+-----------------------------+-----------------------------+
sendrecv: The nodes desires to receive PAUSED indications and Figure 6: Supported messages for different config values
intends to send PAUSED indications whenever any stream is paused.
This is the default value. If the "dir" parameter is omitted, it
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) pause-attr = [pause-config] [SP "nowait"] [SP byte-string]
pause-attr = direction pause-config = "config=" pause-config-value
/ "nowait" pause-config-value = %x31-38
/ token ; for future extensions ; byte-string as defined in RFC 4566, for future extensions
paused-attr = direction
/ token ; for future extensions
direction = "dir=" direction-alts
direction-alts = "sendonly" / "recvonly" / "sendrecv"
Figure 6: ABNF Figure 7: ABNF
An endpoint implementing this specification and using SDP to signal An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate both of the new "pause" and "paused" capability SHOULD indicate the new "pause" parameter with ccm
parameters with ccm signaling. When negotiating usage, it is signaling, but MAY use existing ccm tmmbr signaling [RFC5104] if the
possible select either of them, noting that "pause" contain the full limitations in functionality as described in this specification
"paused" functionality. A sender or receiver SHOULD NOT use the coming from such usage are considered acceptable. The messages from
messages from this specification towards receivers that did not this specification SHOULD NOT be used towards receivers that did not
declare capability for it. declare capability to receive those messages.
There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one
with "paused" applicable to a single payload type in the SDP, unless
the additional line uses "*" as payload type, in which case "*" SHALL
be interpreted as applicable to all listed payload types that does
not have an explicit "pause" or "paused" specification.
There MUST NOT be more than a single direction sub-parameter per There MUST NOT be more than one "a=rtcp-fb" line with "pause"
"pause" and "paused" parameter. There MUST NOT be more than a single applicable to a single payload type in the SDP, unless the additional
"nowait" sub-parameter per "pause" parameter. line uses "*" as payload type, in which case "*" SHALL be interpreted
as applicable to all listed payload types that does not have an
explicit "pause" specification.
9.1. Offer-Answer Use 9.1. Offer-Answer Use
An offerer implementing this specification needs to include "pause" An offerer implementing this specification needs to include "pause"
and/or "paused" CCM parameters with suitable directionality parameter CCM parameter with suitable configuration attribute ("config") in the
("dir") in the SDP, according to what messages it intends to send and SDP, according to what messages it intends to send and desires to
desires or is capable to receive in the session. It is RECOMMENDED receive in the session.
to include both "pause" and "paused" if "pause" is supported, to
enable at least the "paused" functionality if the answer only
supports "paused" or different directionality for the two
functionalities. The "pause" and "paused" functionalities are
negotiated independently, although the "paused" functionality is part
of the "pause" functionality. As a result, an answerer MAY remove
"pause" or "paused" lines from the SDP depending on the agreed mode
of functionality.
In offer/answer, the "dir" parameter is interpreted based on the In SDP offer/answer, the "config" attribute and its message
agent providing the SDP. The node described in the offer is the directions are interpreted based on the agent providing the SDP. The
offerer, and the answerer is described in an answer. In other words, offerer is described in an offer, and the answerer is described in an
an offer for "paused dir=sendonly" means that the offerer intends to answer.
send PAUSED indications whenever it pauses RTP stream delivery in any
of its streams.
An answerer receiving an offer with a "pause" parameter with An answerer receiving an offer with a "pause" CCM parameter and a
dir=sendrecv MAY remove the pause line in its answer, respond with config attribute with a certain value, describing a certain
pause keeping sendrecv for full bi-directionality, or it may change capability to send and receive messages, MAY change the config
dir value to either sendonly or recvonly based on its capabilities attribute value in the answer to another configuration. The
and desired functionality. An offer with a "pause" parameter with permitted answers are listed in the below table.
dir=sendonly or dir=recvonly is either completely removed or accepted
with reverse directionality, i.e. sendonly becomes recvonly or
recvonly becomes sendonly.
An answer receiving an offer with "paused" has the same choices as SDP Offer config value | Permitted SDP Answer config values
for "pause" above. It should be noted that the directionality of -----------------------+-----------------------------------
pause is the inverse of RTP stream direction, while the 1 | 1, 2, 3, 4, 5, 6, 7, 8
directionality of paused is the same as the RTP stream direction. 2 | 3, 4, 5, 6, 7, 8
3 | 2, 4, 5, 6, 7, 8
4 | 5, 6, 7, 8
5 | 4, 6, 7, 8
6 | 6, 7, 8
7 | 8
8 | 7
Figure 8: Config values in Offer/Answer
An offer or answer omitting the config attribute, MUST be interpreted
as equivalent to config=1. In all cases the answerer MAY also
completely remove any "pause" CCM parameter to indicate that it does
not understand or desire to use any pause functionality for the
affected payload types.
If the offerer believes that itself and the intended answerer are If the offerer believes that itself and the intended answerer are
likely the only 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 "pause" line in the offer. If both offer
offer and answer contained a "nowait" parameter, then the hold-off and answer contained a "nowait" parameter, then the hold-off period
time is configured to 0 at both offerer and answerer. is configured to 0 at both offerer and answerer.
9.2. Declarative Use 9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP the SDP. This has implications on the interpretation of the SDP
signaling extensions defined in this draft. First, it is normally signaling extensions defined in this specification.
only necessary to include either "pause" or "paused" parameter to
indicate the level of functionality the node should use in this RTP
session. Including both is only necessary if some implementations
only understands "paused" and some other can understand both. Thus
indicating both means use pause if you understand it, and if you only
understand paused, use that.
The "dir" directionality parameter indicates how the configured node
should behave. For example "pause" with sendonly:
sendonly: The node intends to send PAUSE and RESUME requests for
other nodes' streams and is thus also capable of receiving PAUSED
and REFUSE. It will not support receiving PAUSE and RESUME
requests.
In this example, the configured node should send PAUSE and RESUME First, the "config" attribute and its message directions are
requests if has reason for it. It does not need to respond to any interpreted based on the node receiving the SDP.
PAUSE or RESUME requests as that is not supported.
The "nowait" parameter, if included, is followed as specified. It is Second, the "nowait" parameter, if included, is followed as
the responsibility of the declarative SDP sender to determine if a specified. It is the responsibility of the declarative SDP sender to
configured node will participate in a session that will be point to determine if a configured node will participate in a session that
point, based on the usage. For example, a conference client being will be point to point, based on the usage. For example, a
configured for an any source multicast session using SAP [RFC2974] conference client being configured for an any source multicast
will not be in a point to point session, thus "nowait" cannot be session using SAP [RFC2974] will not be in a point to point session,
included. An RTSP [RFC2326] client receiving a declarative SDP may thus "nowait" cannot be included. An RTSP [RFC2326] client receiving
very well be in a point to point session, although it is highly a declarative SDP may very well be in a point to point session,
doubtful that an RTSP client would need to support this although it is highly doubtful that an RTSP client would need to
specification, considering the inherent PAUSE support in RTSP. support this specification, considering the inherent PAUSE support in
RTSP.
10. Examples 10. 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
skipping to change at page 32, line 14 skipping to change at page 33, line 20
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media s=Pausing Media
t=0 0 t=0 0
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99 m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000 a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=rtcp-fb:* ccm paused
Figure 7: SDP Offer With Pause and Resume Capability Figure 9: SDP Offer With Pause and Resume Capability
The offerer supports all of the messages defined in this The offerer supports all of the messages defined in this
specification and offers a sendrecv stream. The offerer also specification, leaving out the optional config attribute. The
believes that it will be the sole receiver of the answerer's stream offerer also believes that it will be the sole receiver of the
as well as that the answerer will be the sole receiver of the answerer's stream as well as that the answerer will be the sole
offerer's stream and thus includes the "nowait" sub-parameter for receiver of the offerer's stream and thus includes the "nowait" sub-
both "pause" and "paused" parameters. parameter for the "pause" parameter.
This is the SDP answer: This is the SDP answer:
v=0 v=0
o=bob 293847192 293847192 IN IP4 bob.example.com o=bob 293847192 293847192 IN IP4 bob.example.com
s=- s=-
t=0 0 t=0 0
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98 m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause dir=sendonly a=rtcp-fb:98 ccm pause config=2
a=rtcp-fb:98 ccm paused
Figure 8: SDP Answer With Pause and Resume Capability Figure 10: SDP Answer With Pause and Resume Capability
The answerer will not allow its sent streams to be paused or resumed The answerer will not allow its sent streams to be paused or resumed
and thus support pause only in sendonly mode. It does support paused and thus restricts the answer to indicate config=2. It also supports
and intends to send it, and also desires to receive PAUSED pausing its own RTP streams due to local considerations, which is why
indications. Thus paused in sendrecv mode is included in the answer. config=2 is chosen rather than config=4. The answerer somehow knows
The answerer somehow knows that it will not be a point-to-point RTP that it will not be a point-to-point RTP session and has therefore
session and has therefore removed "nowait" from the "pause" line, removed "nowait" from the "pause" line, meaning that the offerer must
meaning that the offerer must use a non-zero hold-off time when being use a non-zero hold-off period when being requested to pause the
requested to pause the stream. stream.
When using TMMBR 0 / TMMBN 0 to achieve pause and resume When using TMMBR 0 / TMMBN 0 to achieve pause and resume
functionality, there are no differences in SDP compared to CCM functionality, there are no differences in SDP compared to CCM
[RFC5104] and therefore no such examples are included here. [RFC5104] and therefore no such examples are included here.
10.2. Point-to-Point Session 10.2. Point-to-Point Session
This is the most basic scenario, which involves two participants, This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off time before pausing a stream transmission accordingly. The hold-off period before pausing a
is 0. stream 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) |
skipping to change at page 33, line 34 skipping to change at page 34, line 38
| 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 9: Pause and Resume Operation in Point-to-Point Figure 11: Pause and Resume Operation in Point-to-Point
Figure 9 shows the basic pause and resume operation in Point-to-Point Figure 11 shows the basic pause and resume operation in Point-to-
scenario. At time t1, an RTP sender sends data to a receiver. At Point scenario. At time t1, an RTP sender sends data to a receiver.
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 :
skipping to change at page 34, line 26 skipping to change at page 35, line 26
| 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 10: TMMBR Pause and Resume in Point-to-Point Figure 12: TMMBR Pause and Resume in Point-to-Point
Figure 10 describes the same point-to-point scenario as above, but Figure 12 describes the same point-to-point scenario as above, but
using TMMBR/TMMBN signaling. using TMMBR/TMMBN signaling.
+---------------+ +----------------+
| RTP Sender A | | RTP Receiver B |
+---------------+ +----------------+
: t1: RTP data :
| -------------------------------> |
| < RTP data paused > |
| t2: TMMBN {A:0} |
| -------------------------------> |
: < Some time passes > :
| t3: TMMBR 0 |
| <------------------------------- |
| t4: TMMBN {A:0,B:0} |
| -------------------------------> |
: < Some time passes > :
| t5: TMMBN {B:0} |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 80000 |
| <------------------------------- |
| t7: RTP data |
| -------------------------------> |
: :
Figure 13: Unsolicited PAUSED using TMMBN
Figure 13 describes the case when an RTP stream sender (A) chooses to
pause an RTP stream due to local considerations. Both the RTP stream
sender (A) and the RTP stream receiver (B) use TMMBR/TMMBN signaling
for pause/resume purposes. A decides to pause the RTP stream at time
t2 and uses TMMBN 0 to signal PAUSED, including itself in the TMMBN
bounding set. At time t3, despite the fact that the RTP stream is
still paused, B decides that it is no longer interested to receive
the RTP stream and signals PAUSE by sending a TMMBR 0. As a result
of that, the bounding set now contains both A and B, and A sends out
a new TMMBN reflecting that. After a while, at time t5, the local
considerations that caused A to pause the RTP stream no longer apply,
causing it to remove itself from the bounding set and to send a new
TMMBN indicating this. At time t6, B decides that it is now
interested to receive the RTP stream again and signals RESUME by
sending a TMMBR containing a bitrate value greater than 0, causing A
to resume sending RTP data.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| ------------------------------------> | | ------------------------------------> |
| t2: PAUSE(7), lost | | t2: PAUSE(7), lost |
| <---X-------------- | | <---X-------------- |
| | | |
| t3: RTP data | | t3: RTP data |
| ------------------------------------> | | ------------------------------------> |
skipping to change at page 35, line 33 skipping to change at page 37, line 33
| t6: RESUME(7), lost | | t6: RESUME(7), lost |
| <---X-------------- | | <---X-------------- |
| t7: RESUME(7) | | t7: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
| t8: RTP data | | t8: RTP data |
| ------------------------------------> | | ------------------------------------> |
| t9: RESUME(7) | | t9: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
: : : :
Figure 11: Pause and Resume Operation With Messages Lost Figure 14: Pause and Resume Operation With Messages Lost
Figure 11 describes what happens if a PAUSE message from an RTP Figure 14 describes what happens if a PAUSE message from an RTP
stream receiver does not reach the RTP stream sender. After sending stream receiver does not reach the RTP stream sender. After sending
a PAUSE message, the RTP stream receiver waits for a time-out to a PAUSE message, the RTP stream receiver waits for a time-out to
detect if the RTP stream sender has paused the data transmission or detect if the RTP stream sender has paused the data transmission or
has sent PAUSED indication according to the rules discussed in has sent PAUSED indication according to the rules discussed in
Section 6.3. As the PAUSE message is lost on the way (at time t2), Section 6.3. As the PAUSE message is lost on the way (at time t2),
RTP data continues to reach to the RTP stream receiver. When the RTP data continues to reach to the RTP stream receiver. When the
timer expires, the RTP stream receiver schedules a retransmission of timer expires, the RTP stream receiver schedules a retransmission of
the PAUSE message, which is sent at time t4. If the PAUSE message the PAUSE message, which is sent at time t4. If the PAUSE message
now reaches the RTP stream sender, it pauses the RTP stream and now reaches the RTP stream sender, it pauses the RTP stream and
replies with PAUSED. replies with PAUSED.
skipping to change at page 36, line 15 skipping to change at page 38, line 15
example be one RTCP feedback transmission interval as determined by example be one RTCP feedback transmission interval as determined by
the AVPF rules. the AVPF rules.
The RTP stream receiver did not realize that the RTP stream was The RTP stream receiver did not realize that the RTP stream was
resumed in time to stop yet another scheduled RESUME from being sent resumed in time to stop yet another scheduled RESUME from being sent
at time t9. This is however harmless since the RESUME PauseID is at time t9. This is however harmless since the RESUME PauseID is
less than the valid one and will be ignored by the RTP stream sender. less than the valid one and will be ignored by the RTP stream sender.
It will also not cause any unwanted resume even if the stream was It will also not cause any unwanted resume even if the stream was
paused based on a PAUSE from some other receiver before receiving the paused based on a PAUSE from some other receiver before receiving the
RESUME, since the valid PauseID is now larger than the one in the RESUME, since the valid PauseID is now larger than the one in the
stray RESUME and will only cause a REFUSE containing the new valid stray RESUME and will only cause a REFUSED containing the new valid
PauseID from the RTP 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: REFUSED(11) |
| ------------------------------> | | ------------------------------> |
| | | |
| t4: RTP data | | t4: RTP data |
| ------------------------------> | | ------------------------------> |
: : : :
Figure 12: Pause Request is Refused in Point-to-Point Figure 15: Pause Request is Refused in Point-to-Point
In Figure 12, the receiver requests to pause the sender, which In Figure 15, 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 REFUSED message.
10.3. Point-to-Multipoint using Mixer 10.3. Point-to-Multipoint using Mixer
An RTP Mixer is an intermediate node connecting different transport- An RTP Mixer is an intermediate node connecting different transport-
level clouds. The Mixer receives streams from different RTP sources, level clouds. The Mixer receives streams from different RTP sources,
selects or combines them based on the application's needs and selects or combines them based on the application's needs and
forwards the generated stream(s) to the destination. The Mixer forwards the generated stream(s) to the destination. The Mixer
typically puts its' own SSRC(s) in RTP data packets instead of the typically puts its' own SSRC(s) in RTP data packets instead of the
original source(s). original source(s).
skipping to change at page 37, line 37 skipping to change at page 39, line 37
| |<------------------------------------| | |<------------------------------------|
| t8:RTP(M:S2) | | | | t8:RTP(M:S2) | | |
|<-----------------| | | |<-----------------| | |
| | t9:PAUSE(S1) | | | | t9:PAUSE(S1) | |
| |----------------->| | | |----------------->| |
| | t10:PAUSED(S1) | | | | t10:PAUSED(S1) | |
| |<-----------------| | | |<-----------------| |
| | <S1:No RTP to M> | | | | <S1:No RTP to M> | |
: : : : : : : :
Figure 13: Pause and Resume Operation for a Voice Activated Mixer Figure 16: Pause and Resume Operation for a Voice Activated Mixer
The session starts at t1 with S1 being the most active speaker and The session starts at t1 with S1 being the most active speaker and
thus being selected as the single video stream to be delivered to R thus being selected as the single video stream to be delivered to R
(t2) using the Mixer SSRC but with S1 as CSRC (indicated after the (t2) using the Mixer SSRC but with S1 as CSRC (indicated after the
colon in the figure). Then S2 joins the session at t3 and starts colon in the figure). Then S2 joins the session at t3 and starts
delivering an RTP stream to the Mixer. As S2 has less voice activity delivering an RTP stream to the Mixer. As S2 has less voice activity
then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE
request. At t5, S2 acknowledges with a PAUSED and at the same request. At t5, S2 acknowledges with a PAUSED and at the same
instant stops delivering RTP to the Mixer. At t6, the user at S2 instant stops delivering RTP to the Mixer. At t6, the user at S2
starts speaking and becomes the most active speaker and the Mixer starts speaking and becomes the most active speaker and the Mixer
skipping to change at page 38, line 48 skipping to change at page 40, line 48
| | t7: RESUME(S,3) | | | t7: RESUME(S,3) |
| |<------------------| | |<------------------|
| t8: RESUME(S,3) | | | t8: RESUME(S,3) | |
|<------------------| | |<------------------| |
| t9: RTP (S) | | | t9: RTP (S) | |
|------------------>| | |------------------>| |
| | t10: RTP (S) | | | t10: RTP (S) |
| |------------------>| | |------------------>|
: : : : : :
Figure 14: Pause and Resume Operation Between Two Participants Using Figure 17: Pause and Resume Operation Between Two Participants Using
a Translator a Translator
Figure 14 describes how a Translator can help the receiver in pausing Figure 17 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 period to see if there is any other
receiver that wants to receive the data, does not receive any receiver that wants to receive the data, does not receive any
disapproving RESUME, hence pauses itself and replies with PAUSED. disapproving RESUME, hence pauses itself and replies with PAUSED.
Similarly the receiver resumes the sender by sending RESUME request Similarly the receiver resumes the sender by sending RESUME request
through Translator. Since this describes only a single pause through Translator. Since this describes only a single pause
operation for a single RTP stream 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 |
+-----+ +-----| +-----+ +-----+ +-----+ +-----| +-----+ +-----+
skipping to change at page 40, line 42 skipping to change at page 42, line 42
| | 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 15: Pause and Resume Operation Between One Sender and Two Figure 18: Pause and Resume Operation Between One Sender and Two
Receivers Through Translator Receivers Through Translator
Figure 15 explains the pause and resume operations when a transport Figure 18 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 an RTP stream 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 T. R1 and R2 receives RTP data from Translator at t2. At this
point, both R1 and R2 will send RTCP Receiver Reports to S informing point, both R1 and R2 will send RTCP Receiver Reports to S informing
that they receive S's 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 period, after which and not having received any disapproving RESUME,
concludes that the stream must be paused. S now stops sending the it concludes that the stream must be paused. S now stops sending the
stream and replies with PAUSED to R1 and R2. When any of the stream and replies with PAUSED to R1 and R2. When any of the
receivers (R1 or R2) chooses to resume the stream from S, in this receivers (R1 or R2) chooses to resume the stream from S, in this
example R1, it sends a RESUME request to the sender. The RTP sender example R1, it sends a RESUME request to the sender. The RTP sender
immediately resumes the stream. immediately resumes the stream.
Consider also an RTP session which includes one or more receivers, Consider also an RTP session which includes one or more receivers,
paused sender(s), and a Translator. Further assume that a new paused sender(s), and a Translator. Further assume that a new
participant joins the session, which is not aware of the paused participant joins the session, which is not aware of the paused
sender(s). On receiving knowledge about the newly joined sender(s). On receiving knowledge about the newly joined
participant, e.g. any RTP traffic or RTCP report (i.e. either SR or participant, e.g. any RTP traffic or RTCP report (i.e. either SR or
RR) from the newly joined participant, the paused sender(s) RR) from the newly joined participant, the paused sender(s)
immediately sends PAUSED indications for the paused streams since immediately sends PAUSED indications for the paused streams since
there is now a receiver in the session that did not pause the there is now a receiver in the session that did not pause the
sender(s) and may want to receive the streams. Having this sender(s) and may want to receive the streams. Having this
information, the newly joined participant has the same possibility as information, the newly joined participant has the same possibility as
any other participant to resume the paused streams. any other participant to resume the paused streams.
11. IANA Considerations 11. IANA Considerations
As outlined in Section 7, this specification requests IANA to This specification requests the following registrations from IANA:
allocate
1. The FMT number TBA1 to be allocated to the PAUSE and RESUME 1. A new value for media stream pause / resume to be registered with
functionality from this specification. IANA in the "FMT Values for RTPFB Payload Types" registry located
at the time of publication at: http://www.iana.org/assignments/
rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8
2. The 'pause' and 'paused' tags to be used with ccm under rtcp-fb Value: TBA1
AVPF attribute in SDP.
3. The 'nowait' parameter to be used with the 'pause' and 'paused' Name: PAUSE-RESUME
tags in SDP.
4. A registry listing registered values for 'pause' Types. Long Name: Media Pause / Resume
Reference: This RFC
5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the 2. A new value "pause" to be registered with IANA in the "Codec
pause Type registry. Control Messages" registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters/sdp-
parameters.xhtml#sdp-parameters-19
Value Name: pause
Long Name: Media Pause / Resume
Usable with: ccm
Reference: This RFC
12. Security Considerations 12. 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
skipping to change at page 42, line 33 skipping to change at page 44, line 42
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.
13. Contributors 13. Contributors
Daniel Grondal contributed in the creation and writing of early Daniel Grondal contributed in the creation and writing of early
versions of this specification. versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/
Answer.
14. Acknowledgements 14. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. versions of this draft. Christian Groves and Bernard Aboba provided
valuable review comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 43, line 17 skipping to change at page 45, line 28
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
2006. 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011.
15.2. Informative References 15.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-02 (work in progress), ietf-avtcore-rtp-topologies-update-04 (work in progress),
May 2014. August 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-02 (work in progress), June 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-
Time Communication Use-cases and Requirements", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014. progress), February 2014.
[I-D.westerlund-avtcore-rtp-simulcast] [I-D.westerlund-avtcore-rtp-simulcast]
Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP
Sessions", draft-westerlund-avtcore-rtp-simulcast-03 (work Sessions", draft-westerlund-avtcore-rtp-simulcast-04 (work
in progress), October 2013. in progress), July 2014.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
skipping to change at page 44, line 20 skipping to change at page 46, line 42
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
May 2011. May 2011.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
NOTE TO RFC EDITOR: Please remove this section prior to publication. NOTE TO RFC EDITOR: Please remove this section prior to publication.
A.1. Modifications Between Version -01 and -02 A.1. Modifications Between Version -02 and -03
o Changed the section on SDP signaling to be more explicit and clear
in what is supported, replacing the 'paused' parameter and the
'dir' attribute with a 'config' parameter that can take a value,
and an explicit listing of what each value means.
o Added a sentence in section on paused state (Section 6.3) that
pause must not affect RTP keepalive.
o Replaced REFUSE message name with REFUSED throughout, to better
indicate that it is not a command but a notification.
o Added text in a few places, clarifying that PAUSED message may be
used unsolicited due to RTP sender local considerations, and also
clarified the interaction between this usage and an RTP stream
receiver pausing the stream. Also added an example describing
this case.
o Clarified that when TMMBN 0 is used as PAUSED message, and when
sent unsolicited due to RTP sender local considerations, the TMMBN
message includes the RTP stream sender itself as part of the
bounding set.
o Clarified that there is no reply to a PAUSED indication.
o Improved the IANA section.
o Editorial improvements.
A.2. Modifications Between Version -01 and -02
o Replaced most text on relation with other signaling technologies o Replaced most text on relation with other signaling technologies
in previous section 5 with a single, summarizing paragraph, as in previous section 5 with a single, summarizing paragraph, as
discussed at IETF 90 in Toronto, and placed it as the last sub- discussed at IETF 90 in Toronto, and placed it as the last sub-
section of section 4 (design considerations). section of section 4 (design considerations).
o Removed unused references. o Removed unused references.
A.2. Modifications Between Version -00 and -01 A.3. Modifications Between Version -00 and -01
o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE o Corrected text in section 6.5 and 6.2 to indicate that a PAUSE
signaled via TMMBR 0 cannot be REFUSEd using TMMBN > 0 signaled via TMMBR 0 cannot be REFUSED using TMMBN > 0
o Improved alignment with RTP Taxonomy draft, including the change o Improved alignment with RTP Taxonomy draft, including the change
of Packet Stream to RTP Stream of Packet Stream to RTP Stream
o Editorial improvements o Editorial improvements
Authors' Addresses Authors' Addresses
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107141311 Phone: +46107141311
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
URI: www.ericsson.com URI: www.ericsson.com
Azam Akram Azam Akram
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Phone: +46107142658 Phone: +46107142658
Email: muhammad.azam.akram@ericsson.com Email: muhammad.azam.akram@ericsson.com
URI: www.ericsson.com URI: www.ericsson.com
skipping to change at page 45, line 24 skipping to change at page 48, line 34
Roni Even Roni Even
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE- Kista 164 80 SE- 164 80 Kista
Sweden Sweden
Phone: +46107148287 Phone: +46107148287
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 147 change blocks. 
388 lines changed or deleted 544 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/