| Network Working Group | A. Akram |
| Internet-Draft | B. Burman |
| Intended status: Standards Track | D. Grondal |
| Expires: April 23, 2013 | M. Westerlund |
| Ericsson AB | |
| October 22, 2012 |
RTP Media Stream Pause and Resume
draft-westerlund-avtext-rtp-stream-pause-03
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 adding a group of new real-time feedback messages used to pause and resume RTP data streams.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
Multimedia conferencing may involve many participants; each has its own preferences and demands control over 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 RTP [RFC3550] 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 SIP [RFC3261] with SDP Offer/Answer [RFC3264].
Centralized nodes, like RTP Mixers, which either uses logic based on voice activity, other measurements, user input over proprietary interfaces, or Media Stream Selection [I-D.westerlund-dispatch-stream-selection] 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 multiple encoding versions (Simulcast) [I-D.westerlund-avtcore-rtp-simulcast] or with Multi-Session Transmission (MST) of scalable encoding such as SVC [RFC6190]. There may be some of the defined encodings or combination of scalable layers that are not used all of the time.
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 RTP [RFC3550] for media transport, using Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] appears appropriate. No currently existing RTCP feedback message supports pausing and resuming an incoming data stream. As this is affects the generation of packets and may even allow the encoding process to be paused, the functionality appears to match Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104] and should thus be defined as a Codec Control Message (CCM) extension.
In addition to following, the definitions from RTP [RFC3550], AVPF [RFC4585] and CCM [RFC5104] also apply in this document.
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 RFC 2119 [RFC2119].
This section discusses the main use cases for media stream pause and resume.
This is the most basic use case with an RTP session containing two end-points. Each end-point has one or more SSRCs.
+---+ +---+ | A |<------->| B | +---+ +---+
Figure 1: Point to Point
The usage of media stream pause in this use case is to temporarily halt media delivery of media streams that the sender provides but the receiver doesn't currently use. This can for example de due to minimized applications where the video stream isn't actually shown on any display, and neither is it used in any other way, such as being recorded.
RTCWEB WG's use case and requirements document [I-D.ietf-rtcweb-use-cases-and-requirements] defines the following API requirement derived in the most basic usage "Simple Video Communication Service" (Section 4.2.1 in [I-D.ietf-rtcweb-use-cases-and-requirements]) :
The PAUSED indication in this document can be used to indicate to the media receiver that the stream delivery is deliberately paused due to a sender side mute operation.
One of the most commonly used topologies in centralized conferencing is based on the RTP Mixer. 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 having its´ own SSRCs 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 media stream the Mixer provides can be an actual media mixing of multiple media sources, but it might also be as simple as selecting one of the underlying sources based on some Mixer policy or control signalling.
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| Mixer |
+---+ | | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 2: RTP Mixer
The media streams being 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 senders 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 media selection could also be under the user's control using a protocol like Media Stream Selection [I-D.westerlund-dispatch-stream-selection]. The media streams may also be simulcasted or scalable encoded (for Multi-Stream Transmission), thus providing multiple versions that can be delivered by the media sender. These examples indicate that there are numerous reasons why a particular media 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 media stream selection to be done in the Mixer.
Because of this, it would be highly beneficial if the Mixer could request to pause a particular media stream from being delivered to it. It also needs to be able to resume delivery with minimal delay.
An end-point in Figure 2 could potentially request to pause the delivery of a given media stream. Possible reasons include the ones in the point to point case [sec-point-to-point] above.
An end-point, like A in Figure 2, 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.
First of all, the Mixer might not include CSRC in it´s stream indications. Secondly, 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. Thirdly, the end-point cannot determine if a given media stream is still needed by the RTP Mixer to deliver to another session participant.
In addition, pause is only part of the semantics when it comes to selecting media streams. As can be seen in MESS [I-D.westerlund-dispatch-stream-selection], it can be beneficial to have both include and exclude semantics. In addition, substitution and possibility to control in what local RTP media stream the selected remote RTP media stream is to be provided gives richer functionality.
Due to the above reasons, we exclude this use case from further consideration.
This section describes the requirements that this specification needs to meet.
The first section [sec-intro] 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.
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. Indication that an RTP media stream is paused is the responsibility of the RTP media stream sender.
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.
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 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.
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, 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.
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. This error condition, a negative acknowledgement, is needed to avoid unnecessary retransmission of requests [sec-retransmit].
When the media stream is not affected as expected by a PAUSE or RESUME request, it 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.
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.
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.
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.
This section compares other possible solutions to achieve a similar functionality, along with motivations why the current solution is chosen.
This section contains what is thought to be a realistic estimate of one-way data transmission times for signaling implementing functionalities of this specification.
Two signaling protocols are compared. SIP is chosen to represent signaling in the control plane and RTCP is chosen to represent signaling in the media plane. For the sake of the comparison, each of these two protocols are listed with one favorable and one unfavorable condition to give the reader a hint of what range of delays that can be expected. The favorable condition is chosen as good as possible, while still realistic. The unfavorable condition is also chosen to be realistically occurring, and is not the worst possible or imaginable. Actual delays can in most cases be expected to lie somewhere between those two values.
It would also be possible to include a signaling protocol using a some dedicated signaling channel, separate from SIP and RTCP, into the comparison. Such signaling protocol can be expected to show performance somewhere in the range covered by the SIP and RTCP comparison below. The protocol can either use UDP as transport, like RTCP, or it can use TCP, like SIP, when the messages becomes too large for the MTU. The data sent on such channel can either be text based, in which case the amount of data can be similar to SIP, or it can be binary, in which case the amount of data can be similar to RTCP. Therefore, the dedicated signaling channel case is not described further in this specification.
Two different access technologies are compared:
NOTE: LTE is at the time of writing the most recent and best performing mobile wireless access. If an earlier mobile wireless access was to be used instead, the estimated transmission times would be considerably increased. For example, it is estimated that using 3GPP HSPA [3GPP.25.308] (evolved 3G, just previous to LTE) would increase RTCP signaling times somewhat and significantly increase signaling times for SIP, although those estimates are too preliminary to provide any values here.
The target scenario includes two UA, residing in two different provider's (operator's) network. Those networks are assumed to be geographically close, that is no inter-continental transmission delays are included in the estimates.
Three signaling alternatives are compared:
The reason to include separate results for wireless uplink and downlink is that delay times can differ significantly.
The targeted topology is outlined in the following figure.
Provider A's network . Provider B's network
.
+-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+
|Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy|
+-----+ +------+ +-------+ . +-------+ +-----+
^ ^ . ^
| | SIP/H.248 . |
| v . |
SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP |
| | MCU |<---->| BGW A |<--.-->| BGW B | |
| +-----+ +-------+ . +-------+ |
v ^ . ^ v
+------+ / RTCP . \ RTCP +------+
| UA A |<---+ . +------>| UA B |
+------+ . +------+
Figure 3: Comparison Signaling Topology
In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS is an Application Server, MCU is a Multipoint Conference Unit, SGW a Signaling GateWay, and BGW a media Border GateWay.
It can be noted that when either one or both UAs use call forwarding or have roamed into yet another provider's network, several more signaling path nodes and a few more media path nodes could be included in the end-to-end signaling path.
The MCU is assumed to be located in one of the provider's network. Signaling delays between the MCU and a UA are presented as the average of MCU and UA being located in the same and different provider's networks.
These assumptions are used for SIP signaling:
These assumptions are used for RTCP signaling:
Common to both SIP and RTCP signaling estimates is that no UA processing delays are included. The reason for that decision is that processing delays are highly implementation and UA dependent. It is expected that wireless UA will be more limited than fixed UA by processing, but they are also constantly and quickly improving so any estimate will very quickly be outdated. More realistic estimates will however have to add such delays, which can be expected to be in the order of a few to a few tens of milliseconds. It is expected that SIP will be more penalized than RTCP by including processing delays, since it has larger and more complex messages. The processing may also include SigComp [RFC5049] compression and decompression in the favorable cases.
As a partial result, the message sizes can be compared, based on the messages defined in this specification [sec-format] and a SIP UPDATE with contents [sec-signaling] as discussed above. Favorable and unfavorable message sizes are presented as stacked bars in the figure below. Message sizes include IPv4 headers but no lower layer data, are rounded to the nearest 25 bytes, and the bars are to scale.
250 500 750 1000 1250 1500 [byte]
+---------+---------+---------+---------+---------+---------+--> Size
|
+-+--+
| |50| 125 RTCP
+-+--+---------------+--------------------------------------------+
| SIP | 525 1650 |
+--------------------+--------------------------------------------+
|
Figure 4: Message Size Comparison
The signaling delay results of the study are summarized in the following two figures. Favorable and unfavorable values are presented as stacked bars. Since there are many factors that impact the calculations, including some random processes, there are uncertainty in the calculations and delay values are thus rounded to nearest 5 ms. The bars are to scale.
50 100 150 200 250 300 [ms]
+---------+---------+---------+---------+---------+---------+---> t
|
| Wireless UA to Wireless UA
+---------------------+--------------------------------------+
| SIP | 110 | 305
+-----+---------------+-----------------------------+--------+
|RTCP | 30 | 260
+-----+---------------------------------------------+
|
| Wireless UA to MCU
+-------------+--+
| SIP |70| 85
+----+--------+--+--------------------------+
|RTCP| 25 | 225
+----+--------------------------------------+
|
| MCU to Wireless UA
+--------------+-----------------------------------+
| SIP | 75 | 255
+---+----------+------------------------------+----+
| | 20 RTCP | 230
+---+-----------------------------------------+
|
Figure 5: Mobile Access Transmission Delay Comparison
As can be seen, RTCP has a smaller signaling delay than SIP in a majority of cases for this mobile access. Non-favorable RTCP is however always worse than favorable SIP.
The UA to MCU signaling corresponds to the use case in Section 3.3. The reason that unfavorable SIP is more beneficial than unfavorable RTCP in this case comes from the fact that latency is fairly short to re-establish an uplink radio channel (as was assumed needed for unfavorable SIP), while unfavorable RTCP does not benefit from this since the delay is mainly due to RTCP Scheduling.
The MCU to UA signaling corresponds to the use case in Section 3.2. It has an unfavorable SIP signaling case with much longer delay than UA to MCU above, because the mixer cannot re-establish a downlink radio channel as quickly as the UA can establish an uplink. This case is applicable when an MCU wants to resume a paused stream, which is likely the most delay sensitive functionality, as discussed in Section 4.1.
Below are the same cases for fixed access depicted. Although delays are generally shorter, scales are kept the same for easy comparison with the previous figure.
50 100 150 200 250 300 [ms]
+---------+---------+---------+---------+---------+---------+---> t
|
| Fixed UA to Fixed UA
+------------+
| SIP | 65
+----+-------+---------------------------+
|RTCP| 25 | 205
+----+-----------------------------------+
|
| Fixed UA to MCU
+---------+
| SIP | 50
+---+-----+-----------------------+
| | 15 RTCP | 200
+---+-----------------------------+
|
| MCU to Fixed UA
+---------+
| SIP | 50
+---+-----+-----------------------+
| | 15 RTCP | 200
+---+-----------------------------+
|
Figure 6: Fixed Access Transmission Delay Comparison
For fixed access, favorable RTCP is still significantly better than SIP, but unfavorable RTCP is significantly worse than SIP. There is no difference between favorable and unfavorable SIP, since in fixed access there is no channel that needs to be re-established.
Regarding the unfavorable values above, it should be possible with reasonable effort to design UA and network nodes that show favorable delays in a majority of cases.
For SIP, the major delays in the unfavorable cases above comes from re-establishing a radio bearer that has entered low power state due to inactivity, and large size SIP messages. The inactivity problem can be removed by using for example SIP keep-alive [RFC5626], at the cost of reduced battery life to keep the signaling radio bearer active, and some very minimal amount of extra data transmission. The large SIP messages can to some extent be reduced by SIP SigComp [RFC5049]. It may however prove harder to reduce delays that comes from forwarding the SDP many times between different signaling nodes.
For RTCP, the major delays comes from low RTCP bandwidth and not being able to use Immediate or Early mode, including use of timer re-consideration. UAs and network nodes can explicitly allocate an appropriate amount of RTCP bandwidth through use of the b=RS and b=RR RTCP bandwidth SDP attributes [RFC3356]. 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.
In SDP [RFC4566], an "inactive" attribute is defined on media level and session level. The attribute is intended to be used to put media "on hold", either at the beginning of a session or as a result of session re-negotiation [RFC3264], for example using SIP re-INVITE [RFC3261], possibly in combination with ITU-T H.248 media gateway control.
This attribute is only possible to specify with media level resolution, is not possible to signal per individual media stream (SSRC) [sec-individual], and is thus not usable for RTP sessions containing more than a single SSRC.
There is a per-ssrc attribute defined in [RFC5576], but that does currently not allow to set an individual stream (SSRC) inactive.
Using "inactive" does thus not provide sufficient functionality for the purpose of this specification.
The Codec Control Messages specification [RFC5104] contains two messages, Temporary Maximum Media Bitrate Request (TMMBR) and Temporary Maximum Media Bitrate Notification (TMMBN), which could seemingly provide some of the necessary functionality, using a bitrate value of 0 as PAUSE request and PAUSED indication, respectively. It is possible to signal per SSRC [sec-individual] and using the media path for signaling (AVPF) [RFC4585] will in most cases provide the shortest achievable signaling delay [sec-real-time].
The defined semantics for TMMBR differ significantly from what is required for PAUSE. When there are several receivers of the same media stream, the stream must not be paused until there are no receiver that desires to receive it [sec-consensus], for example there is no disapproving RESUME for a PAUSE. The TMMBR semantics are the opposite; the first media receiver that sends TMMBR 0 will pause the stream for all receivers. This does not matter in the point-to-point case since there is only a single receiver, but will not provide the desired functionality in other cases.
A possibly even more significant aspect is the guard period present in TMMBR when increasing the bandwidth. The equivalent of a RESUME request using TMMBR would be to send a TMMBR message with a non-zero value, likely at the level of maximum for the session. However, TMMBR/TMMBN semantics (Section 4.2.1.2 of [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. This applies independently of topology, i.e. also for a point to point session. Compared to the proposed solution, this adds several delays. First, there is the delay between the media sender receiving the TMMBR until it can send a TMMBN, then there is the above delay for the guard period before the media sender resumes transmission. This delay before resuming transmission is the most time critical operation in this solution, making use of TMMBR according to the defined semantics infeasible in practice.
A TMMBN message could arguably be used as an acknowledgement [sec-acks] of either PAUSE or RESUME (depending on zero or non-zero bitrate parameter), but will not be able to provide any sequence number functionality [sec-sequence] and will thus risk mis-interpretation due to race situations.
The Media Stream Selection draft [I-D.westerlund-dispatch-stream-selection] includes a functionality that allows to include and exclude a specified stream from a received set of streams, which arguably gives similar results as pausing a stream. The functionality described in that specification is mainly transport agnostic, but the proposed implementation is to extend BFCP [RFC4582], which would likely give a performance somewhere in between RTCP and SIP.
The semantics differ between exclude / include and pause / resume for a stream in topologies other than point-to-point. For example, in RTP Receiver to Mixer [sec-media-receiver-to-mixer], 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 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 stream (CSRC) to be included in the mix again.
It would in fact be possible to use media stream selection for SSRC from the mixer itself, not CSRC, to achieve pause and resume functionality when UA and mixer are connected point-to-point, but that would not work with Translator or in multipoint, and neither would it provide any RTP level indication that the stream is paused.
In the Mixer to RTP sender [sec-mixer-to-media-sender] case, the topology is sufficiently similar to point-to-point to make it possible to use Media Stream Selection for pause and resume functionality, but would still not provide any RTP level indication that the stream is paused.
In topologies where the same RTP media stream is received by several receivers, Media Stream Selection does not provide any functionality to achieve consensus [sec-consensus] and will need modification to be possible to use.
There is also a similar draft that selects sources based on SDP [I-D.lennox-mmusic-sdp-source-selection] information. It builds on the per-ssrc attribute [RFC5576] discussed above [sec-inactive]. This suffers partly from the same mis-match in semantics and lack of functionality for consensus as the section above [sec-mess], and would likely also suffer from lower real-time performance [sec-real-time], especially when implementing necessary signaling to reach consensus [sec-consensus].
The draft on Codec Operation Point (COP) [I-D.westerlund-avtext-codec-operation-point] includes functionality to request a stream to be encoded at a certain bandwidth, including 0. That could also be used to pause and resume a stream. Since that draft is also based on CCM [RFC5104], the performance should be very similar to this specification and it should be possible to achieve sufficiently low signaling delay [sec-real-time].
The message semantics of COP [sec-consensus] also suits the purpose of this specification, and it would be possible to use COP for the sole purpose of controlling bandwidth in a way that effectively constitutes pause and resume. COP also has a functionality that this specification does not, in that it can set the bandwidth individually for sub-streams within a single SSRC, for example in scalable Single Stream Transmission (SST).
The authors however believe that there will be applications that can make good use of pause and resume functionality, but that will not be able to motivate a COP implementation, not even just the 'bitrate' Parameter Type (support for each Parameter Type is individually negotiable in COP). It is thus believed that pause and resume functionality is motivated as a separate specification.
As can be seen from Section 5.1, using SIP and SDP to carry pause and resume information means that it will need to traverse the entire signaling path to reach the signaling destination (either the remote end-point or the entity controlling the RTP Mixer), across any signaling proxies that potentially also has to process the SDP content to determine if they are expected to act on it. The amount of bandwidth required for this signaling solution is in the order of at least 10 times more than an RTCP-based solution.
Especially for UA sitting on mobile wireless access, this will risk introducing delays that are too long [sec-real-time] to provide a good user experience, and the bandwidth cost may also be considered infeasible compared to an RTCP-based solution.
As seen in the same section, the RTCP data is sent through the media path, which is likely shorter (contains fewer intermediate nodes) than the signaling path but may anyway have to traverse a few intermediate nodes. The amount of processing and buffering required in intermediate nodes to forward those RTCP messages is however believed to be significantly less than for intermediate nodes in the signaling path.
Based on those reasons, RTCP is proposed as signaling protocol for the pause and resume functionality.
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. A single Feedback message specification is used. 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.
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.
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.
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 RTP Mixer to Media Sender use case [sec-mixer-to-media-sender].
An RTP media stream receiver can choose to request PAUSE at any time, subject to AVPF timing rules.
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).
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 RESUME [sec-overview-resume] 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.
If the RTP media stream sender receives further PAUSE requests with the available PauseID while waiting as described above, those additional requests are ignored.
If the PAUSE request 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 PAUSED indication [sec-overview-pausing] for the stream. The same condition can be caused by the RTP media stream sender having received a disapproving RESUME for the PAUSE request, but that the PAUSE sender did not receive the RESUME and may instead think that the PAUSE was lost. In both cases, the PAUSE request can be re-transmitted using the same PauseID.
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.
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.
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 time-critical [sec-real-time].
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.
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.
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. 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.
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.
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.
If the RTP media stream sender receives PAUSE requests with the available PauseID while the stream is already paused, those requests are ignored.
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.
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.
An RTP media stream receiver can request to resume a stream at any time, subject to AVPF timing rules.
The RTP media stream receiver must include the available PauseID in the RESUME request for it to be effective.
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.
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.
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.
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 FIR request [RFC5104] 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.
This document introduces three new states for a media stream in an RTP sender, according to the figure and sub-sections below.
+------------------------------------------------------+
| Received RESUME |
v |
+---------+ Received PAUSE +---------+ Hold-off period +--------+
| Playing |---------------->| Pausing |---------------->| Paused |
| |<----------------| | | |
+---------+ Received RESUME +---------+ +--------+
^ | | PAUSE decision |
| | v |
| | PAUSE decision +---------+ PAUSE decision |
| +------------------>| Local |<--------------------+
+-------------------------| Paused |
RESUME decision +---------+
Figure 7: RTP Pause States
This state is not new, but is the normal media sending state from [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.
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:
where RTT is the longest round trip known to the media sender and T_dither_max is defined in section 3.4 of [RFC4585]. The hold-off period MAY be set to 0 by some signaling [sec-signaling] means when it can be determined that there is only a single receiver, for example in point-to-point or some unicast situations.
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.
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.
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.
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.
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 RTP [RFC3550], following two conditions MUST also be considered when an RTP participant sends an RTCP BYE message,
Section 6.3.5 in RTP [RFC3550] 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.
This state can be entered at any time, based on local decision from the media sender. As for Paused State [sec-state-paused], 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.
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.
Section 6 of AVPF [RFC4585] 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.
The Transport layer feedback messages are identified by having the RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. 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 AVPF [RFC4585]. The PAUSE and RESUME transport feedback message is identified by the FMT value = TBA1.
The Common Packet Format for Feedback Messages is defined by AVPF [RFC4585] is:
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) : : :
For the PAUSE and RESUME messages, the following interpretation of the packet fields will be:
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:
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 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Syntax of FCI Entry in the PAUSE and RESUME message
The FCI fields have the following definitions:
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 Section 9.5.
An RTP media stream receiver MAY schedule PAUSE for transmission at any time.
PAUSE has no defined Type Specific parameters and Parameter Len MUST be set to 0.
PauseID SHOULD be the available PauseID, as indicated by PAUSED [sec-paused] or implicitly determined by previously received PAUSE or RESUME [sec-resume] 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 REFUSE [sec-refuse]. A PauseID that is matching the available PauseID is henceforth also called a valid PauseID.
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 Playing State [sec-state-playing].
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.
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.
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 [RFC4585].
When an RTP media stream sender in Playing State [sec-state-playing] receives a valid PAUSE, and unless local considerations currently makes it impossible to pause the stream, it SHALL enter Pausing State [sec-state-pausing] when reaching an appropriate place to pause in the media stream, and act accordingly.
If an RTP media stream sender receives a valid PAUSE while in Pausing, Paused [sec-state-paused] or Local Paused [sec-state-local-paused] States, the received PAUSE SHALL be ignored.
The PAUSED indication MAY be sent either as a result of a valid PAUSE [sec-pause] request, when entering Paused State [sec-state-paused], or based on a RTP media stream sender local decision, when entering Local Paused State [sec-state-local-paused].
PauseID MUST contain the available, valid value to be included in a subsequent RESUME [sec-resume].
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.
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.
While remaining in Paused or Local Paused States, PAUSED MAY be included in all regular RTCP reports.
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.
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.
PauseID SHOULD be the valid PauseID, as indicated by PAUSED [sec-paused] or implicitly determined by previously received PAUSE [sec-pause] 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 REFUSE [sec-refuse].
RESUME has no defined Type Specific parameters and Parameter Len MUST be set to 0.
When an RTP media stream sender in Pausing [sec-state-pausing], Paused [sec-state-paused] or Local Paused State [sec-state-local-paused] receives a valid RESUME, and unless local considerations currently makes it impossible to resume the stream, it SHALL enter Playing State [sec-state-playing] 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.
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.
REFUSE has no defined Type Specific parameters and Parameter Len MUST be set to 0.
If an RTP media sender receives a valid PAUSE [sec-pause] or RESUME [sec-resume] 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.
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.
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.
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.
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.
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.
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.
All messages defined in this specification MAY use either Regular, Early or Immediate timings, taking the following into consideration:
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 AVPF [RFC4585] to include the request for pause and resume. Like AVPF [RFC4585] and CCM [RFC5104], 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.
This specification defines two new parameters to the "ccm" feedback value defined in CCM [RFC5104], "pause" and "paused".
The reason for this separation is to make it possible for partial implementation of this specification, according to the different roles in the use cases section [sec-use-cases].
A sub-parameter named "nowait", indicating that the hold-off time defined in Section 7.2 can be set to 0, reducing the latency before 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.
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.
Direction ("dir") values for "pause" is defined as follows:
Direction values for "paused" is defined as follows:
This is the resulting ABNF [RFC5234], extending existing ABNF in section 7.1 of CCM [RFC5104]:
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"
Figure 9: ABNF
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.
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.
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.
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.
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.
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.
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.
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.
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.
The "dir" directionality parameter indicates how the configured node should behave. For example "pause" with sendonly:
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.
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 SAP [RFC2974] will not be in a point to point session, thus "nowait" cannot be included. An RTSP [RFC2326] 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.
The following examples shows use of PAUSE and RESUME messages, including use of offer-answer:
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.
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
Figure 10: SDP Offer With Pause and Resume Capability
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.
This is the SDP answer:
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
Figure 11: SDP Answer With Pause and Resume Capability
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.
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.
+---------------+ +---------------+
| 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 > |
: :
Figure 12: Pause and Resume Operation in Point-to-Point
Figure 12 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).
+---------------+ +---------------+
| 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) |
| <------------------------------------ |
: :
Figure 13: Pause and Resume Operation With Messages Lost
Figure 13 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 Section 7.3. 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.
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.
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.
+---------------+ +---------------+
| RTP Sender | | RTP Receiver |
+---------------+ +---------------+
: t1: RTP data :
| ------------------------------> |
| t2: PAUSE(11) |
| <------------------------------ |
| |
| < Can not pause RTP data > |
| t3: REFUSE(11) |
| ------------------------------> |
| |
| t4: RTP data |
| ------------------------------> |
: :
Figure 14: Pause Request is Refused in Point-to-Point
In Figure 14, 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.
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).
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.
Note that PauseID is not of any significance for the example and is therefore omitted in the description.
+-----+ +-----+ +-----+ +-----+ | 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> | | : : : :
Figure 15: Pause and Resume Operation for a Voice Activated Mixer
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.
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.
+-------------+ +-------------+ +--------------+
| 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) |
| |------------------>|
: : :
Figure 16: Pause and Resume Operation Between Two Participants Using a Translator
Figure 16 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.
+-----+ +-----+ +-----+ +-----+ | 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 data stream > | | | t9:PAUSED(S,8) | | | |----------------->| | | | | t10:PAUSED(S,8) | | | |----------------->------------------>| : : : : | | t11:RESUME(S,8) | | | |<-----------------| | | t12:RESUME(S,8) | | | |<-----------------| | | | t13:RTP(S) | | | |----------------->| | | | | t14:RTP(S) | | | |----------------->------------------>| : : : :
Figure 17: Pause and Resume Operation Between One Sender and Two Receivers Through Translator
Figure 17 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.
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.
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.
As outlined in Section 8, this specification requests IANA to allocate
This document extends the CCM [RFC5104] 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,
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. |
| [RFC4585] | Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. |
| [RFC5104] | Wenger, S., Chandra, U., Westerlund, M. and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |