draft-ietf-avtext-rtp-stream-pause-08.txt   draft-ietf-avtext-rtp-stream-pause-09.txt 
Network Working Group B. Burman Network Working Group B. Burman
Internet-Draft A. Akram Internet-Draft A. Akram
Updates: 5104 (if approved) Ericsson Updates: 5104 (if approved) Ericsson
Intended status: Standards Track R. Even Intended status: Standards Track R. Even
Expires: January 4, 2016 Huawei Technologies Expires: March 6, 2016 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
July 3, 2015 September 3, 2015
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-08 draft-ietf-avtext-rtp-stream-pause-09
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
(CCM) RTCP feedback package by explicitly allowing and describing (CCM) RTP Control Protocol (RTCP) feedback package by explicitly
specific use of existing CCM messages and adding a group of new real- allowing and describing specific use of existing CCM messages and
time feedback messages used to pause and resume RTP data streams. adding a group of new real-time feedback messages used to pause and
This document updates RFC 5104. resume RTP data streams. This document updates RFC 5104.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2016. This Internet-Draft will expire on March 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 8 3.1. Point to Point . . . . . . . . . . . . . . . . . . . . . 7
3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8 3.2. RTP Mixer to Media Sender . . . . . . . . . . . . . . . . 8
3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 10 3.3. RTP Mixer to Media Sender in Point-to-Multipoint . . . . 9
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 10
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 11 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 11
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 11
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 12 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 12
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Message Acknowledgments . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 14 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. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. PauseID . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 16 5.3. Requesting to Pause . . . . . . . . . . . . . . . . . . . 16
5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 17 5.4. Media Sender Pausing . . . . . . . . . . . . . . . . . . 17
5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 18 5.5. Requesting to Resume . . . . . . . . . . . . . . . . . . 18
5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 20 5.6. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 19
6. Participant States . . . . . . . . . . . . . . . . . . . . . 20 6. Participant States . . . . . . . . . . . . . . . . . . . . . 20
6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 22 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 22
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 23 6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 23
6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 23 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 23
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 24 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 24
8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 27 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.4. REFUSED . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 31 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 31
9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 36
9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 37
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 39 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 40
10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 44
10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. Security Considerations . . . . . . . . . . . . . . . . . . . 50 12. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . 52 15.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 53 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54
A.1. Modifications Between Version -07 and -08 . . . . . . . . 53 A.1. Modifications Between Version -08 and -09 . . . . . . . . 54
A.2. Modifications Between Version -06 and -07 . . . . . . . . 55 A.2. Modifications Between Version -07 and -08 . . . . . . . . 55
A.3. Modifications Between Version -05 and -06 . . . . . . . . 56 A.3. Modifications Between Version -06 and -07 . . . . . . . . 56
A.4. Modifications Between Version -04 and -05 . . . . . . . . 56 A.4. Modifications Between Version -05 and -06 . . . . . . . . 57
A.5. Modifications Between Version -03 and -04 . . . . . . . . 56 A.5. Modifications Between Version -04 and -05 . . . . . . . . 58
A.6. Modifications Between Version -02 and -03 . . . . . . . . 57 A.6. Modifications Between Version -03 and -04 . . . . . . . . 58
A.7. Modifications Between Version -01 and -02 . . . . . . . . 57 A.7. Modifications Between Version -02 and -03 . . . . . . . . 58
A.8. Modifications Between Version -00 and -01 . . . . . . . . 57 A.8. Modifications Between Version -01 and -02 . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 A.9. Modifications Between Version -00 and -01 . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
As real-time communication attracts more people, more applications As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example. are created; multimedia conversation applications being one example.
Multimedia conversation further exists in many forms, for example, Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers. controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its Multimedia conferencing may involve many participants; each has its
own preferences for the communication session, not only at the start own preferences for the communication session, not only at the start
but also during the session. This document describes several but also during the session. This document describes several
scenarios in multimedia communication where a conferencing node or scenarios in multimedia communication where a conferencing node or
participant chooses to temporarily pause an incoming RTP [RFC3550] participant chooses to temporarily pause an incoming RTP [RFC3550]
stream and later resume it when needed. The receiver does not need stream and later resume it when needed. The receiver does not need
to terminate or inactivate the RTP session and start all over again to terminate or inactivate the RTP session and start all over again
by negotiating the session parameters, for example using SIP by negotiating the session parameters, for example using SIP
[RFC3261] with SDP [RFC4566] Offer/Answer [RFC3264]. [RFC3261] with SDP [RFC4566] Offer/Answer [RFC3264].
Centralized nodes, like RTP Mixers or MCUs, which either uses logic Centralized nodes, like RTP Mixers or Multipoint Control Units (MCU),
based on voice activity, other measurements, or user input could which either use logic based on voice activity, other measurements,
reduce the resources consumed in both the sender and the network by or user input could reduce the resources consumed in both the sender
temporarily pausing the RTP streams that aren't required by the RTP and the network by temporarily pausing the RTP streams that aren't
Mixer. If the number of conference participants are greater than required by the RTP Mixer. If the number of conference participants
what the conference logic has chosen to present simultaneously to are greater than what the conference logic has chosen to present
receiving participants, some participant RTP streams sent to the RTP simultaneously to receiving participants, some participant RTP
Mixer may not need to be forwarded to any other participant. Those streams sent to the RTP Mixer may not need to be forwarded to any
RTP streams could then be temporarily paused. This becomes other participant. Those RTP streams could then be temporarily
especially useful when the media sources are provided in multiple paused. This becomes especially useful when the media sources are
encoding versions (Simulcast) [I-D.ietf-mmusic-sdp-simulcast] or with provided in multiple encoding versions (Simulcast)
Multi-Session Transmission (MST) of scalable encoding such as SVC [I-D.ietf-mmusic-sdp-simulcast] or with Multi-Session Transmission
[RFC6190]. There may be some of the defined encodings or combination (MST) of scalable encoding such as SVC [RFC6190]. There may be some
of scalable layers that are not used or cannot be used all of the of the defined encodings or combination of scalable layers that are
time. As an example, a centralized node may choose to pause such not used or cannot be used all of the time. As an example, a
unused RTP streams without being explicitly requested to do so, maybe centralized node may choose to pause such unused RTP streams without
due to temporarily limited network or processing resources. It may being explicitly requested to do so, maybe due to temporarily limited
then also send an explicit indication that the streams are paused. network or processing resources. It may then also send an explicit
indication that the streams are paused.
As the set of RTP streams required at any given point in time is As the set of RTP streams required at any given point in time is
highly dynamic in such scenarios, using the out-of-band signaling highly dynamic in such scenarios, using the out-of-band signaling
channel for pausing, and even more importantly resuming, an RTP channel for pausing, and even more importantly resuming, an RTP
stream is difficult due to the performance requirements. Instead, stream is difficult due to the performance requirements. Instead,
the pause and resume signaling should be in the media plane and go the pause and resume signaling should be in the media plane and go
directly between the affected nodes. When using RTP [RFC3550] for directly between the affected nodes. When using RTP [RFC3550] for
media transport, using the Extended RTP Profile for Real-time media transport, using the Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585]
appears appropriate. No currently existing RTCP feedback message appears appropriate. No currently existing RTCP feedback message
explicitly supports pausing and resuming an incoming RTP stream. As explicitly supports pausing and resuming an incoming RTP stream. As
this affects the generation of packets and may even allow the this affects the generation of packets and may even allow the
encoding process to be paused, the functionality appears to match encoding process to be paused, the functionality appears to match
Codec Control Messages in the RTP Audio-Visual Profile with Feedback Codec Control Messages in the RTP Audio-Visual Profile with Feedback
(AVPF) [RFC5104]. This document defines the solution as a Codec (AVPF) [RFC5104]. This document defines the solution as a Codec
Control Message (CCM) extension. Control Message (CCM) extension.
The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is
used by video conferencing systems for flow control. It is desirable used by video conferencing systems for flow control. It is desirable
to be able to use that method with a bitrate value of zero for pause, to be able to use that method with a bitrate value of zero for pause,
whenever possible. whenever possible. This specification updates RFC 5104 to add the
new Pause and Resume semantics to the TMMBR/TMMBN messages.
2. Definitions 2. Definitions
2.1. Abbreviations 2.1. Abbreviations
3GPP: 3rd Generation Partnership Project
AVPF: Audio-Visual Profile with Feedback (RFC 4585) AVPF: Audio-Visual Profile with Feedback (RFC 4585)
BGW: Border Gateway
CCM: Codec Control Messages (RFC 5104) CCM: Codec Control Messages (RFC 5104)
CNAME: Canonical Name (RTCP SDES) CNAME: Canonical Name (RTCP SDES)
CSRC: Contributing Source (RTP) CSRC: Contributing Source (RTP)
FB: Feedback (AVPF)
FCI: Feedback Control Information (AVPF) FCI: Feedback Control Information (AVPF)
FIR: Full Intra Refresh (CCM) FIR: Full Intra Refresh (CCM)
FMT: Feedback Message Type (AVPF) FMT: Feedback Message Type (AVPF)
LTE: Long-Term Evolution (3GPP)
MCU: Multipoint Control Unit MCU: Multipoint Control Unit
MTU: Maximum Transfer Unit MTU: Maximum Transfer Unit
PT: Payload Type (RTP) PT: Payload Type (RTP)
RTP: Real-time Transport Protocol (RFC 3550) RTP: Real-time Transport Protocol (RFC 3550)
RTCP: RTP Control Protocol (RFC 3550) RTCP: RTP Control Protocol (RFC 3550)
RTCP RR: RTCP Receiver Report RTCP RR: RTCP Receiver Report
SDP: Session Description Protocol (RFC 4566)
SGW: Signaling Gateway RTCP SR: RTCP Sender Report
SIP: Session Initiation Protocol (RFC 3261) SDP: Session Description Protocol (RFC 4566)
SIP: Session Initiation Protocol (RFC 3261)
SSRC: Synchronization Source (RTP) SSRC: Synchronization Source (RTP)
SVC: Scalable Video Coding SVC: Scalable Video Coding
TCP: Transmission Control Protocol (RFC 793)
TMMBR: Temporary Maximum Media Bitrate Request (CCM) TMMBR: Temporary Maximum Media Bitrate Request (CCM)
TMMBN: Temporary Maximum Media Bitrate Notification (CCM) TMMBN: Temporary Maximum Media Bitrate Notification (CCM)
UA: User Agent (SIP) UA: User Agent (SIP)
UDP: User Datagram Protocol (RFC 768) UDP: User Datagram Protocol (RFC 768)
2.2. Terminology 2.2. Terminology
skipping to change at page 10, line 36 skipping to change at page 10, line 26
If the RTP Mixer pauses a stream from A, it will not only pause the If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself, but will also stop the stream from arriving to stream towards itself, but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should C, which C is heavily impacted by, might not approve of, and should
thus have a say on. thus have a say on.
If the Mixer resumes a paused stream from A, it will be resumed also If the Mixer resumes a paused stream from A, it will be resumed also
towards C. In this case, if C is not interested it can simply ignore towards C. In this case, if C is not interested it can simply ignore
the stream and is not impacted as much as above. the stream and is not impacted as much as above.
In this use case there are several receivers of a stream and special In this use case there are several receivers of a stream and the
care must be taken as not to pause a stream that is still wanted by Mixer must take special care so as not to pause a stream that is
some receivers. still wanted by some receivers.
3.4. Media Receiver to RTP Mixer 3.4. Media Receiver to RTP Mixer
In this use case, the direction of the request to pause is the In this use case, the direction of the request to pause is the
opposite compared to the two previous use cases. An Endpoint in opposite compared to the two previous use cases. An Endpoint in
Figure 2 could potentially request to pause the delivery of a given Figure 2 could potentially request to pause the delivery of a given
stream. Possible reasons include the ones in the point to point case stream. Possible reasons include the ones in the point to point case
(Section 3.1) above. (Section 3.1) above.
When the RTP Mixer is only connected to individual unicast paths, the When the RTP Mixer is only connected to individual unicast paths, the
skipping to change at page 11, line 19 skipping to change at page 11, line 7
resume requests. resume requests.
3.5. Media Receiver to Media Sender Across RTP Mixer 3.5. Media Receiver to Media Sender Across RTP Mixer
An Endpoint, like A in Figure 2, could potentially request to pause An Endpoint, like A in Figure 2, could potentially request to pause
the delivery of a given stream, like one of B's, over any of the the delivery of a given stream, like one of B's, over any of the
SSRCs used by the Mixer by sending a pause request for the CSRC SSRCs used by the Mixer by sending a pause request for the CSRC
identifying the stream. However, the authors are of the opinion that identifying the stream. However, the authors are of the opinion that
this is not a suitable solution, for several reasons: this is not a suitable solution, for several reasons:
1. The Mixer might not include CSRC in it's stream indications. 1. The Mixer might not include CSRC in its stream indications.
2. An Endpoint cannot rely on the CSRC to correctly identify the 2. An Endpoint cannot rely on the CSRC to correctly identify the
stream to be paused when the delivered media is some type of mix. stream to be paused when the delivered media is some type of mix.
A more elaborate stream identification solution is needed to A more elaborate stream identification solution is needed to
support this in the general case. support this in the general case.
3. The Endpoint cannot determine if a given stream is still needed 3. The Endpoint cannot determine if a given stream is still needed
by the RTP Mixer to deliver to another session participant. by the RTP Mixer to deliver to another session participant.
Due to the above reasons, we exclude this use case from further Due to the above reasons, we exclude this use case from further
skipping to change at page 18, line 20 skipping to change at page 18, line 9
understand that transmission is deliberately and temporarily understand that transmission is deliberately and temporarily
suspended and no specific corrective action is needed. suspended and no specific corrective action is needed.
The RTP stream sender may want to apply some local consideration to The RTP stream sender may want to apply some local consideration to
exactly when the RTP stream is paused, for example completing some exactly when the RTP stream is paused, for example completing some
media unit or a forward error correction block, before pausing the media unit or a forward error correction block, before pausing the
stream. stream.
The PAUSED indication also contains information about the RTP The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective. extended highest sequence number when the pause became effective.
This provides RTP stream receivers with first hand information This provides RTP stream receivers with firsthand information
allowing them to know whether they lost any packets just before the allowing them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP stream paused or when the stream is resumed again. This allows RTP
stream receivers to quickly and safely take into account that the stream receivers to quickly and safely take into account that the
stream is paused, in for example retransmission or congestion control stream is paused, in for example retransmission or congestion control
algorithms. algorithms.
If the RTP stream sender receives PAUSE requests with the current If the RTP stream sender receives PAUSE requests with the current
PauseID while the stream is already paused, those requests are PauseID while the stream is already paused, those requests are
ignored. ignored.
As long as the stream is being paused, the PAUSED indication MAY be As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP SR or RR. Including PAUSED in sent together with any regular RTCP Sender Report (SR) or Receiver
this way allows RTP stream receivers joining while the stream is Report (RR). Including PAUSED in this way allows RTP stream
paused to quickly know that there is a paused stream, what the last receivers joining while the stream is paused to quickly know that
sent extended RTP sequence number was, and what the current PauseID there is a paused stream, what the last sent extended RTP sequence
is to be able to construct valid PAUSE and RESUME requests at a later number was, and what the current PauseID is to be able to construct
stage. valid PAUSE and RESUME requests at a later stage.
When the RTP stream sender learns that a new Endpoint has joined the When the RTP stream sender learns that a new Endpoint has joined the
RTP session, for example by a new SSRC and a CNAME that was not RTP session, for example by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in for all its paused streams at its earliest opportunity. It should in
addition continue to include PAUSED indications in at least two addition continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
5.5. Requesting to Resume 5.5. Requesting to Resume
skipping to change at page 20, line 14 skipping to change at page 20, line 4
from before the pause, the RTP stream receiver can use a FIR request from before the pause, the RTP stream receiver can use a FIR request
[RFC5104] to explicitly ask for a sample without temporal dependency [RFC5104] to explicitly ask for a sample without temporal dependency
(for video a so-called intra picture), even at the same time as (for video a so-called intra picture), even at the same time as
sending the RESUME. sending the RESUME.
5.6. TMMBR/TMMBN Considerations 5.6. TMMBR/TMMBN Considerations
As stated above, TMMBR/TMMBN may be used to provide pause and resume As stated above, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or point-to-point, TMMBR/TMMBN cannot safely be used for pause or
resume. resume. This use is expected to be mainly for interworking with
implementations that don't support the messages defined in this
specification (Section 8), but make use of TMMBR/TMMBN to achieve a
similar effect.
This is a brief summary of what functionality is provided when using This is a brief summary of what functionality is provided when using
TMMBR/TMMBN: TMMBR/TMMBN:
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
off period to wait for RESUME before pausing the RTP stream. off period to wait for RESUME before pausing the RTP stream.
TMMBR >0: Corresponds to RESUME when the RTP stream was previously TMMBR >0: Corresponds to RESUME when the RTP stream was previously
paused with TMMBR 0. Since there is only a single RTP stream paused with TMMBR 0. Since there is only a single RTP stream
receiver, there is no need for the RTP stream sender to delay receiver, there is no need for the RTP stream sender to delay
skipping to change at page 21, line 19 skipping to change at page 21, line 19
| Playing |---------------->| Pausing |---------------->| Paused | | Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | | | |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+ +---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision | ^ | | PAUSE decision |
| | v | | | v |
| | PAUSE decision +---------+ PAUSE decision | | | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+ | +------------------>| Local |<--------------------+
+-------------------------| Paused | +-------------------------| Paused |
RESUME decision +---------+ RESUME decision +---------+
Figure 4: RTP Pause States Figure 4: RTP Pause States in Sender
6.1. Playing State 6.1. Playing State
This state is not new, but is the normal media sending state from This state is not new, but is the normal media sending state from
[RFC3550]. When entering the state, the current PauseID MUST be [RFC3550]. When entering the state, the current PauseID MUST be
incremented by one in modulo arithmetic. The RTP sequence number for incremented by one in modulo arithmetic. The RTP sequence number for
the first packet sent after a pause SHALL be incremented by one the first packet sent after a pause SHALL be incremented by one
compared to the highest RTP sequence number sent before the pause. compared to the highest RTP sequence number sent before the pause.
The first RTP Time Stamp for the first packet sent after a pause The first RTP Time Stamp for the first packet sent after a pause
SHOULD be set according to capture times at the source, meaning the SHOULD be set according to capture times at the source, meaning the
skipping to change at page 23, line 42 skipping to change at page 23, line 42
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. Pausing transmission SHOULD only be done when the RTP stream sender. Pausing transmission SHOULD only be done when
reaching an appropriate place to pause in the stream, like a media reaching an appropriate place to pause in the stream, like a media
boundary that avoids a media receiver to trigger repair or boundary that avoids a media receiver to trigger repair or
concealment actions. concealment actions.
As for Paused State (Section 6.3), the RTP stream sender SHALL send a As with Paused State (Section 6.3), the RTP stream sender SHALL send
PAUSED indication to all known RTP stream receivers, when entering a PAUSED indication to all known RTP stream receivers, when entering
the state, unless the stream was already in paused state the state, unless the stream was already in paused state
(Section 6.3), and repeat it a sufficient number of times to reach a (Section 6.3). Such PAUSED indication SHALL be repeated a sufficient
high probability that the message is correctly delivered, and number of times to reach a high probability that the message is
stopping such repetition whenever leaving the state. correctly delivered, stopping such repetition whenever leaving the
state.
When using TMMBN 0 as PAUSED indication and when already in paused When using TMMBN 0 as PAUSED indication and when already in paused
state, the actions when entering local paused state depends on the state, the actions when entering local paused state depends on the
bounding set overhead value in the received TMMBR 0 that caused the bounding set overhead value in the received TMMBR 0 that caused the
paused state, and the bounding set overhead value used in (the RTP paused state, and the bounding set overhead value used in (the RTP
stream sender's own) TMMBN 0: stream sender's own) TMMBN 0:
TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL
NOT send any new TMMBN 0 replacing that active (more restrictive) NOT send any new TMMBN 0 replacing that active (more restrictive)
bounding set, even if entering local paused state. bounding set, even if entering local paused state.
skipping to change at page 27, line 30 skipping to change at page 27, line 30
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.6) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be
used instead of the messages defined in this specification when the used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver effective topology is point-to-point. This use is expected to be
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT mainly for interworking with implementations that don't support the
be used for pause/resume functionality. If the messages defined in messages defined in this specification, but make use of TMMBR/TMMBN
this specification are supported in addition to TMMBR/TMMBN by all to achieve a similar effect. If either sender or receiver learns
that the topology is not point-to-point, TMMBR/TMMBN MUST NOT be used
for pause/resume functionality. If the messages defined in this
specification are supported in addition to TMMBR/TMMBN by all
involved parties, pause/resume signaling MUST use messages from this involved parties, pause/resume signaling MUST use messages from this
specification. If the topology is not point-to-point and the specification. If the topology is not point-to-point and the
messages defined in this specification are not supported, pause/ messages defined in this specification are not supported, pause/
resume functionality with TMMBR/TMMBN MUST NOT be used. resume functionality with TMMBR/TMMBN MUST NOT be used.
For the scope of this specification, a past PauseID (Section 5.2) is For the scope of this specification, a past PauseID (Section 5.2) is
defined as having a value between and including (PauseID - 2^15) MOD defined as having a value between and including (PauseID - 2^15) MOD
2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator. 2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator.
Similarly, a future PauseID is defined as having a value between and Similarly, a future PauseID is defined as having a value between and
including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16.
skipping to change at page 31, line 19 skipping to change at page 31, line 21
notification containing the current PauseID, except if the RTP stream notification containing the current PauseID, except if the RTP stream
sender is in Playing State and receives a RESUME with a past PauseID, sender is in Playing State and receives a RESUME with a past PauseID,
in which case the RESUME SHALL be ignored. in which case the RESUME SHALL be ignored.
If several PAUSE or RESUME that would render identical REFUSED If several PAUSE or RESUME that would render identical REFUSED
notifications are received before the scheduled REFUSED is sent, notifications are received before the scheduled REFUSED is sent,
duplicate REFUSED MUST NOT be scheduled for transmission. This duplicate REFUSED MUST NOT be scheduled for transmission. This
effectively lets a single REFUSED respond to several ineffective effectively lets a single REFUSED respond to several ineffective
PAUSE or RESUME requests. PAUSE or RESUME requests.
If REFUSED containing a certain PauseID was already sent and yet more
PAUSE or RESUME messages are received that require additional REFUSED
with that specific PauseID to be scheduled, further REFUSED messages
with that PauseID SHOULD be sent in regular RTCP reports. An
exception to the previous rule is when the stream was paused and
resumed so many times that the PauseID number space has wrapped since
REFUSED was last sent with that PauseID.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSED containing the same PauseID as in the request receives a REFUSED containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSED to clear. For PAUSE, time to allow the condition that caused REFUSED to clear. For PAUSE,
an appropriate time is suggested in Section 8.1. For RESUME, an an appropriate time is suggested in Section 8.1. For RESUME, an
appropriate time is suggested in Section 8.3. appropriate time is suggested in Section 8.3.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSED containing a PauseID different from the request receives a REFUSED containing a PauseID different from the request
MAY schedule another request using the PauseID from the REFUSED MAY schedule another request using the PauseID from the REFUSED
notification. notification.
8.5. Transmission Rules 8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation. depends on the session's mode of operation.
All messages defined in this specification, as well as TMMBR/TMMBN All messages defined in this specification, as well as TMMBR/TMMBN
used for pause/resume purposes (Section 5.6), MAY use either Regular, used for pause/resume purposes (Section 5.6), can use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, but should make a trade-off between
timely transmission (Section 4.1) and RTCP bandwidth consumption.
This can be achieved by taking the following into consideration:
o PAUSE SHOULD use Early or Immediate timing, except for o It is recommended that PAUSE use Early or Immediate timing, except
retransmissions that SHOULD use Regular timing. for retransmissions where RTCP bandwidth can motivate the use of
Regular timing.
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID is
SHOULD be sent with Immediate or Early timing, while subsequent recommended to be sent with Immediate or Early timing, to stop
PAUSED for that PauseID SHOULD use Regular timing. Unsolicited unnecessary repetitions of PAUSE. It is recommended that
PAUSED (sent when entering Local Paused State (Section 6.4)) subsequent transmissions of PAUSED for that PauseID use Regular
SHOULD always use Immediate or Early timing, until PAUSED for that timing, to avoid that multiple PAUSE requests cause excessive
PauseID is considered delivered at least once to all receivers of PAUSED RTCP bandwidth.
the paused RTP stream, after which it SHOULD use Regular timing.
o RESUME SHOULD always use Immediate or Early timing. o It is recommended that unsolicited PAUSED (sent when entering
Local Paused State (Section 6.4)) always use Immediate or Early
timing, until PAUSED for that PauseID is considered delivered at
least once to all receivers of the paused RTP stream, to avoid
that RTP stream receivers take unnecessary corrective action when
the RTP stream is no longer received, after which it is
recommended that PAUSE uses Regular timing (as for PAUSED
triggered by PAUSE above).
o RESUME is often time-critical and it is recommended that it always
uses Immediate or Early timing.
o The first transmission of REFUSED for each (non-wrapped) PauseID o The first transmission of REFUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent is recommended to be sent with Immediate or Early timing, to stop
REFUSED for that PauseID SHOULD use Regular timing. unnecessary repetitions of PAUSE or RESUME. It is recommended
that subsequent REFUSED for that PauseID use Regular timing, to
avoid that multiple unreasonable requests cause excessive REFUSED
RTCP bandwidth.
9. Signaling 9. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to
include the request for pause and resume. This specification follows include the request for pause and resume. This specification follows
all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an
rtcp-fb attribute relating to payload type in a session description. rtcp-fb attribute relating to payload type in a session description.
skipping to change at page 34, line 18 skipping to change at page 34, line 28
environment where only parts of the functionality provided by this environment where only parts of the functionality provided by this
specification are needed. The above defined "config" functionality specification are needed. The above defined "config" functionality
sub-sets provide a trade-off between completeness and the need for sub-sets provide a trade-off between completeness and the need for
implementation interoperability, achieving at least a level of implementation interoperability, achieving at least a level of
functionality corresponding to what is desired by the least capable functionality corresponding to what is desired by the least capable
party when used as specified here. Implementation of any other party when used as specified here. Implementation of any other
functionality sub-sets of this specification than the above defined functionality sub-sets of this specification than the above defined
is NOT RECOMMENDED. is NOT RECOMMENDED.
When signaling a config value other than 1, an implementation MUST When signaling a config value other than 1, an implementation MUST
ignore non-supported messages on reception, and MAY omit sending non- ignore non-supported messages on reception, and SHOULD omit sending
supported messages. The below table summarizes per-message send and messages not supported by the remote peer. One example where is can
receive support for the different config attribute values ("X" be motivated to send messages that some receivers do not support, is
indicating support and "-" indicating non-support): when there are multiple message receivers with different message
support (different config values). That approach avoids that the
least capable receiver limits the functionality provided to others.
The below table summarizes per-message send and receive support for
the different config attribute values ("X" indicating support and "-"
indicating non-support):
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| # | Send | Receive | | # | Send | Receive |
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | | | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED |
+---+-----------------------------+-----------------------------+ +---+-----------------------------+-----------------------------+
| 1 | X X X X | X X X X | | 1 | X X X X | X X X X |
| 2 | X X X - | - - X X | | 2 | X X X - | - - X X |
| 3 | - - X X | X X X - | | 3 | - - X X | X X X - |
| 4 | X X - - | - - X X | | 4 | X X - - | - - X X |
| 5 | - - X X | X X - - | | 5 | - - X X | X X - - |
skipping to change at page 35, line 37 skipping to change at page 36, line 4
pause-config-value = 1*2DIGIT pause-config-value = 1*2DIGIT
; byte-string as defined in RFC 4566 ; byte-string as defined in RFC 4566
Figure 8: ABNF Figure 8: ABNF
An endpoint implementing this specification and using SDP to signal An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate the new "pause" parameter with ccm capability SHOULD indicate the new "pause" parameter with ccm
signaling, but MAY instead use existing ccm tmmbr signaling [RFC5104] signaling, but MAY instead use existing ccm tmmbr signaling [RFC5104]
if the limitations in functionality when using TMMBR/TMMBN as if the limitations in functionality when using TMMBR/TMMBN as
described in this specification (Section 5.6) are considered described in this specification (Section 5.6) are considered
acceptable. The messages from this specification (Section 8) SHOULD acceptable. In that case, no partial message support is possible.
NOT be used towards receivers that did not declare capability to The messages from this specification (Section 8) SHOULD NOT be used
receive those messages. towards receivers that did not declare capability to receive those
messages.
The pause functionality can normally be expected to work The pause functionality can normally be expected to work
independently of the payload type. However, there might exist independently of the payload type. However, there might exist
situations where an endpoint needs to restrict or at least configure situations where an endpoint needs to restrict or at least configure
the capabilities differently depending on the payload type carrying the capabilities differently depending on the payload type carrying
the media stream. Reasons for this might relate to capabilities to the media stream. Reasons for this might relate to capabilities to
correctly handle media boundaries and avoid any pause or resume correctly handle media boundaries and avoid any pause or resume
operation to occur where it would leave a receiver or decoder with no 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 choice than to attempt to repair or discard the media received just
prior to or at the point of resuming. prior to or at the point of resuming.
skipping to change at page 50, line 40 skipping to change at page 50, line 40
one or more PAUSE requests into the RTP session, an attacker can one or more PAUSE requests into the RTP session, an attacker can
potentially prevent any media from flowing, especially when the hold- potentially prevent any media from flowing, especially when the hold-
off period is zero. The injection of PAUSE messages is quite simple, off period is zero. The injection of PAUSE messages is quite simple,
requiring knowledge of the SSRC and the PauseID. This information is requiring knowledge of the SSRC and the PauseID. This information is
visible to an on-path attacker unless RTCP messages are encrypted. visible to an on-path attacker unless RTCP messages are encrypted.
Even off-path attacks are possible as signalling messages often carry Even off-path attacks are possible as signalling messages often carry
the SSRC value, while the 16-bit PauseID have to be guessed or tried. the SSRC value, while the 16-bit PauseID have to be guessed or tried.
The way of protecting the RTP session from these injections is to The way of protecting the RTP session from these injections is to
perform source authentication combined with message integrity, to perform source authentication combined with message integrity, to
prevent other than intended session participants from sending these prevent other than intended session participants from sending these
messages. There exist several different choices for securing RTP messages. The security solution should provide replay protection,
sessions to prevent this type of attack. SRTP is the the most otherwise an attacker could for sessions that are long lived enough
common, but also other methods exist as discussed in "Options for to wrap the PauseID replay old messages at the appropriate time to
Securing RTP Sessions" [RFC7201]. influence the media sender state. There exist several different
choices for securing RTP sessions to prevent this type of attack.
SRTP is the most common, but also other methods exist as discussed in
"Options for Securing RTP Sessions" [RFC7201].
Most of the methods for securing RTP however do not provide source Most of the methods for securing RTP however do not provide source
authentication of each individual participant in a multi-party use authentication of each individual participant in a multi-party use
case. In case one of the session participants is malicious, it can case. In case one of the session participants is malicious, it can
wreck significant havoc within the RTP session and similarly cause a wreck significant havoc within the RTP session and similarly cause a
DoS on the RTP session from within. That damage can also be DoS on the RTP session from within. That damage can also be
attempted to be obfuscated by having the attacker impersonate other attempted to be obfuscated by having the attacker impersonate other
endpoints within the session. These attacks can be mitigated by endpoints within the session. These attacks can be mitigated by
using a solution that provides true source authentication of all using a solution that provides true source authentication of all
participants' RTCP packets. However, that has other implications. participants' RTCP packets. However, that has other implications.
For multi-party sessions including a middlebox, that middlebox is For multi-party sessions including a middlebox, that middlebox is
RECOMMENDED to perform checks on all forwarded RTCP packets so that RECOMMENDED to perform checks on all forwarded RTCP packets so that
each participant only uses its set of SSRCs, to prevent the attacker each participant only uses its set of SSRCs, to prevent the attacker
utilizing another participant's SSRCs. utilizing another participant's SSRCs. An attacker that can send a
PAUSE request without it reaching any other participant than the
media sender can have its request being unopposed. This is mitigated
in multi-party topologies that ensure that requests are seen by all
or most of the RTP session participants, enabling these participants
to send RESUME. In topologies with middleboxes that consume and
process PAUSE requests, the middlebox can also mitigate such behavior
as it will commonly not generate or forward a PAUSE message if it
knows of another participant having use for the media stream.
The above text has been focused on using the PAUSE message as the The above text has been focused on using the PAUSE message as the
tool for malicious impact on the RTP session. That is because of the tool for malicious impact on the RTP session. That is because of the
greater impact from denying users access to RTP media streams. In greater impact from denying users access to RTP media streams. In
contrast, if an attacker attempts to use RESUME in a malicious contrast, if an attacker attempts to use RESUME in a malicious
purpose, it will result in that the media streams are delivered. purpose, it will result in that the media streams are delivered.
However, such an attack basically prevents the use the Pause and However, such an attack basically prevents the use the Pause and
Resume functionality. Thus, potentially forcing a reduction of the Resume functionality. Thus, potentially forcing a reduction of the
media quality due to limitation in available resources, like media quality due to limitation in available resources, like
bandwidth that must be shared. bandwidth that must be shared.
skipping to change at page 51, line 40 skipping to change at page 51, line 51
Daniel Grondal contributed in the creation and writing of early Daniel Grondal contributed in the creation and writing of early
versions of this specification. Christian Groves contributed versions of this specification. Christian Groves contributed
significantly to the SDP config attribute and its use in Offer/ significantly to the SDP config attribute and its use in Offer/
Answer. Answer.
14. Acknowledgements 14. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. The authors would also like to thank Emil versions of this draft. The authors would also like to thank Emil
Ivov, Christian Groves, Bernard Aboba, and Ben Campbell, who provided Ivov, Christian Groves, David Madnelberg, Meral Shirazipour, Spencer
valuable review comments. Dawkins, Bernard Aboba, and Ben Campbell, who provided valuable
review comments.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(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,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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,
DOI 10.17487/RFC6263, June 2011,
<http://www.rfc-editor.org/info/rfc6263>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-06 (work
in progress), February 2015. in progress), July 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-10 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015. July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-07 (work in progress), June avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-00 (work in progress), January 2015. mmusic-sdp-simulcast-01 (work in progress), July 2015.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326,
DOI 10.17487/RFC2326, April 1998,
<http://www.rfc-editor.org/info/rfc2326>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[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. DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
March 2015. DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>.
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 -07 and -08 A.1. Modifications Between Version -08 and -09
Changes based on IETF last call and IESG comments.
o Expanded some acronyms on first usage.
o Clarified why this document updated RFC 5104.
o Removed some unused abbreviations.
o Clarified when TMMBR/TMMBN is expected to be used in Section 5.6.
o Mandate using SHALL repetition of PAUSED indications in
Section 6.4.
o Removed paragraph in Section 8.4 on PauseID and REFUSED as being
redundant.
o Transmission rules in Section 8.5 was reworded and stoped using
RFC 2119 terms, instead uses recommendations and lists
motivations.
o In Section 9 (Signalling) it was clarified that one SHOULD only
send messages supported by receivers, but provide example of cases
when one may still send messages not supported by every receiver
of that message. Also clarified that TMMBR/TMMBN for pause is
monolithic in capability.
o Security consideration was updated to consider replay attacks.
o Security consideration was updated to describe the mitigation
against malicous RTP session participants in multi-party cases
that seeing all messages provide.
A.2. Modifications Between Version -07 and -08
Changes based on IESG AD Evaluation. Changes based on IESG AD Evaluation.
o Moved the mentioning of RTCWEB RFC7478 API requirements out from o Moved the mentioning of RTCWEB RFC7478 API requirements out from
3.1 to section 3, adding a couple of clarifying sentences. 3.1 to section 3, adding a couple of clarifying sentences.
o Highlighted that the use case in section 3.4 deals with a o Highlighted that the use case in section 3.4 deals with a
different direction of the pause request than the previous use different direction of the pause request than the previous use
cases. cases.
skipping to change at page 55, line 12 skipping to change at page 56, line 30
all received messages to all receivers, not only the first PAUSE all received messages to all receivers, not only the first PAUSE
message. message.
o Changed references to RFC3264 and RFC4566 to be normative. o Changed references to RFC3264 and RFC4566 to be normative.
o Updated ietf-rtcweb-use-cases-and-requirements reference to be o Updated ietf-rtcweb-use-cases-and-requirements reference to be
RFC7478. RFC7478.
o Editorial improvements and clarifications. o Editorial improvements and clarifications.
A.2. Modifications Between Version -06 and -07 A.3. Modifications Between Version -06 and -07
o Completely rewrote the Security Consideration section. o Completely rewrote the Security Consideration section.
o Aligned text such that REFUSED is always referred to as a o Aligned text such that REFUSED is always referred to as a
notification, not indication. notification, not indication.
o Added and changed text in several places, clarifying the case when o Added and changed text in several places, clarifying the case when
TMMBR/TMMBN bounding set overhead value matters, related to TMMBR/TMMBN bounding set overhead value matters, related to
whether local RTP stream sender or remote RTP stream receiver owns whether local RTP stream sender or remote RTP stream receiver owns
the TMMBR 0 restriction, and the consequences this has on pause/ the TMMBR 0 restriction, and the consequences this has on pause/
skipping to change at page 56, line 13 skipping to change at page 57, line 30
o Added SDP rules on how to handle unknown pause attribute values. o Added SDP rules on how to handle unknown pause attribute values.
o Clarified how to handle an SDP with both "ccm pause" and "ccm o Clarified how to handle an SDP with both "ccm pause" and "ccm
tmmbr". tmmbr".
o Changed from "Translator" to "Relay" in examples, to make it o Changed from "Translator" to "Relay" in examples, to make it
clearer in relation to the updated topologies draft. clearer in relation to the updated topologies draft.
o Editorial improvements. o Editorial improvements.
A.3. Modifications Between Version -05 and -06 A.4. 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 56, line 41 skipping to change at page 58, line 10
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.4. Modifications Between Version -04 and -05 A.5. 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.5. Modifications Between Version -03 and -04 A.6. Modifications Between Version -03 and -04
o Change of Copyright boilerplate o Change of Copyright boilerplate
A.6. Modifications Between Version -02 and -03 A.7. 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 57, line 35 skipping to change at page 59, line 5
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.7. Modifications Between Version -01 and -02 A.8. 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.8. Modifications Between Version -00 and -01 A.9. 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. 72 change blocks. 
151 lines changed or deleted 229 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/