Audio/Video Transport P. Yang
Internet-Draft R. Even
Intended status: Standards Track Huawei Technologies Co., Ltd.
Expires: April 21, 2011 H. Moustafa
France Telecom - Orange
October 18, 2010
Switching from unicast to multicast for multicast short time-shift
draft-yang-avt-switch-multicast-short-timeshift-00.txt
Abstract
When a client requests a time-shift service for a multicast session
using RTP for media transport, like pause, instant replay, slow-
motion video, frame-by-frame viewing, rewind, fast-forward, etc., it
needs to switch from multicast session to unicast session. This
unicast session will always serve for the time-shift service unless
the client manually switches back to the multicast session. Actually
a time- shift request may happens for all clients. That is,
multicast session stream will be replaced by many unicast time-shift
streams having significant impact on network bandwidth usage.
In this document, we describe a method using existing RTP and RTCP
protocol infrastructure that switches back to multicast session from
unicast session of time-shift. In this method, a burst RTP flow
which is a little faster than the primary multicast rate may be
transmitted so that unicast session may catch up and switch back to
multicast session.
Status of this Memo
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 21, 2011.
Copyright Notice
Yang, et al. Expires April 21, 2011 [Page 1]
Internet-Draft Switching for multicast short time-shift October 2010
Copyright (c) 2010 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. RTSP Time-shift and MST Reverse Switch . . . . . . . . . . 5
1.2. RAMS and MST Reverse Switch . . . . . . . . . . . . . . . 6
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Reverse switch for multicast short time-shift . . . . . . . . 7
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Yang, et al. Expires April 21, 2011 [Page 2]
Internet-Draft Switching for multicast short time-shift October 2010
1. Introduction
Interactive time-shift is an important service for media application.
Through time-shift control operations (e.g. pause, instant replay,
slow-motion video, frame-by-frame viewing, rewind and fast-forward),
viewers can access recorded programming and live streams. The time-
shift service is available for recorded media and real-time
streaming. For the real-time streaming, time-shift service requires
recording/caching of the information. The time-shifted information
can be sent by the original media source or by a server in the
network that caches the stream and provides the time-shift service.
Note that time-shift service may run on the client side but this
requires the client to be able to cache the stream and
synchronization to the main multicast stream needs to be managed by
the client and does not require any specific protocol.
This document looks at time-shift services where the original content
is delivered using multicast. In this use case the time-shift
service is using a unicast stream from a Multicast Short Time-shift
(MST) server to the client. The synchronization between the
multicast and unicast stream can be achieved by the client if he is
using control commands like fast forward or RTSP [ref] Scale request.
The MST can notice that the client is receiving in the unicast stream
the same information that is current in the multicast stream.
Network traffic will rise with the increase in the number of clients
using time-shift service, because the time-shift service traffic
changes from a multicast stream (one multicast stream for all
clients) to a large number of unicast streams (one unicast stream per
client). Time- shift services like slow-motion view, instant replay,
frame-by-frame viewing, pause and rewind may often occur for most of
viewers in prime-time (e.g. when watching sports events).
We can separate the time-shift services of primary live streams
delivered over multicast/broadcast into multicast long time-shift and
multicast short time-shift. Some of the manipulations requested by
the viewers are multicast short time-shift (e.g. short pause, instant
replay, slow-motion video and frame-by-frame viewing). For the
multicast short time-shift, the time offset between the unicast time-
shift playback, after the time-shift request, and the current time of
the primary multicast stream is small enabling the unicast stream to
catch up with primary multicast stream by speeding up the playback,
and then switch back to the original multicast session.
In this document, we propose a solution for enabling the time-shifted
stream receivers to catch up with the original multicast stream using
the tools offered by the existing RTP and RTCP protocols. The
Yang, et al. Expires April 21, 2011 [Page 3]
Internet-Draft Switching for multicast short time-shift October 2010
document also describes how to switch back to the primary multicast
session from the unicast session initiated by either the client or
the server. Using this solution allows the network bandwidth to be
effectively saved for the time-shift service of multicast
application.
In the scenario that we consider in this draft, an intermediary
network element (that we refer to as Multicast Short Time-shift
server) joins the multicast session and continuously caches the
multicast stream. When an RTP receiver sends a time-shift request,
the MST server starts a new unicast RTP session and transmits the
unicast stream to the RTP receiver over that session. A simplified
network diagram showing this scenario employing an intermediary
network element is shown in Figure 1, where the hashed lines show the
unicast stream.
+--------------------------------+
| Intermediary Network Element |
| |
| MST Server |
+--------------------------------+
^ :
| :
| :
| v
+-----------+ +-------------+ +-------------+
| Multicast | | |---------->| Time-shift |
| |------->| Router | | RTP |
| Source | | |..........>| Receiver |
+-----------+ +-------------+ +-------------+
|
| +-------------+
| | Existing |
+---------------->| RTP |
| Receiver |
+-------------+
Figure 1: Reverse switch for multicast short time-shift
through an intermediary network element
The proposed solution is not dependent on a specific streaming
control protocol like RTSP [ref]. It addresses the synchronization
between a primary multicast RTP stream and a parallel time-shifted
unicast RTP stream. A principle design goal is to use an existing
protocol to define this solution. This improves the versatility of
the existing implementations, and promotes faster deployment and
better interoperability. To this effect, the proposal is to use the
switching of flows from unicast stream to multicast stream described
in RAMS [draft-ietf-avt-rapid-acquisition-for-rtp], and use the
capabilities of RTCP to handle the signaling needed to accomplish
Yang, et al. Expires April 21, 2011 [Page 4]
Internet-Draft Switching for multicast short time-shift October 2010
this automatic reverse switch for multicast short time-shift.
1.1. RTSP Time-shift and MST Reverse Switch
RTSP 2.0[draft-ietf-mmusic-rfc2326bis] is an application-level
protocol for setup and control of the media delivery with real-time
properties, and provides an extensible framework to enable
controlled, on-demand delivery of real-time data, typically streaming
media.
RTSP defines any necessary media transport signalling with regards to
RTP. In appendix C.1 it defines the interaction of RTSP with respect
to the RTP protocol [RFC3550]. Yet RTSP is not limited to RTP media
delivery control but any delivery type of data. It provides a
general media delivery control mechanism to play out the media, pause
media, or stop media over different delivery channels, such as UDP,
multicast UDP, TCP, RTP over UDP, etc.
RTSP can also provide interactive time-shift function with different
scale and speed. Section 13.4.8 in [draft-ietf-mmusic-rfc2326bis]
has a scenario for Playing Live with time-shift where a certain media
server may offer time-shift services to their clients. The usage of
this play method can implement time- shift for Live Media or On-
demand Media. Section 16.44 in [draft-ietf-mmusic-rfc2326bis]
addresses the scaling for video and audio, it suggests sending only
key frames for video but this may not achieve the right scale speed
since it depends on the locality of such frames in the stream. It
also requires analysis of the media payload for all supported codecs
to find the key frames. In this document we call the interactive
time-shift function in [draft-ietf-mmusic-rfc2326bis] as "RTSP Time-
shift".
For Live Media using RTP multicast over UDP, RTSP Time-shift can
provide an initial switch from multicast session to unicast session
when time-shift happens, but it cannot complete the reverse switch
from unicast session of time-shift to the original multicast session.
An MST server can for example transmit the unicast stream of the
time-shift by a short burst stream and indicate to the receivers to
speed up the playback through Non-perceptual Speedup Playback. After
the burst of the unicast stream of time-shift catches up with the
primary multicast stream, the client can switch back to the primary
multicast stream so that the network bandwidth can be effectively
saved. The synchronization due to catch up with the primary
multicast session may also happen due to the client operation like
the fast forward.
Yang, et al. Expires April 21, 2011 [Page 5]
Internet-Draft Switching for multicast short time-shift October 2010
1.2. RAMS and MST Reverse Switch
RAMS [draft-ietf-avt-rapid-acquisition-for-rtp] describes a method
using the existing RTP and RTCP protocol for reducing the acquisition
delay, allowing fast channel switch. RAMS defines the reverse switch
from unicast burst session to the primary multicast session.
2. Conventions
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 [RFC2119].
3. Definitions
This document uses the following acronyms and definitions frequently:
Time-shift Control: Refers to the manipulation control of time-shift
service (e.g. pause, slow-motion video, frame-by-frame viewing,
rewind, fast- forward, etc.), not include the play method.
Time-shift Playback: Refers to the normal playback with a natural
playback rate after the time-shift control.
Multicast Time-shift Interval: Refers to the time interval or the
number of packets between the primary multicast stream and the normal
playback during the unicast session after the time-shift control. In
other words, it presents the time interval between the start point
frame of the unicast session and the frame of the current location of
the primary multicast session.
Multicast Short Time-shift: The case when the multicast Time-shift
Interval is short, such as 30 seconds. The normal playback during
the unicast session after the time-shift control means that viewers
finish the time-shift control (e.g. pause, rewind and fast-
forward)and start to receive the unicast stream and play back again
at the speed of the Primary multicast stream.
Primary multicast stream: The multicast stream before time-shift
request.
Instant Replay: It is the case of the replaying of video footage of
an event or incident directly after its occurrence. In television
broadcasting of sports events, instant replay is often used during
live broadcast, to show a passage of play which was important or
remarkable, or which was unclear on the first sight.
Yang, et al. Expires April 21, 2011 [Page 6]
Internet-Draft Switching for multicast short time-shift October 2010
Slow-motion Video: The case when the playback of a video clip appears
to be slower than the natural speed of the events.
Non-perceptual Speedup Playback: During the speedup playback, after
each interval of some frames, one frame is skipped as if it was not
present, the next frame is directly rendered to take the place of the
skipped frame, while keeping a fixed Frame Per Second (FPS)during the
playback speedup.
4. Reverse switch for multicast short time-shift
This section gives an overview on the proposed method for reverse
multicast time- shift switch from unicast time-shift RTP Sessions.
4.1. Overview
RTP Control Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback [RFC5760] specifies an extension to
the RTCP to use unicast feedback to a multicast sender. The (Unicast
RTCP) Feedback Target is a logical function to which RTCP unicast
feedback traffic is addressed. The functions of the Feedback Target
and the Distribution Source MAY be co-located or integrated in the
same entity. In this case, The (Unicast RTCP) Feedback Target MAY be
co-located or integrated in the Multicast Time-shift Server.
This section presents a proposed method to switch back to the
multicast session from the unicast session of time-shift considering
multicast short time-shift. The proposed method allows the network
bandwidth to be effectively saved when an RTP receiver finishes its
time-shift request and starts its time- shift playback by unicast
stream. A Multicast Short Time-shift Server (MST) and new RTCP
feedback messages are also introduced for the proposed method.
The MST server has a cache where the most recent packets from the
primary multicast stream are continuously stored for some time. When
a viewer wants to normally playback the unicast stream after time-
shift request, the RTP receiver needs to send a playback request to
the feedback target, and then receives the unicast stream from the
MST server. In order to switch back to the original multicast
stream, the MST server needs to transmit a burst unicast stream to
RTP receivers. Using an accelerated bitrate (as compared to the
bitrate of the original multicast stream). This means that at a
certain point in time, the unicast burst will catch up with the
original multicast stream. At this point, the RTP receiver no longer
needs to receive the unicast burst and can switch back to the
original multicast session.
Yang, et al. Expires April 21, 2011 [Page 7]
Internet-Draft Switching for multicast short time-shift October 2010
The transmission of the unicast burst stream of time-shift playback
depends on the time-shift buffer size of RTP receivers and the
Multicast Short Time-shift Interval. In the case when the time-shift
buffer size of an RTP receiver can inadequately accommodate the
number of packets of the Multicast Short Time-shift Interval, the
receiver needs to playback for the duration of the speeding-up until
the remaining number of packets does not overflow at the time-shift
buffer. During the playback of the speeding-up, the receiver may
speed up video playback by the non-perceptual speedup playback so
that viewers could never perceived the existence of the speeding-up.
Refer to [I-D.yang-avt-rtp-synced-playback]
4.2. Message Flows
This section introduces the different messages for the proposed
method and the related messages flows.
- MST(Multicast Short Time-shift) synchronization
transmission(MSTST): This is the generic form of the different
messages that will be transmitted during the proposed method in this
draft for reverse switch multicast short time-shift.
-Time-Shift-Control-Commands: This message presents the request for
the Time-Shift service (e.g. fast forward, pause, reverse, ..etc.).
This message may be addressed by the MST server or other time-shift
server.
- MSTST Playback Request(MSTST-PReq): It's the message sent from the
RTP receiver to the MST to request the playback after the time-shift
request.
- MSTST Playback Response(MSTST-PRes): It's the response message sent
from the MST to the RTP receiver to confirm the playback process
initiation. Following this message, the RTP receiver will receive
the unicast burst RTP stream from the MST.
- MSTST Synchronization Indication(MSTST-SInd): When the unicast
burst catch up with the original multicast stream, this message is
sent from the MST to the RTP receiver to indicate this fact.
- MSTST Synchronization Response(MSTST-SRes): This message is sent by
the RTP receiver as a response to the MST confirming the need to
switch back to the original multicast session. Following this
message the RTP receiver is able to receive the multicast stream.
- MSTST Termination Request(MSTST-TReq): This message is sent by the
RTP receiver to the MST to terminate the process of the time-shift.
Yang, et al. Expires April 21, 2011 [Page 8]
Internet-Draft Switching for multicast short time-shift October 2010
- MSTST Termination Response(MSTST-TRes): This message is a reply
sent by the MST to the RTP to confirm to the MSTST-TReq.
-------------------------
| MST Server |
----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) |
----------- | | -------- ------------
| ------------------------- | |
| | | |
|--- RTP Multicast->-------------------->| |
| | | |
| ................................................
| . .
| . <::Time-shift control commands ::> .
| . ..Time-shift media stream ..> .
| ................................................
| | | |
| |<''''''''' RTCP MSTST-PReq''''''''|
| |'''''''''' RTCP MSTST-PRes'''''''>|
| | | |
| | | |
| |....... Unicast RTP Burst .......>|
| | | |
| | | |
| |'''''''''' RTCP MSTST-SInd'''''''>|
| |<''''''''' RTCP MSTST-SRes''''''''|
| | | |
| | | |
| | |<~SFGMP Join~|
| | | |
| | | |
|------------------ RTP Multicast -------------------->|
| | | |
| | | |
| |<''''''''' RTCP MSTST-TReq''''''''|
| |'''''''''' RTCP MSTST-TRes ''''''>|
| | | |
| | | |
| |<''''''''' (RTCP BYE) ''''''''''''|
| | | |
Yang, et al. Expires April 21, 2011 [Page 9]
Internet-Draft Switching for multicast short time-shift October 2010
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. Acknowledgements
TBD.
8. Normative References
[I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-24 (work in
progress), July 2010.
[I-D.yang-avt-rtp-synced-playback]
Yang, P. and Y. Wang, "Synchronized Playback in Rapid
Acquisition of Multicast Sessions",
draft-yang-avt-rtp-synced-playback-04 (work in progress),
March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Authors' Addresses
Peilin Yang
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District, Nanjing 210012
P.R.China
Phone: +86-25-56622638
Email: yangpeilin@huawei.com
Yang, et al. Expires April 21, 2011 [Page 10]
Internet-Draft Switching for multicast short time-shift October 2010
Roni Even
Huawei Technologies Co., Ltd.
14 David Hamelech, Tel Aviv 64953
Israel
Email: even.roni@huawei.com
Hassnaa Moustafa
France Telecom - Orange
38-40 rue du General Leclerc Issy Les Moulineaux, 92794 Cedex 9
France
Email: hassnaa.moustafa@orange-ftgroup.com
Tina Tsou (editor)
Huawei Technologies
Section F, Huawei Industrial Base
Bantian Longgang, Shenzhen 518129
P.R. China
Phone: +86 755 28972912
Email: tena@huawei.com
Gu Yingjie
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District, Nanjing 210012
P.R.China
Email: guyingjie@huawei.com
Yang, et al. Expires April 21, 2011 [Page 11]