draft-ietf-avtext-rtp-stream-pause-06.txt   draft-ietf-avtext-rtp-stream-pause-07.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: August 15, 2015 Huawei Technologies Expires: September 10, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
February 11, 2015 March 9, 2015
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-06 draft-ietf-avtext-rtp-stream-pause-07
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 August 15, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12 4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 12
4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13 4.6. Request Retransmission . . . . . . . . . . . . . . . . . 13
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 13
4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 13
5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 15
5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15 5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . 22 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 23
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 25 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 29 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 30
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 32 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 33
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 33 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 35
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 36
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 35 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 37
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 40 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 41
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 42 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
12. Security Considerations . . . . . . . . . . . . . . . . . . . 46 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 48
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
15.1. Normative References . . . . . . . . . . . . . . . . . . 47 15.1. Normative References . . . . . . . . . . . . . . . . . . 48
15.2. Informative References . . . . . . . . . . . . . . . . . 47 15.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 48 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 50
A.1. Modifications Between Version -05 and -06 . . . . . . . . 48 A.1. Modifications Between Version -06 and -07 . . . . . . . . 50
A.2. Modifications Between Version -04 and -05 . . . . . . . . 49 A.2. Modifications Between Version -05 and -06 . . . . . . . . 51
A.3. Modifications Between Version -03 and -04 . . . . . . . . 49 A.3. Modifications Between Version -04 and -05 . . . . . . . . 52
A.4. Modifications Between Version -02 and -03 . . . . . . . . 49 A.4. Modifications Between Version -03 and -04 . . . . . . . . 52
A.5. Modifications Between Version -01 and -02 . . . . . . . . 50 A.5. Modifications Between Version -02 and -03 . . . . . . . . 52
A.6. Modifications Between Version -00 and -01 . . . . . . . . 50 A.6. Modifications Between Version -01 and -02 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 A.7. Modifications Between Version -00 and -01 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 6, line 36 skipping to change at page 6, line 36
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 REFUSED 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
REFUSED Indication from an RTP stream sender that a PAUSE or REFUSED: Notification from an RTP stream sender that a PAUSE or
RESUME request will not be honored RESUME request will not be honored
Mixer: The intermediate RTP node which receives an RTP stream from Mixer: The intermediate RTP node which receives an RTP stream from
different endpoints, combines them to make one RTP stream and different endpoints, combines them to make one RTP stream and
forwards to destinations, in the sense described in Topo-Mixer of forwards 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 14, line 29 skipping to change at page 14, line 29
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. where new semantics is needed.
A single Feedback message specification is used to implement the new A single Feedback message specification is used to implement the new
messages. The message consists of a number of Feedback Control messages. The message consists of a number of Feedback Control
Information (FCI) blocks, where each block can be a PAUSE request, a Information (FCI) blocks, where each block can be a PAUSE request, a
RESUME request, PAUSED indication, a REFUSED response, or an RESUME request, PAUSED indication, a REFUSED notification, or an
extension to this specification. This structure allows a single extension to this specification. This structure allows a single
feedback message to handle pause functionality on a number of feedback message to handle pause functionality on a number of
streams. streams.
The PAUSED functionality is also defined in such a way that it can be The PAUSED functionality is also defined in such a way that it can be
used standalone by the RTP stream sender to indicate a local decision used standalone by the RTP stream sender to indicate a local decision
to pause, and inform any receiver of the fact that halting media to pause, and inform any receiver of the fact that halting media
delivery is deliberate and which RTP packet was the last transmitted. delivery is deliberate and which RTP packet was the last transmitted.
Special considerations that apply when using TMMBR/TMMBN for pause Special considerations that apply when using TMMBR/TMMBN for pause
skipping to change at page 16, line 16 skipping to change at page 16, line 16
TMMBR 0 the request MAY be re-transmitted when the requester fails to TMMBR 0 the request MAY be re-transmitted 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 REFUSED response that contains the of this condition by sending a REFUSED notification that contains the
next available PauseID value. This REFUSED also informs the RTP next available PauseID value. This REFUSED also informs the RTP
stream receiver that it is probably not feasible to send another stream receiver that it is probably not feasible to send another
PAUSE for some time, not even with the available PauseID, since there PAUSE for some time, not even with the available PauseID, since there
are other 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
REFUSED response will then provide sufficient information to create a REFUSED notification will then provide sufficient information to
valid PAUSE. The required extra signaling round-trip is not create a valid PAUSE. The required extra signaling round-trip is not
considered harmful, since it is assumed that pausing a stream is not considered harmful, since it is assumed that pausing a stream is not
time-critical (Section 4.1). time-critical (Section 4.1).
There may be local considerations making it impossible or infeasible There may be local considerations making it impossible or infeasible
to pause the stream, and the RTP stream sender can then respond with to pause the stream, and the RTP stream sender can then respond with
a REFUSED. In this case, if the used PauseID would otherwise have a REFUSED. In this case, if the used PauseID would otherwise have
been effective, REFUSED 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,
regardless of bounding set overhead value.
If the RTP stream sender receives several identical PAUSE for an RTP If the RTP stream sender receives several identical PAUSE for an RTP
stream that was already at least once responded with REFUSED and the stream that was already at least once responded with REFUSED and the
condition causing REFUSED remains, those additional REFUSED should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSED can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical PAUSE requests. several identical PAUSE requests.
5.3. Media Sender Pausing 5.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.
skipping to change at page 18, line 24 skipping to change at page 18, line 24
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 at the RTP stream sender, for There may be local considerations at the RTP stream sender, for
example that the media device is not ready, making it temporarily example that the media device is not ready, making it temporarily
impossible to resume the stream at that point in time, and the RTP impossible to resume the stream at that point in time, and the RTP
stream sender MAY then respond with a REFUSED containing the same stream sender MAY then respond with a REFUSED containing the same
PauseID as in the RESUME. When receiving such REFUSED with a PauseID PauseID as in the RESUME. When receiving such REFUSED with a PauseID
identical to the one in the sent RESUME, RTP stream receivers SHOULD identical to the one in the sent RESUME, RTP stream receivers SHOULD
then avoid sending further RESUME requests for some reasonable amount then avoid sending further RESUME requests for some reasonable amount
of time, to allow the condition to clear. of time, to allow the condition to clear. An RTP stream sender
having sent a REFUSED SHOULD resume the stream through local
considerations (see below) when the condition that caused the REFUSED
is no longer true.
If the RTP stream sender receives several identical RESUME for an RTP If the RTP stream sender receives several identical RESUME for an RTP
stream that was already at least once responded with REFUSED and the stream that was already at least once responded with REFUSED and the
condition causing REFUSED remains, those additional REFUSED should be condition causing REFUSED remains, those additional REFUSED should be
sent with regular RTCP timing. A single REFUSED can respond to sent with regular RTCP timing. A single REFUSED can respond to
several identical RESUME requests. several identical RESUME requests.
A pausing RTP stream sender can apply local considerations and MAY A pausing RTP stream sender can apply local considerations and MAY
resume a paused RTP stream at any time. If TMMBR 0 was used to pause resume a paused RTP stream at any time. If TMMBR 0 was used to pause
the RTP stream, it cannot be resumed due to local considerations, the RTP stream, it cannot be resumed due to local considerations. If
unless the RTP stream is paused only due to local considerations TMMBR/TMMBN signaling is used, if the RTP stream is paused due to
(Section 5.3) and thus no RTP stream receiver has requested to pause local considerations (Section 5.3), and the RTP stream sender thus
the stream with TMMBR 0. owns the TMMBN bounding set, the RTP stream can also be resumed due
to local considerations.
When resuming a paused stream, especially for media that makes use of When resuming a paused stream, especially for media that makes use of
temporal redundancy between samples such as video, the temporal temporal redundancy between samples such as video, 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
skipping to change at page 19, line 37 skipping to change at page 19, line 41
bitrate from zero. The bitrate value used when resuming after bitrate from zero. The bitrate value used when resuming after
pausing with TMMBR 0 is either according to known limitations, or pausing with TMMBR 0 is either according to known limitations, or
based on starting a stream with the configured maximum for the based on starting a stream with the configured maximum for the
stream or session, for example given by b-parameter in SDP. stream or session, for example given by b-parameter in SDP.
TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with
TMMBR 0, but may, just as PAUSED, also be used unsolicited. An TMMBR 0, but may, just as PAUSED, also be used unsolicited. An
unsolicited RTP stream pause based on local sender considerations unsolicited RTP stream pause based on local sender considerations
uses the RTP stream's own SSRC as TMMBR restriction owner in the uses the RTP stream's own SSRC as TMMBR restriction owner in the
TMMBN message bounding set. Also corresponds to a REFUSED TMMBN message bounding set. Also corresponds to a REFUSED
indication when a stream is requested to be resumed with TMMBR >0. notification when a stream is requested to be resumed with TMMBR
>0, thus resulting in the stream sender becoming the owner of the
bounding set in the TMMBN message.
TMMBN >0: Cannot be used as REFUSED indication when a stream is TMMBN >0: Cannot be used as REFUSED notification when a stream is
requested to be paused with TMMBR 0, for reasons stated in requested to be paused with TMMBR 0, for reasons stated in
Section 5.2. Section 5.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 REFUSED in this section SHALL references to PAUSE, PAUSED, RESUME and REFUSED in this section SHALL
be taken to apply to the extent possible also when TMMBR/TMMBN are be taken to apply to the extent possible also when TMMBR/TMMBN are
used (Section 5.5) for this functionality. used (Section 5.5) for this functionality.
skipping to change at page 21, line 7 skipping to change at page 21, line 15
2 * RTT + T_dither_max, 2 * RTT + T_dither_max,
where RTT is the longest round trip known to the RTP stream sender where RTT is the longest round trip known to the RTP stream sender
and T_dither_max is defined in section 3.4 of [RFC4585]. The hold- and T_dither_max is defined in section 3.4 of [RFC4585]. The hold-
off period MAY be set to 0 by some signaling (Section 9) means when off period MAY be set to 0 by some signaling (Section 9) means when
it can be determined that there is only a single receiver, for it can be determined that there is only a single receiver, for
example in point-to-point or some unicast situations. example in point-to-point or some unicast situations.
If the RTP stream sender has set the hold-off period to 0 and If the RTP stream sender has set the hold-off period to 0 and
receives information that it was an incorrect decision and that there receives information that it was an incorrect decision and that there
are in fact several receivers of the stream, for example by RTCP RR, are in fact several receivers of the stream, it MUST change the hold-
it MUST change the hold-off to instead be based on the above formula. off to instead be based on the above formula.
An RTP stream sender SHOULD use the following criteria to determine
if there is only a single receiver, unless it has explicit and more
reliable information:
o Observing only a single CNAME across all received SSRCs (CNAMEs
for received CSRCs are insignificant), or
o If RTCP reporting groups
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] is used,
observing only a single, endpoint external RTCP reporting group.
6.3. Paused State 6.3. Paused State
An RTP stream is in paused state when the sender pauses its An RTP stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the hold- transmission after receiving at least one PAUSE message and the hold-
off period has passed without receiving any RESUME message for that off period has passed without receiving any RESUME message for that
stream. stream. Pausing transmission SHOULD only be done when reaching an
appropriate place to pause in the stream, like a media boundary that
avoids a media receiver to trigger repair or concealment actions.
When entering the state, the RTP stream sender SHALL send a PAUSED When entering the state, the RTP stream sender SHALL send a PAUSED
indication to all known RTP stream receivers, and SHALL also repeat indication to all known RTP stream receivers, and SHALL also repeat
PAUSED in the next two regular RTCP reports. PAUSED in the next two regular RTCP reports, as long as it is then
still in paused state.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
Following sub-sections discusses some potential issues when an RTP 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
skipping to change at page 22, line 12 skipping to change at page 22, line 30
that receiver sends an RTCP BYE message observed by the sender, that receiver sends an RTCP BYE message observed by the sender,
the sender SHALL resume the RTP stream. the sender SHALL resume the RTP stream.
6.3.2. SSRC Time-out 6.3.2. SSRC Time-out
Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP
participant. Every RTP participant maintains a sender and receiver participant. Every RTP participant maintains a sender and receiver
list in a session. If a participant does not get any RTP or RTCP list in a session. If a participant does not get any RTP or RTCP
packets from some other participant for the last five RTCP reporting packets from some other participant for the last five RTCP reporting
intervals it removes that participant from the receiver list. Any intervals it removes that participant from the receiver list. Any
streams that were paused by that removed participant SHALL be streams that were paused by that removed participant SSRC SHALL be
resumed. resumed.
6.4. Local Paused State 6.4. Local Paused State
This state can be entered at any time, based on local decision from This state can be entered at any time, based on local decision from
the RTP stream sender. As for Paused State (Section 6.3), the RTP the RTP stream sender. Pausing transmission SHOULD only be done when
stream sender SHALL send a PAUSED indication to all known RTP stream reaching an appropriate place to pause in the stream, like a media
receivers, when entering the state, and repeat it a sufficient number boundary that avoids a media receiver to trigger repair or
of times to reach a high probability that the message is correctly concealment actions.
delivered, unless the stream was already in paused state
(Section 6.3).
When using TMMBN 0 as PAUSED indication, being in paused state, and As for Paused State (Section 6.3), the RTP stream sender SHALL send a
entering local paused state, the RTP stream sender SHALL send TMMBN 0 PAUSED indication to all known RTP stream receivers, when entering
with itself included in the TMMBN bounding set. the state, unless the stream was already in paused state
(Section 6.3), and repeat it a sufficient number of times to reach a
high probability that the message is correctly delivered, and
stopping such repetition whenever leaving the state.
As indicated in Figure 4, this state has higher precedence than When using TMMBN 0 as PAUSED indication and when already in paused
paused state (Section 6.3) and RESUME messages alone cannot resume a state, the actions when entering local paused state depends on the
paused RTP stream as long as the local decision still applies. bounding set overhead value in the received TMMBR 0 that caused the
paused state, and the bounding set overhead value used in (the RTP
stream sender's own) TMMBN 0:
TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL
NOT send any new TMMBN 0 replacing that active (more restrictive)
bounding set, even if entering local paused state.
TMMBN 0 overhead > TMMBR 0 overhead: The RTP stream sender SHALL
send TMMBN 0 with itself in the TMMBN bounding set when entering
local paused state.
The case above when using TMMBN 0 as PAUSED indication, being in
local paused state, and having received a TMMBR 0 with a bounding set
overhead value greater than the value the RTP stream sender would
itself use in a TMMBN 0 requires further consideration and is for
clarity henceforth referred to as "restricted local paused state".
As indicated in Figure 4, local paused 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. An RTP stream sender in local paused state is responsible
to leave the state whenever the conditions that caused the decision
to enter the state no longer apply.
If the RTP stream sender is in restricted local paused state, it
cannot leave that state until the TMMBR 0 limit causing the state is
removed by a TMMBR >0 (RESUME). If the RTP stream sender then needs
to stay in local paused state due to local considerations, it MAY
continue pausing the RTP stream by entering local paused state and
MUST then act accordingly, including sending a TMMBN 0 with itself in
the bounding set.
Pausing an RTP stream MUST NOT affect the sending of RTP keepalive Pausing an RTP stream MUST NOT affect the sending of RTP keepalive
[RFC6263][RFC5245] applicable to that RTP stream. [RFC6263][RFC5245] applicable to that RTP stream.
When leaving the state, the stream state SHALL become Playing, When leaving the local paused state, the stream state SHALL become
regardless whether or not there were any RTP stream receivers that Playing, regardless whether or not there were any RTP stream
sent PAUSE for that stream, effectively clearing the RTP stream receivers that sent PAUSE for that stream during the local paused
sender's memory for that stream. This does however not apply when state, effectively clearing the RTP stream sender's memory for that
the stream was paused by a TMMBR 0, either before entering or during stream.
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, which is further sub-typed into Transport layer feedback message, which is further sub-typed into
either a PAUSE request, a RESUME request, a PAUSED indication, or a either a PAUSE request, a RESUME request, a PAUSED indication, or a
REFUSED indication. REFUSED notification.
The Transport layer feedback messages are identified by having the The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This
Transport layer feedback message, containing one or more of the sub- Transport layer feedback message, containing one or more of the sub-
typed messages, is henceforth referred to as the PAUSE-RESUME typed messages, is henceforth referred to as the PAUSE-RESUME
message. The specific FCI format is identified by a Feedback Message message. The specific FCI format is identified by a Feedback Message
Type (FMT) value in common packet header for feedback message defined Type (FMT) value in common packet header for feedback message defined
in section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport in section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME transport
feedback message FCI is identified by FMT value = TBA1. feedback message FCI is identified by FMT value = TBA1.
skipping to change at page 24, line 31 skipping to change at page 25, line 31
SSRC being paused. If pausing is the result of a PAUSE request, SSRC being paused. If pausing is the result of a PAUSE request,
the value in PAUSED is effectively the same as Target SSRC in a the value in PAUSED is effectively the same as Target SSRC in a
related PAUSE request. For REFUSED, it MUST be the Target SSRC of related PAUSE request. For REFUSED, it MUST be the Target SSRC of
the PAUSE or RESUME request that cannot change state. A CSRC MUST the PAUSE or RESUME request that cannot change state. A CSRC MUST
NOT be used as a target as the interpretation of such a request is NOT be used as a target as the interpretation of such a request is
unclear. unclear.
Type (4 bits): The pause feedback type. The values defined in this Type (4 bits): The pause feedback type. The values defined in this
specification are as follows, specification are as follows,
0: PAUSE request message 0: PAUSE request message.
1: RESUME request message 1: RESUME request message.
2: PAUSED indication message 2: PAUSED indication message.
3: REFUSED indication message 3: REFUSED notification message.
4-15: Reserved for future use 4-15: Reserved for future use. FCI fields with these Type values
SHALL be ignored on reception by receivers and MUST NOT be used
by senders implementing this specification.
Res: (4 bits): Type specific reserved. SHALL be ignored by Res: (4 bits): Type specific reserved. SHALL be ignored by
receivers implementing this specification and MUST be set to 0 by receivers implementing this specification and MUST be set to 0 by
senders implementing this specification. senders implementing this specification.
Parameter Len: (8 bits): Length of the Type Specific field in 32-bit Parameter Len: (8 bits): Length of the Type Specific field in 32-bit
words. MAY be 0. words. MAY be 0.
PauseID (16 bits): Message sequence identification. SHALL be PauseID (16 bits): Message sequence identification. SHALL be
incremented by one modulo 2^16 for each new PAUSE message, unless incremented by one modulo 2^16 for each new PAUSE message, unless
the message is re-transmitted. The initial value SHOULD be 0. the message is re-transmitted. The initial value SHOULD be 0.
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. A receiver implementing this specification MUST be able to
skip and ignore any unknown Type Specific data, even for Type
values defined in this specification.
8. Message Details 8. Message Details
This section contains detailed explanations of each message defined This section contains detailed explanations of each message defined
in this specification. All transmissions of requests and indications in this specification. All transmissions of requests and indications
are governed by the transmission rules as defined by Section 8.5. are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSED in this section Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be
skipping to change at page 25, line 34 skipping to change at page 26, line 38
resume signaling MUST use messages from this specification. If the resume signaling MUST use messages from this specification. If the
topology is not point-to-point and the messages defined in this topology is not point-to-point and the messages defined in this
specification are not supported, pause/resume functionality with specification are not supported, pause/resume functionality with
TMMBR/TMMBN MUST 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.
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 REFUSED (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.
skipping to change at page 26, line 30 skipping to change at page 27, line 32
If the targeted RTP stream does not pause, if no PAUSED indication If the targeted RTP stream does not pause, if no PAUSED indication
with a larger PauseID than the one used in PAUSE, and if no REFUSED with a larger PauseID than the one used in PAUSE, and if no REFUSED
is 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) 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 MUST be sent whenever entering Paused State The PAUSED indication MUST be sent whenever entering Paused State
(Section 6.3) as a result of receiving a valid PAUSE (Section 8.1) (Section 6.3) as a result of receiving a valid PAUSE (Section 8.1)
request, or when entering Local Paused State (Section 6.4) based on a request, or when entering Local Paused State (Section 6.4) based on a
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 at the start of the Type
sequence number valid when the RTP stream was paused. Parameter Len Specific field with the RTP extended highest sequence number
MUST be set to 1. (Section 6.4.1 of [RFC3550]) valid when the RTP stream was paused.
After having entered Paused or Local Paused State and thus having After having entered Paused or Local Paused State and thus having
sent PAUSED once, PAUSED MUST also be included in (at least) the next sent PAUSED once, PAUSED MUST also be included in (at least) the next
two regular RTCP reports, given that the pause condition is then two regular RTCP reports, given that the pause condition is then
still effective. still effective.
PAUSED indications MAY be retransmitted, subject to transmission PAUSED indications MAY be retransmitted, subject to transmission
rules (Section 8.5), to increase the probability that the message rules (Section 8.5), to increase the probability that the message
reaches the receiver in a timely fashion. This can be especially reaches the receiver in a timely fashion. This can be especially
important when entering Local Paused State. The number of important when entering Local Paused State. The number of
skipping to change at page 28, line 5 skipping to change at page 28, line 52
RESUME requests MAY be retransmitted, subject to transmission rules RESUME requests MAY be retransmitted, subject to transmission rules
(Section 8.5), to increase the probability that the message reaches (Section 8.5), to increase the probability that the message reaches
the receiver in a timely fashion. The number of repetitions to use the receiver in a timely fashion. The number of repetitions to use
could be tuned to observed loss rate and desired loss probability, could be tuned to observed loss rate and desired loss probability,
for example based on RTCP reports received from the intended message for example based on RTCP reports received from the intended message
target. Such retransmission SHOULD stop as soon as RTP packets from target. Such retransmission SHOULD stop as soon as RTP packets from
the targeted stream are received, or a REFUSED with a valid PauseID the targeted stream are received, or a REFUSED with a valid PauseID
for the targeted RTP stream is received. 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.
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 schedules a REFUSED message for transmission as stream sender schedules a REFUSED message for transmission as
specified below. 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 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 RESUME (Section 8.3) request that cannot be fulfilled by the RTP
stream sender due to some local consideration, it SHALL schedule stream sender due to some local consideration, it SHALL schedule
transmission of a REFUSED indication containing the valid PauseID transmission of a REFUSED notification containing the valid PauseID
from the rejected request. from the rejected request.
REFUSED has no defined Type Specific parameters and Parameter Len REFUSED has no defined Type Specific parameters.
MUST be set to 0.
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 notification 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, notifications are received before the scheduled REFUSED is sent,
duplicate REFUSED MUST NOT be scheduled for transmission. This duplicate REFUSED MUST NOT be scheduled for transmission. This
effectively lets a single REFUSED respond to several invalid PAUSE or effectively lets a single REFUSED respond to several invalid PAUSE or
RESUME requests. RESUME requests.
If REFUSED containing a certain PauseID was already sent and yet more If REFUSED containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSED PAUSE or RESUME messages are received that require additional REFUSED
with that specific PauseID to be scheduled, and unless the PauseID with that specific PauseID to be scheduled, and unless the PauseID
number space has wrapped since REFUSED was last sent with that number space has wrapped since REFUSED was last sent with that
PauseID, further REFUSED 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 REFUSED containing the same PauseID as in the request receives a REFUSED containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSED to clear. time to allow the condition that caused REFUSED to clear.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSED containing a PauseID different from the request receives a REFUSED containing a PauseID different from the request
MAY schedule another request using the PauseID from the REFUSED MAY schedule another request using the PauseID from the REFUSED
indication. notification.
8.5. Transmission Rules 8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation. depends on the session's mode of operation.
All messages defined in this specification, as well as TMMBR/TMMBN All messages defined in this specification, as well as TMMBR/TMMBN
used for pause/resume purposes (Section 5.5), MAY use either Regular, used for pause/resume purposes (Section 5.5), MAY use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, taking the following into consideration:
skipping to change at page 30, line 19 skipping to change at page 31, line 14
specification), signaling rtcp-fb attribute with ccm tmmbr specification), signaling rtcp-fb attribute with ccm tmmbr
parameter is 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 There is however no guarantee that TMMBR/TMMBN implementations
pre-dating this specification work exactly as described here when pre-dating this specification work exactly as described here when
used with a bitrate value of 0. used with a bitrate value of 0.
The "pause" parameter has two optional attributes, "nowait" and The "pause" parameter has two optional attributes, "nowait" and
"config": "config":
o "nowait" indicates that the hold-off period defined in Section 6.2 o "nowait" indicates that the hold-off period defined in Section 6.2
can be set to 0, reducing the latency before the stream can paused can be set to 0, reducing the latency before the stream can be
after receiving a PAUSE request. This condition occurs when there paused after receiving a PAUSE request. This condition occurs
will be only a single receiver per direction in the RTP session, when there will only be a single receiver per direction in the RTP
for example in point-to-point sessions. It is also possible to session, for example in point-to-point sessions. It is also
use in scenarios using unidirectional media. The conditions that possible to use in scenarios using unidirectional media. The
allow "nowait" to be set also indicate that it would be possible conditions that allow "nowait" to be set (Section 6.2) also
to use CCM TMMBR/TMMBN as pause/resume signaling. indicate that it would be possible to use CCM TMMBR/TMMBN as
pause/resume signaling.
o "config" allows for partial implementation of this specification o "config" allows for partial implementation of this specification
according to the different roles in the use cases section according to the different roles in the use cases section
(Section 3), and takes a value that describes what sub-set is (Section 3), and takes a value that describes what sub-set is
implemented: implemented:
1 Full implementation of this specification. This is the default 1 Full implementation of this specification. This is the default
configuration. A missing config attribute MUST be treated configuration. A missing config attribute MUST be treated
equivalent to providing a config value of 1. equivalent to providing a config value of 1.
skipping to change at page 31, line 27 skipping to change at page 32, line 22
7 The implementation supports and desires to receive PAUSED 7 The implementation supports and desires to receive PAUSED
indications for received RTP streams, but does not pause or indications for received RTP streams, but does not pause or
send PAUSED indications for sent RTP streams. It does not send PAUSED indications for sent RTP streams. It does not
support any other messages defined in this specification. support any other messages defined in this specification.
8 The implementation supports pausing sent RTP streams and 8 The implementation supports pausing sent RTP streams and
sending PAUSED indications for them, but does not support sending PAUSED indications for them, but does not support
receiving PAUSED indications for received RTP streams. It does receiving PAUSED indications for received RTP streams. It does
not support any other messages defined in this specification. not support any other messages defined in this specification.
When signaling a config value other than 1, an implementation MAY When signaling a config value other than 1, an implementation MUST
ignore non-supported messages on reception, and MAY omit sending non- ignore non-supported messages on reception, and MAY omit sending non-
supported messages. The below table summarizes per-message send and supported messages. The below table summarizes per-message send and
receive support for the different config attribute values ("X" receive support for the different config attribute values ("X"
indicating support and "-" indicating non-support): indicating support and "-" indicating non-support):
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| # | Send | Receive | | # | Send | Receive |
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X | | 1 | X X X X | X X X X |
skipping to change at page 32, line 5 skipping to change at page 33, line 5
| 6 | - - X - | - - X - | | 6 | - - X - | - - X - |
| 7 | - - - - | - - X - | | 7 | - - - - | - - X - |
| 8 | - - X - | - - - - | | 8 | - - X - | - - - - |
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
Figure 6: Supported messages for different config values Figure 6: Supported messages for different config values
This is the resulting ABNF [RFC5234], extending existing ABNF in This is the resulting ABNF [RFC5234], extending existing ABNF in
section 7.1 of CCM [RFC5104]: section 7.1 of CCM [RFC5104]:
rtcp-fb-ccm-param =/ SP "pause" [SP pause-attr] rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
pause-attr = [pause-config] [SP "nowait"] [SP byte-string] pause-attr = pause-config ; partial message support
/ "nowait" ; no hold-off
/ byte-string ; for future extensions
pause-config = "config=" pause-config-value pause-config = "config=" pause-config-value
pause-config-value = %x31-38 pause-config-value = 1*2DIGIT
; byte-string as defined in RFC 4566, for future extensions ; byte-string as defined in RFC 4566
Figure 7: 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 the new "pause" parameter with ccm capability SHOULD indicate the new "pause" parameter with ccm
signaling, but MAY use existing ccm tmmbr signaling [RFC5104] if the signaling, but MAY use existing ccm tmmbr signaling [RFC5104] if the
limitations in functionality as described in this specification limitations in functionality as described in this specification
coming from such usage are considered acceptable. The messages from coming from such usage are considered acceptable. The messages from
this specification SHOULD NOT be used towards receivers that did not this specification SHOULD NOT be used towards receivers that did not
declare capability to receive those messages. declare capability to receive those messages.
The pause functionality can normally be expected to work independent
of the payload type. However, there might exist situations where an
endpoint likes to restrict or at least differently configure the
capabilities depending on the payload type carrying the media stream.
Reasons for this might relate to capabilities to correctly handle
media boundaries and avoid any pause or resume operation to occur
where it would leave a receiver or decoder with no choice than to
attempt to repair or discard the media received just prior to or at
the point of resuming.
There MUST NOT be more than one "a=rtcp-fb" line with "pause" There MUST NOT be more than one "a=rtcp-fb" line with "pause"
applicable to a single payload type in the SDP, unless the additional applicable to a single payload type in the SDP, unless the additional
line uses "*" as payload type, in which case "*" SHALL be interpreted line uses "*" as payload type, in which case "*" SHALL be interpreted
as applicable to all listed payload types that does not have an as applicable to all listed payload types that do not have an
explicit "pause" specification. explicit "pause" specification. The "config" pause attribute MUST
NOT appear more than once for each "pause" CCM parameter. The
"nowait" pause attribute MUST NOT appear more than once for each
"pause" CCM parameter.
9.1. Offer-Answer Use 9.1. Offer-Answer Use
An offerer implementing this specification needs to include "pause" An offerer implementing this specification needs to include "pause"
CCM parameter with suitable configuration attribute ("config") in the CCM parameter with suitable configuration attribute ("config") in the
SDP, according to what messages it intends to send and desires to SDP, according to what messages it intends to send and desires to
receive in the session. receive in the session.
In SDP offer/answer, the "config" attribute and its message In SDP offer/answer, the "config" attribute and its message
directions are interpreted based on the agent providing the SDP. The directions are interpreted based on the agent providing the SDP. The
offerer is described in an offer, and the answerer is described in an offerer is described in an offer, and the answerer is described in an
answer. answer.
An answerer receiving an offer with a "pause" CCM parameter and a An answerer receiving an offer with a "pause" CCM line and a config
config attribute with a certain value, describing a certain attribute with a certain value, describing a certain capability to
capability to send and receive messages, MAY change the config send and receive messages, MAY change the config attribute value in
attribute value in the answer to another configuration. The the answer to another configuration. The permitted answers are
permitted answers are listed in the below table. listed in the below table.
SDP Offer config value | Permitted SDP Answer config values SDP Offer config value | Permitted SDP Answer config values
-----------------------+----------------------------------- -----------------------+-----------------------------------
1 | 1, 2, 3, 4, 5, 6, 7, 8 1 | 1, 2, 3, 4, 5, 6, 7, 8
2 | 3, 4, 5, 6, 7, 8 2 | 3, 4, 5, 6, 7, 8
3 | 2, 4, 5, 6, 7, 8 3 | 2, 4, 5, 6, 7, 8
4 | 5, 6, 7, 8 4 | 5, 6, 7, 8
5 | 4, 6, 7, 8 5 | 4, 6, 7, 8
6 | 6, 7, 8 6 | 6, 7, 8
7 | 8 7 | 8
8 | 7 8 | 7
Figure 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. Implementations of this specification
completely remove any "pause" CCM parameter to indicate that it does MUST NOT use any other config values than the ones defined above in
not understand or desire to use any pause functionality for the an offer or answer, and MUST remove the "pause" CCM line in the
affected payload types. answer when receiving an offer with a config value it does not
understand. In all cases the answerer MAY also completely remove any
"pause" CCM line 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 Endpoints 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" attribute on the "pause" line in the offer. If an answerer
answerer receives the "nowait" sub-parameter on the "pause" line in receives the "nowait" attribute on the "pause" line in the SDP, and
the SDP, and if it has information that the offerer and itself are if it has information that the offerer and itself are not the only
not the only Endpoints in the RTP session, it MUST NOT include any Endpoints in the RTP session, it MUST NOT include any "nowait"
"nowait" sub-parameter on its "pause" line in the SDP answer. The attribute on its "pause" line in the SDP answer. The answerer MUST
answerer MUST NOT add "nowait" on the "pause" line in the answer NOT add "nowait" on the "pause" line in the answer unless it is
unless it is present on the "pause" line in the offer. If both offer present on the "pause" line in the offer. If both offer and answer
and answer contained a "nowait" parameter, then the hold-off period contained a "nowait" parameter, then the hold-off period is
is configured to 0 at both offerer and answerer. configured to 0 at both offerer and answerer.
Unknown pause attributes MUST be ignored in the offer and MUST then
be omitted from the answer.
If both "pause" and "tmmbr" are present in the offer, both MAY be
included also in the answer, in which case TMMBR/TMMBN MUST NOT be
used for pause/resume purposes (with a bitrate value of 0), to avoid
signaling ambiguity.
9.2. Declarative Use 9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP the SDP. This has implications on the interpretation of the SDP
signaling extensions defined in this specification. signaling extensions defined in this specification.
First, the "config" attribute and its message directions are First, the "config" attribute and its message directions are
interpreted based on the node receiving the SDP. interpreted based on the node receiving the SDP, and describes the
RECOMMENDED level of operation. If the joining client does not
support the indicated config value, some RTP session stream
optimizations may not be possible in that some RTP streams will not
be paused by the joining client, and/or the joining client may not be
able to resume and receive wanted streams because they are paused.
Second, the "nowait" parameter, if included, is followed as Second, the "nowait" parameter, if included, is followed as
specified. It is the responsibility of the declarative SDP sender to specified. It is the responsibility of the declarative SDP sender to
determine if a configured node will participate in a session that determine if a configured node will participate in a session that
will be point to point, based on the usage. For example, a will be point to point, based on the usage. For example, a
conference client being configured for an any source multicast conference client being configured for an any source multicast
session using SAP [RFC2974] will not be in a point to point session, session using SAP [RFC2974] will not be in a point to point session,
thus "nowait" cannot be included. An RTSP [RFC2326] client receiving thus "nowait" cannot be included. An RTSP [RFC2326] client receiving
a declarative SDP may very well be in a point to point session, a declarative SDP may very well be in a point to point session,
although it is highly doubtful that an RTSP client would need to although it is highly doubtful that an RTSP client would need to
support this specification, considering the inherent PAUSE support in support this specification, considering the inherent PAUSE support in
RTSP. RTSP.
Unknown pause attributes MUST be ignored.
If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
NOT be used for pause/resume purposes (with a bitrate value of 0), to
avoid signaling ambiguity.
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
3. Point-to-Multipoint using Mixer 3. Point-to-Multipoint using Mixer
4. Point-to-Multipoint using Relay
4. Point-to-Multipoint using Translator
10.1. Offer-Answer 10.1. Offer-Answer
The below figures contains an example how to show support for pausing The below figures contains an example how to show support for pausing
and resuming the streams, as well as indicating whether or not the and resuming the streams, as well as indicating whether or not the
hold-off period can be set to 0. hold-off period can be set to 0.
v=0 v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media s=Pausing Media
skipping to change at page 36, line 24 skipping to change at page 37, line 38
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t4: RESUME(3) | | t4: RESUME(3) |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: PAUSE(4) | | t6: PAUSE(4) |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t7: PAUSED(4) |
| -------------------------------> |
: : : :
Figure 11: Pause and Resume Operation in Point-to-Point Figure 11: Pause and Resume Operation in Point-to-Point
Figure 11 shows the basic pause and resume operation in Point-to- Figure 11 shows the basic pause and resume operation in Point-to-
Point scenario. At time t1, an RTP sender sends data to a receiver. Point scenario. At time t1, an RTP sender sends data to a receiver.
At time t2, the RTP receiver requests the sender to pause the stream, At time t2, the RTP receiver requests the sender to pause the stream,
using PauseID 3 (which it knew since before in this example). The using PauseID 3 (which it knew since before in this example). The
sender pauses the data and replies with a PAUSED containing the same sender pauses the data and replies with a PAUSED containing the same
PauseID. Some time later (at time t4) the receiver requests the PauseID. Some time later (at time t4) the receiver requests the
sender to resume, which resumes its transmission. The next PAUSE, sender to resume, which resumes its transmission. The next PAUSE,
sent at time t6, contains an updated PauseID (4). sent at time t6, contains an updated PauseID (4), with a
corresponding PAUSED being sent at time t7.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| -------------------------------> | | -------------------------------> |
| t2: TMMBR 0 | | t2: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t3: TMMBN 0 | | t3: TMMBN 0 |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t4: TMMBR 150000 | | t4: TMMBR 150000 |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: TMMBR 0 | | t6: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
| t7: TMMBN 0 |
| -------------------------------> |
: : : :
Figure 12: TMMBR Pause and Resume in Point-to-Point Figure 12: TMMBR Pause and Resume in Point-to-Point
Figure 12 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 | | RTP Sender A | | RTP Receiver B |
+---------------+ +----------------+ +---------------+ +----------------+
skipping to change at page 42, line 12 skipping to change at page 43, line 12
a RESUME request to S2. At t7, S2 has received the RESUME request a RESUME request to S2. At t7, S2 has received the RESUME request
and acts on it by resuming RTP stream delivery to M. When the RTP and acts on it by resuming RTP stream delivery to M. When the RTP
stream from t7 arrives at the Mixer, it switches this RTP stream into stream from t7 arrives at the Mixer, it switches this RTP stream into
its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes its SSRC (M) at t8 and changes the CSRC to S2. As S1 now becomes
unused, the Mixer issues a PAUSE request to S1 at t9, which is unused, the Mixer issues a PAUSE request to S1 at t9, which is
acknowledged at t10 with a PAUSED and the RTP stream from S1 stops acknowledged at t10 with a PAUSED and the RTP stream from S1 stops
being delivered. being delivered.
10.4. Point-to-Multipoint using Translator 10.4. Point-to-Multipoint using Translator
A transport Translator in an RTP session forwards the message from A transport Relay in an RTP session forwards the message from one
one peer to all the others. Unlike Mixer, the Translator does not peer to all the others. Unlike Mixer, the Relay does not mix the
mix the streams or change the SSRC of the messages or RTP media. streams or change the SSRC of the messages or RTP media. These
These examples are to show that the messages defined in this examples are to show that the messages defined in this specification
specification can be safely used also in a transport Translator case. can be safely used also in a transport Relay case. The parentheses
The parentheses in the figures contains (Target SSRC, PauseID) in the figures contains (Target SSRC, PauseID) information for the
information for the messages defined in this specification. messages defined in this specification.
+-------------+ +-------------+ +--------------+ +-------------+ +-------------+ +-------------+
| Sender(S) | | Translator | | Receiver(R) | | Sender(S) | | Relay | | Receiver(R) |
+-------------+ +-------------| +--------------+ +-------------+ +-------------+ +-------------+
: t1: RTP(S) : : : t1: RTP(S) : :
|------------------>| | |------------------>| |
| | t2: RTP (S) | | | t2: RTP (S) |
| |------------------>| | |------------------>|
| | t3: PAUSE(S,3) | | | t3: PAUSE(S,3) |
| |<------------------| | |<------------------|
| t4:PAUSE(S,3) | | | t4:PAUSE(S,3) | |
|<------------------| | |<------------------| |
: < Sender waiting for possible RESUME> : : < Sender waiting for possible RESUME> :
| < RTP data paused > | | < RTP data paused > |
| t5: PAUSED(S,3) | | | t5: PAUSED(S,3) | |
|------------------>| | |------------------>| |
| | t6: PAUSED(S,3) | | | t6: PAUSED(S,3) |
| |------------------>| | |------------------>|
: : : : : :
| | t7: RESUME(S,3) | | | t7: RESUME(S,3) |
| |<------------------| | |<------------------|
| t8: RESUME(S,3) | | | t8: RESUME(S,3) | |
|<------------------| | |<------------------| |
| t9: RTP (S) | | | t9: RTP (S) | |
|------------------>| | |------------------>| |
| | t10: RTP (S) | | | t10: RTP (S) |
| |------------------>| | |------------------>|
: : : : : :
Figure 17: Pause and Resume Operation Between Two Participants Using Figure 17: Pause and Resume Operation Between Two Participants Using
a Translator a Relay
Figure 17 describes how a Translator can help the receiver in pausing Figure 17 describes how a Relay can help the receiver in pausing and
and resuming the sender. The sender S sends RTP data to the receiver resuming the sender. The sender S sends RTP data to the receiver R
R through Translator, which just forwards the data without modifying through Relay, which just forwards the data without modifying the
the SSRCs. The receiver sends a PAUSE request to the sender, which SSRCs. The receiver sends a PAUSE request to the sender, which in
in this example knows that there may be more receivers of the stream this example knows that there may be more receivers of the stream and
and waits a non-zero hold-off period to see if there is any other waits a non-zero hold-off period to see if there is any other
receiver that wants to receive the data, does not receive any receiver that wants to receive the data, does not receive any
disapproving RESUME, hence pauses itself and replies with PAUSED. disapproving RESUME, hence pauses itself and replies with PAUSED.
Similarly the receiver resumes the sender by sending RESUME request Similarly the receiver resumes the sender by sending RESUME request
through Translator. Since this describes only a single pause through Relay. Since this describes only a single pause operation
operation for a single RTP stream sender, all messages uses a single for a single RTP stream sender, all messages uses a single PauseID,
PauseID, in this example 3. in this example 3.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| S | | T | | R1 | | R2 | | S | | Rel | | R1 | | R2 |
+-----+ +-----| +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
: t1:RTP(S) : : : : t1:RTP(S) : : :
|----------------->| | | |----------------->| | |
| | t2:RTP(S) | | | | t2:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
| | t3:PAUSE(S,7) | | | | t3:PAUSE(S,7) | |
| |<-----------------| | | |<-----------------| |
| t4:PAUSE(S,7) | | | | t4:PAUSE(S,7) | | |
|<-----------------|------------------------------------>| |<-----------------|------------------------------------>|
| | | t5:RESUME(S,7) | | | | t5:RESUME(S,7) |
| |<------------------------------------| | |<------------------------------------|
skipping to change at page 44, line 43 skipping to change at page 45, line 43
| |<-----------------| | | |<-----------------| |
| t12:RESUME(S,8) | | | | t12:RESUME(S,8) | | |
|<-----------------| | | |<-----------------| | |
| t13:RTP(S) | | | | t13:RTP(S) | | |
|----------------->| | | |----------------->| | |
| | t14:RTP(S) | | | | t14:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
Figure 18: Pause and Resume Operation Between One Sender and Two Figure 18: Pause and Resume Operation Between One Sender and Two
Receivers Through Translator Receivers Through Relay
Figure 18 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 Relay is involved between a sender and two receivers in an RTP
session. Each message exchange is represented by the time it session. Each message exchange is represented by the time it
happens. At time t1, Sender (S) starts sending an RTP stream to the happens. At time t1, Sender (S) starts sending an RTP stream to the
Translator, which is forwarded to R1 and R2 through the Translator, Relay, which is forwarded to R1 and R2 through the Relay, Rel. R1 and
T. R1 and R2 receives RTP data from Translator at t2. At this R2 receives RTP data from Relay at t2. At this point, both R1 and R2
point, both R1 and R2 will send RTCP Receiver Reports to S informing will send RTCP Receiver Reports to S informing that they receive S's
that they receive S's stream. stream.
After some time (at t3), R1 chooses to pause the stream. On After some time (at t3), R1 chooses to pause the stream. On
receiving the PAUSE request from R1 at t4, S knows that there are at receiving the PAUSE request from R1 at t4, S knows that there are at
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 Relay. The sender S sees
sees the RESUME at time t6 and continues to send data to T which the RESUME at time t6 and continues to send data to Relay which
forwards to both R1 and R2. At t7, the receiver R2 chooses to pause forwards to both R1 and R2. At t7, the receiver R2 chooses to pause
the stream by sending a PAUSE request with an updated PauseID. The the stream by sending a PAUSE request with an updated PauseID. The
sender S still knows that there are more than one receiver (R1 and sender S still knows that there are more than one receiver (R1 and
R2) that may want the stream and again waits a non-zero hold-off R2) that may want the stream and again waits a non-zero hold-off
period, after which and not having received any disapproving RESUME, period, after which and not having received any disapproving RESUME,
it concludes that the stream must be paused. S now stops sending the it concludes that the stream must be paused. S now stops sending the
stream and replies with PAUSED to R1 and R2. When any of the stream and replies with PAUSED to R1 and R2. When any of the
receivers (R1 or R2) chooses to resume the stream from S, in this receivers (R1 or R2) chooses to resume the stream from S, in this
example R1, it sends a RESUME request to the sender. The RTP sender example R1, it sends a RESUME request to the sender. 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 Relay. Further assume that a new participant
participant joins the session, which is not aware of the paused joins the session, which is not aware of the paused sender(s). On
sender(s). On receiving knowledge about the newly joined receiving knowledge about the newly joined participant, e.g. any RTP
participant, e.g. any RTP traffic or RTCP report (i.e. either SR or traffic or RTCP report (i.e. either SR or RR) from the newly joined
RR) from the newly joined participant, the paused sender(s) participant, the paused sender(s) immediately sends PAUSED
immediately sends PAUSED indications for the paused streams since indications for the paused streams since there is now a receiver in
there is now a receiver in the session that did not pause the the session that did not pause the sender(s) and may want to receive
sender(s) and may want to receive the streams. Having this the streams. Having this information, the newly joined participant
information, the newly joined participant has the same possibility as has the same possibility as any other participant to resume the
any other participant to resume the paused streams. paused streams.
11. IANA Considerations 11. IANA Considerations
This specification requests the following registrations from IANA: This specification requests the following registrations from IANA:
1. A new value for media stream pause / resume to be registered with 1. A new value for media stream pause / resume to be registered with
IANA in the "FMT Values for RTPFB Payload Types" registry located IANA in the "FMT Values for RTPFB Payload Types" registry located
at the time of publication at: http://www.iana.org/assignments/ at the time of publication at: http://www.iana.org/assignments/
rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8 rtp-parameters/rtp-parameters.xhtml#rtp-parameters-8
skipping to change at page 46, line 22 skipping to change at page 47, line 22
Long Name: Media Pause / Resume Long Name: Media Pause / Resume
Usable with: ccm Usable with: ccm
Reference: This RFC 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, RESUME, PAUSED, and REFUSED. The exchange of these new
some security implications, which need to be addressed by the user. messages have some security implications, which need to be addressed
Following are some important implications, by the user.
1. Identity spoofing - An attacker can spoof him/herself as an The messages defined in this specification can have substantial
authenticated user and can falsely pause or resume any source impact on the perceived media quality if used in a malicious way.
transmission. In order to prevent this type of attack, a strong First of all, there is the risk for Denial of Service (DoS) on any
authentication and integrity protection mechanism is needed. RTP session that uses the PAUSE-RESUME functionality. By injecting
one or more PAUSE requests into the RTP session, an attacker can
potentially prevent any media from flowing, especially when the hold-
off period is zero. The injection of PAUSE messages is quite simple,
requiring knowledge of the SSRC and the PauseID. This information is
visible to an on-path attacker unless RTCP messages are encrypted.
Even off-path attacks are possible as signalling messages often carry
the SSRC value, while the 16-bit PauseID have to be guessed or tried.
The way of protecting the RTP session from these injections is to
perform source authentication combined with message integrity, to
prevent other than intended session participants from sending these
messages. There exist several different choices for securing RTP
sessions to prevent this type of attack. SRTP is the the most
common, but also other methods exist as discussed in "Options for
Securing RTP Sessions" [RFC7201].
2. Denial of Service (DoS) - An attacker can falsely pause all Most of the methods for securing RTP however, do not provide source
source streams which MAY result in Denial of Service (DoS). An authentication of each individual participant in a multi-party use
Authentication protocol may prevent this attack. case. In case one of the session participants is malicious, they can
wreck significant havoc within the RTP session and similarly cause a
DoS on the RTP session from within. That damage can also be
attempted to be obfuscated by having the attacker impersonate other
endpoints within the session. These attacks can be mitigated by
using a solution that provides true source authentication of all
participant's RTCP packets. However, that has other implications.
For multi-party sessions including a middlebox, that middlebox is
RECOMMENDED to perform checks on all forwarded RTCP packets so that
each participant only uses its set of SSRCs, to prevent the attacker
utilizing another participant's SSRCs.
3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP The above text has been focused on using the PAUSE message as the
source is prone to a Man-in-Middle attack. Public key tool for malicious impact on the RTP session. That is because of the
authentication may be used to prevent MiMT. greater impact from denying users access to RTP media streams. In
contrast, if an attacker attempts to use RESUME in a malicious
purpose, it will result in that the media streams are delivered.
However, such an attack basically prevents the use the Pause and
Resume functionality. Thus, potentially forcing a reduction of the
media quality due to limitation in available resources, like
bandwidth that must be shared.
The session establishment signalling is also a potential venue of
attack, as that can be used to prevent the enabling of Pause and
Resume functionality by modifying the signalling messages. The above
mitigation of attacks based on source authentication also requires
the signalling system to securely handle identities, and assert that
only the intended identities are allowed into the RTP session and
provided the relevant security contexts.
13. Contributors 13. Contributors
Daniel Grondal contributed in the creation and writing of early Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/ significantly to the SDP config attribute and its use in Offer/
Answer. Answer.
14. Acknowledgements 14. Acknowledgements
skipping to change at page 47, line 39 skipping to change at page 49, line 28
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
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-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work
in progress), February 2015.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-05 (work in progress), ietf-avtcore-rtp-topologies-update-06 (work in progress),
November 2014. March 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., 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-05 (work in progress), January 2015. rtp-grouping-taxonomy-06 (work in progress), March 2015.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Westerlund, M., Nandakumar, S., and M. Zanaty, "Using
Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp- Simulcast in SDP and RTP Sessions", draft-ietf-mmusic-sdp-
simulcast-00 (work in progress), January 2015. 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-16 (work in ietf-rtcweb-use-cases-and-requirements-16 (work in
skipping to change at page 48, line 38 skipping to change at page 50, line 33
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014.
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 -05 and -06 A.1. Modifications Between Version -06 and -07
o Completely rewrote the Security Consideration section.
o Aligned text such that REFUSED is always referred to as a
notification, not indication.
o Added and changed text in several places, clarifying the case when
TMMBR/TMMBN bounding set overhead value matters, related to
whether local RTP stream sender or remote RTP stream receiver owns
the TMMBR 0 restriction, and the consequences this has on pause/
resume logic.
o Moved text on when to stop media stream transmission from when
receiving PAUSE and entering pausing state, to when entering
paused or local paused states.
o Added text on how to determine if there is a single receiver or
not, aligned with what is specified in draft-ietf-avtcore-multi-
stream, adding a reference to draft-ietf-avtcore-multi-stream-
optimisation to be able to use a single RTCP reporting group as
one criteria.
o Added clarifying text on repeating PAUSED and RESUME messages only
as long as remaining in the relevant state.
o Clarified that it is the RTP stream sender's responsibility to
leave local paused state when the condition causing that state is
no longer true.
o Added text to better allow for extensions to this specification,
since there is already some text on extensions.
o Corrected and amended ABNF to make CCM pause parameters order-
independent, allow for a larger config pause attribute value
range, and added corresponding text to handle that additional
flexibility.
o Added SDP rules on how to handle unknown pause attribute values.
o Clarified how to handle an SDP with both "ccm pause" and "ccm
tmmbr".
o Changed from "Translator" to "Relay" in examples, to make it
clearer in relation to the updated topologies draft.
o Editorial improvements.
A.2. Modifications Between Version -05 and -06
o Clarified in Message Details section for PAUSED that o Clarified in Message Details section for PAUSED that
retransmission of the message can be used to increase the retransmission of the message can be used to increase the
probability that the message reaches the receiver in a timely probability that the message reaches the receiver in a timely
fashion, and also added text that says the number of repetitions fashion, and also added text that says the number of repetitions
can be tuned to observed loss rate and the desired loss can be tuned to observed loss rate and the desired loss
probability. Also removed Editor's notes on potential ACK for probability. Also removed Editor's notes on potential ACK for
unsolicited PAUSED, since the issue is solved by the above. unsolicited PAUSED, since the issue is solved by the above.
o In the same section as above, added that PAUSED may be included in o In the same section as above, added that PAUSED may be included in
skipping to change at page 49, line 23 skipping to change at page 52, line 19
targeted stream are received. targeted stream are received.
o Changed simulcast reference, since that draft was moved from o Changed simulcast reference, since that draft was moved from
AVTCORE to MMUSIC and made WG draft. AVTCORE to MMUSIC and made WG draft.
o Changed End Point to Endpoint to reflect change in RTP Grouping o Changed End Point to Endpoint to reflect change in RTP Grouping
Taxonomy draft. Taxonomy draft.
o Editorial improvements. o Editorial improvements.
A.2. Modifications Between Version -04 and -05 A.3. 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.3. Modifications Between Version -03 and -04 A.4. Modifications Between Version -03 and -04
o Change of Copyright boilerplate o Change of Copyright boilerplate
A.4. Modifications Between Version -02 and -03 A.5. 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 50, line 16 skipping to change at page 53, line 11
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.5. Modifications Between Version -01 and -02 A.6. 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.6. Modifications Between Version -00 and -01 A.7. 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. 84 change blocks. 
224 lines changed or deleted 411 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/