One document matched: draft-ietf-avtext-rtp-stream-pause-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-avtext-rtp-stream-pause-00"
ipr="trust200902" updates="5104">
<front>
<title abbrev="Media Stream Pause">RTP Media Stream Pause and
Resume</title>
<author fullname="Azam Akram" initials="A." surname="Akram">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE - 164 80 Kista</city>
<region/>
<code/>
<country>Sweden</country>
</postal>
<phone>+46107142658</phone>
<facsimile>+46107175550</facsimile>
<email>muhammad.azam.akram@ericsson.com</email>
<uri>www.ericsson.com</uri>
</address>
</author>
<author fullname="Bo Burman" initials="B." surname="Burman">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE - 164 80 Kista</city>
<region/>
<code/>
<country>Sweden</country>
</postal>
<phone>+46107141311</phone>
<facsimile>+46107175550</facsimile>
<email>bo.burman@ericsson.com</email>
<uri>www.ericsson.com</uri>
</address>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city>Tel Aviv</city>
<region/>
<code/>
<country>Israel</country>
</postal>
<phone/>
<facsimile/>
<email>roni.even@mail01.huawei.com</email>
<uri/>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE- Kista 164 80</city>
<region/>
<code/>
<country>Sweden</country>
</postal>
<phone>+46107148287</phone>
<facsimile/>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date day="16" month="May" year="2014"/>
<abstract>
<t>With the increased popularity of real-time multimedia applications,
it is desirable to provide good control of resource usage, and users
also demand more control over communication sessions. This document
describes how a receiver in a multimedia conversation can pause and
resume incoming data from a sender by sending real-time feedback
messages when using Real-time Transport Protocol (RTP) for real time
data transport. This document extends the Codec Control Messages (CCM)
RTCP feedback package by explicitly allowing and describing specific use
of existing CCM messages and adding a group of new real-time feedback
messages used to pause and resume RTP data streams. This document
updates RFC 5104.</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>As real-time communication attracts more people, more applications
are created; multimedia conversation applications being one example.
Multimedia conversation further exists in many forms, for example,
peer-to-peer chat application and multiparty video conferencing
controlled by central media nodes, such as RTP Mixers.</t>
<t>Multimedia conferencing may involve many participants; each has its
own preferences for the communication session, not only at the start but
also during the session. This document describes several scenarios in
multimedia communication where a conferencing node or participant
chooses to temporarily pause an incoming <xref
target="RFC3550">RTP</xref> media stream from a specific source and
later resume it when needed. The receiver does not need to terminate or
inactivate the RTP session and start all over again by negotiating the
session parameters, for example using <xref target="RFC3261">SIP</xref>
with <xref target="RFC3264">SDP Offer/Answer</xref>.</t>
<t>Centralized nodes, like RTP Mixers or MCUs, which either uses logic
based on voice activity, other measurements, or user input could reduce
the resources consumed in both the media sender and the network by
temporarily pausing the media streams that aren't required by the RTP
Mixer. If the number of conference participants are greater than what
the conference logic has chosen to present simultaneously to receiving
participants, some participant media streams sent to the RTP Mixer may
not need to be forwarded to any other participant. Those media streams
could then be temporarily paused. This becomes especially useful when
the media sources are provided in <xref
target="I-D.westerlund-avtcore-rtp-simulcast">multiple encoding versions
(Simulcast)</xref> or with Multi-Session Transmission (MST) of scalable
encoding such as <xref target="RFC6190">SVC</xref>. There may be some of
the defined encodings or combination of scalable layers that are not
used all of the time.</t>
<t>As the media streams required at any given point in time is highly
dynamic in such scenarios, using the out-of-band signalling channel for
pausing, and even more importantly resuming, a media stream is difficult
due to the performance requirements. Instead, the pause and resume
signalling should be in the media plane and go directly between the
affected nodes. When using <xref target="RFC3550">RTP </xref> for media
transport, using <xref target="RFC4585">Extended RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/AVPF)</xref> appears appropriate. No currently existing RTCP
feedback message explicitly supports pausing and resuming an incoming
media stream. As this affects the generation of packets and may even
allow the encoding process to be paused, the functionality appears to
match <xref target="RFC5104">Codec Control Messages in the RTP
Audio-Visual Profile with Feedback (AVPF)</xref> and it is proposed to
define the solution as a Codec Control Message (CCM) extension.</t>
<t>The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is
used by video conferencing systems for flow control. It is desirable to
be able to use that method with a bitrate value of zero for pause and
resume, whenever possible.</t>
</section>
<section title="Definitions">
<section title="Abbreviations">
<t><list style="hanging">
<t hangText="3GPP:">3rd Generation Partnership Project</t>
<t hangText="AVPF:">Audio-Visual Profile with Feedback (RFC
4585)</t>
<t hangText="BGW:">Border Gateway</t>
<t hangText="CCM:">Codec Control Messages (RFC 5104)</t>
<t hangText="CNAME:">Canonical Name (RTCP SDES)</t>
<t hangText="CSRC:">Contributing Source (RTP)</t>
<t hangText="FB:">Feedback (AVPF)</t>
<t hangText="FCI:">Feedback Control Information (AVPF)</t>
<t hangText="FIR:">Full Intra Refresh (CCM)</t>
<t hangText="FMT:">Feedback Message Type (AVPF)</t>
<t hangText="LTE:">Long-Term Evolution (3GPP)</t>
<t hangText="MCU:">Multipoint Control Unit</t>
<t hangText="MTU:">Maximum Transfer Unit</t>
<t hangText="PT:">Payload Type (RTP)</t>
<t hangText="RTP:">Real-time Transport Protocol (RFC 3550)</t>
<t hangText="RTCP:">Real-time Transport Control Protocol (RFC
3550)</t>
<t hangText="RTCP RR:">RTCP Receiver Report</t>
<t hangText="SDP:">Session Description Protocol (RFC 4566)</t>
<t hangText="SGW:">Signaling Gateway</t>
<t hangText="SIP:">Session Initiation Protocol (RFC 3261)</t>
<t hangText="SSRC:">Synchronization Source (RTP)</t>
<t hangText="SVC:">Scalable Video Coding</t>
<t hangText="TCP:">Transmission Control Protocol (RFC 793)</t>
<t hangText="TMMBR:">Temporary Maximum Media Bitrate Request
(CCM)</t>
<t hangText="TMMBN:">Temporary Maximum Media Bitrate Notification
(CCM)</t>
<t hangText="UA:">User Agent (SIP)</t>
<t hangText="UDP:">User Datagram Protocol (RFC 768)</t>
</list></t>
</section>
<section title="Terminology">
<t>In addition to following, the definitions from <xref
target="RFC3550">RTP</xref>, <xref target="RFC4585">AVPF</xref>, <xref
target="RFC5104">CCM</xref>, and <xref
target="I-D.ietf-avtext-rtp-grouping-taxonomy">RTP Taxonomy</xref>
also apply in this document.</t>
<t><list style="hanging">
<t hangText="Feedback Messages:"><xref target="RFC5104">CCM</xref>
categorized different RTCP feedback messages into four types,
Request, Command, Indication and Notification. This document
places the PAUSE and RESUME messages into Request category, PAUSED
as Indication and REFUSE as Notification.<list style="hanging">
<t hangText="PAUSE">Request from a media receiver to pause a
stream</t>
<t hangText="RESUME">Request from a media receiver to resume a
paused stream</t>
<t hangText="PAUSED">Indication from a media sender that a
stream is paused</t>
<t hangText="REFUSE">Notification from a media sender that a
PAUSE or RESUME request will not be honored</t>
</list></t>
<t hangText="Acknowledgement:">The confirmation from receiver to
sender that the message has been received.</t>
<t hangText="Sender:">The RTP entity that sends an RTP Packet
Stream.</t>
<t hangText="Receiver:">The RTP entity that receives an RTP Packet
Stream.</t>
<t hangText="Mixer:">The intermediate RTP node which receives a
Packet Stream from different nodes, combines them to make one
stream and forwards to destinations, in the sense described in
Topo-Mixer of <xref
target="I-D.ietf-avtcore-rtp-topologies-update">RTP
Topologies</xref>.</t>
<t hangText="Participant:">A member which is part of an RTP
session, acting as receiver, sender or both.</t>
<t hangText="Paused Sender:">An RTP sender that has stopped its
transmission, i.e. no other participant receives its RTP
transmission, either based on having received a PAUSE request,
defined in this specification, or based on a local decision.</t>
<t hangText="Pausing Receiver:">An RTP receiver which sends a
PAUSE request, defined in this specification, to other
participant(s).</t>
<t hangText="Stream:">Used as a short term for Source Packet
Stream, unless otherwise noted.</t>
</list></t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="sec-use-cases" title="Use Cases">
<t>This section discusses the main use cases for media stream pause and
resume.</t>
<section anchor="sec-point-to-point" title="Point to Point">
<t>This is the most basic use case with an RTP session containing two
end-points. Each end-point sends one or more streams.</t>
<figure align="center" anchor="fig-point-to-point"
title="Point to Point">
<artwork><![CDATA[
+---+ +---+
| A |<------->| B |
+---+ +---+
]]></artwork>
</figure>
<t>The usage of media stream pause in this use case is to temporarily
halt media delivery of streams that the sender provides but the
receiver does not currently use. This can for example be due to
minimized applications where the video stream is not actually shown on
any display, and neither is it used in any other way, such as being
recorded.</t>
<t>In this case, since there is only a single receiver of the stream,
pausing or resuming a stream does not impact anyone else than the
sender and the single receiver of that stream.</t>
<t>RTCWEB WG's <xref
target="I-D.ietf-rtcweb-use-cases-and-requirements">use case and
requirements document</xref> defines the following API requirements in
Appendix A, used also by W3C WebRTC WG:<list style="hanging">
<t hangText="A8">The Web API must provide means for the web
application to mute/unmute a stream or stream component(s). When a
stream is sent to a peer mute status must be preserved in the
stream received by the peer.</t>
<t hangText="A9">The Web API must provide means for the web
application to cease the sending of a stream to a peer.</t>
</list>This memo provides means to optimize transport usage by stop
sending muted streams and start sending again when unmuting.</t>
</section>
<section anchor="sec-mixer-to-media-sender"
title="RTP Mixer to Media Sender">
<t>One of the most commonly used topologies in centralized
conferencing is based on the <xref
target="I-D.ietf-avtcore-rtp-topologies-update">RTP Mixer</xref>. The
main reason for this is that it provides a very consistent view of the
RTP session towards each participant. That is accomplished through the
Mixer originating its´ own streams, identified by SSRC, and any
media sent to the participants will be sent using those SSRCs. If the
Mixer wants to identify the underlying Media Sources for its´
conceptual streams, it can identify them using CSRC. The stream the
Mixer provides can be an actual media mix of multiple Media Sources,
but it might also be switching received streams as described in
Sections 3.6-3.8 of <xref
target="I-D.ietf-avtcore-rtp-topologies-update"/>.</t>
<figure align="center" anchor="fig-mixer"
title="RTP Mixer in Unicast-only">
<artwork><![CDATA[
+---+ +-----------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +-----------+ +---+
]]></artwork>
</figure>
<t>Which streams that are delivered to a given receiver, A, can depend
on several things. It can either be the RTP Mixer´s own logic
and measurements such as voice activity on the incoming audio streams.
It can be that the number of sent Media Sources exceed what is
reasonable to present simultaneously at any given receiver. It can
also be a human controlling the conference that determines how the
media should be mixed; this would be more common in lecture or similar
applications where regular listeners may be prevented from breaking
into the session unless approved by the moderator. The streams may
also be part of a <xref target="I-D.westerlund-avtcore-rtp-simulcast">
Simulcast</xref> or <xref target="RFC6190">scalable encoded (for
Multi-Stream Transmission)</xref>, thus providing multiple versions
that can be delivered by the media sender. These examples indicate
that there are numerous reasons why a particular stream would not
currently be in use, but must be available for use at very short
notice if any dynamic event occurs that causes a different stream
selection to be done in the Mixer.</t>
<t>Because of this, it would be highly beneficial if the Mixer could
request to pause a particular stream from being delivered to it. It
also needs to be able to resume delivery with minimal delay.</t>
<t>Just as for <xref
target="sec-point-to-point">point-to-point</xref>, there is only a
single receiver of the stream, the RTP Mixer, and pausing or resuming
a stream does not affect anyone else than the sender and single
receiver of that stream.</t>
</section>
<section anchor="sec-mixer-to-media-sender-multipoint"
title="RTP Mixer to Media Sender in Point-to-Multipoint">
<t>This use case is similar to the previous section, however the RTP
Mixer is involved in three domains that need to be separated; the
Multicast Network (including participants A and C), participant B, and
participant D. The difference from above is that A and C share a
multicast domain, which is depicted below.</t>
<figure align="center" anchor="fig-mixer-multipoint"
title="RTP Mixer in Point-to-Multipoint">
<artwork><![CDATA[ +-----+
+---+ / \ +-----------+ +---+
| A |<---/ \ | |<---->| B |
+---+ / Multi- \ | | +---+
+ Cast +->| Mixer |
+---+ \ Network / | | +---+
| C |<---\ / | |<---->| D |
+---+ \ / +-----------+ +---+
+-----+
]]></artwork>
</figure>
<t>If the RTP Mixer pauses a stream from A, it will not only pause the
stream towards itself, but will also stop the stream from arriving to
C, which C is heavily impacted by, might not approve of, and should
thus have a say on.</t>
<t>If the Mixer resumes a paused stream from A, it will be resumed
also towards C. In this case, if C is not interested it can simply
ignore the stream and is not impacted as much as above.</t>
<t>In this use case there are several receivers of a stream and
special care must be taken as not to pause a stream that is still
wanted by some receivers.</t>
</section>
<section anchor="sec-media-receiver-to-mixer"
title="Media Receiver to RTP Mixer">
<t>An end-point in <xref target="fig-mixer"/> could potentially
request to pause the delivery of a given media stream. Possible
reasons include the ones in the <xref
target="sec-point-to-point">point to point case</xref> above.</t>
<t>When the RTP Mixer is only connected to individual unicast paths,
the use case and any considerations are identical to the point to
point use case.</t>
<t>However, when the end-point requesting media stream pause is
connected to the RTP Mixer through a multicast network, such as A or C
in <xref target="fig-mixer-multipoint"/>, the use case instead becomes
identical to the one in <xref
target="sec-mixer-to-media-sender-multipoint"/>, only with reverse
direction of the streams and pause/resume requests.</t>
</section>
<section anchor="sec-across-mixer"
title="Media Receiver to Media Sender Across RTP Mixer">
<t>An end-point, like A in <xref target="fig-mixer"/>, could
potentially request to pause the delivery of a given media stream,
like one of B's, over any of the SSRCs used by the Mixer by sending a
pause request for the CSRC identifying the media stream. However, the
authors are of the opinion that this is not a suitable solution, for
several reasons:<list style="numbers">
<t>The Mixer might not include CSRC in it´s stream
indications.</t>
<t>An end-point cannot rely on the CSRC to correctly identify the
media stream to be paused when the delivered media is some type of
mix. A more elaborate media stream identification solution is
needed to support this in the general case.</t>
<t>The end-point cannot determine if a given media stream is still
needed by the RTP Mixer to deliver to another session
participant.</t>
</list></t>
<t>Due to the above reasons, we exclude this use case from further
consideration.</t>
</section>
</section>
<section title="Design Considerations">
<t>This section describes the requirements that this specification needs
to meet.</t>
<section anchor="sec-real-time" title="Real-time Nature">
<t><xref target="sec-intro">The first section</xref> of this
specification describes some possible reasons why a receiver may pause
an RTP sender. Pausing and resuming is time-dependent, i.e. a receiver
may choose to pause an RTP stream for a certain duration, after which
the receiver may want the sender to resume. This time dependency means
that the messages related to pause and resume must be transmitted to
the sender in real-time in order for them to be purposeful. The pause
operation is arguably not very time critical since it mainly provides
a reduction of resource usage. Timely handling of the resume operation
is however likely to directly impact the end-user's perceived quality
experience, since it affects the availability of media that the user
expects to receive more or less instantly.</t>
</section>
<section anchor="sec-direction" title="Message Direction">
<t>It is the responsibility of a media receiver, who wants to pause or
resume a media stream from the sender(s), to transmit PAUSE and RESUME
messages. A media sender who likes to pause itself, can simply do it.
Any indication that an RTP media stream is paused is the
responsibility of the RTP media stream sender and may in some cases
not even be needed by the media stream receiver.</t>
</section>
<section anchor="sec-individual" title="Apply to Individual Sources">
<t>The PAUSE and RESUME messages apply to single RTP media streams
identified by their SSRC, which means the receiver targets the
sender's SSRC in the PAUSE and RESUME requests. If a paused sender
starts sending with a new SSRC, the receivers will need to send a new
PAUSE request in order to pause it. PAUSED indications refer to a
single one of the sender's own, paused SSRC.</t>
</section>
<section anchor="sec-consensus" title="Consensus">
<t>An RTP media stream sender should not pause an SSRC that some
receiver still wishes to receive. The reason is that in RTP topologies
where the media stream is shared between multiple receivers, a single
receiver on that shared network, independent of it being multicast, a
mesh with joint RTP session or a transport Translator based, must not
single-handedly cause the media stream to be paused without letting
all other receivers to voice their opinions on whether or not the
stream should be paused. A consequence of this is that a newly joining
receiver, for example indicated by an RTCP Receiver Report containing
both a new SSRC and a CNAME that does not already occur in the
session, firstly needs to learn the existence of paused streams, and
secondly should be able to resume any paused stream. Any single
receiver wanting to resume a stream should also cause it to be
resumed.</t>
</section>
<section anchor="sec-acks" title="Acknowledgements">
<t>RTP and RTCP does not guarantee reliable data transmission. It uses
whatever assurance the lower layer transport protocol can provide.
However, this is commonly UDP that provides no reliability guarantees.
Thus it is possible that a PAUSE and/or RESUME message transmitted
from an RTP end-point does not reach its destination, i.e. the
targeted RTP media stream sender. When PAUSE or RESUME reaches the RTP
media stream sender and are effective, i.e., an active media sender
pauses, or a resuming have media data to transmit, it is immediately
seen from the arrival or non-arrival of RTP packets for that RTP media
stream. Thus, no explicit acknowledgements are required in this
case.</t>
<t>In some cases when a PAUSE or RESUME message reaches the media
sender, it will not be able to pause or resume the stream due to some
local consideration, for example lack of data to transmit. This error
condition, a negative acknowledgement, may be needed to avoid
unnecessary <xref target="sec-retransmit">retransmission of
requests</xref>.</t>
</section>
<section anchor="sec-retransmit" title="Retransmitting Requests">
<t>When the media stream is not affected as expected by a PAUSE or
RESUME request, the request may have been lost and the sender of the
request will need to retransmit it. The retransmission should take the
round trip time into account, and will also need to take the normal
RTCP bandwidth and timing rules applicable to the RTP session into
account, when scheduling retransmission of feedback.</t>
<t>When it comes to resume requests that are more time critical, the
best resume performance may be achieved by repeating the request as
often as possible until a sufficient number have been sent to reach a
high probability of request delivery, or the media stream gets
delivered.</t>
</section>
<section anchor="sec-sequence" title="Sequence Numbering">
<t>A PAUSE request message will need to have a sequence number to
separate retransmissions from new requests. A retransmission keeps the
sequence number unchanged, while it is incremented every time a new
PAUSE request is transmitted that is not a retransmission of a
previous request.</t>
<t>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 PAUSE and RESUME. Thus, RESUME needs to share sequence
number space with PAUSE and implicitly references which PAUSE it
refers to. For the same reasons, the explicit PAUSED indication also
needs to share sequence number space with PAUSE and RESUME.</t>
</section>
</section>
<section title="Relation to Other Solutions">
<t>This section compares other possible solutions to achieve a similar
functionality, along with motivations why the current solution is
chosen.</t>
<section anchor="sec-comparison"
title="Signaling Technology Performance Comparison">
<t><list style="hanging">
<t hangText="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.</t>
</list></t>
<t>This section contains what is thought to be a realistic estimate of
one-way data transmission times for signaling implementing
functionalities of this specification.</t>
<t>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.</t>
<t>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.</t>
<t>Two different access technologies are compared:<list
style="symbols">
<t>Wired, fixed access is chosen as a representative low-delay
alternative.</t>
<t>Mobile wireless access according to <xref
target="TS36.201">3GPP LTE</xref>, also known as "4G", is chosen
as a representative high-delay alternative.</t>
</list></t>
<t>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
<xref target="TS25.308">3GPP HSPA</xref> (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.</t>
<t>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.</t>
<t>Three signaling alternatives are compared:<list style="symbols">
<t>Wireless UA to wireless UA, including two wireless links,
uplink and downlink.</t>
<t>Wireless UA to media server (MCU), including a single wireless
uplink.</t>
<t>Media server (MCU) to wireless UA, including a single wireless
downlink.</t>
</list></t>
<t>The reason to include separate results for wireless uplink and
downlink is that delay times can differ significantly.</t>
<t>The targeted topology is outlined in the following figure.</t>
<figure align="center" anchor="fig-signaling-topology"
title="Comparison Signaling Topology">
<artwork><![CDATA[
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 |
+------+ . +------+
]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>These assumptions are used for SIP signaling:<list style="symbols">
<t>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 <xref
target="TS26.114">3GPP MTSI</xref>, with the addition of SDP
feedback message indication outlined in <xref
target="sec-signaling">this specification</xref>. A more complex
media session with more streams would significantly add to the SDP
size.</t>
<t>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.</t>
<t>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.</t>
<t>Favorable case:<list style="symbols">
<t><xref target="RFC5049">SIP SigComp</xref> 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.</t>
</list></t>
<t>Unfavorable case:<list style="symbols">
<t>SIP message is not compressed on the mobile link.</t>
<t>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.</t>
</list></t>
</list>These assumptions are used for RTCP signaling:<list
style="symbols">
<t>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 <xref
target="sec-format"/>.</t>
<t>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.</t>
<t>Since there are random delay factors in RTCP transmission, the
expected, most probable value is used in the estimates.</t>
<t>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.</t>
<t>Favorable case:<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>Reduced-size RTCP is used, which is considered appropriate
for the type of messages defined in this specification.</t>
<t><xref target="RFC5225">RTP/RTCP header compression</xref>
is not used, not even on the mobile link.</t>
</list></t>
<t>Unfavorable case:<list style="symbols">
<t>The expected, regular AVPF RTCP interval is used, including
an expected value for timer re-consideration.</t>
<t>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.</t>
</list></t>
</list></t>
<t>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 <xref target="RFC5049">SigComp</xref> compression and
decompression in the favorable cases.</t>
<t>As a partial result, the message sizes can be compared, based on
the messages <xref target="sec-format">defined in this
specification</xref> and a <xref target="sec-signaling">SIP UPDATE
with contents </xref> 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.</t>
<figure anchor="fig-message-size" title="Message Size Comparison">
<artwork><![CDATA[
250 500 750 1000 1250 1500 [byte]
+---------+---------+---------+---------+---------+---------+--> Size
|
+-+--+
| |50| 125 RTCP
+-+--+---------------+--------------------------------------------+
| SIP | 525 1650 |
+--------------------+--------------------------------------------+
|
]]></artwork>
</figure>
<t>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.</t>
<figure anchor="fig-mobile-transmission-delay"
title="Mobile Access Transmission Delay Comparison">
<artwork><![CDATA[
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
+---+-----------------------------------------+
|
]]></artwork>
</figure>
<t>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.</t>
<t>The UA to MCU signaling corresponds to the use case in <xref
target="sec-media-receiver-to-mixer"/>. 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.</t>
<t>The MCU to UA signaling corresponds to the use case in <xref
target="sec-mixer-to-media-sender"/>. 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 <xref
target="sec-real-time"/>.</t>
<t>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.</t>
<figure anchor="fig-fixed-transmission-delay"
title="Fixed Access Transmission Delay Comparison">
<artwork><![CDATA[
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
+---+-----------------------------+
|
]]></artwork>
</figure>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC5626">SIP
keep-alive</xref>, 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 <xref target="RFC5049">SigComp</xref>. It may however
prove harder to reduce delays that comes from forwarding the SDP many
times between different signaling nodes.</t>
<t>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
<xref target="RFC3556">RTCP bandwidth SDP attributes</xref>. For RTP
media 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 media 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.</t>
</section>
<section anchor="sec-tmmbr" title="CCM TMMBR / TMMBN">
<t>The <xref target="RFC5104">Codec Control Messages
specification</xref> 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 <xref target="sec-individual">signal
per SSRC</xref> and using the <xref target="RFC4585">media path for
signaling (AVPF)</xref> will in most cases provide the <xref
target="sec-real-time">shortest achievable signaling delay</xref>.
However, in some cases the defined semantics for TMMBR differ from
what is required for PAUSE.</t>
<t>When there is only a single receiver of a media stream, TMMBR 0 and
PAUSE are effectively identical.</t>
<t>When there are several receivers of the same media stream, the
stream must <xref target="sec-consensus">not be paused until there are
no receiver that desires to receive it</xref>, 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
media receiver that sends TMMBR 0 will pause the stream for all
receivers.</t>
<t>When there is only a single receiver of a media stream that is
paused, TMMBR with a bitrate greater than 0 can effectively function
as a RESUME, resuming the media stream immediately <xref
target="sec-consensus">as needed</xref>.</t>
<t>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 <xref target="RFC5104"/>)
requires a media 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 media sender knows in the RTP session. So, there is both
the delay between the media sender receiving the TMMBR until it can
send a TMMBN, and the above delay for the guard period before the
media sender are 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
media stream receivers.</t>
</section>
<section anchor="sec-inactive"
title="SDP "inactive" Attribute">
<t>In <xref target="RFC4566">SDP</xref>, 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 <xref
target="RFC3264">re-negotiation</xref>, for example using <xref
target="RFC3261">SIP re-INVITE</xref>, possibly in combination with
ITU-T H.248 media gateway control.</t>
<t>This attribute is only possible to specify with media level
resolution, is not possible to signal <xref
target="sec-individual">per individual media stream (SSRC)</xref>, and
is thus not usable for RTP sessions containing more than a single
SSRC.</t>
<t>There is a per-ssrc attribute defined in <xref target="RFC5576"/>,
but that does currently not allow to set an individual stream (SSRC)
inactive.</t>
<t>Using "inactive" does thus not provide sufficient functionality for
the purpose of this specification.</t>
</section>
<section title="Media Source Selection in SDP">
<t>There is a draft that <xref
target="I-D.lennox-mmusic-sdp-source-selection">selects sources based
on SDP</xref> information. It builds on the <xref
target="RFC5576">per-ssrc attribute</xref> discussed <xref
target="sec-inactive">above</xref>.</t>
<t>The semantics differ between selecting a Media Source and pause /
resume for a stream in topologies other than point-to-point. For
example, in <xref target="sec-media-receiver-to-mixer">RTP Receiver to
Mixer</xref>, 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 <xref target="sec-consensus">consensus</xref> and
would likely also suffer from <xref target="sec-real-time">lower
real-time performance</xref>.</t>
</section>
<section anchor="sec-conclusion" title="Conclusion">
<t>As can be seen from <xref target="sec-comparison"/>, 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.</t>
<t>Especially for UA sitting on mobile wireless access, this will risk
introducing delays that are <xref target="sec-real-time">too
long</xref> to provide a good user experience, and the bandwidth cost
may also be considered infeasible compared to an RTCP-based
solution.</t>
<t>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.</t>
<t>Based on those reasons, RTCP is proposed as signaling protocol for
the pause and resume functionality. Much of the wanted functionality
can in a point-to-point case be achieved with the existing <xref
target="RFC5104">TMMBR/TMMBN CCM messages</xref>, but they cannot be
used when the media stream is sent to multiple simultaneous
receivers.</t>
</section>
</section>
<section anchor="sec-overview" title="Solution Overview">
<t>The proposed solution implements PAUSE and RESUME functionality based
on sending AVPF RTCP feedback messages from any RTP session participant
that wants to pause or resume a media stream targeted at the media
stream sender, as identified by the sender SSRC.</t>
<t>It is proposed to re-use <xref target="RFC5104">CCM TMMBR and
TMMBN</xref> to the extent possible, and to define a small set of new
RTCP feedback messages where new semantics is needed. Considerations
that that apply when using TMMBR/TMMBN for pause and resume purposes are
also described.</t>
<t>A single Feedback message specification is used to implement the new
messages. The message consists of a number of Feedback Control
Information (FCI) blocks, where each block can be a PAUSE request, a
RESUME request, PAUSED indication, a REFUSE response, or an extension to
this specification. This structure allows a single feedback message to
handle pause functionality on a number of media streams.</t>
<t>The PAUSED functionality is also defined in such a way that it can be
used standalone by the media sender to indicate a local decision to
pause, and inform any receiver of the fact that halting media delivery
is deliberate and which RTP packet was the last transmitted.</t>
<t>This section is intended to be explanatory and therefore
intentionally contains no mandatory statements. Such statements can
instead be found in other parts of this specification.</t>
<section anchor="sec-overview-cap" title="Expressing Capability">
<t>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 PAUSED indication is defined separately from
the others to support partial implementation, which is specifically
believed to be feasible for the <xref
target="sec-mixer-to-media-sender">RTP Mixer to Media Sender use
case</xref>.</t>
<t>For the case when TMMBR/TMMBN are used for pause and resume
purposes, it is possible to explicitly express joint support for TMMBR
and TMMBN, but not for TMMBN only.</t>
</section>
<section anchor="sec-overview-pause" title="Requesting to Pause">
<t>An RTP media stream receiver can choose to request PAUSE at any
time, subject to AVPF timing rules. This also applies when using TMMBR
0 in the point-to-point case.</t>
<t>The PAUSE request contains a PauseID, which is incremented by one
(in modulo arithmetic) with each PAUSE request that is not a
re-transmission. The PauseID is scoped by and thus a property of the
targeted RTP media stream (SSRC).</t>
<t>When a non-paused RTP media stream sender receives the PAUSE
request, it continues to send media while waiting for some time to
allow other RTP media stream receivers in the same RTP session that
saw this PAUSE request to disapprove by sending a <xref
target="sec-overview-resume">RESUME</xref> for the same stream and
with the same PauseID as in the disapproved PAUSE. If such
disapproving RESUME arrives at the RTP media stream sender during the
wait period before the stream is paused, the pause is not performed.
In point-to-point configurations, the wait period may be 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.</t>
<t>If the RTP media stream sender receives further PAUSE requests with
the available PauseID while waiting as described above, those
additional requests are ignored.</t>
<t>If the PAUSE request or TMMBR 0 is lost before it reaches the RTP
media stream sender, it will be discovered by the RTP media stream
receiver because it continues to receive the RTP media stream. It will
also not see any <xref target="sec-overview-pausing">PAUSED
indication</xref> or TMMBN 0 for the stream. The same condition can be
caused by the RTP media stream sender having received a disapproving
RESUME from a media stream receiver A for a PAUSE request sent by a
media stream sender B, but that the PAUSE sender (B) did not 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 same
PauseID. If using TMMBR 0 the request MAY be re-transmitted when the
requestor fails to receive a TMMBN 0 confirmation.</t>
<t>If the pending stream pause is aborted due to a disapproving
RESUME, the PauseID from the disapproved PAUSE is invalidated by the
RESUME and any new PAUSE must use an incremented PauseID (in modulo
arithmetic) to be effective.</t>
<t>An RTP media stream sender receiving a PAUSE not using the
available PauseID informs the RTP media stream receiver sending the
ineffective PAUSE of this condition by sending a REFUSE response that
contains the next available PauseID value. This REFUSE also informs
the RTP media stream receiver that it is probably not feasible to send
another PAUSE for some time, not even with the available PauseID,
since there are other RTP media stream receivers that wish to receive
the stream.</t>
<t>A similar situation where an ineffective PauseID is chosen can
appear when a new RTP media stream receiver joins a session and wants
to PAUSE a stream, but does not yet know the available PauseID to use.
The REFUSE response will then provide sufficient information to create
a valid PAUSE. The required extra signaling round-trip is not
considered harmful, since it is assumed that pausing a stream is not
<xref target="sec-real-time">time-critical</xref>.</t>
<t>There may be local considerations making it impossible or
infeasible to pause the stream, and the RTP media stream sender can
then respond with a REFUSE. In this case, if the used PauseID would
otherwise have been effective, the REFUSE contains the same PauseID as
in the PAUSE request, and the PauseID is kept as available.</t>
<t>If the RTP media stream sender receives several identical PAUSE for
an RTP media stream that was already at least once responded with
REFUSE and the condition causing REFUSE remains, those additional
REFUSE should be sent with regular RTCP timing. A single REFUSE can
respond to several identical PAUSE requests.</t>
</section>
<section anchor="sec-overview-pausing" title="Media Sender Pausing">
<t>An RTP media 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 some local sender consideration. When it does, it sends a PAUSED
indication, containing the available PauseID. If the stream was 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 TMMBN 0,
except for PAUSED message parameters. Note that PauseID is incremented
when pausing locally (without having received a PAUSE). It also sends
the PAUSED indication in the next two regular RTCP reports, given that
the pause condition is then still effective.</t>
<t>The RTP media stream sender may want to apply some local
consideration to exactly when the stream is paused, for example
completing some media unit or a forward error correction block, before
pausing the stream.</t>
<t>The PAUSED indication also contains information about the RTP
extended highest sequence number when the pause became effective. This
provides RTP media stream receivers with first hand information
allowing them to know whether they lost any packets just before the
stream paused or when the stream is resumed again. This allows RTP
media stream receivers to quickly and safely take into account that
the stream is paused, in for example retransmission or congestion
control algorithms.</t>
<t>If the RTP media stream sender receives PAUSE requests with the
available PauseID while the stream is already paused, those requests
are ignored.</t>
<t>As long as the stream is being paused, the PAUSED indication MAY be
sent together with any regular RTCP SR or RR. Including PAUSED in this
way allows RTP media stream receivers joining while the stream is
paused to quickly know that there is a paused stream, what the last
sent extended RTP sequence number was, and what the next available
PauseID is to be able to construct valid PAUSE and RESUME requests at
a later stage.</t>
<t>When the RTP media 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 previously seen in the RTP session, it should send PAUSED
indications for all its paused streams at its earliest opportunity. It
should in addition continue to include PAUSED indications in at least
two regular RTCP reports.</t>
</section>
<section anchor="sec-overview-resume" title="Requesting to Resume">
<t>An RTP media stream receiver can request to resume a stream with a
RESUME request at any time, subject to AVPF timing rules. If the
stream was paused with TMMBR 0, resuming the stream is made with TMMBR
containing a bitrate value larger than 0. The bitrate value used when
resuming after a PAUSE with TMMBR 0 is either according to known
limitations, or the configured maximum for the stream or session. What
is said on RESUME in the rest of this paragraph apply also to the use
of TMMBR with a bitrate value larger than 0, except for RESUME message
parameters.</t>
<t>The RTP media stream receiver must include the available PauseID in
the RESUME request for it to be effective.</t>
<t>A pausing RTP media stream sender that receives a RESUME including
the correct available PauseID resumes the stream at the earliest
opportunity. Receiving RESUME requests for a stream that is not paused
does not require any action and can be ignored.</t>
<t>There may be local considerations, for example that the media
device is not ready, making it temporarily impossible to resume the
stream at that point in time, and the RTP media stream sender MAY then
respond with a REFUSE containing the same PauseID as in the RESUME.
When receiving such REFUSE with a PauseID identical to the one in the
sent RESUME, RTP media stream receivers SHOULD then avoid sending
further RESUME requests for some reasonable amount of time, to allow
the condition to clear.</t>
<t>If the RTP media stream sender receives several identical RESUME
for an RTP media stream that was already at least once responded with
REFUSE and the condition causing REFUSE remains, those additional
REFUSE should be sent with regular RTCP timing. A single REFUSE can
respond to several identical RESUME requests.</t>
<t>When resuming a paused media stream, especially for media that
makes use of temporal redundancy between samples such as video, the
temporal dependency between samples taken before the pause and at the
time instant the stream is resumed may not be appropriate to use in
the encoding. Should such temporal dependency between before and after
the media was paused be used by the media sender, it requires the
media receiver to have saved the sample from before the pause for
successful continued decoding when resuming. The use of this temporal
dependency is left up to the media sender. If temporal dependency is
not used when media is resumed, the first encoded sample after the
pause will not contain any temporal dependency to samples before the
pause (for video it may be a so-called intra picture). If temporal
dependency to before the pause is used by the media sender when
resuming, and if the media receiver did not save any sample from
before the pause, the media receiver can use a <xref
target="RFC5104">FIR request</xref> to explicitly ask for a sample
without temporal dependency (for video a so-called intra picture),
even at the same time as sending the RESUME.</t>
</section>
<section anchor="sec-overview-tmmbr" title="TMMBR/TMMBN Considerations">
<t>As stated, TMMBR/TMMBN may be used to provide pause and resume
functionality for the point-to-point case. If the topology is not
point-to-point, TMMBR/TMMBN cannot safely be used for pause or
resume.</t>
<t>This is a brief summary of what functionality is provided when
using TMMBR/TMMBN:<list style="hanging">
<t hangText="TMMBR 0:">Corresponds to PAUSE, without the
requirement for any hold-off period to wait for RESUME before
pausing the media stream.</t>
<t hangText="TMMBR >0:">Corresponds to RESUME when the media
stream was previously paused with TMMBR 0. Since there is only a
single media receiver, there is no need for the media sender to
delay resuming the media stream until after sending TMMBN >0,
or to apply the hold-off period specified in <xref
target="RFC5104"/> before increasing the bitrate from zero.</t>
<t hangText="TMMBN 0:">Corresponds to PAUSED. Also corresponds to
a REFUSE indication when a media stream is requested to be resumed
with TMMBR >0.</t>
<t hangText="TMMBN >0:">Corresponds to a REFUSE indication when
a media stream is requested to be paused with TMMBR 0.</t>
</list></t>
</section>
</section>
<section anchor="sec-states" title="Participant States">
<t>This document introduces three new states for a media stream in an
RTP sender, according to the figure and sub-sections below. Any
references to PAUSE, PAUSED, RESUME and REFUSE in this section SHALL be
taken to apply to the extent possible also when <xref
target="sec-overview-tmmbr">TMMBR/TMMBN are used</xref> for this
functionality.</t>
<!--MW: Need to discuss how Local Paused interacts with Requests.-->
<figure align="center" anchor="fig-pause-states"
title="RTP Pause States">
<artwork><![CDATA[
+------------------------------------------------------+
| Received RESUME |
v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision |
| | v |
| | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+
+-------------------------| Paused |
RESUME decision +---------+
]]></artwork>
</figure>
<section anchor="sec-state-playing" title="Playing State">
<t>This state is not new, but is the normal media sending state from
<xref target="RFC3550"/>. When entering the state, the PauseID MUST be
incremented 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 highest RTP sequence number sent before the pause. The
first RTP Time Stamp for the first packet sent after a pause SHOULD be
set according to capture times at the source.</t>
</section>
<section anchor="sec-state-pausing" title="Pausing State">
<t>In this state, the media sender has received at least one PAUSE
message for the stream in question. The media sender SHALL wait during
a hold-off period for the possible reception of RESUME messages for
the RTP media stream being paused before actually pausing media
transmission. The period to wait SHALL be long enough to allow another
media receiver to respond to the PAUSE with a RESUME, if it determines
that it would not like to see the stream paused. This delay period
(denoted by 'Hold-off period' in the figure) is determined by the
formula:<list style="empty">
<t>2 * RTT + T_dither_max,</t>
</list></t>
<t>where RTT is the longest round trip known to the media sender and
T_dither_max is defined in section 3.4 of <xref target="RFC4585"/>.
The hold-off period MAY be set to 0 by some <xref
target="sec-signaling">signaling</xref> means when it can be
determined that there is only a single receiver, for example in
point-to-point or some unicast situations.</t>
<!--MW: In future version the above values should be more clearly motivated.-->
<t>If the RTP media stream sender has set the hold-off period to 0 and
receives information that it was an incorrect decision and that there
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.</t>
</section>
<section anchor="sec-state-paused" title="Paused State">
<t>An RTP media stream is in paused state when the sender pauses its
transmission after receiving at least one PAUSE message and the
hold-off period has passed without receiving any RESUME message for
that stream.</t>
<t>When entering the state, the media sender SHALL send a PAUSED
indication to all known media receivers, and SHALL also repeat PAUSED
in the next two regular RTCP reports.</t>
<t>Following sub-sections discusses some potential issues when an RTP
sender goes into paused state. These conditions are also valid if an
RTP Translator is used in the communication. When an RTP Mixer
implementing this specification is involved between the participants
(which forwards the stream by marking the RTP data with its own SSRC),
it SHALL be a responsibility of the Mixer to control sending PAUSE and
RESUME requests to the sender. The below conditions also apply to the
sender and receiver parts of the RTP Mixer, respectively.</t>
<section anchor="sec-bye" title="RTCP BYE Message">
<t>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
6.3.7 of <xref target="RFC3550">RTP</xref>, following two conditions
MUST also be considered when an RTP participant sends an RTCP BYE
message,</t>
<t><list style="symbols">
<t>If a paused sender sends an RTCP BYE message, receivers
observing this SHALL NOT send further PAUSE or RESUME requests
to it.</t>
<t>Since a sender pauses its transmission on receiving the PAUSE
requests from any receiver in a session, the sender MUST keep
record of which receiver that caused the RTP media stream to
pause. If that receiver sends an RTCP BYE message observed by
the sender, the sender SHALL resume the RTP media stream.</t>
</list></t>
</section>
<section anchor="sec-time-out" title="SSRC Time-out">
<t>Section 6.3.5 in <xref target="RFC3550">RTP</xref> describes the
SSRC time-out of an RTP participant. Every RTP participant maintains
a sender and receiver 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 intervals it removes that participant from the
receiver list. Any streams that were paused by that removed
participant SHALL be resumed.</t>
</section>
</section>
<section anchor="sec-state-local-paused" title="Local Paused State">
<t>This state can be entered at any time, based on local decision from
the media sender. As for <xref target="sec-state-paused">Paused
State</xref>, the media sender SHALL send a PAUSED indication to all
known media receivers, when entering the state, and repeat it in the
next two regular RTCP reports.</t>
<t>When leaving the state, the stream state SHALL become Playing,
regardless whether or not there were any media receivers that sent
PAUSE for that stream, effectively clearing the media sender's memory
for that media stream.</t>
</section>
</section>
<section anchor="sec-format" title="Message Format">
<t>Section 6 of <xref target="RFC4585">AVPF</xref> defines three types
of low-delay RTCP feedback messages, i.e. Transport layer,
Payload-specific, and Application layer feedback messages. This document
defines a new Transport layer feedback message, this message is either a
PAUSE request, a RESUME request, or one of four different types of
acknowledgements in response to either PAUSE or RESUME requests.</t>
<t>The Transport layer feedback messages are identified by having the
RTCP payload type be RTPFB (205) as defined by <xref
target="RFC4585">AVPF</xref>. The PAUSE and RESUME messages are
identified by Feedback Message Type (FMT) value in common packet header
for feedback message defined in section 6.1 of <xref
target="RFC4585">AVPF</xref>. The PAUSE and RESUME transport feedback
message is identified by the FMT value = TBA1.</t>
<t>The Common Packet Format for Feedback Messages is defined by <xref
target="RFC4585">AVPF</xref> is:</t>
<figure>
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :]]></artwork>
</figure>
<t>For the PAUSE and RESUME messages, the following interpretation of
the packet fields will be:</t>
<t><list style="hanging">
<t hangText="FMT:">The FMT value identifying the PAUSE and RESUME
message: TBA1</t>
<t hangText="PT:">Payload Type = 205 (RTPFB)</t>
<t hangText="Length:">As defined by AVPF, i.e. the length of this
packet in 32-bit words minus one, including the header and any
padding.</t>
<t hangText="SSRC of packet sender:">The SSRC of the RTP session
participant sending the messages in the FCI. Note, for end-points
that have multiple SSRCs in an RTP session, any of its SSRCs MAY be
used to send any of the pause message types.</t>
<t hangText="SSRC of media source:">Not used, SHALL be set to 0. The
FCI identifies the SSRC the message is targeted for.</t>
</list>The Feedback Control Information (FCI) field consist of one or
more PAUSE, RESUME, PAUSED, REFUSE, or any future extension. These
messages have the following FCI format:</t>
<figure anchor="fig-syntax"
title="Syntax of FCI Entry in the PAUSE and RESUME message">
<artwork><![CDATA[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res | Parameter Len | PauseID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Type Specific :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The FCI fields have the following definitions:<list style="hanging">
<t hangText="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 be the SSRC being paused. If pausing is the
result of a PAUSE request, the value in PAUSED is effectively the
same as Target SSRC in a related PAUSE request. For REFUSE, it MUST
be the Target SSRC of the PAUSE or RESUME request that cannot change
state. A CSRC MUST NOT be used as a target as the interpretation of
such a request is unclear.</t>
<t hangText="Type (4 bits):">The pause feedback type. The values
defined in this specification are as follows,<list style="hanging">
<t hangText="0:">PAUSE request message</t>
<t hangText="1:">RESUME request message</t>
<t hangText="2:">PAUSED indication message</t>
<t hangText="3:">REFUSE indication message</t>
<t hangText="4-15:">Reserved for future use</t>
</list></t>
<t hangText="Res: (4 bits):">Type specific reserved. SHALL be
ignored by receivers implementing this specification and MUST be set
to 0 by senders implementing this specification.</t>
<t hangText="Parameter Len: (8 bits):">Length of the Type Specific
field in 32-bit words. MAY be 0.</t>
<t hangText="PauseID (16 bits):">Message sequence identification.
SHALL be incremented by one modulo 2^16 for each new PAUSE message,
unless the message is re-transmitted. The initial value SHOULD be 0.
The PauseID is scoped by the Target SSRC, meaning that PAUSE,
RESUME, and PAUSED messages therefore share the same PauseID space
for a specific Target SSRC.</t>
<t hangText="Type Specific: (variable):">Defined per pause feedback
Type. MAY be empty.</t>
</list></t>
<t/>
</section>
<section anchor="sec-details" title="Message Details">
<t>This section contains detailed explanations of each message defined
in this specification. All transmissions of request and indications are
governed by the transmission rules as defined by <xref
target="sec-transmission"/>.</t>
<t>Any references to PAUSE, PAUSED, RESUME and REFUSE in this section
SHALL be taken to apply to the extent possible also when <xref
target="sec-overview-tmmbr">TMMBR/TMMBN are used</xref> for this
functionality. TMMBR/TMMBN MAY be used instead of the messages defined
in this specification when the effective topology is point-to-point. If
either sender or receiver learns that the topology is not
point-to-point, TMMBR/TMMBN MUST NOT be used for pause/resume
functionality. If the messages defined in this specification are
supported in addition to TMMBR/TMMBN, pause/resume signaling MUST revert
to use those instead. If the topology is not point-to-point and the
messages defined in this specification are not supported, pause/resume
functionality with TMMBR/TMMBN MUST NOT be used.</t>
<section anchor="sec-pause" title="PAUSE">
<t>An RTP media stream receiver MAY schedule PAUSE for transmission at
any time.</t>
<t>PAUSE has no defined Type Specific parameters and Parameter Len
MUST be set to 0.</t>
<t>PauseID SHOULD be the available PauseID, as indicated by <xref
target="sec-paused">PAUSED</xref> or implicitly determined by
previously received PAUSE or <xref target="sec-resume">RESUME</xref>
requests. A randomly chosen PauseID MAY be used if it was not possible
to retrieve PauseID information, in which case the PAUSE will either
succeed, or the correct PauseID can be learnt from the returned <xref
target="sec-refuse">REFUSE</xref>. A PauseID that is matching the
available PauseID is henceforth also called a valid PauseID.</t>
<t>PauseID needs to be incremented by one, in modulo arithmetic, for
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
to ensure that the PauseID matches what is the current available
PauseID at the media sender. The media sender increments what it
considers to be the available PauseID when entering <xref
target="sec-state-playing">Playing State</xref>.</t>
<t>For the scope of this specification, a PauseID larger than the
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
the modulo operator. Similarly, a PauseID smaller than the current one
is defined as having a value between and including (PauseID - 2^15)
MOD 2^16 and (PauseID - 1) MOD 2^16.</t>
<t>If an RTP media stream receiver that sent a PAUSE with a certain
PauseID receives a RESUME with the same PauseID, it is RECOMMENDED
that it refrains from sending further PAUSE requests for some
appropriate time since the RESUME indicates that there are other
receivers that still wishes to receive the stream.</t>
<t>If the targeted RTP media stream does not pause, if no PAUSED
indication 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 for retransmission, using the same PauseID. RTT is the
observed round-trip to the RTP media stream sender and T_dither_max is
defined in section 3.4 of <xref target="RFC4585"/>.</t>
<t>When an RTP media stream sender in <xref
target="sec-state-playing">Playing State</xref> receives a valid
PAUSE, and unless local considerations currently makes it impossible
to pause the stream, it SHALL enter <xref
target="sec-state-pausing">Pausing State</xref> when reaching an
appropriate place to pause in the media stream, and act
accordingly.</t>
<t>If an RTP media stream sender receives a valid PAUSE while in
Pausing, <xref target="sec-state-paused">Paused</xref> or <xref
target="sec-state-local-paused">Local Paused</xref> States, the
received PAUSE SHALL be ignored.</t>
</section>
<section anchor="sec-paused" title="PAUSED">
<t>The PAUSED indication MAY be sent either as a result of a valid
<xref target="sec-pause">PAUSE</xref> request, when entering <xref
target="sec-state-paused">Paused State</xref>, or based on a RTP media
stream sender local decision, when entering <xref
target="sec-state-local-paused">Local Paused State</xref>.</t>
<t>PauseID MUST contain the available, valid value to be included in a
subsequent <xref target="sec-resume">RESUME</xref>.</t>
<t>PAUSED SHALL contain a 32 bit parameter with the RTP extended
highest sequence number valid when the RTP media stream was paused.
Parameter Len MUST be set to 1.</t>
<t>After having entered Paused or Local Paused State and thus having
sent PAUSED once, PAUSED MUST also be included in the next two regular
RTCP reports, given that the pause condition is then still
effective.</t>
<t>While remaining in Paused or Local Paused States, PAUSED MAY be
included in all regular RTCP reports.</t>
<t>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
two regular RTCP reports, whenever the RTP media sender learns that
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
previously seen in the RTP session.</t>
</section>
<section anchor="sec-resume" title="RESUME">
<t>An RTP media stream receiver MAY schedule RESUME for transmission
whenever it wishes to resume a paused stream, or to disapprove a
stream from being paused.</t>
<t>PauseID SHOULD be the valid PauseID, as indicated by <xref
target="sec-paused">PAUSED</xref> or implicitly determined by
previously received <xref target="sec-pause">PAUSE</xref> or RESUME
requests. A randomly chosen PauseID MAY be used if it was not possible
to retrieve PauseID information, in which case the RESUME will either
succeed, or the correct PauseID can be learnt from a returned <xref
target="sec-refuse">REFUSE</xref>.</t>
<t>RESUME has no defined Type Specific parameters and Parameter Len
MUST be set to 0.</t>
<t>When an RTP media stream sender in <xref
target="sec-state-pausing">Pausing</xref>, <xref
target="sec-state-paused">Paused</xref> or <xref
target="sec-state-local-paused">Local Paused State</xref> receives a
valid RESUME, and unless local considerations currently makes it
impossible to resume the stream, it SHALL enter <xref
target="sec-state-playing">Playing State</xref> and act accordingly.
If the RTP media stream sender is incapable of honoring the RESUME
request with a valid PauseID, or receives a RESUME request with an
invalid PauseID while in Paused or Pausing state, the RTP media stream
sender sends a REFUSE message as specified below.</t>
<t>If an RTP media stream sender in Playing State receives a RESUME
containing either a valid PauseID or a PauseID that is less than the
valid PauseID, the received RESUME SHALL be ignored.</t>
</section>
<section anchor="sec-refuse" title="REFUSE">
<t>REFUSE has no defined Type Specific parameters and Parameter Len
MUST be set to 0.</t>
<t>If an RTP media sender receives a valid <xref
target="sec-pause">PAUSE</xref> or <xref
target="sec-resume">RESUME</xref> request that cannot be fulfilled by
the sender due to some local consideration, it SHALL schedule
transmission of a REFUSE indication containing the valid PauseID from
the rejected request.</t>
<t>If an RTP media stream sender receives PAUSE or RESUME requests
with a non-valid PauseID it SHALL schedule a REFUSE response
containing the available, valid PauseID, except if the RTP media
stream sender is in Playing State and receives a RESUME with a PauseID
less than the valid one, in which case the RESUME SHALL be
ignored.</t>
<t>If several PAUSE or RESUME that would render identical REFUSE
responses are received before the scheduled REFUSE is sent, duplicate
REFUSE MUST NOT be scheduled for transmission. This effectively lets a
single REFUSE respond to several invalid PAUSE or RESUME requests.</t>
<t>If REFUSE containing a certain PauseID was already sent and yet
more PAUSE or RESUME messages are received that require additional
REFUSE with that specific PauseID to be scheduled, and unless the
PauseID number space has wrapped since REFUSE was last sent with that
PauseID, further REFUSE messages with that PauseID SHOULD be sent in
regular RTCP reports.</t>
<t>An RTP media stream receiver that sent a PAUSE or RESUME request
and receives a REFUSE containing the same PauseID as in the request
SHOULD refrain from sending an identical request for some appropriate
time to allow the condition that caused REFUSE to clear.</t>
<t>An RTP media stream receiver that sent a PAUSE or RESUME request
and receives a REFUSE containing a PauseID different from the request
MAY schedule another request using the PauseID from the REFUSE
indication.</t>
</section>
<section anchor="sec-transmission" title="Transmission Rules">
<t>The transmission of any RTCP feedback messages defined in this
specification MUST follow the normal AVPF defined timing rules and
depends on the session's mode of operation.</t>
<t>All messages defined in this specification MAY use either Regular,
Early or Immediate timings, taking the following into
consideration:<list style="symbols">
<t>PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing.</t>
<t>The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing.</t>
<t>RESUME SHOULD always use Immediate or Early timing.</t>
<t>The first transmission of REFUSE for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
REFUSE for that PauseID SHOULD use Regular timing.</t>
</list></t>
</section>
</section>
<section anchor="sec-signaling" title="Signalling">
<t>The capability of handling messages defined in this specification MAY
be exchanged at a higher layer such as SDP. This document extends the
rtcp-fb attribute defined in section 4 of <xref
target="RFC4585">AVPF</xref> to include the request for pause and
resume. Like <xref target="RFC4585">AVPF</xref> and <xref
target="RFC5104">CCM </xref>, it is RECOMMENDED to use the rtcp-fb
attribute at media level and it MUST NOT be used at session level. This
specification follows all the rules defined in AVPF for rtcp-fb
attribute relating to payload type in a session description.<list
style="empty">
<t>Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
resume functionality (with the restrictions described in this memo),
signaling rtcp-fb attribute with ccm tmmbr parameter is sufficient
and no further signaling is necessary.</t>
<!--MW: This note is partially incorrect and should be addressed. A TMMBR implementation may support
TMMBR 0 but there are no guarantee. Therefore it would be more correct that request that
explicit pause signalling is used, and that it is noted that some TMMBR only indicating systems
may in fact support TMMBR 0 signalling. -->
</list></t>
<t>This specification defines two new parameters to the "ccm" feedback
value defined in <xref target="RFC5104">CCM</xref>, "pause" and
"paused".<list style="symbols">
<t>"pause" represents the capability to understand the RTCP feedback
message and all of the defined FCIs of PAUSE, RESUME, PAUSED and
REFUSE. A direction sub-parameter is used to determine if a given
node desires to issue PAUSE or RESUME requests, can respond to PAUSE
or RESUME requests, or both.</t>
<t>"paused" represents the functionality of supporting the playing
and local paused states and generate PAUSED FCI when a media stream
delivery is paused. A direction sub-parameter is used to determine
if a given node desires to receive these indications, intends to
send them, or both.</t>
</list></t>
<t>The reason for this separation is to make it possible for partial
implementation of this specification, according to the different roles
in the <xref target="sec-use-cases">use cases section</xref>.</t>
<t>A sub-parameter named "nowait", indicating that the hold-off time
defined in <xref target="sec-state-pausing"/> can be set to 0, reducing
the latency before the media stream can paused after receiving a PAUSE
request. This condition occurs when there will be only a single receiver
per direction in the RTP session, for example in point-to-point
sessions. It is also possible to use in scenarios using unidirectional
media. The conditions that allow "nowait" to be set also indicate that
it would be possible to use CCM TMMBR/TMMBN as pause/resume
signaling.</t>
<t>A sub-parameter named "dir" is used to indicate in which directions a
given node will use the pause or paused functionality. The node being
configured or issuing an offer or an answer uses the directionality in
the following way. Note that pause and paused have separate and
different definitions.</t>
<t>Direction ("dir") values for "pause" is defined as follows:<list
style="hanging">
<t hangText="sendonly:">The node intends to send PAUSE and RESUME
requests for other nodes' media streams and is thus also capable of
receiving PAUSED and REFUSE. It will not support receiving PAUSE and
RESUME requests.</t>
<t hangText="recvonly:">The node supports receiving PAUSE and RESUME
requests targeted for media streams sent by the node. It will send
PAUSED and REFUSE as needed. The node will not send any PAUSE and
RESUME requests.</t>
<t hangText="sendrecv:">The node supports receiving PAUSE and RESUME
requests targeted for media streams sent by the node. The node
intends to send PAUSE and RESUME requests for other nodes' media
streams. Thus the node is capable of sending and receiving all types
of pause messages. This is the default value. If the "dir" parameter
is omitted, it MUST be interpreted to represent this value.</t>
</list></t>
<t>Direction values for "paused" is defined as follows:<list
style="hanging">
<t hangText="sendonly:">The node intends to send PAUSED indications
whenever it pauses media delivery in any of its media streams. It
has no need to receive PAUSED indications itself.</t>
<t hangText="recvonly:">The node desires to receive PAUSED
indications whenever any media stream sent by another node is
paused. It does not intend to send any PAUSED indications.</t>
<t hangText="sendrecv:">The nodes desires to receive PAUSED
indications and intends to send PAUSED indications whenever any
media stream is paused. This is the default value. If the "dir"
parameter is omitted, it MUST be interpreted to represent this
value.</t>
</list></t>
<t>This is the resulting <xref target="RFC5234">ABNF</xref>, extending
existing ABNF in section 7.1 of <xref target="RFC5104">CCM</xref>:</t>
<figure anchor="fig-abnf" title="ABNF">
<artwork><![CDATA[
rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr)
/ SP "paused" *(SP paused-attr)
pause-attr = direction
/ "nowait"
/ token ; for future extensions
paused-attr = direction
/ token ; for future extensions
direction = "dir=" direction-alts
direction-alts = "sendonly" / "recvonly" / "sendrecv"
]]></artwork>
</figure>
<t>An endpoint implementing this specification and using SDP to signal
capability SHOULD indicate both of the new "pause" and "paused"
parameters with ccm signaling. When negotiating usage, it is possible
select either of them, noting that "pause" contain the full "paused"
functionality. A sender or receiver SHOULD NOT use the messages from
this specification towards receivers that did not declare capability for
it.</t>
<t>There MUST NOT be more than one "a=rtcp-fb" line with "pause" and one
with "paused" applicable to a single payload type in the SDP, unless the
additional line uses "*" as payload type, in which case "*" SHALL be
interpreted as applicable to all listed payload types that does not have
an explicit "pause" or "paused" specification.</t>
<t>There MUST NOT be more than a single direction sub-parameter per
"pause" and "paused" parameter. There MUST NOT be more than a single
"nowait" sub-parameter per "pause" parameter.</t>
<section anchor="sec-offer-answer" title="Offer-Answer Use">
<t>An offerer implementing this specification needs to include "pause"
and/or "paused" CCM parameters with suitable directionality parameter
("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 to
include both "pause" and "paused" if "pause" is supported, to enable
at least the "paused" functionality if the answer only supports
"paused" or different directionality for the two functionalities. The
"pause" and "paused" functionalities are negotiated independently,
although the "paused" functionality is part of the "pause"
functionality. As a result, an answerer MAY remove "pause" or "paused"
lines from the SDP depending on the agreed mode of functionality.</t>
<t>In offer/answer, the "dir" parameter is interpreted based on the
agent providing the SDP. The node described in the offer is the
offerer, and the answerer is described in an answer. In other words,
an offer for "paused dir=sendonly" means that the offerer intends to
send PAUSED indications whenever it pauses media delivery in any of
its media streams.</t>
<t>An answerer receiving an offer with a "pause" parameter with
dir=sendrecv MAY remove the pause line in its answer, respond with
pause keeping sendrecv for full bi-directionality, or it may change
dir value to either sendonly or recvonly based on its capabilities and
desired functionality. An offer with a "pause" parameter with
dir=sendonly or dir=recvonly is either completely removed or accepted
with reverse directionality, i.e. sendonly becomes recvonly or
recvonly becomes sendonly.</t>
<t>An answer receiving an offer with "paused" has the same choices as
for "pause" above. It should be noted that the directionality of pause
is the inverse of media direction, while the directionality of paused
is the same as the media direction.</t>
<t>If the offerer believes that itself and the intended answerer are
likely the only end-points in the RTP session, it MAY include the
"nowait" sub-parameter on the "pause" line in the offer. If an
answerer receives the "nowait" sub-parameter on the "pause" line in
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
"nowait" sub-parameter on its "pause" line in the SDP answer. The
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 offer
and answer contained a "nowait" parameter, then the hold-off time is
configured to 0 at both offerer and answerer.</t>
</section>
<section title="Declarative Use">
<t>In declarative use, the SDP is used to configure the node receiving
the SDP. This has implications on the interpretation of the SDP
signalling extensions defined in this draft. First, it is normally
only necessary to include either "pause" or "paused" parameter to
indicate the level of functionality the node should use in this RTP
session. Including both is only necessary if some implementations only
understands "paused" and some other can understand both. Thus
indicating both means use pause if you understand it, and if you only
understand paused, use that.</t>
<t>The "dir" directionality parameter indicates how the configured
node should behave. For example "pause" with sendonly:<list
style="hanging">
<t hangText="sendonly:">The node intends to send PAUSE and RESUME
requests for other nodes' media streams and is thus also capable
of receiving PAUSED and REFUSE. It will not support receiving
PAUSE and RESUME requests.</t>
</list></t>
<t>In this example, the configured node should send PAUSE and RESUME
requests if has reason for it. It does not need to respond to any
PAUSE or RESUME requests as that is not supported.</t>
<t>The "nowait" parameter, if included, is followed as specified. It
is the responsibility of the declarative SDP sender to determine if a
configured node will participate in a session that will be point to
point, based on the usage. For example, a conference client being
configured for an any source multicast session using <xref
target="RFC2974">SAP</xref> will not be in a point to point session,
thus "nowait" cannot be included. An <xref
target="RFC2326">RTSP</xref> client receiving a declarative SDP may
very well be in a point to point session, although it is highly
doubtful that an RTSP client would need to support this specification,
considering the inherent PAUSE support in RTSP.</t>
</section>
</section>
<section anchor="sec-examples" title="Examples">
<t>The following examples shows use of PAUSE and RESUME messages,
including use of offer-answer:</t>
<t><list style="numbers">
<t>Offer-Answer</t>
<t>Point-to-Point session</t>
<t>Point-to-multipoint using Mixer</t>
<t>Point-to-multipoint using Translator</t>
</list></t>
<section title="Offer-Answer">
<t>The below figures contains an example how to show support for
pausing and resuming the streams, as well as indicating whether or not
the hold-off period can be set to 0.</t>
<figure anchor="fig-example-sdp-offer"
title="SDP Offer With Pause and Resume Capability">
<artwork><![CDATA[v=0
o=alice 3203093520 3203093520 IN IP4 alice.example.com
s=Pausing Media
t=0 0
c=IN IP4 alice.example.com
m=audio 49170 RTP/AVPF 98 99
a=rtpmap:98 G719/48000
a=rtpmap:99 PCMA/8000
a=rtcp-fb:* ccm pause nowait
a=rtcp-fb:* ccm paused
]]></artwork>
</figure>
<t>The offerer supports all of the messages defined in this
specification and offers a sendrecv stream. The offerer also 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 offerer's stream
and thus includes the "nowait" sub-parameter for both "pause" and
"paused" parameters.</t>
<t>This is the SDP answer:</t>
<figure anchor="fig-example-sdp-answer"
title="SDP Answer With Pause and Resume Capability">
<artwork><![CDATA[v=0
o=bob 293847192 293847192 IN IP4 bob.example.com
s=-
t=0 0
c=IN IP4 bob.example.com
m=audio 49202 RTP/AVPF 98
a=rtpmap:98 G719/48000
a=rtcp-fb:98 ccm pause dir=sendonly
a=rtcp-fb:98 ccm paused
]]></artwork>
</figure>
<t>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 intends to send it, and also desires to receive PAUSED
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
session and has therefore removed "nowait" from the "pause" line,
meaning that the offerer must use a non-zero hold-off time when being
requested to pause the stream.</t>
<t>When using TMMBR 0 / TMMBN 0 to achieve pause and resume
functionality, there are no differences in SDP compared to <xref
target="RFC5104">CCM</xref> and therefore no such examples are
included here.</t>
</section>
<section title="Point-to-Point Session">
<t>This is the most basic scenario, which involves two participants,
each acting as a sender and/or receiver. Any RTP data receiver sends
PAUSE or RESUME messages to the sender, which pauses or resumes
transmission accordingly. The hold-off time before pausing a stream is
0.</t>
<figure align="center" anchor="fig-pause-resume"
title="Pause and Resume Operation in Point-to-Point">
<artwork><![CDATA[
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: PAUSE(3) |
| <------------------------------- |
| < RTP data paused > |
| t3: PAUSED(3) |
| -------------------------------> |
: < Some time passes > :
| t4: RESUME(3) |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: PAUSE(4) |
| <------------------------------- |
| < RTP data paused > |
: :
]]></artwork>
</figure>
<t><xref target="fig-pause-resume"/> shows the basic pause and resume
operation in Point-to-Point scenario. At time t1, an RTP sender sends
data to a receiver. At time t2, the RTP receiver requests the sender
to pause the stream, using PauseID 3 (which it knew since before in
this example). The sender pauses the data and replies with a PAUSED
containing the same PauseID. Some time later (at time t4) the receiver
requests the sender to resume, which resumes its transmission. The
next PAUSE, sent at time t6, contains an updated PauseID (4).</t>
<figure align="center" anchor="fig-pause-resume-tmmbr"
title="TMMBR Pause and Resume in Point-to-Point">
<artwork><![CDATA[
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| -------------------------------> |
| t2: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
| t3: TMMBN 0 |
| -------------------------------> |
: < Some time passes > :
| t4: TMMBR 150000 |
| <------------------------------- |
| t5: RTP data |
| -------------------------------> |
: < Some time passes > :
| t6: TMMBR 0 |
| <------------------------------- |
| < RTP data paused > |
: :
]]></artwork>
</figure>
<t><xref target="fig-pause-resume-tmmbr"/> describes the same
point-to-point scenario as above, but using TMMBR/TMMBN signaling.</t>
<figure align="center" anchor="fig-pause-lost"
title="Pause and Resume Operation With Messages Lost">
<artwork><![CDATA[
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------------> |
| t2: PAUSE(7), lost |
| <---X-------------- |
| |
| t3: RTP data |
| ------------------------------------> |
: :
| <Timeout, still receiving data> |
| t4: PAUSE(7) |
| <------------------------------------ |
| < RTP data paused > |
| t5: PAUSED(7) |
| ------------------------------------> |
: < Some time passes > :
| t6: RESUME(7), lost |
| <---X-------------- |
| t7: RESUME(7) |
| <------------------------------------ |
| t8: RTP data |
| ------------------------------------> |
| t9: RESUME(7) |
| <------------------------------------ |
: :
]]></artwork>
</figure>
<t><xref target="fig-pause-lost"/> describes what happens if a PAUSE
message from an RTP media stream receiver does not reach the RTP media
stream sender. After sending a PAUSE message, the RTP media stream
receiver waits for a time-out to detect if the RTP media stream sender
has paused the data transmission or has sent PAUSED indication
according to the rules discussed in <xref target="sec-state-paused"/>.
As the PAUSE message is lost on the way (at time t2), RTP data
continues to reach to the RTP media stream receiver. When the timer
expires, the RTP media stream receiver schedules a retransmission of
the PAUSE message, which is sent at time t4. If the PAUSE message now
reaches the RTP media stream sender, it pauses the RTP media stream
and replies with PAUSED.</t>
<t>At time t6, the RTP media stream receiver wishes to resume the
stream again and sends a RESUME, which is lost. This does not cause
any severe effect, since there is no requirement to wait until further
RESUME are sent and another RESUME are sent already at time t7, which
now reaches the RTP media stream sender that consequently resumes the
stream at time t8. The time interval between t6 and t7 can vary, but
may for example be one RTCP feedback transmission interval as
determined by the AVPF rules.</t>
<t>The RTP media stream receiver did not realize that the RTP stream
was resumed in time to stop yet another scheduled RESUME from being
sent at time t9. This is however harmless since the RESUME PauseID is
less than the valid one and will be ignored by the RTP media stream
sender. It will also not cause any unwanted resume even if the stream
was paused based on a PAUSE from some other receiver before receiving
the RESUME, since the valid PauseID is now larger than the one in the
stray RESUME and will only cause a REFUSE containing the new valid
PauseID from the RTP media stream sender.</t>
<figure align="center" anchor="fig-pause-refused"
title="Pause Request is Refused in Point-to-Point">
<artwork><![CDATA[
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------> |
| t2: PAUSE(11) |
| <------------------------------ |
| |
| < Can not pause RTP data > |
| t3: REFUSE(11) |
| ------------------------------> |
| |
| t4: RTP data |
| ------------------------------> |
: :
]]></artwork>
</figure>
<t>In <xref target="fig-pause-refused"/>, the receiver requests to
pause the sender, which refuses to pause due to some consideration
local to the sender and responds with a REFUSE message.</t>
</section>
<section title="Point-to-multipoint using Mixer">
<t>An RTP Mixer is an intermediate node connecting different
transport-level clouds. The Mixer receives streams from different RTP
sources, selects or combines them based on the application´s
needs and forwards the generated stream(s) to the destination. The
Mixer typically puts its´ own SSRC(s) in RTP data packets
instead of the original source(s).</t>
<t>The Mixer keeps track of all the media streams delivered to the
Mixer and how they are currently used. In this example, it selects the
video stream to deliver to the receiver R based on the voice activity
of the media senders. The video stream will be delivered to R using
M's SSRC and with an CSRC indicating the original source.</t>
<t>Note that PauseID is not of any significance for the example and is
therefore omitted in the description.</t>
<figure anchor="fig-vad-mixer"
title="Pause and Resume Operation for a Voice Activated Mixer">
<artwork align="center"><![CDATA[
+-----+ +-----+ +-----+ +-----+
| R | | M | | S1 | | S2 |
+-----+ +-----| +-----+ +-----+
: : t1:RTP(S1) : :
| t2:RTP(M:S1) |<-----------------| |
|<-----------------| | |
| | t3:RTP(S2) | |
| |<------------------------------------|
| | t4: PAUSE(S2) | |
| |------------------------------------>|
| | | t5: PAUSED(S2) |
| |<------------------------------------|
| | | <S2:No RTP to M> |
| | t6: RESUME(S2) | |
| |------------------------------------>|
| | | t7: RTP to M |
| |<------------------------------------|
| t8:RTP(M:S2) | | |
|<-----------------| | |
| | t9:PAUSE(S1) | |
| |----------------->| |
| | t10:PAUSED(S1) | |
| |<-----------------| |
| | <S1:No RTP to M> | |
: : : :
]]></artwork>
</figure>
<t>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
(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
delivering media to the Mixer. As S2 has less voice activity 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 instant stops
delivering RTP to the Mixer. At t6, the user at S2 starts speaking and
becomes the most active speaker and the Mixer 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 and acts on it by
resuming RTP media delivery to M. When the media from t7 arrives at
the Mixer, it switches this media into 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 acknowledged at t10 with a PAUSED and
the RTP media stream from S1 stops being delivered.</t>
</section>
<section title="Point-to-multipoint using Translator ">
<t>A transport Translator in an RTP session forwards the message from
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. These
examples are to show that the messages defined in this specification
can be safely used also in a transport Translator case. The
parentheses in the figures contains (Target SSRC, PauseID) information
for the messages defined in this specification.</t>
<figure align="center" anchor="fig-translator"
title="Pause and Resume Operation Between Two Participants Using a Translator">
<artwork><![CDATA[
+-------------+ +-------------+ +--------------+
| Sender(S) | | Translator | | Receiver(R) |
+-------------+ +-------------| +--------------+
: t1: RTP(S) : :
|------------------>| |
| | t2: RTP (S) |
| |------------------>|
| | t3: PAUSE(S,3) |
| |<------------------|
| t4:PAUSE(S,3) | |
|<------------------| |
: < Sender waiting for possible RESUME> :
| < RTP data paused > |
| t5: PAUSED(S,3) | |
|------------------>| |
| | t6: PAUSED(S,3) |
| |------------------>|
: : :
| | t7: RESUME(S,3) |
| |<------------------|
| t8: RESUME(S,3) | |
|<------------------| |
| t9: RTP (S) | |
|------------------>| |
| | t10: RTP (S) |
| |------------------>|
: : :
]]></artwork>
</figure>
<t><xref target="fig-translator"/> describes how a Translator can help
the receiver in pausing and resuming the sender. The sender S sends
RTP data to the receiver R through Translator, which just forwards the
data without modifying 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 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 disapproving RESUME, hence pauses itself and replies with
PAUSED. Similarly the receiver resumes the sender by sending RESUME
request through Translator. Since this describes only a single pause
operation for a single media sender, all messages uses a single
PauseID, in this example 3.</t>
<figure align="center" anchor="fig-translator-two-receivers"
title="Pause and Resume Operation Between One Sender and Two Receivers Through Translator">
<artwork><![CDATA[
+-----+ +-----+ +-----+ +-----+
| S | | T | | R1 | | R2 |
+-----+ +-----| +-----+ +-----+
: t1:RTP(S) : : :
|----------------->| | |
| | t2:RTP(S) | |
| |----------------->------------------>|
| | t3:PAUSE(S,7) | |
| |<-----------------| |
| t4:PAUSE(S,7) | | |
|<-----------------|------------------------------------>|
| | | t5:RESUME(S,7) |
| |<------------------------------------|
| t6:RESUME(S,7) | | |
|<-----------------| | |
| |<RTP stream continues to R1 and R2> |
| | | t7: PAUSE(S,8) |
| |<------------------------------------|
| t8:PAUSE(S,8) | | |
|<-----------------| | |
: : : :
| < Pauses RTP Packet Stream > | |
| t9:PAUSED(S,8) | | |
|----------------->| | |
| | t10:PAUSED(S,8) | |
| |----------------->------------------>|
: : : :
| | t11:RESUME(S,8) | |
| |<-----------------| |
| t12:RESUME(S,8) | | |
|<-----------------| | |
| t13:RTP(S) | | |
|----------------->| | |
| | t14:RTP(S) | |
| |----------------->------------------>|
: : : :
]]></artwork>
</figure>
<t><xref target="fig-translator-two-receivers"/> explains the pause
and resume operations when a transport Translator is involved between
a sender and two receivers in an RTP session. Each message exchange is
represented by the time it happens. At time t1, Sender (S) starts
sending media to the Translator, which is forwarded to R1 and R2
through the Translator, 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 that they receive S's media stream.</t>
<t>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
least one receiver that may still want to receive the data and uses a
non-zero hold-off period to wait for possible RESUME messages. R2 did
also receive the PAUSE request at time t4 and since it still wants to
receive the stream, it sends a RESUME for it at time t5, which is
forwarded to the sender S by the translator T. The sender S sees the
RESUME at time t6 and continues to send data to T which forwards to
both R1 and R2. At t7, the receiver R2 chooses to pause the stream by
sending a PAUSE request with an updated PauseID. The sender S still
knows that there are more than one receiver (R1 and R2) that may want
the stream and again waits a non-zero hold-off time, after which and
not having received any disapproving RESUME, it concludes that the
stream must be paused. S now stops sending the stream and replies with
PAUSED to R1 and R2. When any of the receivers (R1 or R2) chooses to
resume the stream from S, in this example R1, it sends a RESUME
request to the sender. The RTP sender immediately resumes the
stream.</t>
<t>Consider also an RTP session which includes one or more receivers,
paused sender(s), and a Translator. Further assume that a new
participant joins the session, which is not aware of the paused
sender(s). On receiving knowledge about the newly joined participant,
e.g. any RTP traffic or RTCP report (i.e. either SR or RR) from the
newly joined participant, the paused sender(s) immediately sends
PAUSED indications for the paused streams since there is now a
receiver in the session that did not pause the sender(s) and may want
to receive the streams. Having this information, the newly joined
participant has the same possibility as any other participant to
resume the paused streams.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>As outlined in <xref target="sec-format"/>, this specification
requests IANA to allocate<list style="numbers">
<t>The FMT number TBA1 to be allocated to the PAUSE and RESUME
functionality from this specification.</t>
<t>The 'pause' and 'paused' tags to be used with ccm under rtcp-fb
AVPF attribute in SDP.</t>
<t>The 'nowait' parameter to be used with the 'pause' and 'paused'
tags in SDP.</t>
<t>A registry listing registered values for 'pause' Types.</t>
<t>PAUSE, RESUME, PAUSED, and REFUSE with the listed numbers in the
pause Type registry.</t>
</list></t>
<t/>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document extends the <xref target="RFC5104">CCM</xref> and
defines new messages, i.e. PAUSE and RESUME. The exchange of these new
messages MAY have some security implications, which need to be addressed
by the user. Following are some important implications,</t>
<t><list style="numbers">
<t>Identity spoofing - An attacker can spoof him/herself as an
authenticated user and can falsely pause or resume any source
transmission. In order to prevent this type of attack, a strong
authentication and integrity protection mechanism is needed.</t>
<t>Denial of Service (DoS) - An attacker can falsely pause all
source streams which MAY result in Denial of Service (DoS). An
Authentication protocol may prevent this attack.</t>
<t>Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP
source is prone to a Man-in-Middle attack. Public key authentication
may be used to prevent MiMT.</t>
</list></t>
</section>
<section title="Contributors">
<t>Daniel Gröndal contributed in the creation and writing of
earlier versions of this specification.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Daniel Grondal made valuable contributions during the initial
versions of this draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.4585"?>
<?rfc include="reference.RFC.5104"?>
<?rfc include='reference.RFC.5234'?>
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2326'?>
<?rfc include='reference.RFC.2974'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3264'?>
<?rfc include='reference.RFC.3556'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.5049'?>
<?rfc include='reference.RFC.5225'?>
<?rfc include='reference.RFC.5576'?>
<?rfc include='reference.RFC.5626'?>
<?rfc include='reference.RFC.6190'?>
<?rfc include='reference.I-D.westerlund-avtcore-rtp-simulcast'?>
<?rfc include='reference.I-D.lennox-mmusic-sdp-source-selection'?>
<?rfc include='reference.I-D.ietf-rtcweb-use-cases-and-requirements'?>
<?rfc include='reference.I-D.ietf-avtext-rtp-grouping-taxonomy'?>
<?rfc include='reference.I-D.ietf-avtcore-rtp-topologies-update'?>
<reference anchor="TS25.308"
target="http://www.3gpp.org/ftp/Specs/html-info/25308.htm">
<front>
<title>High Speed Downlink Packet Access (HSDPA); Overall
description; Stage 2</title>
<author>
<organization>3GPP</organization>
</author>
<date day="22" month="December" year="2011"/>
</front>
<seriesInfo name="3GPP TS" value="25.308 10.6.0"/>
</reference>
<reference anchor="TS26.114"
target="http://www.3gpp.org/ftp/Specs/html-info/26114.htm">
<front>
<title>IP Multimedia Subsystem (IMS); Multimedia telephony; Media
handling and interaction</title>
<author>
<organization>3GPP</organization>
</author>
<date day="27" month="June" year="2013"/>
</front>
<seriesInfo name="3GPP TS" value="26.114 10.7.0"/>
</reference>
<reference anchor="TS36.201"
target="http://www.3gpp.org/ftp/Specs/html-info/36201.htm">
<front>
<title>Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
physical layer; General description</title>
<author>
<organization>3GPP</organization>
</author>
<date day="22" month="December" year="2010"/>
</front>
<seriesInfo name="3GPP TS" value="36.201 10.0.0"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:04:24 |