draft-ietf-avtext-rtp-stream-pause-01.txt   draft-ietf-avtext-rtp-stream-pause-02.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 5, 2015 Huawei Technologies Expires: January 25, 2015 Huawei Technologies
M. Westerlund M. Westerlund
Ericsson Ericsson
July 4, 2014 July 24, 2014
RTP Stream Pause and Resume RTP Stream Pause and Resume
draft-ietf-avtext-rtp-stream-pause-01 draft-ietf-avtext-rtp-stream-pause-02
Abstract Abstract
With the increased popularity of real-time multimedia applications, With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback resume incoming data from a sender by sending real-time feedback
messages when using Real-time Transport Protocol (RTP) for real time messages when using Real-time Transport Protocol (RTP) for real time
data transport. This document extends the Codec Control Messages data transport. This document extends the Codec Control Messages
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on January 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9 3.4. Media Receiver to RTP Mixer . . . . . . . . . . . . . . . 9
3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10 3.5. Media Receiver to Media Sender Across RTP Mixer . . . . . 10
4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 10
4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10 4.1. Real-time Nature . . . . . . . . . . . . . . . . . . . . 10
4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11 4.2. Message Direction . . . . . . . . . . . . . . . . . . . . 11
4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11 4.3. Apply to Individual Sources . . . . . . . . . . . . . . . 11
4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Consensus . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 4.5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12 4.6. Retransmitting Requests . . . . . . . . . . . . . . . . . 12
4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12 4.7. Sequence Numbering . . . . . . . . . . . . . . . . . . . 12
5. Relation to Other Solutions . . . . . . . . . . . . . . . . . 12 4.8. Relation to Other Solutions . . . . . . . . . . . . . . . 12
5.1. Signaling Technology Performance Comparison . . . . . . . 12 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 13
5.2. CCM TMMBR / TMMBN . . . . . . . . . . . . . . . . . . . . 20 5.1. Expressing Capability . . . . . . . . . . . . . . . . . . 13
5.3. SDP "inactive" Attribute . . . . . . . . . . . . . . . . 21 5.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 14
5.4. Media Source Selection in SDP . . . . . . . . . . . . . . 21 5.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 15
5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 16
6. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 22 5.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 17
6.1. Expressing Capability . . . . . . . . . . . . . . . . . . 23 6. Participant States . . . . . . . . . . . . . . . . . . . . . 18
6.2. Requesting to Pause . . . . . . . . . . . . . . . . . . . 23 6.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Media Sender Pausing . . . . . . . . . . . . . . . . . . 25 6.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Requesting to Resume . . . . . . . . . . . . . . . . . . 26 6.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 19
6.5. TMMBR/TMMBN Considerations . . . . . . . . . . . . . . . 27 6.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 20
6.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 20
7. Participant States . . . . . . . . . . . . . . . . . . . . . 27 6.4. Local Paused State . . . . . . . . . . . . . . . . . . . 20
7.1. Playing State . . . . . . . . . . . . . . . . . . . . . . 28 7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Pausing State . . . . . . . . . . . . . . . . . . . . . . 28 8. Message Details . . . . . . . . . . . . . . . . . . . . . . . 23
7.3. Paused State . . . . . . . . . . . . . . . . . . . . . . 29 8.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3.1. RTCP BYE Message . . . . . . . . . . . . . . . . . . 29 8.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3.2. SSRC Time-out . . . . . . . . . . . . . . . . . . . . 29 8.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. Local Paused State . . . . . . . . . . . . . . . . . . . 30 8.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Message Format . . . . . . . . . . . . . . . . . . . . . . . 30 8.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 26
9. Message Details . . . . . . . . . . . . . . . . . . . . . . . 32 9. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 29
9.2. PAUSED . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.2. Declarative Use . . . . . . . . . . . . . . . . . . . . . 30
9.3. RESUME . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.4. REFUSE . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 31
9.5. Transmission Rules . . . . . . . . . . . . . . . . . . . 36 10.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 33
10. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 36
10.1. Offer-Answer Use . . . . . . . . . . . . . . . . . . . . 39 10.4. Point-to-Multipoint using Translator . . . . . . . . . . 38
10.2. Declarative Use . . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11.1. Offer-Answer . . . . . . . . . . . . . . . . . . . . . . 41 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42
11.2. Point-to-Point Session . . . . . . . . . . . . . . . . . 42 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
11.3. Point-to-Multipoint using Mixer . . . . . . . . . . . . 45 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.4. Point-to-Multipoint using Translator . . . . . . . . . . 47 15.1. Normative References . . . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 15.2. Informative References . . . . . . . . . . . . . . . . . 43
13. Security Considerations . . . . . . . . . . . . . . . . . . . 51 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 44
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 A.1. Modifications Between Version -01 and -02 . . . . . . . . 44
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 A.2. Modifications Between Version -00 and -01 . . . . . . . . 44
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
16.1. Normative References . . . . . . . . . . . . . . . . . . 51
16.2. Informative References . . . . . . . . . . . . . . . . . 52
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 54
A.1. Modifications Between Version -00 and -01 . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
As real-time communication attracts more people, more applications As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example. are created; multimedia conversation applications being one example.
Multimedia conversation further exists in many forms, for example, Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers. controlled by central media nodes, such as RTP Mixers.
Multimedia conferencing may involve many participants; each has its Multimedia conferencing may involve many participants; each has its
skipping to change at page 5, line 4 skipping to change at page 4, line 50
2. Definitions 2. Definitions
2.1. Abbreviations 2.1. Abbreviations
3GPP: 3rd Generation Partnership Project 3GPP: 3rd Generation Partnership Project
AVPF: Audio-Visual Profile with Feedback (RFC 4585) AVPF: Audio-Visual Profile with Feedback (RFC 4585)
BGW: Border Gateway BGW: Border Gateway
CCM: Codec Control Messages (RFC 5104)
CCM: Codec Control Messages (RFC 5104)
CNAME: Canonical Name (RTCP SDES) CNAME: Canonical Name (RTCP SDES)
CSRC: Contributing Source (RTP) CSRC: Contributing Source (RTP)
FB: Feedback (AVPF) FB: Feedback (AVPF)
FCI: Feedback Control Information (AVPF) FCI: Feedback Control Information (AVPF)
FIR: Full Intra Refresh (CCM) FIR: Full Intra Refresh (CCM)
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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
In addition to following, the definitions from RTP [RFC3550], AVPF In addition to the following, the definitions from RTP [RFC3550],
[RFC4585], CCM [RFC5104], and RTP Taxonomy AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy
[I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document. [I-D.ietf-avtext-rtp-grouping-taxonomy] also apply in this document.
Feedback Messages: CCM [RFC5104] categorized different RTCP feedback Feedback Messages: CCM [RFC5104] categorized different RTCP feedback
messages into four types, Request, Command, Indication and messages into four types, Request, Command, Indication and
Notification. This document places the PAUSE and RESUME messages Notification. This document places the PAUSE and RESUME messages
into Request category, PAUSED as Indication and REFUSE as into Request category, PAUSED as Indication and REFUSE 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
skipping to change at page 12, line 40 skipping to change at page 12, line 40
new PAUSE request is transmitted that is not a retransmission of a new PAUSE request is transmitted that is not a retransmission of a
previous request. previous request.
Since RESUME always takes precedence over PAUSE and are even allowed Since RESUME always takes precedence over PAUSE and are even allowed
to avoid pausing a stream, there is a need to keep strict ordering of to avoid pausing a stream, there is a need to keep strict ordering of
PAUSE and RESUME. Thus, RESUME needs to share sequence number space PAUSE and RESUME. Thus, RESUME needs to share sequence number space
with PAUSE and implicitly references which PAUSE it refers to. For with PAUSE and implicitly references which PAUSE it refers to. For
the same reasons, the explicit PAUSED indication also needs to share the same reasons, the explicit PAUSED indication also needs to share
sequence number space with PAUSE and RESUME. sequence number space with PAUSE and RESUME.
5. Relation to Other Solutions 4.8. Relation to Other Solutions
This section compares other possible solutions to achieve a similar
functionality, along with motivations why the current solution is
chosen.
5.1. Signaling Technology Performance Comparison
Editor's note: This section is related to the motivation for
selecting RTCP as signaling technology rather than SIP/SDP and
should be considered to be removed or at least significantly
reduced if and when this draft is adopted as a working group
draft, since there now seems to be consensus that RTCP is the
preferred technology.
This section contains what is thought to be a realistic estimate of
one-way data transmission times for signaling implementing
functionalities of this specification.
Two signaling protocols are compared. SIP is chosen to represent
signaling in the control plane and RTCP is chosen to represent
signaling in the media plane. For the sake of the comparison, each
of these two protocols are listed with one favorable and one
unfavorable condition to give the reader a hint of what range of
delays that can be expected. The favorable condition is chosen as
good as possible, while still realistic. The unfavorable condition
is also chosen to be realistically occurring, and is not the worst
possible or imaginable. Actual delays can in most cases be expected
to lie somewhere between those two values.
It would also be possible to include a signaling protocol using a
some dedicated signaling channel, separate from SIP and RTCP, into
the comparison. Such signaling protocol can be expected to show
performance somewhere in the range covered by the SIP and RTCP
comparison below. The protocol can either use UDP as transport, like
RTCP, or it can use TCP, like SIP, when the messages becomes too
large for the MTU. The data sent on such channel can either be text
based, in which case the amount of data can be similar to SIP, or it
can be binary, in which case the amount of data can be similar to
RTCP. Therefore, the dedicated signaling channel case is not
described further in this specification.
Two different access technologies are compared:
o Wired, fixed access is chosen as a representative low-delay
alternative.
o Mobile wireless access according to 3GPP LTE [TS36.201], also
known as "4G", is chosen as a representative high-delay
alternative.
NOTE: LTE is at the time of writing the most recent and best
performing mobile wireless access. If an earlier mobile wireless
access was to be used instead, the estimated transmission times would
be considerably increased. For example, it is estimated that using
3GPP HSPA [TS25.308] (evolved 3G, just previous to LTE) would
increase RTCP signaling times somewhat and significantly increase
signaling times for SIP, although those estimates are too preliminary
to provide any values here.
The target scenario includes two UA, residing in two different
provider's (operator's) network. Those networks are assumed to be
geographically close, that is no inter-continental transmission
delays are included in the estimates.
Three signaling alternatives are compared:
o Wireless UA to wireless UA, including two wireless links, uplink
and downlink.
o Wireless UA to media server (MCU), including a single wireless
uplink.
o Media server (MCU) to wireless UA, including a single wireless
downlink.
The reason to include separate results for wireless uplink and
downlink is that delay times can differ significantly.
The targeted topology is outlined in the following figure.
Provider A's network . Provider B's network
.
+-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+
|Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy|
+-----+ +------+ +-------+ . +-------+ +-----+
^ ^ . ^
| | SIP/H.248 . |
| v . |
SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP |
| | MCU |<---->| BGW A |<--.-->| BGW B | |
| +-----+ +-------+ . +-------+ |
v ^ . ^ v
+------+ / RTCP . \ RTCP +------+
| UA A |<---+ . +------>| UA B |
+------+ . +------+
Figure 4: Comparison Signaling Topology
In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS
is an Application Server, MCU is a Multipoint Conference Unit, SGW a
Signaling GateWay, and BGW a media Border GateWay.
It can be noted that when either one or both UAs use call forwarding
or have roamed into yet another provider's network, several more
signaling path nodes and a few more media path nodes could be
included in the end-to-end signaling path.
The MCU is assumed to be located in one of the provider's network.
Signaling delays between the MCU and a UA are presented as the
average of MCU and UA being located in the same and different
provider's networks.
These assumptions are used for SIP signaling:
o A SIP UPDATE is used within an established session to dynamically
impact individual streams to achieve the pause and resume
functionality. The offer and answer SDP contains one audio and
one video media, compliant with what is suggested in 3GPP MTSI
[TS26.114], with the addition of SDP feedback message indication
outlined in this specification (Section 10). A more complex media
session with more streams would significantly add to the SDP size.
o UDP is used as transport, except when risking to exceed MTU, in
which case TCP is used instead. This is evaluated on a per-
message basis.
o Only SIP forward direction is included in the delay estimate, that
is, delays needed to receive a response such as 200 OK are not
included.
o Favorable case:
* SIP SigComp [RFC5049] in dynamic mode is used for SIP and SDP
signaling on the mobile link, reducing the SIP message size to
approximately 1/3 of the original size.
o Unfavorable case:
* SIP message is not compressed on the mobile link.
* SIP signaling on the mobile link uses a dedicated mobile
wireless access radio channel that was idle for some time, has
entered low power state and thus has to be re-established by
radio layer signaling before any data can be sent.
These assumptions are used for RTCP signaling:
o A minimal compound RTCP feedback packet is used, including one SR
and one SDES with only the CNAME item present, with the addition
of the feedback message outlined in Section 8.
o RTCP bandwidth is chosen based on a 200 kbit/s session, which is
considered to be a low bandwidth for media that would be worth
pausing, and using the default 5% of this for RTCP traffic results
in 10 kbit/s. This low bandwidth makes RTCP scheduling delays be
a significant factor in the unfavorable case.
o Since there are random delay factors in RTCP transmission, the
expected, most probable value is used in the estimates.
o The mobile wireless access channel used for RTCP will always be
active, that is there will be sufficient data to send at any time
such that the radio channel will never have to be re-established.
This is considered reasonable since it is assumed that the same
channel is not only used for the messages defined in this
specification, but also for other RTP and RTCP data.
o Favorable case:
* It is assumed that AVPF Early or Immediate mode can always be
used for the signaling described in this specification, since
such signaling will be small in size and only occur
occasionally in RTCP time scale.
* Early mode does not use dithering of send times (T_dither_max
is set to 0), that is, sender and receiver of the message are
connected point-to-point. It can be noted that in case of a
multiparty session where multiple End Points can see each
others' messages, and unless the number of End Points is very
large, it is very unlikely that more than a single End Point
has the desire to send the same message (defined in this
specification) as another End Point, and at almost exactly the
same time. It is therefore arguably not very meaningful for
messages in this specification to try to do feedback
suppression by using a non-zero T_dither_max, even in
multiparty sessions, but AVPF does not allow for any exemption
from that rule.
* Reduced-size RTCP is used, which is considered appropriate for
the type of messages defined in this specification.
* RTP/RTCP header compression [RFC5225] is not used, not even on
the mobile link.
o Unfavorable case:
* The expected, regular AVPF RTCP interval is used, including an
expected value for timer re-consideration.
* A full, not reduced-size, minimal compound RTCP feedback packet
without header compression is always used. No reduction of
scheduling delays from the use of reduced-size RTCP is included
in the evaluation, since that would also require a reasonable
estimate of the mix of compound and non-compound RTCP, which
was considered too difficult for this study. The given
unfavorable delays are thus an over-estimate compared to a more
realistic case.
Common to both SIP and RTCP signaling estimates is that no UA
processing delays are included. The reason for that decision is that
processing delays are highly implementation and UA dependent. It is
expected that wireless UA will be more limited than fixed UA by
processing, but they are also constantly and quickly improving so any
estimate will very quickly be outdated. More realistic estimates
will however have to add such delays, which can be expected to be in
the order of a few to a few tens of milliseconds. It is expected
that SIP will be more penalized than RTCP by including processing
delays, since it has larger and more complex messages. The
processing may also include SigComp [RFC5049] compression and
decompression in the favorable cases.
As a partial result, the message sizes can be compared, based on the
messages defined in this specification (Section 8) and a SIP UPDATE
with contents (Section 10) as discussed above. Favorable and
unfavorable message sizes are presented as stacked bars in the figure
below. Message sizes include IPv4 headers but no lower layer data,
are rounded to the nearest 25 bytes, and the bars are to scale.
250 500 750 1000 1250 1500 [byte]
+---------+---------+---------+---------+---------+---------+--> Size
|
+-+--+
| |50| 125 RTCP
+-+--+---------------+--------------------------------------------+
| SIP | 525 1650 |
+--------------------+--------------------------------------------+
|
Figure 5: Message Size Comparison
The signaling delay results of the study are summarized in the
following two figures. Favorable and unfavorable values are
presented as stacked bars. Since there are many factors that impact
the calculations, including some random processes, there are
uncertainty in the calculations and delay values are thus rounded to
nearest 5 ms. The bars are to scale.
50 100 150 200 250 300 [ms]
+---------+---------+---------+---------+---------+---------+---> t
|
| Wireless UA to Wireless UA
+---------------------+--------------------------------------+
| SIP | 110 | 305
+-----+---------------+-----------------------------+--------+
|RTCP | 30 | 260
+-----+---------------------------------------------+
|
| Wireless UA to MCU
+-------------+--+
| SIP |70| 85
+----+--------+--+--------------------------+
|RTCP| 25 | 225
+----+--------------------------------------+
|
| MCU to Wireless UA
+--------------+-----------------------------------+
| SIP | 75 | 255
+---+----------+------------------------------+----+
| | 20 RTCP | 230
+---+-----------------------------------------+
|
Figure 6: Mobile Access Transmission Delay Comparison
As can be seen, RTCP has a smaller signaling delay than SIP in a
majority of cases for this mobile access. Non-favorable RTCP is
however always worse than favorable SIP.
The UA to MCU signaling corresponds to the use case in Section 3.4.
The reason that unfavorable SIP is more beneficial than unfavorable
RTCP in this case comes from the fact that latency is fairly short to
re-establish an uplink radio channel (as was assumed needed for
unfavorable SIP), while unfavorable RTCP does not benefit from this
since the delay is mainly due to RTCP Scheduling.
The MCU to UA signaling corresponds to the use case in Section 3.2.
It has an unfavorable SIP signaling case with much longer delay than
UA to MCU above, because the mixer cannot re-establish a downlink
radio channel as quickly as the UA can establish an uplink. This
case is applicable when an MCU wants to resume a paused stream, which
is likely the most delay sensitive functionality, as discussed in
Section 4.1.
Below are the same cases for fixed access depicted. Although delays
are generally shorter, scales are kept the same for easy comparison
with the previous figure.
50 100 150 200 250 300 [ms]
+---------+---------+---------+---------+---------+---------+---> t
|
| Fixed UA to Fixed UA
+------------+
| SIP | 65
+----+-------+---------------------------+
|RTCP| 25 | 205
+----+-----------------------------------+
|
| Fixed UA to MCU
+---------+
| SIP | 50
+---+-----+-----------------------+
| | 15 RTCP | 200
+---+-----------------------------+
|
| MCU to Fixed UA
+---------+
| SIP | 50
+---+-----+-----------------------+
| | 15 RTCP | 200
+---+-----------------------------+
|
Figure 7: Fixed Access Transmission Delay Comparison
For fixed access, favorable RTCP is still significantly better than
SIP, but unfavorable RTCP is significantly worse than SIP. There is
no difference between favorable and unfavorable SIP, since in fixed
access there is no channel that needs to be re-established.
Regarding the unfavorable values above, it should be possible with
reasonable effort to design UA and network nodes that show favorable
delays in a majority of cases.
For SIP, the major delays in the unfavorable cases above comes from
re-establishing a radio bearer that has entered low power state due
to inactivity, and large size SIP messages. The inactivity problem
can be removed by using for example SIP keep-alive [RFC5626], at the
cost of reduced battery life to keep the signaling radio bearer
active, and some very minimal amount of extra data transmission. The
large SIP messages can to some extent be reduced by SIP SigComp
[RFC5049]. It may however prove harder to reduce delays that comes
from forwarding the SDP many times between different signaling nodes.
For RTCP, the major delays comes from low RTCP bandwidth and not
being able to use Immediate or Early mode, including use of timer re-
consideration. UAs and network nodes can explicitly allocate an
appropriate amount of RTCP bandwidth through use of the b=RS and b=RR
RTCP bandwidth SDP attributes [RFC3556]. For RTP streams of higher
bandwidth than the 200 kbit/s used in this comparison, which will be
even more interesting to pause, RTCP bandwidth will per default also
be higher, significantly reducing the signaling delays. For example,
using a 1000 kbit/s stream instead of a 200 kbit/s stream will reduce
the unfavorable RTCP delays from 260 ms to 115 ms for Wireless-
Wireless, from 225 ms to 80 ms for Wireless-MCU, and from 230 ms to
80 ms for MCU-Wireless.
5.2. CCM TMMBR / TMMBN
The Codec Control Messages specification [RFC5104] contains two
messages, Temporary Maximum Media Bitrate Request (TMMBR) and
Temporary Maximum Media Bitrate Notification (TMMBN), which could
provide some of the necessary functionality. TMMBR with a bitrate
value of 0 could effectively constitute a PAUSE request and TMMBN 0
could effectively be a PAUSED indication, and there are already
implementations making use of TMMBR 0 in this way. It is possible to
signal per SSRC (Section 4.3) and using the media path for signaling
(AVPF) [RFC4585] will in most cases provide the shortest achievable
signaling delay (Section 4.1). However, in some cases the defined
semantics for TMMBR differ from what is required for PAUSE.
When there is only a single receiver of a stream, TMMBR 0 and PAUSE
are effectively identical.
When there are several receivers of the same stream, the stream must
not be paused until there are no receiver that desires to receive it
(Section 4.4), for example there is no disapproving RESUME for a
PAUSE. In the presence of several simultaneous receivers, the TMMBR
semantics is the opposite; the first RTP stream receiver that sends
TMMBR 0 will pause the stream for all receivers.
When there is only a single receiver of a stream that is paused,
TMMBR with a bitrate greater than 0 can effectively function as a
RESUME, resuming the stream immediately as needed (Section 4.4).
For the case of multiple simultaneous receivers, TMMBR specifies to
use a guard period when increasing the bandwidth. In this case,
TMMBR/TMMBN semantics (Section 4.2.1.2 of [RFC5104]) requires an RTP
stream sender to wait 2*RTT+T_dither_max after having sent a TMMBN,
indicating the intention to increase the bandwidth, before it
actually increases its bandwidth usage. The RTT is specified to be
the longest the RTP stream sender knows in the RTP session. So,
there is both the delay between the RTP stream sender receiving the
TMMBR until it can send a TMMBN, and the above delay for the guard
period before the RTP stream sender is allowed to resume
transmission. This delay before resuming transmission is the most
time critical operation in this solution, making use of TMMBR as
RESUME according to the defined semantics infeasible in practice when
there are multiple simultaneous stream receivers.
5.3. SDP "inactive" Attribute
In SDP [RFC4566], an "inactive" attribute is defined on media level
and session level. The attribute is intended to be used to put media
"on hold", either at the beginning of a session or as a result of
session re-negotiation [RFC3264], for example using SIP re-INVITE
[RFC3261], possibly in combination with ITU-T H.248 media gateway
control.
This attribute is only possible to specify with media level
resolution, is not possible to signal per individual stream (SSRC)
(Section 4.3), and is thus not usable for RTP sessions containing
more than a single SSRC.
There is a per-ssrc attribute defined in [RFC5576], but that does
currently not allow to set an individual stream (SSRC) inactive.
Using "inactive" does thus not provide sufficient functionality for
the purpose of this specification.
5.4. Media Source Selection in SDP
There is a draft that selects sources based on SDP
[I-D.lennox-mmusic-sdp-source-selection] information. It builds on
the per-ssrc attribute [RFC5576] discussed above (Section 5.3).
The semantics differ between selecting a media source and pause /
resume for a stream in topologies other than point-to-point. For
example, in RTP Receiver to Mixer (Section 3.4), pausing a stream
(SSRC) from the mixer should stop it being received altogether, while
excluding a stream (CSRC) from the mix would just avoid that specific
media source being included in the stream from the mixer. There is a
similar difference between resuming a stream (SSRC) from the mixer
and allowing a media source (CSRC) to be included in the mix again.
This suffers from a lack of functionality for consensus (Section 4.4)
and would likely also suffer from lower real-time performance
(Section 4.1).
5.5. Conclusion
As can be seen from Section 5.1, using SIP and SDP to carry pause and
resume information means that it will need to traverse the entire
signaling path to reach the signaling destination (either the remote
End Point or the entity controlling the RTP Mixer), across any
signaling proxies that potentially also has to process the SDP
content to determine if they are expected to act on it. The amount
of bandwidth required for a SIP/SDP-based signaling solution is in
the order of at least 10 times more than an RTCP-based solution.
Especially for UA sitting on mobile wireless access, this will risk
introducing delays that are too long (Section 4.1) to provide a good
user experience, and the bandwidth cost may also be considered
infeasible compared to an RTCP-based solution.
As seen in the same section, the RTCP data is sent through the media
path, which is likely shorter (contains fewer intermediate nodes)
than the signaling path but may anyway have to traverse a few
intermediate nodes. The amount of processing and buffering required
in intermediate nodes to forward those RTCP messages is however
believed to be significantly less than for intermediate nodes in the
signaling path.
Based on those reasons, RTCP is proposed as signaling protocol for A performance comparison between SIP/SDP and RTCP signaling
the pause and resume functionality. Much of the wanted functionality technologies was made and included in draft versions of this
can in a point-to-point case be achieved with the existing TMMBR/ specification. Using SIP and SDP [RFC4566] to carry pause and resume
TMMBN CCM messages [RFC5104], but they cannot be used when the stream information means that it will need to traverse the entire signaling
is sent to multiple simultaneous receivers. path to reach the signaling destination (either the remote End Point
or the entity controlling the RTP Mixer), across any signaling
proxies that potentially also has to process the SDP content to
determine if they are expected to act on it. The amount of bandwidth
required for a SIP/SDP-based signaling solution is in the order of at
least 10 times more than an RTCP-based solution. Especially for UA
sitting on mobile wireless access, this will risk introducing delays
that are too long (Section 4.1) to provide a good user experience,
and the bandwidth cost may also be considered infeasible compared to
an RTCP-based solution. RTCP data is sent through the media path,
which is likely shorter (contains fewer intermediate nodes) than the
signaling path, may anyway have to traverse a few intermediate nodes.
The amount of processing and buffering required in intermediate nodes
to forward those RTCP messages is however believed to be
significantly less than for intermediate nodes in the signaling path.
Based on those considerations, RTCP is chosen as signaling protocol
for the pause and resume functionality.
6. Solution Overview 5. Solution Overview
The proposed solution implements PAUSE and RESUME functionality based The proposed solution implements PAUSE and RESUME functionality based
on sending AVPF RTCP feedback messages from any RTP session on sending AVPF RTCP feedback messages from any RTP session
participant that wants to pause or resume a stream targeted at the participant that wants to pause or resume a stream targeted at the
stream sender, as identified by the sender SSRC. stream sender, as identified by the sender SSRC.
It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent It is proposed to re-use CCM TMMBR and TMMBN [RFC5104] to the extent
possible, and to define a small set of new RTCP feedback messages possible, and to define a small set of new RTCP feedback messages
where new semantics is needed. Considerations that apply when using where new semantics is needed. Considerations that apply when using
TMMBR/TMMBN for pause and resume purposes are also described. TMMBR/TMMBN for pause and resume purposes are also described.
skipping to change at page 23, line 14 skipping to change at page 13, line 43
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.
This section is intended to be explanatory and therefore This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification. instead be found in other parts of this specification.
6.1. Expressing Capability 5.1. Expressing Capability
An End Point can use an extension to CCM SDP signaling to declare An End Point can use an extension to CCM SDP signaling to declare
capability to understand the messages defined in this specification. capability to understand the messages defined in this specification.
Capability to understand PAUSED indication is defined separately from Capability to understand PAUSED indication is defined separately from
the others to support partial implementation, which is specifically the others to support partial implementation, which is specifically
believed to be feasible for the RTP Mixer to Media Sender use case believed to be feasible for the RTP Mixer to Media Sender use case
(Section 3.2). (Section 3.2).
For the case when TMMBR/TMMBN are used for pause and resume purposes, For the case when TMMBR/TMMBN are used for pause and resume purposes,
it is possible to explicitly express joint support for TMMBR and it is possible to explicitly express joint support for TMMBR and
TMMBN, but not for TMMBN only. TMMBN, but not for TMMBN only.
6.2. Requesting to Pause 5.2. Requesting to Pause
An RTP stream receiver can choose to request PAUSE at any time, An RTP stream receiver can choose to request PAUSE at any time,
subject to AVPF timing rules. This also applies when using TMMBR 0 subject to AVPF timing rules. This also applies when using TMMBR 0
in the point-to-point case. in the point-to-point case.
The PAUSE request contains a PauseID, which is incremented by one (in The PAUSE request contains a PauseID, which is incremented by one (in
modulo arithmetic) with each PAUSE request that is not a re- modulo arithmetic) with each PAUSE request that is not a re-
transmission. The PauseID is scoped by and thus a property of the transmission. The PauseID is scoped by and thus a property of the
targeted RTP stream (SSRC). targeted RTP stream (SSRC).
When a non-paused RTP stream sender receives the PAUSE request, it When a non-paused RTP stream sender receives the PAUSE request, it
continues to send the RTP stream while waiting for some time to allow continues to send the RTP stream while waiting for some time to allow
other RTP stream receivers in the same RTP session that saw this other RTP stream receivers in the same RTP session that saw this
PAUSE request to disapprove by sending a RESUME (Section 6.4) for the PAUSE request to disapprove by sending a RESUME (Section 5.4) for the
same stream and with the same PauseID as in the disapproved PAUSE. same stream and with the same PauseID as in the disapproved PAUSE.
If such disapproving RESUME arrives at the RTP stream sender during If such disapproving RESUME arrives at the RTP stream sender during
the wait period before the stream is paused, the pause is not the wait period before the stream is paused, the pause is not
performed. In point-to-point configurations, the wait period may be performed. In point-to-point configurations, the wait period may be
set to zero. Using a wait period of zero is also appropriate when set to zero. Using a wait period of zero is also appropriate when
using TMMBR 0 and in line with the semantics for that message. using TMMBR 0 and in line with the semantics for that message.
If the RTP stream sender receives further PAUSE requests with the If the RTP stream sender receives further PAUSE requests with the
available PauseID while waiting as described above, those additional available PauseID while waiting as described above, those additional
requests are ignored. requests are ignored.
If the PAUSE request or TMMBR 0 is lost before it reaches the RTP If the PAUSE request or TMMBR 0 is lost before it reaches the RTP
stream sender, it will be discovered by the RTP stream receiver stream sender, it will be discovered by the RTP stream receiver
because it continues to receive the RTP stream. It will also not see because it continues to receive the RTP stream. It will also not see
any PAUSED indication (Section 6.3) or TMMBN 0 for the stream. The any PAUSED indication (Section 5.3) or TMMBN 0 for the stream. The
same condition can be caused by the RTP stream sender having received same condition can be caused by the RTP stream sender having received
a disapproving RESUME from a stream receiver A for a PAUSE request a disapproving RESUME from a stream receiver A for a PAUSE request
sent by a stream sender B, but that the PAUSE sender (B) did not sent by a stream sender B, but that the PAUSE sender (B) did not
receive the RESUME (from A) and may instead think that the PAUSE was receive the RESUME (from A) and may instead think that the PAUSE was
lost. In both cases, a PAUSE request can be re-transmitted using the lost. In both cases, a PAUSE request can be re-transmitted using the
same PauseID. If using TMMBR 0 the request MAY be re-transmitted same PauseID. If using TMMBR 0 the request MAY be re-transmitted
when the requester fails to receive a TMMBN 0 confirmation. when the requester fails to 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
skipping to change at page 25, line 5 skipping to change at page 15, line 37
the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN
SHALL contain the current bounding set, and the fact that a TMMBR 0 SHALL contain the current bounding set, and the fact that a TMMBR 0
will always be the most restrictive point in any bounding set. will always be the most restrictive point in any bounding set.
If the RTP stream sender receives several identical PAUSE for an RTP If the RTP stream sender receives several identical PAUSE for an RTP
stream that was already at least once responded with REFUSE and the stream that was already at least once responded with REFUSE and the
condition causing REFUSE remains, those additional REFUSE should be condition causing REFUSE remains, those additional REFUSE should be
sent with regular RTCP timing. A single REFUSE can respond to sent with regular RTCP timing. A single REFUSE can respond to
several identical PAUSE requests. several identical PAUSE requests.
6.3. Media Sender Pausing 5.3. Media Sender Pausing
An RTP stream sender can choose to pause the stream at any time. An RTP stream sender can choose to pause the stream at any time.
This can either be as a result of receiving a PAUSE, or be based on This can either be as a result of receiving a PAUSE, or be based on
some local sender consideration. When it does, it sends a PAUSED some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. If the stream was indication, containing the available PauseID. If the stream was
paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication. What is
said on PAUSED in the rest of this paragraph apply also to the use of said on PAUSED in the rest of this paragraph apply also to the use of
TMMBN 0, except for PAUSED message parameters. Note that PauseID is TMMBN 0, except for PAUSED message parameters. Note that PauseID is
incremented when pausing locally (without having received a PAUSE). incremented when pausing locally (without having received a PAUSE).
It also sends the PAUSED indication in the next two regular RTCP It also sends the PAUSED indication in the next two regular RTCP
skipping to change at page 26, line 5 skipping to change at page 16, line 33
PauseID is to be able to construct valid PAUSE and RESUME requests at PauseID is to be able to construct valid PAUSE and RESUME requests at
a later stage. a later stage.
When the RTP stream sender learns that a new End Point has joined the When the RTP stream sender learns that a new End Point has joined the
RTP session, for example by a new SSRC and a CNAME that was not RTP session, for example by a new SSRC and a CNAME that was not
previously seen in the RTP session, it should send PAUSED indications previously seen in the RTP session, it should send PAUSED indications
for all its paused streams at its earliest opportunity. It should in for all its paused streams at its earliest opportunity. It should in
addition continue to include PAUSED indications in at least two addition continue to include PAUSED indications in at least two
regular RTCP reports. regular RTCP reports.
6.4. Requesting to Resume 5.4. Requesting to Resume
An RTP stream receiver can request to resume a stream with a RESUME An RTP stream receiver can request to resume a stream with a RESUME
request at any time, subject to AVPF timing rules. If the stream was request at any time, subject to AVPF timing rules. If the stream was
paused with TMMBR 0, resuming the stream is made with TMMBR paused with TMMBR 0, resuming the stream is made with TMMBR
containing a bitrate value larger than 0. The bitrate value used containing a bitrate value larger than 0. The bitrate value used
when resuming after a PAUSE with TMMBR 0 is either according to known when resuming after a PAUSE with TMMBR 0 is either according to known
limitations, or the configured maximum for the stream or session. limitations, or the configured maximum for the stream or session.
What is said on RESUME in the rest of this paragraph apply also to What is said on RESUME in the rest of this paragraph apply also to
the use of TMMBR with a bitrate value larger than 0, except for the use of TMMBR with a bitrate value larger than 0, except for
RESUME message parameters. RESUME message parameters.
skipping to change at page 27, line 10 skipping to change at page 17, line 39
temporal dependency is not used when the RTP stream is resumed, the temporal dependency is not used when the RTP stream is resumed, the
first encoded sample after the pause will not contain any temporal first encoded sample after the pause will not contain any temporal
dependency to samples before the pause (for video it may be a so- dependency to samples before the pause (for video it may be a so-
called intra picture). If temporal dependency to before the pause is called intra picture). If temporal dependency to before the pause is
used by the RTP stream sender when resuming, and if the RTP stream used by the RTP stream sender when resuming, and if the RTP stream
receiver did not save any sample from before the pause, the RTP receiver did not save any sample from before the pause, the RTP
stream receiver can use a FIR request [RFC5104] to explicitly ask for stream receiver can use a FIR request [RFC5104] to explicitly ask for
a sample without temporal dependency (for video a so-called intra a sample without temporal dependency (for video a so-called intra
picture), even at the same time as sending the RESUME. picture), even at the same time as sending the RESUME.
6.5. TMMBR/TMMBN Considerations 5.5. TMMBR/TMMBN Considerations
As stated, TMMBR/TMMBN may be used to provide pause and resume As stated, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or point-to-point, TMMBR/TMMBN cannot safely be used for pause or
resume. resume.
This is a brief summary of what functionality is provided when using This is a brief summary of what functionality is provided when using
TMMBR/TMMBN: TMMBR/TMMBN:
TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- TMMBR 0: Corresponds to PAUSE, without the requirement for any hold-
skipping to change at page 27, line 35 skipping to change at page 18, line 17
receiver, there is no need for the RTP stream sender to delay receiver, there is no need for the RTP stream sender to delay
resuming the stream until after sending TMMBN >0, or to apply the resuming the stream until after sending TMMBN >0, or to apply the
hold-off period specified in [RFC5104] before increasing the hold-off period specified in [RFC5104] before increasing the
bitrate from zero. bitrate from zero.
TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE TMMBN 0: Corresponds to PAUSED. Also corresponds to a REFUSE
indication when a stream is requested to be resumed with TMMBR >0. indication when a stream is requested to be resumed with TMMBR >0.
TMMBN >0: Cannot be used as REFUSE indication when a stream is TMMBN >0: Cannot be used as REFUSE indication when a stream is
requested to be paused with TMMBR 0, for reasons stated in requested to be paused with TMMBR 0, for reasons stated in
Section 6.2. Section 5.2.
7. Participant States 6. Participant States
This document introduces three new states for a stream in an RTP This document introduces three new states for a stream in an RTP
sender, according to the figure and sub-sections below. Any sender, according to the figure and sub-sections below. Any
references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL
be taken to apply to the extent possible also when TMMBR/TMMBN are be taken to apply to the extent possible also when TMMBR/TMMBN are
used (Section 6.5) for this functionality. used (Section 5.5) for this functionality.
+------------------------------------------------------+ +------------------------------------------------------+
| Received RESUME | | Received RESUME |
v | v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+ +---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused | | Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | | | |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+ +---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision | ^ | | PAUSE decision |
| | v | | | v |
| | PAUSE decision +---------+ PAUSE decision | | | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+ | +------------------>| Local |<--------------------+
+-------------------------| Paused | +-------------------------| Paused |
RESUME decision +---------+ RESUME decision +---------+
Figure 8: RTP Pause States Figure 4: RTP Pause States
7.1. Playing State 6.1. Playing State
This state is not new, but is the normal media sending state from This state is not new, but is the normal media sending state from
[RFC3550]. When entering the state, the PauseID MUST be incremented [RFC3550]. When entering the state, the PauseID MUST be incremented
by one in modulo arithmetic. The RTP sequence number for the first by one in modulo arithmetic. The RTP sequence number for the first
packet sent after a pause SHALL be incremented by one compared to the packet sent after a pause SHALL be incremented by one compared to the
highest RTP sequence number sent before the pause. The first RTP highest RTP sequence number sent before the pause. The first RTP
Time Stamp for the first packet sent after a pause SHOULD be set Time Stamp for the first packet sent after a pause SHOULD be set
according to capture times at the source. according to capture times at the source.
7.2. Pausing State 6.2. Pausing State
In this state, the RTP stream sender has received at least one PAUSE In this state, the RTP stream sender has received at least one PAUSE
message for the stream in question. The RTP stream sender SHALL wait message for the stream in question. The RTP stream sender SHALL wait
during a hold-off period for the possible reception of RESUME during a hold-off period for the possible reception of RESUME
messages for the RTP stream being paused before actually pausing RTP messages for the RTP stream being paused before actually pausing RTP
stream transmission. The period to wait SHALL be long enough to stream transmission. The period to wait SHALL be long enough to
allow another RTP stream receiver to respond to the PAUSE with a allow another RTP stream receiver to respond to the PAUSE with a
RESUME, if it determines that it would not like to see the stream RESUME, if it determines that it would not like to see the stream
paused. This delay period (denoted by 'Hold-off period' in the paused. This delay period (denoted by 'Hold-off period' in the
figure) is determined by the formula: figure) is determined by the formula:
2 * RTT + T_dither_max, 2 * RTT + T_dither_max,
where RTT is the longest round trip known to the 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 10) 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, for example by RTCP RR,
it MUST change the hold-off to instead be based on the above formula. it MUST change the hold-off to instead be based on the above formula.
7.3. Paused State 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.
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.
Following sub-sections discusses some potential issues when an RTP Following sub-sections discusses some potential issues when an RTP
sender goes into paused state. These conditions are also valid if an sender goes into paused state. These conditions are also valid if an
RTP Translator is used in the communication. When an RTP Mixer RTP Translator is used in the communication. When an RTP Mixer
implementing this specification is involved between the participants implementing this specification is involved between the participants
(which forwards the stream by marking the RTP data with its own (which forwards the stream by marking the RTP data with its own
SSRC), it SHALL be a responsibility of the Mixer to control sending SSRC), it SHALL be a responsibility of the Mixer to control sending
PAUSE and RESUME requests to the sender. The below conditions also PAUSE and RESUME requests to the sender. The below conditions also
apply to the sender and receiver parts of the RTP Mixer, apply to the sender and receiver parts of the RTP Mixer,
respectively. respectively.
7.3.1. RTCP BYE Message 6.3.1. RTCP BYE Message
When a participant leaves the RTP session, it sends an RTCP BYE When a participant leaves the RTP session, it sends an RTCP BYE
message. In addition to the semantics described in section 6.3.4 and message. In addition to the semantics described in section 6.3.4 and
6.3.7 of RTP [RFC3550], following two conditions MUST also be 6.3.7 of RTP [RFC3550], following two conditions MUST also be
considered when an RTP participant sends an RTCP BYE message, considered when an RTP participant sends an RTCP BYE message,
o If a paused sender sends an RTCP BYE message, receivers observing o If a paused sender sends an RTCP BYE message, receivers observing
this SHALL NOT send further PAUSE or RESUME requests to it. this SHALL NOT send further PAUSE or RESUME requests to it.
o Since a sender pauses its transmission on receiving the PAUSE o Since a sender pauses its transmission on receiving the PAUSE
requests from any receiver in a session, the sender MUST keep requests from any receiver in a session, the sender MUST keep
record of which receiver that caused the RTP stream to pause. If record of which receiver that caused the RTP stream to pause. If
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.
7.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 SHALL be
resumed. resumed.
7.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 7.3), the RTP the RTP stream sender. As for Paused State (Section 6.3), the RTP
stream sender SHALL send a PAUSED indication to all known RTP stream stream sender SHALL send a PAUSED indication to all known RTP stream
receivers, when entering the state, and repeat it in the next two receivers, when entering the state, and repeat it in the next two
regular RTCP reports. regular RTCP reports.
When leaving the state, the stream state SHALL become Playing, When leaving the state, the stream state SHALL become Playing,
regardless whether or not there were any RTP stream receivers that regardless whether or not there were any RTP stream receivers that
sent PAUSE for that stream, effectively clearing the RTP stream sent PAUSE for that stream, effectively clearing the RTP stream
sender's memory for that stream. sender's memory for that stream.
8. Message Format 7. Message Format
Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP
feedback messages, i.e. Transport layer, Payload-specific, and feedback messages, i.e. Transport layer, Payload-specific, and
Application layer feedback messages. This document defines a new Application layer feedback messages. This document defines a new
Transport layer feedback message, this message is either a PAUSE Transport layer feedback message, this message is either a PAUSE
request, a RESUME request, or one of four different types of request, a RESUME request, or one of four different types of
acknowledgments in response to either PAUSE or RESUME requests. acknowledgments in response to either PAUSE or RESUME requests.
The Transport layer feedback messages are identified by having the The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. The
skipping to change at page 31, line 37 skipping to change at page 22, line 15
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC | | Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID | | Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific : : Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Syntax of FCI Entry in the PAUSE and RESUME message Figure 5: Syntax of FCI Entry in the PAUSE and RESUME message
The FCI fields have the following definitions: The FCI fields have the following definitions:
Target SSRC (32 bits): For a PAUSE and RESUME messages, this value Target SSRC (32 bits): For a PAUSE and RESUME messages, this value
is the SSRC that the request is intended for. For PAUSED, it MUST is the SSRC that the request is intended for. For PAUSED, it MUST
be the SSRC being paused. If pausing is the result of a PAUSE be the SSRC being paused. If pausing is the result of a PAUSE
request, the value in PAUSED is effectively the same as Target request, the value in PAUSED is effectively the same as Target
SSRC in a related PAUSE request. For REFUSE, it MUST be the SSRC in a related PAUSE request. For REFUSE, it MUST be the
Target SSRC of the PAUSE or RESUME request that cannot change Target SSRC of the PAUSE or RESUME request that cannot change
state. A CSRC MUST NOT be used as a target as the interpretation state. A CSRC MUST NOT be used as a target as the interpretation
skipping to change at page 32, line 31 skipping to change at page 23, line 10
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.
9. Message Details 8. Message Details
This section contains detailed explanations of each message defined This section contains detailed explanations of each message defined
in this specification. All transmissions of request and indications in this specification. All transmissions of request and indications
are governed by the transmission rules as defined by Section 9.5. are governed by the transmission rules as defined by Section 8.5.
Any references to PAUSE, PAUSED, RESUME and REFUSE in this section Any references to PAUSE, PAUSED, RESUME and REFUSE 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 6.5) for this functionality. TMMBR/TMMBN MAY be are used (Section 5.5) for this functionality. TMMBR/TMMBN MAY be
used instead of the messages defined in this specification when the used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver effective topology is point-to-point. If either sender or receiver
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
be used for pause/resume functionality. If the messages defined in be used for pause/resume functionality. If the messages defined in
this specification are supported in addition to TMMBR/TMMBN, pause/ this specification are supported in addition to TMMBR/TMMBN, pause/
resume signaling MUST revert to use those instead. If the topology resume signaling MUST revert to use those instead. If the topology
is not point-to-point and the messages defined in this specification is not point-to-point and the messages defined in this specification
are not supported, pause/resume functionality with TMMBR/TMMBN MUST are not supported, pause/resume functionality with TMMBR/TMMBN MUST
NOT be used. NOT be used.
9.1. PAUSE 8.1. PAUSE
An RTP stream receiver MAY schedule PAUSE for transmission at any An RTP stream receiver MAY schedule PAUSE for transmission at any
time. time.
PAUSE has no defined Type Specific parameters and Parameter Len MUST PAUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
PauseID SHOULD be the available PauseID, as indicated by PAUSED PauseID SHOULD be the available PauseID, as indicated by PAUSED
(Section 9.2) or implicitly determined by previously received PAUSE (Section 8.2) or implicitly determined by previously received PAUSE
or RESUME (Section 9.3) requests. A randomly chosen PauseID MAY be or RESUME (Section 8.3) requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve PauseID information, in which used if it was not possible to retrieve PauseID information, in which
case the PAUSE will either succeed, or the correct PauseID can be case the PAUSE will either succeed, or the correct PauseID can be
found in the returned REFUSE (Section 9.4). A PauseID that is found in the returned REFUSE (Section 8.4). A PauseID that is
matching the available PauseID is henceforth also called a valid matching the available PauseID is henceforth also called a valid
PauseID. PauseID.
PauseID needs to be incremented by one, in modulo arithmetic, for PauseID needs to be incremented by one, in modulo arithmetic, for
each PAUSE request that is not a retransmission, compared to what was each PAUSE request that is not a retransmission, compared to what was
used in the last PAUSED indication sent by the media sender. This is used in the last PAUSED indication sent by the media sender. This is
to ensure that the PauseID matches what is the current available to ensure that the PauseID matches what is the current available
PauseID at the RTP stream sender. The RTP stream sender increments PauseID at the RTP stream sender. The RTP stream sender increments
what it considers to be the available PauseID when entering Playing what it considers to be the available PauseID when entering Playing
State (Section 7.1). State (Section 6.1).
For the scope of this specification, a PauseID larger than the For the scope of this specification, a PauseID larger than the
current one is defined as having a value between and including current one is defined as having a value between and including
(PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16, where "MOD" is
the modulo operator. Similarly, a PauseID smaller than the current the modulo operator. Similarly, a PauseID smaller than the current
one is defined as having a value between and including (PauseID - one is defined as having a value between and including (PauseID -
2^15) MOD 2^16 and (PauseID - 1) MOD 2^16. 2^15) MOD 2^16 and (PauseID - 1) MOD 2^16.
If an RTP stream receiver that sent a PAUSE with a certain PauseID If an RTP stream receiver that sent a PAUSE with a certain PauseID
receives a RESUME with the same PauseID, it is RECOMMENDED that it receives a RESUME with the same PauseID, it is RECOMMENDED that it
skipping to change at page 33, line 50 skipping to change at page 24, line 27
time since the RESUME indicates that there are other receivers that time since the RESUME indicates that there are other receivers that
still wishes to receive the stream. still wishes to receive the stream.
If the targeted RTP stream does not pause, if no PAUSED indication If the targeted RTP stream does not pause, if no PAUSED indication
with a larger PauseID than the one used in PAUSE, and if no REFUSE is with a larger PauseID than the one used in PAUSE, and if no REFUSE is
received within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled 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 7.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 7.2) when reaching an appropriate place to pause in the (Section 6.2) when reaching an appropriate place to pause in the
stream, and act accordingly. stream, and act accordingly.
If an RTP stream sender receives a valid PAUSE while in Pausing, If an RTP stream sender receives a valid PAUSE while in Pausing,
Paused (Section 7.3) or Local Paused (Section 7.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.
9.2. PAUSED 8.2. PAUSED
The PAUSED indication MAY be sent either as a result of a valid PAUSE The PAUSED indication MAY be sent either as a result of a valid PAUSE
(Section 9.1) request, when entering Paused State (Section 7.3), or (Section 8.1) request, when entering Paused State (Section 6.3), or
based on a RTP stream sender local decision, when entering Local based on a RTP stream sender local decision, when entering Local
Paused State (Section 7.4). Paused State (Section 6.4).
PauseID MUST contain the available, valid value to be included in a PauseID MUST contain the available, valid value to be included in a
subsequent RESUME (Section 9.3). subsequent RESUME (Section 8.3).
PAUSED SHALL contain a 32 bit parameter with the RTP extended highest PAUSED SHALL contain a 32 bit parameter with the RTP extended highest
sequence number valid when the RTP stream was paused. Parameter Len sequence number valid when the RTP stream was paused. Parameter Len
MUST be set to 1. MUST be set to 1.
After having entered Paused or Local Paused State and thus having After having entered Paused or Local Paused State and thus having
sent PAUSED once, PAUSED MUST also be included in the next two sent PAUSED once, PAUSED MUST also be included in the next two
regular RTCP reports, given that the pause condition is then still regular RTCP reports, given that the pause condition is then still
effective. effective.
While remaining in Paused or Local Paused States, PAUSED MAY be While remaining in Paused or Local Paused States, PAUSED MAY be
included in all regular RTCP reports. included in all regular RTCP reports.
When in Paused or Local Paused States, It is RECOMMENDED to send When in Paused or Local Paused States, It is RECOMMENDED to send
PAUSED at the earliest opportunity and also to include it in the next PAUSED at the earliest opportunity and also to include it in the next
two regular RTCP reports, whenever the RTP stream sender learns that two regular RTCP reports, whenever the RTP stream sender learns that
there are End Points that did not previously receive the stream, for there are End Points that did not previously receive the stream, for
example by RTCP reports with an SSRC and a CNAME that was not example by RTCP reports with an SSRC and a CNAME that was not
previously seen in the RTP session. previously seen in the RTP session.
9.3. RESUME 8.3. RESUME
An RTP stream receiver MAY schedule RESUME for transmission whenever An RTP stream receiver MAY schedule RESUME for transmission whenever
it wishes to resume a paused stream, or to disapprove a stream from it wishes to resume a paused stream, or to disapprove a stream from
being paused. being paused.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED PauseID SHOULD be the valid PauseID, as indicated by PAUSED
(Section 9.2) or implicitly determined by previously received PAUSE (Section 8.2) or implicitly determined by previously received PAUSE
(Section 9.1) or RESUME requests. A randomly chosen PauseID MAY be (Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be
used if it was not possible to retrieve PauseID information, in which used if it was not possible to retrieve PauseID information, in which
case the RESUME will either succeed, or the correct PauseID can be case the RESUME will either succeed, or the correct PauseID can be
found in a returned REFUSE (Section 9.4). found in a returned REFUSE (Section 8.4).
RESUME has no defined Type Specific parameters and Parameter Len MUST RESUME has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
When an RTP stream sender in Pausing (Section 7.2), Paused When an RTP stream sender in Pausing (Section 6.2), Paused
(Section 7.3) or Local Paused State (Section 7.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 7.1) and to resume the stream, it SHALL enter Playing State (Section 6.1) and
act accordingly. If the RTP stream sender is incapable of honoring act accordingly. If the RTP stream sender is incapable of honoring
the RESUME request with a valid PauseID, or receives a RESUME request the RESUME request with a valid PauseID, or receives a RESUME request
with an invalid PauseID while in Paused or Pausing state, the RTP with an invalid PauseID while in Paused or Pausing state, the RTP
stream sender sends a REFUSE message as specified below. stream sender sends a REFUSE message as specified below.
If an RTP stream sender in Playing State receives a RESUME containing If an RTP stream sender in Playing State receives a RESUME containing
either a valid PauseID or a PauseID that is less than the valid either a valid PauseID or a PauseID that is less than the valid
PauseID, the received RESUME SHALL be ignored. PauseID, the received RESUME SHALL be ignored.
9.4. REFUSE 8.4. REFUSE
REFUSE has no defined Type Specific parameters and Parameter Len MUST REFUSE has no defined Type Specific parameters and Parameter Len MUST
be set to 0. be set to 0.
If an RTP stream sender receives a valid PAUSE (Section 9.1) or If an RTP stream sender receives a valid PAUSE (Section 8.1) or
RESUME (Section 9.3) request that cannot be fulfilled by the sender RESUME (Section 8.3) request that cannot be fulfilled by the sender
due to some local consideration, it SHALL schedule transmission of a due to some local consideration, it SHALL schedule transmission of a
REFUSE indication containing the valid PauseID from the rejected REFUSE indication containing the valid PauseID from the rejected
request. request.
If an RTP stream sender receives PAUSE or RESUME requests with a non- If an RTP stream sender receives PAUSE or RESUME requests with a non-
valid PauseID it SHALL schedule a REFUSE response containing the valid PauseID it SHALL schedule a REFUSE response containing the
available, valid PauseID, except if the RTP stream sender is in available, valid PauseID, except if the RTP stream sender is in
Playing State and receives a RESUME with a PauseID less than the Playing State and receives a RESUME with a PauseID less than the
valid one, in which case the RESUME SHALL be ignored. valid one, in which case the RESUME SHALL be ignored.
skipping to change at page 36, line 12 skipping to change at page 26, line 44
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing the same PauseID as in the request receives a REFUSE containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSE to clear. time to allow the condition that caused REFUSE to clear.
An RTP stream receiver that sent a PAUSE or RESUME request and An RTP stream receiver that sent a PAUSE or RESUME request and
receives a REFUSE containing a PauseID different from the request MAY receives a REFUSE containing a PauseID different from the request MAY
schedule another request using the PauseID from the REFUSE schedule another request using the PauseID from the REFUSE
indication. indication.
9.5. Transmission Rules 8.5. Transmission Rules
The transmission of any RTCP feedback messages defined in this The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation. depends on the session's mode of operation.
All messages defined in this specification MAY use either Regular, All messages defined in this specification MAY use either Regular,
Early or Immediate timings, taking the following into consideration: Early or Immediate timings, taking the following into consideration:
o PAUSE SHOULD use Early or Immediate timing, except for o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing. retransmissions that SHOULD use Regular timing.
skipping to change at page 36, line 34 skipping to change at page 27, line 18
o The first transmission of PAUSED for each (non-wrapped) PauseID o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. PAUSED for that PauseID SHOULD use Regular timing.
o RESUME SHOULD always use Immediate or Early timing. o RESUME SHOULD always use Immediate or Early timing.
o The first transmission of REFUSE for each (non-wrapped) PauseID o The first transmission of REFUSE for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent SHOULD be sent with Immediate or Early timing, while subsequent
REFUSE for that PauseID SHOULD use Regular timing. REFUSE for that PauseID SHOULD use Regular timing.
10. Signaling 9. Signaling
The capability of handling messages defined in this specification MAY The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends be exchanged at a higher layer such as SDP. This document extends
the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to the rtcp-fb attribute defined in section 4 of AVPF [RFC4585] to
include the request for pause and resume. Like AVPF [RFC4585] and include the request for pause and resume. Like AVPF [RFC4585] and
CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at CCM [RFC5104], it is RECOMMENDED to use the rtcp-fb attribute at
media level and it MUST NOT be used at session level. This media level and it MUST NOT be used at session level. This
specification follows all the rules defined in AVPF for rtcp-fb specification follows all the rules defined in AVPF for rtcp-fb
attribute relating to payload type in a session description. attribute relating to payload type in a session description.
skipping to change at page 37, line 22 skipping to change at page 28, line 6
and local paused states and generate PAUSED FCI when a stream and local paused states and generate PAUSED FCI when a stream
delivery is paused. A direction sub-parameter is used to delivery is paused. A direction sub-parameter is used to
determine if a given node desires to receive these indications, determine if a given node desires to receive these indications,
intends to send them, or both. intends to send them, or both.
The reason for this separation is to make it possible for partial The reason for this separation is to make it possible for partial
implementation of this specification, according to the different implementation of this specification, according to the different
roles in the use cases section (Section 3). roles in the use cases section (Section 3).
A sub-parameter named "nowait", indicating that the hold-off time A sub-parameter named "nowait", indicating that the hold-off time
defined in Section 7.2 can be set to 0, reducing the latency before defined in Section 6.2 can be set to 0, reducing the latency before
the stream can paused after receiving a PAUSE request. This the stream can paused after receiving a PAUSE request. This
condition occurs when there will be only a single receiver per condition occurs when there will be only a single receiver per
direction in the RTP session, for example in point-to-point sessions. direction in the RTP session, for example in point-to-point sessions.
It is also possible to use in scenarios using unidirectional media. It is also possible to use in scenarios using unidirectional media.
The conditions that allow "nowait" to be set also indicate that it The conditions that allow "nowait" to be set also indicate that it
would be possible to use CCM TMMBR/TMMBN as pause/resume signaling. would be possible to use CCM TMMBR/TMMBN as pause/resume signaling.
A sub-parameter named "dir" is used to indicate in which directions a A sub-parameter named "dir" is used to indicate in which directions a
given node will use the pause or paused functionality. The node given node will use the pause or paused functionality. The node
being configured or issuing an offer or an answer uses the being configured or issuing an offer or an answer uses the
skipping to change at page 38, line 36 skipping to change at page 29, line 18
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr) rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
/ SP "paused" *(SP paused-attr) / SP "paused" *(SP paused-attr)
pause-attr = direction pause-attr = direction
/ "nowait" / "nowait"
/ token ; for future extensions / token ; for future extensions
paused-attr = direction paused-attr = direction
/ token ; for future extensions / token ; for future extensions
direction = "dir=" direction-alts direction = "dir=" direction-alts
direction-alts = "sendonly" / "recvonly" / "sendrecv" direction-alts = "sendonly" / "recvonly" / "sendrecv"
Figure 10: ABNF Figure 6: ABNF
An endpoint implementing this specification and using SDP to signal An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate both of the new "pause" and "paused" capability SHOULD indicate both of the new "pause" and "paused"
parameters with ccm signaling. When negotiating usage, it is parameters with ccm signaling. When negotiating usage, it is
possible select either of them, noting that "pause" contain the full possible select either of them, noting that "pause" contain the full
"paused" functionality. A sender or receiver SHOULD NOT use the "paused" functionality. A sender or receiver SHOULD NOT use the
messages from this specification towards receivers that did not messages from this specification towards receivers that did not
declare capability for it. declare capability for it.
There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one
with "paused" applicable to a single payload type in the SDP, unless with "paused" applicable to a single payload type in the SDP, unless
the additional line uses "*" as payload type, in which case "*" SHALL the additional line uses "*" as payload type, in which case "*" SHALL
be interpreted as applicable to all listed payload types that does be interpreted as applicable to all listed payload types that does
not have an explicit "pause" or "paused" specification. not have an explicit "pause" or "paused" specification.
There MUST NOT be more than a single direction sub-parameter per There MUST NOT be more than a single direction sub-parameter per
"pause" and "paused" parameter. There MUST NOT be more than a single "pause" and "paused" parameter. There MUST NOT be more than a single
"nowait" sub-parameter per "pause" parameter. "nowait" sub-parameter per "pause" parameter.
10.1. Offer-Answer Use 9.1. Offer-Answer Use
An offerer implementing this specification needs to include "pause" An offerer implementing this specification needs to include "pause"
and/or "paused" CCM parameters with suitable directionality parameter and/or "paused" CCM parameters with suitable directionality parameter
("dir") in the SDP, according to what messages it intends to send and ("dir") in the SDP, according to what messages it intends to send and
desires or is capable to receive in the session. It is RECOMMENDED desires or is capable to receive in the session. It is RECOMMENDED
to include both "pause" and "paused" if "pause" is supported, to to include both "pause" and "paused" if "pause" is supported, to
enable at least the "paused" functionality if the answer only enable at least the "paused" functionality if the answer only
supports "paused" or different directionality for the two supports "paused" or different directionality for the two
functionalities. The "pause" and "paused" functionalities are functionalities. The "pause" and "paused" functionalities are
negotiated independently, although the "paused" functionality is part negotiated independently, although the "paused" functionality is part
skipping to change at page 40, line 8 skipping to change at page 30, line 38
"nowait" sub-parameter on the "pause" line in the offer. If an "nowait" sub-parameter on the "pause" line in the offer. If an
answerer receives the "nowait" sub-parameter on the "pause" line in answerer receives the "nowait" sub-parameter on the "pause" line in
the SDP, and if it has information that the offerer and itself are the SDP, and if it has information that the offerer and itself are
not the only End Points in the RTP session, it MUST NOT include any not the only End Points in the RTP session, it MUST NOT include any
"nowait" sub-parameter on its "pause" line in the SDP answer. The "nowait" sub-parameter on its "pause" line in the SDP answer. The
answerer MUST NOT add "nowait" on the "pause" line in the answer answerer MUST NOT add "nowait" on the "pause" line in the answer
unless it is present on the "paused" line in the offer. If both unless it is present on the "paused" line in the offer. If both
offer and answer contained a "nowait" parameter, then the hold-off offer and answer contained a "nowait" parameter, then the hold-off
time is configured to 0 at both offerer and answerer. time is configured to 0 at both offerer and answerer.
10.2. Declarative Use 9.2. Declarative Use
In declarative use, the SDP is used to configure the node receiving In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP the SDP. This has implications on the interpretation of the SDP
signaling extensions defined in this draft. First, it is normally signaling extensions defined in this draft. First, it is normally
only necessary to include either "pause" or "paused" parameter to only necessary to include either "pause" or "paused" parameter to
indicate the level of functionality the node should use in this RTP indicate the level of functionality the node should use in this RTP
session. Including both is only necessary if some implementations session. Including both is only necessary if some implementations
only understands "paused" and some other can understand both. Thus only understands "paused" and some other can understand both. Thus
indicating both means use pause if you understand it, and if you only indicating both means use pause if you understand it, and if you only
understand paused, use that. understand paused, use that.
skipping to change at page 40, line 43 skipping to change at page 31, line 25
the responsibility of the declarative SDP sender to determine if a the responsibility of the declarative SDP sender to determine if a
configured node will participate in a session that will be point to configured node will participate in a session that will be point to
point, based on the usage. For example, a conference client being point, based on the usage. For example, a conference client being
configured for an any source multicast session using SAP [RFC2974] configured for an any source multicast session using SAP [RFC2974]
will not be in a point to point session, thus "nowait" cannot be will not be in a point to point session, thus "nowait" cannot be
included. An RTSP [RFC2326] client receiving a declarative SDP may included. An RTSP [RFC2326] client receiving a declarative SDP may
very well be in a point to point session, although it is highly very well be in a point to point session, although it is highly
doubtful that an RTSP client would need to support this doubtful that an RTSP client would need to support this
specification, considering the inherent PAUSE support in RTSP. specification, considering the inherent PAUSE support in RTSP.
11. 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 Translator 4. Point-to-Multipoint using Translator
11.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
t=0 0 t=0 0
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99 m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000 a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=rtcp-fb:* ccm paused a=rtcp-fb:* ccm paused
Figure 11: SDP Offer With Pause and Resume Capability Figure 7: SDP Offer With Pause and Resume Capability
The offerer supports all of the messages defined in this The offerer supports all of the messages defined in this
specification and offers a sendrecv stream. The offerer also specification and offers a sendrecv stream. The offerer also
believes that it will be the sole receiver of the answerer's stream believes that it will be the sole receiver of the answerer's stream
as well as that the answerer will be the sole receiver of the as well as that the answerer will be the sole receiver of the
offerer's stream and thus includes the "nowait" sub-parameter for offerer's stream and thus includes the "nowait" sub-parameter for
both "pause" and "paused" parameters. both "pause" and "paused" parameters.
This is the SDP answer: This is the SDP answer:
v=0 v=0
o=bob 293847192 293847192 IN IP4 bob.example.com o=bob 293847192 293847192 IN IP4 bob.example.com
s=- s=-
t=0 0 t=0 0
c=IN IP4 bob.example.com c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98 m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000 a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause dir=sendonly a=rtcp-fb:98 ccm pause dir=sendonly
a=rtcp-fb:98 ccm paused a=rtcp-fb:98 ccm paused
Figure 12: SDP Answer With Pause and Resume Capability Figure 8: SDP Answer With Pause and Resume Capability
The answerer will not allow its sent streams to be paused or resumed The answerer will not allow its sent streams to be paused or resumed
and thus support pause only in sendonly mode. It does support paused and thus support pause only in sendonly mode. It does support paused
and intends to send it, and also desires to receive PAUSED and intends to send it, and also desires to receive PAUSED
indications. Thus paused in sendrecv mode is included in the answer. indications. Thus paused in sendrecv mode is included in the answer.
The answerer somehow knows that it will not be a point-to-point RTP The answerer somehow knows that it will not be a point-to-point RTP
session and has therefore removed "nowait" from the "pause" line, session and has therefore removed "nowait" from the "pause" line,
meaning that the offerer must use a non-zero hold-off time when being meaning that the offerer must use a non-zero hold-off time when being
requested to pause the stream. requested to pause the stream.
When using TMMBR 0 / TMMBN 0 to achieve pause and resume When using TMMBR 0 / TMMBN 0 to achieve pause and resume
functionality, there are no differences in SDP compared to CCM functionality, there are no differences in SDP compared to CCM
[RFC5104] and therefore no such examples are included here. [RFC5104] and therefore no such examples are included here.
11.2. Point-to-Point Session 10.2. Point-to-Point Session
This is the most basic scenario, which involves two participants, This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off time before pausing a stream transmission accordingly. The hold-off time before pausing a stream
is 0. is 0.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 42, line 44 skipping to change at page 33, line 34
| t4: RESUME(3) | | t4: RESUME(3) |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: PAUSE(4) | | t6: PAUSE(4) |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
: : : :
Figure 13: Pause and Resume Operation in Point-to-Point Figure 9: Pause and Resume Operation in Point-to-Point
Figure 13 shows the basic pause and resume operation in Point-to- Figure 9 shows the basic pause and resume operation in Point-to-Point
Point scenario. At time t1, an RTP sender sends data to a receiver. scenario. At time t1, an RTP sender sends data to a receiver. At
At time t2, the RTP receiver requests the sender to pause the stream, time t2, the RTP receiver requests the sender to pause the stream,
using PauseID 3 (which it knew since before in this example). The using PauseID 3 (which it knew since before in this example). The
sender pauses the data and replies with a PAUSED containing the same sender pauses the data and replies with a PAUSED containing the same
PauseID. Some time later (at time t4) the receiver requests the PauseID. Some time later (at time t4) the receiver requests the
sender to resume, which resumes its transmission. The next PAUSE, sender to resume, which resumes its transmission. The next PAUSE,
sent at time t6, contains an updated PauseID (4). sent at time t6, contains an updated PauseID (4).
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
skipping to change at page 43, line 29 skipping to change at page 34, line 26
| t4: TMMBR 150000 | | t4: TMMBR 150000 |
| <------------------------------- | | <------------------------------- |
| t5: RTP data | | t5: RTP data |
| -------------------------------> | | -------------------------------> |
: < Some time passes > : : < Some time passes > :
| t6: TMMBR 0 | | t6: TMMBR 0 |
| <------------------------------- | | <------------------------------- |
| < RTP data paused > | | < RTP data paused > |
: : : :
Figure 14: TMMBR Pause and Resume in Point-to-Point Figure 10: TMMBR Pause and Resume in Point-to-Point
Figure 14 describes the same point-to-point scenario as above, but Figure 10 describes the same point-to-point scenario as above, but
using TMMBR/TMMBN signaling. using TMMBR/TMMBN signaling.
+---------------+ +---------------+ +---------------+ +---------------+
| RTP Sender | | RTP Receiver | | RTP Sender | | RTP Receiver |
+---------------+ +---------------+ +---------------+ +---------------+
: t1: RTP data : : t1: RTP data :
| ------------------------------------> | | ------------------------------------> |
| t2: PAUSE(7), lost | | t2: PAUSE(7), lost |
| <---X-------------- | | <---X-------------- |
| | | |
skipping to change at page 44, line 33 skipping to change at page 35, line 33
| t6: RESUME(7), lost | | t6: RESUME(7), lost |
| <---X-------------- | | <---X-------------- |
| t7: RESUME(7) | | t7: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
| t8: RTP data | | t8: RTP data |
| ------------------------------------> | | ------------------------------------> |
| t9: RESUME(7) | | t9: RESUME(7) |
| <------------------------------------ | | <------------------------------------ |
: : : :
Figure 15: Pause and Resume Operation With Messages Lost Figure 11: Pause and Resume Operation With Messages Lost
Figure 15 describes what happens if a PAUSE message from an RTP Figure 11 describes what happens if a PAUSE message from an RTP
stream receiver does not reach the RTP stream sender. After sending stream receiver does not reach the RTP stream sender. After sending
a PAUSE message, the RTP stream receiver waits for a time-out to a PAUSE message, the RTP stream receiver waits for a time-out to
detect if the RTP stream sender has paused the data transmission or detect if the RTP stream sender has paused the data transmission or
has sent PAUSED indication according to the rules discussed in has sent PAUSED indication according to the rules discussed in
Section 7.3. As the PAUSE message is lost on the way (at time t2), Section 6.3. As the PAUSE message is lost on the way (at time t2),
RTP data continues to reach to the RTP stream receiver. When the RTP data continues to reach to the RTP stream receiver. When the
timer expires, the RTP stream receiver schedules a retransmission of timer expires, the RTP stream receiver schedules a retransmission of
the PAUSE message, which is sent at time t4. If the PAUSE message the PAUSE message, which is sent at time t4. If the PAUSE message
now reaches the RTP stream sender, it pauses the RTP stream and now reaches the RTP stream sender, it pauses the RTP stream and
replies with PAUSED. replies with PAUSED.
At time t6, the RTP stream receiver wishes to resume the stream again At time t6, the RTP stream receiver wishes to resume the stream again
and sends a RESUME, which is lost. This does not cause any severe and sends a RESUME, which is lost. This does not cause any severe
effect, since there is no requirement to wait until further RESUME effect, since there is no requirement to wait until further RESUME
are sent and another RESUME are sent already at time t7, which now are sent and another RESUME are sent already at time t7, which now
skipping to change at page 45, line 34 skipping to change at page 36, line 34
| <------------------------------ | | <------------------------------ |
| | | |
| < Can not pause RTP data > | | < Can not pause RTP data > |
| t3: REFUSE(11) | | t3: REFUSE(11) |
| ------------------------------> | | ------------------------------> |
| | | |
| t4: RTP data | | t4: RTP data |
| ------------------------------> | | ------------------------------> |
: : : :
Figure 16: Pause Request is Refused in Point-to-Point Figure 12: Pause Request is Refused in Point-to-Point
In Figure 16, the receiver requests to pause the sender, which In Figure 12, the receiver requests to pause the sender, which
refuses to pause due to some consideration local to the sender and refuses to pause due to some consideration local to the sender and
responds with a REFUSE message. responds with a REFUSE message.
11.3. Point-to-Multipoint using Mixer 10.3. Point-to-Multipoint using Mixer
An RTP Mixer is an intermediate node connecting different transport- An RTP Mixer is an intermediate node connecting different transport-
level clouds. The Mixer receives streams from different RTP sources, level clouds. The Mixer receives streams from different RTP sources,
selects or combines them based on the application's needs and selects or combines them based on the application's needs and
forwards the generated stream(s) to the destination. The Mixer forwards the generated stream(s) to the destination. The Mixer
typically puts its' own SSRC(s) in RTP data packets instead of the typically puts its' own SSRC(s) in RTP data packets instead of the
original source(s). original source(s).
The Mixer keeps track of all the streams delivered to the Mixer and The Mixer keeps track of all the streams delivered to the Mixer and
how they are currently used. In this example, it selects the video how they are currently used. In this example, it selects the video
skipping to change at page 46, line 37 skipping to change at page 37, line 37
| |<------------------------------------| | |<------------------------------------|
| t8:RTP(M:S2) | | | | t8:RTP(M:S2) | | |
|<-----------------| | | |<-----------------| | |
| | t9:PAUSE(S1) | | | | t9:PAUSE(S1) | |
| |----------------->| | | |----------------->| |
| | t10:PAUSED(S1) | | | | t10:PAUSED(S1) | |
| |<-----------------| | | |<-----------------| |
| | <S1:No RTP to M> | | | | <S1:No RTP to M> | |
: : : : : : : :
Figure 17: Pause and Resume Operation for a Voice Activated Mixer Figure 13: Pause and Resume Operation for a Voice Activated Mixer
The session starts at t1 with S1 being the most active speaker and The session starts at t1 with S1 being the most active speaker and
thus being selected as the single video stream to be delivered to R thus being selected as the single video stream to be delivered to R
(t2) using the Mixer SSRC but with S1 as CSRC (indicated after the (t2) using the Mixer SSRC but with S1 as CSRC (indicated after the
colon in the figure). Then S2 joins the session at t3 and starts colon in the figure). Then S2 joins the session at t3 and starts
delivering an RTP stream to the Mixer. As S2 has less voice activity delivering an RTP stream to the Mixer. As S2 has less voice activity
then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE then S1, the Mixer decides to pause S2 at t4 by sending S2 a PAUSE
request. At t5, S2 acknowledges with a PAUSED and at the same request. At t5, S2 acknowledges with a PAUSED and at the same
instant stops delivering RTP to the Mixer. At t6, the user at S2 instant stops delivering RTP to the Mixer. At t6, the user at S2
starts speaking and becomes the most active speaker and the Mixer starts speaking and becomes the most active speaker and the Mixer
decides to switch the video stream to S2, and therefore quickly sends decides to switch the video stream to S2, and therefore quickly sends
a RESUME request to S2. At t7, S2 has received the RESUME request a RESUME request to S2. At t7, S2 has received the RESUME request
and acts on it by resuming RTP 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.
11.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 Translator in an RTP session forwards the message from
one peer to all the others. Unlike Mixer, the Translator does not one peer to all the others. Unlike Mixer, the Translator does not
mix the streams or change the SSRC of the messages or RTP media. mix the streams or change the SSRC of the messages or RTP media.
These examples are to show that the messages defined in this These examples are to show that the messages defined in this
specification can be safely used also in a transport Translator case. specification can be safely used also in a transport Translator case.
The parentheses in the figures contains (Target SSRC, PauseID) The parentheses in the figures contains (Target SSRC, PauseID)
information for the messages defined in this specification. information for the messages defined in this specification.
+-------------+ +-------------+ +--------------+ +-------------+ +-------------+ +--------------+
skipping to change at page 47, line 48 skipping to change at page 38, line 48
| | t7: RESUME(S,3) | | | t7: RESUME(S,3) |
| |<------------------| | |<------------------|
| t8: RESUME(S,3) | | | t8: RESUME(S,3) | |
|<------------------| | |<------------------| |
| t9: RTP (S) | | | t9: RTP (S) | |
|------------------>| | |------------------>| |
| | t10: RTP (S) | | | t10: RTP (S) |
| |------------------>| | |------------------>|
: : : : : :
Figure 18: Pause and Resume Operation Between Two Participants Using Figure 14: Pause and Resume Operation Between Two Participants Using
a Translator a Translator
Figure 18 describes how a Translator can help the receiver in pausing Figure 14 describes how a Translator can help the receiver in pausing
and resuming the sender. The sender S sends RTP data to the receiver and resuming the sender. The sender S sends RTP data to the receiver
R through Translator, which just forwards the data without modifying R through Translator, which just forwards the data without modifying
the SSRCs. The receiver sends a PAUSE request to the sender, which the SSRCs. The receiver sends a PAUSE request to the sender, which
in this example knows that there may be more receivers of the stream in this example knows that there may be more receivers of the stream
and waits a non-zero hold-off time to see if there is any other and waits a non-zero hold-off time to see if there is any other
receiver that wants to receive the data, does not receive any receiver that wants to receive the data, does not receive any
disapproving RESUME, hence pauses itself and replies with PAUSED. disapproving RESUME, hence pauses itself and replies with PAUSED.
Similarly the receiver resumes the sender by sending RESUME request Similarly the receiver resumes the sender by sending RESUME request
through Translator. Since this describes only a single pause through Translator. Since this describes only a single pause
operation for a single RTP stream sender, all messages uses a single operation for a single RTP stream sender, all messages uses a single
skipping to change at page 49, line 42 skipping to change at page 40, line 42
| | t11:RESUME(S,8) | | | | t11:RESUME(S,8) | |
| |<-----------------| | | |<-----------------| |
| t12:RESUME(S,8) | | | | t12:RESUME(S,8) | | |
|<-----------------| | | |<-----------------| | |
| t13:RTP(S) | | | | t13:RTP(S) | | |
|----------------->| | | |----------------->| | |
| | t14:RTP(S) | | | | t14:RTP(S) | |
| |----------------->------------------>| | |----------------->------------------>|
: : : : : : : :
Figure 19: Pause and Resume Operation Between One Sender and Two Figure 15: Pause and Resume Operation Between One Sender and Two
Receivers Through Translator Receivers Through Translator
Figure 19 explains the pause and resume operations when a transport Figure 15 explains the pause and resume operations when a transport
Translator is involved between a sender and two receivers in an RTP Translator is involved between a sender and two receivers in an RTP
session. Each message exchange is represented by the time it session. Each message exchange is represented by the time it
happens. At time t1, Sender (S) starts sending an RTP stream to the happens. At time t1, Sender (S) starts sending an RTP stream to the
Translator, which is forwarded to R1 and R2 through the Translator, Translator, which is forwarded to R1 and R2 through the Translator,
T. R1 and R2 receives RTP data from Translator at t2. At this T. R1 and R2 receives RTP data from Translator at t2. At this
point, both R1 and R2 will send RTCP Receiver Reports to S informing point, both R1 and R2 will send RTCP Receiver Reports to S informing
that they receive S's stream. that they receive S's stream.
After some time (at t3), R1 chooses to pause the stream. On After some time (at t3), R1 chooses to pause the stream. On
receiving the PAUSE request from R1 at t4, S knows that there are at receiving the PAUSE request from R1 at t4, S knows that there are at
skipping to change at page 50, line 38 skipping to change at page 41, line 38
participant joins the session, which is not aware of the paused participant joins the session, which is not aware of the paused
sender(s). On receiving knowledge about the newly joined sender(s). On receiving knowledge about the newly joined
participant, e.g. any RTP traffic or RTCP report (i.e. either SR or participant, e.g. any RTP traffic or RTCP report (i.e. either SR or
RR) from the newly joined participant, the paused sender(s) RR) from the newly joined participant, the paused sender(s)
immediately sends PAUSED indications for the paused streams since immediately sends PAUSED indications for the paused streams since
there is now a receiver in the session that did not pause the there is now a receiver in the session that did not pause the
sender(s) and may want to receive the streams. Having this sender(s) and may want to receive the streams. Having this
information, the newly joined participant has the same possibility as information, the newly joined participant has the same possibility as
any other participant to resume the paused streams. any other participant to resume the paused streams.
12. IANA Considerations 11. IANA Considerations
As outlined in Section 8, this specification requests IANA to As outlined in Section 7, this specification requests IANA to
allocate allocate
1. The FMT number TBA1 to be allocated to the PAUSE and RESUME 1. The FMT number TBA1 to be allocated to the PAUSE and RESUME
functionality from this specification. functionality from this specification.
2. The 'pause' and 'paused' tags to be used with ccm under rtcp-fb 2. The 'pause' and 'paused' tags to be used with ccm under rtcp-fb
AVPF attribute in SDP. AVPF attribute in SDP.
3. The 'nowait' parameter to be used with the 'pause' and 'paused' 3. The 'nowait' parameter to be used with the 'pause' and 'paused'
tags in SDP. tags in SDP.
4. A registry listing registered values for 'pause' Types. 4. A registry listing registered values for 'pause' Types.
5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the 5. PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the
pause Type registry. pause Type registry.
13. Security Considerations 12. Security Considerations
This document extends the CCM [RFC5104] and defines new messages, This document extends the CCM [RFC5104] and defines new messages,
i.e. PAUSE and RESUME. The exchange of these new messages MAY have i.e. PAUSE and RESUME. The exchange of these new messages MAY have
some security implications, which need to be addressed by the user. some security implications, which need to be addressed by the user.
Following are some important implications, Following are some important implications,
1. Identity spoofing - An attacker can spoof him/herself as an 1. Identity spoofing - An attacker can spoof him/herself as an
authenticated user and can falsely pause or resume any source authenticated user and can falsely pause or resume any source
transmission. In order to prevent this type of attack, a strong transmission. In order to prevent this type of attack, a strong
authentication and integrity protection mechanism is needed. authentication and integrity protection mechanism is needed.
2. Denial of Service (DoS) - An attacker can falsely pause all 2. Denial of Service (DoS) - An attacker can falsely pause all
source streams which MAY result in Denial of Service (DoS). An source streams which MAY result in Denial of Service (DoS). An
Authentication protocol may prevent this attack. Authentication protocol may prevent this attack.
3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP 3. Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP
source is prone to a Man-in-Middle attack. Public key source is prone to a Man-in-Middle attack. Public key
authentication may be used to prevent MiMT. authentication may be used to prevent MiMT.
14. Contributors 13. Contributors
Daniel Grondal contributed in the creation and writing of earlier Daniel Grondal contributed in the creation and writing of early
versions of this specification. versions of this specification.
15. Acknowledgements 14. Acknowledgements
Daniel Grondal made valuable contributions during the initial Daniel Grondal made valuable contributions during the initial
versions of this draft. versions of this draft.
16. References 15. References
16.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[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, July
2006. 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
16.2. Informative References 15.2. Informative References
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-02 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
May 2014. May 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-01 (work in progress), February rtp-grouping-taxonomy-01 (work in progress), February
2014. 2014.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-use-cases-and-requirements]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use-cases and Requirements", draft- Time Communication Use-cases and Requirements", draft-
ietf-rtcweb-use-cases-and-requirements-14 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014. progress), February 2014.
[I-D.lennox-mmusic-sdp-source-selection]
Lennox, J. and H. Schulzrinne, "Mechanisms for Media
Source Selection in the Session Description Protocol
(SDP)", draft-lennox-mmusic-sdp-source-selection-05 (work
in progress), October 2012.
[I-D.westerlund-avtcore-rtp-simulcast] [I-D.westerlund-avtcore-rtp-simulcast]
Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP Westerlund, M. and S. Nandakumar, "Using Simulcast in RTP
Sessions", draft-westerlund-avtcore-rtp-simulcast-03 (work Sessions", draft-westerlund-avtcore-rtp-simulcast-03 (work
in progress), October 2013. in progress), October 2013.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[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, June
2002. 2002.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
3556, July 2003.
[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.
[RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo,
"Applying Signaling Compression (SigComp) to the Session
Initiation Protocol (SIP)", RFC 5049, December 2007.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, April 2008.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[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.
[TS25.308] Appendix A. Changes From Earlier Versions
3GPP, "High Speed Downlink Packet Access (HSDPA); Overall
description; Stage 2", 3GPP TS 25.308 10.6.0, December
2011, <http://www.3gpp.org/ftp/Specs/html-info/25308.htm>.
[TS26.114] NOTE TO RFC EDITOR: Please remove this section prior to publication.
3GPP, "IP Multimedia Subsystem (IMS); Multimedia
telephony; Media handling and interaction", 3GPP TS 26.114
10.7.0, June 2013,
<http://www.3gpp.org/ftp/Specs/html-info/26114.htm>.
[TS36.201] A.1. Modifications Between Version -01 and -02
3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); LTE physical layer; General description", 3GPP
TS 36.201 10.0.0, December 2010,
<http://www.3gpp.org/ftp/Specs/html-info/36201.htm>.
Appendix A. Changes From Earlier Versions o Replaced most text on relation with other signaling technologies
in previous section 5 with a single, summarizing paragraph, as
discussed at IETF 90 in Toronto, and placed it as the last sub-
section of section 4 (design considerations).
NOTE TO RFC EDITOR: Please remove this section prior to publication. o Removed unused references.
A.1. Modifications Between Version -00 and -01 A.2. 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. 99 change blocks. 
647 lines changed or deleted 164 lines changed or added

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