draft-ietf-avtext-rtp-stream-pause-05.txt   draft-ietf-avtext-rtp-stream-pause-06.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: April 30, 2015 Huawei Technologies Expires: August 15, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
October 27, 2014 February 11, 2015
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-05 draft-ietf-avtext-rtp-stream-pause-06
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 April 30, 2015. This Internet-Draft will expire on August 15, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16 5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 16
5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 18 5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 18
5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19 5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19
6. Participant States . . . . . . . . . . . . . . . . . . . . . 19 6. Participant States . . . . . . . . . . . . . . . . . . . . . 19
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 21
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 21
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 22
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 22
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 23 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 28 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 29
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 34
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 39 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 40
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 41 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 42
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 12. Security Considerations . . . . . . . . . . . . . . . . . . . 46
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
15.1. Normative References . . . . . . . . . . . . . . . . . . 46 15.1. Normative References . . . . . . . . . . . . . . . . . . 47
15.2. Informative References . . . . . . . . . . . . . . . . . 46 15.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 47 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 48
A.1. Modifications Between Version -04 and -05 . . . . . . . . 47 A.1. Modifications Between Version -05 and -06 . . . . . . . . 48
A.2. Modifications Between Version -03 and -04 . . . . . . . . 47 A.2. Modifications Between Version -04 and -05 . . . . . . . . 49
A.3. Modifications Between Version -02 and -03 . . . . . . . . 48 A.3. Modifications Between Version -03 and -04 . . . . . . . . 49
A.4. Modifications Between Version -01 and -02 . . . . . . . . 48 A.4. Modifications Between Version -02 and -03 . . . . . . . . 49
A.5. Modifications Between Version -00 and -01 . . . . . . . . 48 A.5. Modifications Between Version -01 and -02 . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 A.6. Modifications Between Version -00 and -01 . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 33 skipping to change at page 4, line 33
Centralized nodes, like RTP Mixers or MCUs, which either uses logic Centralized nodes, like RTP Mixers or MCUs, which either uses logic
based on voice activity, other measurements, or user input could based on voice activity, other measurements, or user input could
reduce the resources consumed in both the sender and the network by reduce the resources consumed in both the sender and the network by
temporarily pausing the RTP streams that aren't required by the RTP temporarily pausing the RTP streams that aren't required by the RTP
Mixer. If the number of conference participants are greater than Mixer. If the number of conference participants are greater than
what the conference logic has chosen to present simultaneously to what the conference logic has chosen to present simultaneously to
receiving participants, some participant RTP streams sent to the RTP receiving participants, some participant RTP streams sent to the RTP
Mixer may not need to be forwarded to any other participant. Those Mixer may not need to be forwarded to any other participant. Those
RTP streams could then be temporarily paused. This becomes RTP streams could then be temporarily paused. This becomes
especially useful when the media sources are provided in multiple especially useful when the media sources are provided in multiple
encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast] encoding versions (Simulcast) [I-D.ietf-mmusic-sdp-simulcast] or with
or with Multi-Session Transmission (MST) of scalable encoding such as Multi-Session Transmission (MST) of scalable encoding such as SVC
SVC [RFC6190]. There may be some of the defined encodings or [RFC6190]. There may be some of the defined encodings or combination
combination of scalable layers that are not used or cannot be used of scalable layers that are not used or cannot be used all of the
all of the time, for example due to temporarily limited network or time, for example due to temporarily limited network or processing
processing resources, and a centralized node may choose to pause such resources, and a centralized node may choose to pause such RTP
RTP streams without being requested to do so, but anyway send an streams without being requested to do so, but anyway send an explicit
explicit indication that the stream is paused. 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
skipping to change at page 6, line 48 skipping to change at page 6, line 48
RESUME Request from an RTP stream receiver to resume a paused RESUME Request from an RTP stream receiver to resume a paused
stream stream
PAUSED Indication from an RTP stream sender that a stream is PAUSED Indication from an RTP stream sender that a stream is
paused paused
REFUSED Indication 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 endpoints, 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.
Paused sender: An RTP stream sender that has stopped its Paused sender: An RTP stream sender that has stopped its
transmission, i.e. no other participant receives its RTP transmission, i.e. no other participant receives its RTP
transmission, either based on having received a PAUSE request, transmission, either based on having received a PAUSE request,
defined in this specification, or based on a local decision. defined in this specification, or based on a local decision.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Use Cases 3. Use Cases
This section discusses the main use cases for RTP stream pause and This section discusses the main use cases for RTP stream pause and
resume. resume.
3.1. Point to Point 3.1. Point to Point
This is the most basic use case with an RTP session containing two This is the most basic use case with an RTP session containing two
End Points. Each End Point sends one or more streams. Endpoints. Each Endpoint sends one or more streams.
+---+ +---+ +---+ +---+
| A |<------->| B | | A |<------->| B |
+---+ +---+ +---+ +---+
Figure 1: Point to Point Figure 1: Point to Point
The usage of RTP stream pause in this use case is to temporarily halt The usage of RTP stream pause in this use case is to temporarily halt
delivery of streams that the sender provides but the receiver does delivery of streams that the sender provides but the receiver does
not currently use. This can for example be due to minimized not currently use. This can for example be due to minimized
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Which streams that are delivered to a given receiver, A, can depend Which streams that are delivered to a given receiver, A, can depend
on several things. It can either be the RTP Mixer's own logic and on several things. It can either be the RTP Mixer's own logic and
measurements such as voice activity on the incoming audio streams. measurements such as voice activity on the incoming audio streams.
It can be that the number of sent media sources exceed what is It can be that the number of sent media sources exceed what is
reasonable to present simultaneously at any given receiver. It can reasonable to present simultaneously at any given receiver. It can
also be a human controlling the conference that determines how the also be a human controlling the conference that determines how the
media should be mixed; this would be more common in lecture or media should be mixed; this would be more common in lecture or
similar applications where regular listeners may be prevented from similar applications where regular listeners may be prevented from
breaking into the session unless approved by the moderator. The breaking into the session unless approved by the moderator. The
streams may also be part of a Simulcast streams may also be part of a Simulcast
[I-D.westerlund-avtcore-rtp-simulcast] or scalable encoded (for [I-D.ietf-mmusic-sdp-simulcast] or scalable encoded (for Multi-
Multi-Session Transmission) [RFC6190], thus providing multiple Session Transmission) [RFC6190], thus providing multiple versions
versions that can be delivered by the RTP stream sender. These that can be delivered by the RTP stream sender. These examples
examples indicate that there are numerous reasons why a particular indicate that there are numerous reasons why a particular stream
stream would not currently be in use, but must be available for use would not currently be in use, but must be available for use at very
at very short notice if any dynamic event occurs that causes a short notice if any dynamic event occurs that causes a different
different stream selection to be done in the Mixer. stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could Because of this, it would be highly beneficial if the Mixer could
request to pause a particular stream from being delivered to it. It request 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 In some cases, especially when the Mixer sends multiple RTP streams
per receiving client, there may be situations that makes it desirable per receiving client, there may be situations that makes it desirable
to the Mixer to pause some of its sent RTP streams, even without to the Mixer to pause some of its sent RTP streams, even without
being explicitly asked to do so by the receiving client. Such being explicitly asked to do so by the receiving client. Such
situations can for example be caused by a temporary lack of available situations can for example be caused by a temporary lack of available
skipping to change at page 10, line 32 skipping to change at page 10, line 32
If the Mixer resumes a paused stream from A, it will be resumed also If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested it can simply ignore towards C. In this case, if C is not interested it can simply ignore
the stream and is not impacted as much as above. the stream and is not impacted as much as above.
In this use case there are several receivers of a stream and special In this use case there are several receivers of a stream and special
care must be taken as not to pause a stream that is still wanted by care must be taken as not to pause a stream that is still wanted by
some receivers. some receivers.
3.4. Media Receiver to RTP Mixer 3.4. Media Receiver to RTP Mixer
An End Point in Figure 2 could potentially request to pause the An Endpoint in Figure 2 could potentially request to pause the
delivery of a given stream. Possible reasons include the ones in the delivery of a given stream. Possible reasons include the ones in the
point to point case (Section 3.1) above. point to point case (Section 3.1) above.
When the RTP Mixer is only connected to individual unicast paths, the When the RTP Mixer is only connected to individual unicast paths, the
use case and any considerations are identical to the point to point use case and any considerations are identical to the point to point
use case. use case.
However, when the End Point requesting stream pause is connected to However, when the Endpoint requesting stream pause is connected to
the RTP Mixer through a multicast network, such as A or C in the RTP Mixer through a multicast network, such as A or C in
Figure 3, the use case instead becomes identical to the one in Figure 3, the use case instead becomes identical to the one in
Section 3.3, only with reverse direction of the streams and pause/ Section 3.3, only with reverse direction of the streams and pause/
resume requests. resume requests.
3.5. Media Receiver to Media Sender Across RTP Mixer 3.5. Media Receiver to Media Sender Across RTP Mixer
An End Point, like A in Figure 2, could potentially request to pause An Endpoint, like A in Figure 2, could potentially request to pause
the delivery of a given stream, like one of B's, over any of the the delivery of a given stream, like one of B's, over any of the
SSRCs used by the Mixer by sending a pause request for the CSRC SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the stream. However, the authors are of the opinion that identifying the stream. However, the authors are of the opinion that
this is not a suitable solution, for several reasons: this is not a suitable solution, for several reasons:
1. The Mixer might not include CSRC in it's stream indications. 1. The Mixer might not include CSRC in it's stream indications.
2. An End Point cannot rely on the CSRC to correctly identify the 2. An Endpoint cannot rely on the CSRC to correctly identify the
stream to be paused when the delivered media is some type of mix. stream to be paused when the delivered media is some type of mix.
A more elaborate stream identification solution is needed to A more elaborate stream identification solution is needed to
support this in the general case. support this in the general case.
3. The End Point cannot determine if a given stream is still needed 3. The Endpoint cannot determine if a given stream is still needed
by the RTP Mixer to deliver to another session participant. by the RTP Mixer to deliver to another session participant.
Due to the above reasons, we exclude this use case from further Due to the above reasons, we exclude this use case from further
consideration. consideration.
4. Design Considerations 4. Design Considerations
This section describes the requirements that this specification needs This section describes the requirements that this specification needs
to meet. to meet.
skipping to change at page 12, line 41 skipping to change at page 12, line 41
RTP stream on its own behalf, without being explicitly asked to do RTP stream on its own behalf, without being explicitly asked to do
so. Such local consideration in the RTP sender takes precedence over so. Such local consideration in the RTP sender takes precedence over
RTP receiver wishes to receive the stream. RTP receiver wishes to receive the stream.
4.5. Message Acknowledgments 4.5. Message Acknowledgments
RTP and RTCP does not guarantee reliable data transmission. It uses RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower layer transport protocol can provide. whatever assurance the lower layer transport protocol can provide.
However, this is commonly UDP that provides no reliability However, this is commonly UDP that provides no reliability
guarantees. Thus it is possible that a PAUSE and/or RESUME message guarantees. Thus it is possible that a PAUSE and/or RESUME message
transmitted from an RTP End Point does not reach its destination, transmitted from an RTP Endpoint does not reach its destination, i.e.
i.e. the targeted RTP stream sender. When PAUSE or RESUME reaches the targeted RTP stream sender. When PAUSE or RESUME reaches the RTP
the RTP stream sender and are effective, i.e., an active RTP stream stream sender and are effective, i.e., an active RTP stream sender
sender pauses, or a resuming RTP stream sender have media data to pauses, or a resuming RTP stream sender have media data to transmit,
transmit, it is immediately seen from the arrival or non-arrival of it is immediately seen from the arrival or non-arrival of RTP packets
RTP packets for that RTP stream. Thus, no explicit acknowledgments for that RTP stream. Thus, no explicit acknowledgments are required
are required in this case. in this case.
In some cases when a PAUSE or RESUME message reaches the RTP stream In some cases when a PAUSE or RESUME message reaches the RTP stream
sender, it will not be able to pause or resume the stream due to some sender, it will not be able to pause or resume the stream due to some
local consideration, for example lack of data to transmit. This local consideration, for example lack of data to transmit. This
error condition, a negative acknowledgment, may be needed to avoid error condition, a negative acknowledgment, may be needed to avoid
unnecessary retransmission of requests (Section 4.6). unnecessary retransmission of requests (Section 4.6).
4.6. Request Retransmission 4.6. Request Retransmission
When the stream is not affected as expected by a PAUSE or RESUME When the stream is not affected as expected by a PAUSE or RESUME
skipping to change at page 13, line 45 skipping to change at page 13, line 45
with PAUSE and implicitly references which PAUSE it refers to. For with PAUSE and implicitly references which PAUSE it refers to. For
the same reasons, the explicit PAUSED indication also needs to share the same reasons, the explicit PAUSED indication also needs to share
sequence number space with PAUSE and RESUME. sequence number space with PAUSE and RESUME.
4.8. Relation to Other Solutions 4.8. Relation to Other Solutions
A performance comparison between SIP/SDP and RTCP signaling A performance comparison between SIP/SDP and RTCP signaling
technologies was made and included in draft versions of this technologies was made and included in draft versions of this
specification. Using SIP and SDP [RFC4566] to carry pause and resume specification. Using SIP and SDP [RFC4566] to carry pause and resume
information means that it will need to traverse the entire signaling information means that it will need to traverse the entire signaling
path to reach the signaling destination (either the remote End Point path to reach the signaling destination (either the remote Endpoint
or the entity controlling the RTP Mixer), across any signaling or the entity controlling the RTP Mixer), across any signaling
proxies that potentially also has to process the SDP content to proxies that potentially also has to process the SDP content to
determine if they are expected to act on it. The amount of bandwidth determine if they are expected to act on it. The amount of bandwidth
required for a SIP/SDP-based signaling solution is in the order of at required for a SIP/SDP-based signaling solution is in the order of at
least 10 times more than an RTCP-based solution. Especially for UA least 10 times more than an RTCP-based solution. Especially for UA
sitting on mobile wireless access, this will risk introducing delays sitting on mobile wireless access, this will risk introducing delays
that are too long (Section 4.1) to provide a good user experience, that are too long (Section 4.1) to provide a good user experience,
and the bandwidth cost may also be considered infeasible compared to and the bandwidth cost may also be considered infeasible compared to
an RTCP-based solution. RTCP data is sent through the media path, an RTCP-based solution. RTCP data is sent through the media path,
which is likely shorter (contains fewer intermediate nodes) than the which is likely shorter (contains fewer intermediate nodes) than the
skipping to change at page 15, line 11 skipping to change at page 15, line 11
0, and any reference to PAUSED is equally applicable to TMMBN 0. 0, and any reference to PAUSED is equally applicable to TMMBN 0.
Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the Therefore and for brevity, TMMBR/TMMBN will not be mentioned in the
text, unless there is specific reason to do so. text, unless there is specific reason to do so.
This section is intended to be explanatory and therefore This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification. instead be found in other parts of this specification.
5.1. Expressing Capability 5.1. Expressing Capability
An End Point can use an extension to CCM SDP signaling to declare An Endpoint can use an extension to CCM SDP signaling to declare
capability to understand the messages defined in this specification. capability to understand the messages defined in this specification.
Capability to understand only a subset of messages is possible, to Capability to understand only a subset of messages is possible, to
support partial implementation, which is specifically believed to be support partial implementation, which is specifically believed to be
feasible for the RTP Mixer to Media Sender use case (Section 3.2). feasible for the RTP Mixer to Media Sender use case (Section 3.2).
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
skipping to change at page 17, line 41 skipping to change at page 17, line 41
ignored. ignored.
As long as the stream is being paused, the PAUSED indication MAY be As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP SR or RR. Including PAUSED in sent together with any regular RTCP SR or RR. Including PAUSED in
this way allows RTP stream receivers joining while the stream is this way allows RTP stream receivers joining while the stream is
paused to quickly know that there is a paused stream, what the last paused to quickly know that there is a paused stream, what the last
sent extended RTP sequence number was, and what the next available sent extended RTP sequence number was, and what the next available
PauseID is to be able to construct valid PAUSE and RESUME requests at PauseID is to be able to construct valid PAUSE and RESUME requests at
a later stage. a later stage.
When the RTP stream sender learns that a new End Point has joined the When the RTP stream sender learns that a new Endpoint has joined the
RTP session, for example by a new SSRC and a CNAME that was not RTP session, for example by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in for all its paused streams at its earliest opportunity. It should in
addition continue to include PAUSED indications in at least two addition continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
5.4. Requesting to Resume 5.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. The RTP stream request at any time, subject to AVPF timing rules. The RTP stream
skipping to change at page 22, line 25 skipping to change at page 22, line 25
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 a sufficient number receivers, when entering the state, and repeat it a sufficient number
of times to reach a high probability that the message is correctly of times to reach a high probability that the message is correctly
delivered, unless the stream was already in paused state delivered, unless the stream was already in paused state
(Section 6.3). (Section 6.3).
Editor's note: Consider specifying an explicit PAUSED ACK message
that stops this message retransmission.
When using TMMBN 0 as PAUSED indication, being in paused state, and When using TMMBN 0 as PAUSED indication, being in paused state, and
entering local paused state, the RTP stream sender SHALL send TMMBN 0 entering local paused state, the RTP stream sender SHALL send TMMBN 0
with itself included in the TMMBN bounding set. with itself included in the TMMBN bounding set.
As indicated in Figure 4, this state has higher precedence than As indicated in Figure 4, this state has higher precedence than
paused state (Section 6.3) and RESUME messages alone cannot resume a paused state (Section 6.3) and RESUME messages alone cannot resume a
paused RTP stream as long as the local decision still applies. paused RTP stream as long as the local decision still applies.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
skipping to change at page 23, line 10 skipping to change at page 22, line 52
removes the RTP sender from the TMMBN bounding set, and a new TMMBN removes the RTP sender from the TMMBN bounding set, and a new TMMBN
with the updated bounding set MUST be sent accordingly. The stream with the updated bounding set MUST be sent accordingly. The stream
state can become Playing only when there is no entry with a bitrate state can become Playing only when there is no entry with a bitrate
value of 0 in the stream's bounding set. 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, which is further sub-typed into
request, a RESUME request, or one of four different types of either a PAUSE request, a RESUME request, a PAUSED indication, or a
acknowledgments in response to either PAUSE or RESUME requests. REFUSED indication.
The Transport layer feedback messages are identified by having the The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This
PAUSE and RESUME messages are identified by Feedback Message Type Transport layer feedback message, containing one or more of the sub-
(FMT) value in common packet header for feedback message defined in typed messages, is henceforth referred to as the PAUSE-RESUME
section 6.1 of AVPF [RFC4585]. The PAUSE and RESUME transport message. The specific FCI format is identified by a Feedback Message
feedback message is identified by the FMT value = TBA1. Type (FMT) value in common packet header for feedback message defined
in section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport
feedback message FCI is identified by FMT value = TBA1.
The Common Packet Format for Feedback Messages defined by AVPF The Common Packet Format for Feedback Messages defined by AVPF
[RFC4585] is: [RFC4585] is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length | |V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
For the PAUSE and RESUME messages, the following interpretation of For the PAUSE-RESUME message defined in this memo, the following
the packet fields will be: interpretations of the packet fields apply:
FMT: The FMT value identifying the PAUSE and RESUME message: TBA1 FMT: The FMT value identifying the PAUSE-RESUME FCI: TBA1
PT: Payload Type = 205 (RTPFB) PT: Payload Type = 205 (RTPFB)
Length: As defined by AVPF, i.e. the length of this packet in 32-bit Length: As defined by AVPF, i.e. the length of this packet in 32-bit
words minus one, including the header and any padding. words minus one, including the header and any padding.
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 Endpoints that have
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to multiple SSRCs in an RTP session, any of its SSRCs MAY be used to
send any of the pause message types. send any of the pause message types.
SSRC of media source: Not used, SHALL be set to 0. The FCI SSRC of media source: Not used, SHALL be set to 0. The FCI
identifies the SSRC the message is targeted for. identifies the SSRC the message is targeted for.
The Feedback Control Information (FCI) field consist of one or more The Feedback Control Information (FCI) field consists of one or more
PAUSE, RESUME, PAUSED, REFUSED, 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-RESUME message, this value is the
is the SSRC that the request is intended for. For PAUSED, it MUST SSRC that the request is intended for. For PAUSED, it MUST be the
be the SSRC being paused. If pausing is the result of a PAUSE SSRC being paused. If pausing is the result of a PAUSE request,
request, the value in PAUSED is effectively the same as Target the value in PAUSED is effectively the same as Target SSRC in a
SSRC in a related PAUSE request. For REFUSED, it MUST be the related PAUSE request. For REFUSED, it MUST be the Target SSRC of
Target SSRC of the PAUSE or RESUME request that cannot change the PAUSE or RESUME request that cannot change state. A CSRC MUST
state. A CSRC MUST NOT be used as a target as the interpretation NOT be used as a target as the interpretation of such a request is
of such a request is unclear. unclear.
Type (4 bits): The pause feedback type. The values defined in this Type (4 bits): The pause feedback type. The values defined in this
specification are as follows, specification are as follows,
0: PAUSE request message 0: PAUSE request message
1: RESUME request message 1: RESUME request message
2: PAUSED indication message 2: PAUSED indication message
skipping to change at page 25, line 18 skipping to change at page 25, line 13
The PauseID is scoped by the Target SSRC, meaning that PAUSE, The PauseID is scoped by the Target SSRC, meaning that PAUSE,
RESUME, and PAUSED messages therefore share the same PauseID space RESUME, and PAUSED messages therefore share the same PauseID space
for a specific Target SSRC. for a specific Target SSRC.
Type Specific: (variable): Defined per pause feedback Type. MAY be Type Specific: (variable): Defined per pause feedback Type. MAY be
empty. 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 requests and indications
are governed by the transmission rules as defined by Section 8.5. are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSED in this section Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.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/
skipping to change at page 27, line 10 skipping to change at page 27, line 6
RTP stream sender local decision. 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 (at least) the next
regular RTCP reports, given that the pause condition is then still two regular RTCP reports, given that the pause condition is then
effective. still effective.
PAUSED indications MAY be retransmitted, subject to transmission
rules (Section 8.5), to increase the probability that the message
reaches the receiver in a timely fashion. This can be especially
important when entering Local Paused State. The number of
repetitions to use could be tuned to observed loss rate and desired
loss probability, for example based on RTCP reports received from the
intended message target.
While remaining in Paused or Local Paused States, PAUSED MAY be While remaining in Paused or Local Paused States, PAUSED MAY be
included in all regular RTCP reports. included in all compound RTCP reports, as long as the negotiated RTCP
bandwidth is not exceeded.
When in Paused or Local Paused States, It is RECOMMENDED to send When in Paused or Local Paused States, whenever the RTP stream sender
PAUSED at the earliest opportunity and also to include it in the next learns that there are Endpoints that did not previously receive the
two regular RTCP reports, whenever the RTP stream sender learns that stream, for example by RTCP reports with an SSRC and a CNAME that was
there are End Points that did not previously receive the stream, for not previously seen in the RTP session, it is RECOMMENDED to send
example by RTCP reports with an SSRC and a CNAME that was not PAUSED at the earliest opportunity and also to include it in (at
previously seen in the RTP session. least) the next two regular RTCP reports, given that the pause
condition is then still effective.
8.3. RESUME 8.3. RESUME
An RTP stream receiver MAY schedule RESUME for transmission whenever An RTP stream receiver MAY schedule RESUME for transmission whenever
it wishes to resume a paused stream, or to disapprove a stream from it wishes to resume a paused stream, or to disapprove a stream from
being paused. being paused.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED PauseID SHOULD be the 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 REFUSED (Section 8.4). found in a returned REFUSED (Section 8.4).
RESUME requests MAY be retransmitted, subject to transmission rules
(Section 8.5), to increase the probability that the message reaches
the receiver in a timely fashion. The number of repetitions to use
could be tuned to observed loss rate and desired loss probability,
for example based on RTCP reports received from the intended message
target. Such retransmission SHOULD stop as soon as RTP packets from
the targeted stream are received, or a REFUSED with a valid PauseID
for the targeted RTP stream is received.
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 REFUSED message as specified below. stream sender schedules a REFUSED message for transmission as
specified below.
If an RTP stream sender in Playing State receives a RESUME containing If an RTP stream sender in Playing State receives a RESUME containing
either a valid PauseID or a PauseID that is less than the valid either 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. REFUSED 8.4. REFUSED
If an RTP stream sender receives a valid PAUSE (Section 8.1) or
RESUME (Section 8.3) request that cannot be fulfilled by the RTP
stream sender due to some local consideration, it SHALL schedule
transmission of a REFUSED indication containing the valid PauseID
from the rejected request.
REFUSED has no defined Type Specific parameters and Parameter Len REFUSED has no defined Type Specific parameters and Parameter Len
MUST be set to 0. MUST be set to 0.
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
due to some local consideration, it SHALL schedule transmission of a
REFUSED indication containing the valid PauseID from the rejected
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 REFUSED 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 REFUSED If several PAUSE or RESUME that would render identical REFUSED
responses are received before the scheduled REFUSED is sent, responses are received before the scheduled REFUSED is sent,
duplicate REFUSED MUST NOT be scheduled for transmission. This duplicate REFUSED MUST NOT be scheduled for transmission. This
effectively lets a single REFUSED respond to several invalid PAUSE or effectively lets a single REFUSED respond to several invalid PAUSE or
skipping to change at page 29, line 20 skipping to change at page 29, line 36
retransmissions that SHOULD use Regular timing. retransmissions that SHOULD use Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. Unsolicited PAUSED for that PauseID SHOULD use Regular timing. Unsolicited
PAUSED (sent when entering Local Paused State (Section 6.4)) PAUSED (sent when entering Local Paused State (Section 6.4))
SHOULD always use Immediate or Early timing, until PAUSED for that SHOULD always use Immediate or Early timing, until PAUSED for that
PauseID is considered delivered at least once to all receivers of PauseID is considered delivered at least once to all receivers of
the paused RTP stream, after which it SHOULD use Regular timing. the paused RTP stream, after which it SHOULD use Regular timing.
Editor's note: Consider specifying a PAUSED ACK message as
explicit indication of reception.
o RESUME SHOULD always use Immediate or Early timing. o RESUME SHOULD always use Immediate or Early timing.
o The first transmission of REFUSED for each (non-wrapped) PauseID o The first transmission of REFUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
REFUSED 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
skipping to change at page 33, line 6 skipping to change at page 33, line 25
Figure 8: Config values in Offer/Answer Figure 8: Config values in Offer/Answer
An offer or answer omitting the config attribute, MUST be interpreted An offer or answer omitting the config attribute, MUST be interpreted
as equivalent to config=1. In all cases the answerer MAY also as equivalent to config=1. In all cases the answerer MAY also
completely remove any "pause" CCM parameter to indicate that it does completely remove any "pause" CCM parameter to indicate that it does
not understand or desire to use any pause functionality for the not understand or desire to use any pause functionality for the
affected payload types. 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 Endpoints 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 Endpoints 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 "pause" line in the offer. If both offer unless it is present on the "pause" line in the offer. If both offer
and answer contained a "nowait" parameter, then the hold-off period and answer contained a "nowait" parameter, then the hold-off period
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
skipping to change at page 46, line 41 skipping to change at page 47, line 41
2010. 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. 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-04 (work in progress), ietf-avtcore-rtp-topologies-update-05 (work in progress),
August 2014. November 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-02 (work in progress), June 2014. rtp-grouping-taxonomy-05 (work in progress), January 2015.
[I-D.ietf-mmusic-sdp-simulcast]
Westerlund, M., Nandakumar, S., and M. Zanaty, "Using
Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp-
simulcast-00 (work in progress), January 2015.
[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-16 (work in
progress), February 2014. progress), January 2015.
[I-D.westerlund-avtcore-rtp-simulcast]
Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP
Sessions", draft-westerlund-avtcore-rtp-simulcast-04 (work
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 47, line 42 skipping to change at page 48, 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 -04 and -05 A.1. Modifications Between Version -05 and -06
o Clarified in Message Details section for PAUSED that
retransmission of the message can be used to increase the
probability that the message reaches the receiver in a timely
fashion, and also added text that says the number of repetitions
can be tuned to observed loss rate and the desired loss
probability. Also removed Editor's notes on potential ACK for
unsolicited PAUSED, since the issue is solved by the above.
o In the same section as above, added that PAUSED may be included in
all compound RTCP reports, as long as the negotiated RTCP
bandwidth is not exceeded.
o In Message Details section for RESUME, added text on
retransmission similar to the one mentioned for PAUSED above.
Also included text that says such retransmission SHOULD stop as
soon as RTP packets or a REFUSED with a valid PauseID from the
targeted stream are received.
o Changed simulcast reference, since that draft was moved from
AVTCORE to MMUSIC and made WG draft.
o Changed End Point to Endpoint to reflect change in RTP Grouping
Taxonomy draft.
o Editorial improvements.
A.2. Modifications Between Version -04 and -05
o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and o Added text in sections 4.1, 4.6, 6.4 and 8.5 on retransmission and
timing of unsolicited PAUSED, to improve the message timeliness timing of unsolicited PAUSED, to improve the message timeliness
and probability of reception. and probability of reception.
A.2. Modifications Between Version -03 and -04 A.3. Modifications Between Version -03 and -04
o Change of Copyright boilerplate o Change of Copyright boilerplate
A.3. Modifications Between Version -02 and -03 A.4. Modifications Between Version -02 and -03
o Changed the section on SDP signaling to be more explicit and clear o Changed the section on SDP signaling to be more explicit and clear
in what is supported, replacing the 'paused' parameter and the in what is supported, replacing the 'paused' parameter and the
'dir' attribute with a 'config' parameter that can take a value, 'dir' attribute with a 'config' parameter that can take a value,
and an explicit listing of what each value means. and an explicit listing of what each value means.
o Added a sentence in section on paused state (Section 6.3) that o Added a sentence in section on paused state (Section 6.3) that
pause must not affect RTP keepalive. pause must not affect RTP keepalive.
o Replaced REFUSE message name with REFUSED throughout, to better o Replaced REFUSE message name with REFUSED throughout, to better
skipping to change at page 48, line 35 skipping to change at page 50, line 16
sent unsolicited due to RTP sender local considerations, the TMMBN sent unsolicited due to RTP sender local considerations, the TMMBN
message includes the RTP stream sender itself as part of the message includes the RTP stream sender itself as part of the
bounding set. bounding set.
o Clarified that there is no reply to a PAUSED indication. o Clarified that there is no reply to a PAUSED indication.
o Improved the IANA section. o Improved the IANA section.
o Editorial improvements. o Editorial improvements.
A.4. Modifications Between Version -01 and -02 A.5. 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.5. Modifications Between Version -00 and -01 A.6. 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
 End of changes. 49 change blocks. 
118 lines changed or deleted 163 lines changed or added

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