Internet DRAFT - draft-einarsson-mmusic-rtsp-macuri
draft-einarsson-mmusic-rtsp-macuri
Multiparty Multimedia Session T. Lohmar
Control Working Group Ericsson GmbH
Internet-Draft J. Gordon
Intended status: Experimental RealNetworks, Inc.
Expires: January 14, 2010 T. Einarsson
Ericsson AB
July 13, 2009
Fast Content Switching with RTSP 2.0
draft-einarsson-mmusic-rtsp-macuri-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Lohmar, et al. Expires January 14, 2010 [Page 1]
Internet-Draft RTSP-FCS July 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
RTSP defines the setup and control for on demand and live streaming
media sessions, which are delivered via an external media transport
protocol such as RTP/UDP. RTSP does not define a mechanism to change
the content during an on-going streaming session. Such a mechanism
improves the streaming experience when a user browses through
multiple offerings on a single streaming site.
This document describes several methods to improve content switching.
The basic principle is to re-use already established transport
sessions (e.g. RTP/UDP sessions) and negotiate new content to be
delivered on the existing sessions. If additional transport sessions
are necessary, those sessions are established separately. This
principle of re-using the RTSP control and transport sessions
decreases the content switch delay to a large extent and improves the
end-user experience.
The present document defines a mechanism for switching to new
content, both when the client already has the content description
available and when it does not.
This document additionally considers switching of a single media
stream in a session, when several alternative media components are
available. For instance, the content may provide several alternate
audio tracks in different languages to be played with a single video
stream.
The principle of Fast Content Switching and Start-up is also defined
in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326].
Requirements Language
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].
Lohmar, et al. Expires January 14, 2010 [Page 2]
Internet-Draft RTSP-FCS July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. High level procedure description . . . . . . . . . . . . . 4
1.2. New features for RTSP 2.0 . . . . . . . . . . . . . . . . 6
2. RTSP 2.0 Protocol Extension . . . . . . . . . . . . . . . . . 6
2.1. "Switch-Stream" RTSP Header Field . . . . . . . . . . . . 6
2.2. Semantics of RTSP PLAY method . . . . . . . . . . . . . . 7
2.3. RTP Transport Sessions . . . . . . . . . . . . . . . . . . 8
3. Switching to new content with available description . . . . . 8
4. Switching to new content without content description . . . . . 9
5. Switching Media within an RTSP session . . . . . . . . . . . . 11
6. Adding Media Components to an ongoing session . . . . . . . . 12
7. Removing Media Components from an ongoing session . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Lohmar, et al. Expires January 14, 2010 [Page 3]
Internet-Draft RTSP-FCS July 2009
1. Introduction
RTSP defines the setup and control for on demand and live streaming
media sessions. The media data is delivered via an external media
transport protocol, typically RTP/UDP. RTSP does not define a
mechanism to change the content during an on-going streaming session.
When changing from one RTSP resource to another offered by the same
server, the streaming session must be torn down and newly
established. This procedure can take an excessive amount of time and
resources.
The present document defines a mechanism to change the streaming
content during an on-going RTSP session. The existing transport
sessions are re-used. Additional transport sessions may be
established when the new content conains more media components than
needed for the old content and unnesessary transport sessions may be
released when no longer needed. Such a mechanism improves the
streaming experience when a user browses through various content
offered by same streaming server.
The RTSP protocol extensions defined in the present document are
applicable for both live and on-demand streaming sessions. A number
of general RTSP extensions are defined to enable fast content
switching during an on-going streaming session. These extensions are
to be implemented by RTSP clients and servers wishing to support any
of these features. Feature tags are used to exchange supported
capabilities.
1.1. High level procedure description
A streaming client needs to have an RTSP URI to start the streaming
session. The required codecs and transmission formats are described
via SDP or other supported media description format. The client may
need to retreive the content description from the RTSP server prior
to session setup.
In order to establish a streaming session, the client first needs to
establish transport sessions for each media component it will be
streaming. Each media component is uniquely identified by a media
control URI. Transport parameters such as UDP source and destination
ports are exchanged during the set-up of the transport sessions. The
control URIs are described in the session description.
When all needed transport sessions are established, the actual
content delivery and reception process can begin (RTSP PLAY method).
The client receives needed synchronization information with the PLAY
response from the server. This includes timestamp synchronization,
sequence numbers and synchronization source identifiers (SSRCs) per
Lohmar, et al. Expires January 14, 2010 [Page 4]
Internet-Draft RTSP-FCS July 2009
media components (identified by according media control URIs).
When the user changes to new content on the same server, only one
PLAY transaction is needed when the number of media components are
the same (e.g. old session contains audio and video media components
and the new content does as well). New synchronization information
is provided with the RTP-Info in the PLAY response. Replacement the
media control URIs for the transport sessions is also clarified
during the PLAY transaction.
In case the number of needed media components is increased (e.g.
switching from audio and video content to audio, video and timed-
text), then the client establishes additonal transport sessions.
Synchronization with the earlier established components is realized
through the RTSP PLAY transaction. In case the new content needs
fewer media components then the old content, the unnecessary
components are released.
The fast content switching procedure does not require a client to
have all SDP information before switching to new content. It may
request the SDP information for the new content with the RTSP PLAY
request. Therefore, the procedure of content switching with and
without an available session description is slightly different and
will be handled independently in the following.
Content Switching with content description:
If the client has already received the content description before the
fast content switch request, it can process it prior to the switch
request and determine whether or not additional media components are
needed. In case new media components are needed, the client may
establish the new transport sessions either before or pipelined with
the PLAY request for the new content.
Content Switching without content description:
Often the client does not have the content description but only an
aggregate RTSP content description URI. Since the streaming sessions
will frequently constist of the same number of media components (e.g.
one audio and one video), it is very likely that the client can re-
use established transport sessions. In case fewer media sessions are
required, the client can release its established resources when it
receives the response. If additional media sessions are needed, the
client may establish these sessions after the media description
response is received.
Switching an individual component in a streaming session:
Lohmar, et al. Expires January 14, 2010 [Page 5]
Internet-Draft RTSP-FCS July 2009
This document also defines a mechanism to change parts of the content
during an ongoing streaming session. For instance, the user may
choose to change the audio stream from the original language track to
a translation in another language. Alternatively, he may wish to
change only the video component - such as a different camera view
during a racing event - while keeping the same audio stream.
In most cases, a content switch can be performed with a single RTSP
transaction. However, in order to preserve interoperability with
RTSP-aware intermediate devices such as application layer gateways,
RTSP clients should ensure that SETUP requests and responses are sent
for each transport session to be used. This allows the intermediate
device to establish the necessary configuration, for instance routing
of UDP ports for RTP/UDP sessions. Once the transport session has
been negotiate with a SETUP request and response, it may be reused
for subsequent content upon a switch.
1.2. New features for RTSP 2.0
The following new RTSP feature tags are defined:
o "rtsp-switch" feature-tag, defined in Section 3.
o "rtsp-switch-req-sdp" feature-tag, defined in Section 4.
o "rtsp-switch-stream" feature-tag, defined in Section 5.
In addition the following new RTSP header fields are defined:
o "Switch-Stream" header, defined in Section 2.1.
o "SDP-Requested" header, defined in Section 4.
2. RTSP 2.0 Protocol Extension
In order to change the content of an on-going RTSP session, a number
of streaming parameters are changed for the new content. The new
parameters for the transport session can be provided with the RTP-
Info field in the PLAY response. A new protocol header to replace
the RTSP control and media URIs is described in the next section
followed by the expected semantics of the RTSP PLAY method.
2.1. "Switch-Stream" RTSP Header Field
The "Switch-Stream" header field may be used in an RTSP PLAY request
or response message. It is used to describe the replacement of media
streams after a content switch. The "Switch-Stream" header field may
Lohmar, et al. Expires January 14, 2010 [Page 6]
Internet-Draft RTSP-FCS July 2009
be used with aggregated control and with media control URIs.
The "Switch-Stream" header syntax in ABNF [RFC5234] is as follows:
Switch-Stream = "Switch-Stream" COLON switch-spec
*(COMMA switch-spec) CRLF
switch-spec = old-stream ";" new-stream
old-stream = "old" "=" (DQ rtsp-url DQ) / (DQ DQ)
new-stream = "new" "=" (DQ rtsp-url DQ) / (DQ DQ)
rtsp-url = rtsp-url ; as defined in RFC 2326 [5]
DQ = %x22 ; US-ASCII double-quote mark (34)
LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace
COMMA = * ( SP / HT ) "," SWS; comma
COLON = * ( SP / HT ) ":" SWS; colon
If both old media stream and new media stream URIs are indicated in
the "Switch-Stream" header field of a PLAY request from an RTSP
client to an RTSP server, then the server MUST interpret this as a
request to replace the specified media stream with the new media
stream, hence reusing the existing transport parameters.
If the "Switch-Stream" header field is included in a PLAY response
from an RTSP server to an RTSP client, then this header informs the
client about the media streams that are currently being streamed to
the client. The old media stream MAY be omitted in this case.
If only the new media stream URI is indicated in the "Switch-Stream"
header field of a PLAY request from an RTSP client to an RTSP server,
then the RTSP server MUST interpret this as a request to switch to
the new media stream. The server decides the mapping. The RTSP
server MUST indicate the SSRC of the new media stream in the RTP-Info
of the reply, in order to enable the client to locate the new stream.
If only the old stream URI is indicated in the "Switch-Stream" header
field of a PLAY request from an RTSP client to an RTSP server, then
the server MUST interpret this as a request for complete removal of
the specified media stream. The client and the server release the
resources for this stream without explicit TEARDOWN signalling, as
such signalling may lead intermediate application level gateways or
RTSP proxies to also release the RTSP session and the other transport
resources. The usage of the "Switch-Stream" header is defined in
clauses Section 3, Section 4 and Section 7.
2.2. Semantics of RTSP PLAY method
A PLAY request sent while a stream is still playing is a legal
operation in RTSP 2.0 with different semantics than those defined in
Lohmar, et al. Expires January 14, 2010 [Page 7]
Internet-Draft RTSP-FCS July 2009
RTSP 1.0. The later PLAY request replaces the first PLAY request.
The new PLAY request MAY change RTSP session attributes such as the
session identifier.
2.3. RTP Transport Sessions
The most common media transport for RTSP is RTP/UDP. The following
descriptions and definitions are applicable when using RTP/UDP as
media transport. Other media transport protocols may require similar
considerations which are not defined in the present document.
After switching content as defined by this document, the SSRC
identifier used on a specific RTP session may change. In the event
that the SSRC changes, it MUST be included in the RTP-Info header.
The RTSP server MUST change the SSRC value for a specific RTP session
after a fast content switching operation is performed if any of the
following apply:
o the payload types of the old and new media streams are the same but
the payload configuration differs;
o the clockrate of the new media stream is different from the old; or
o the mapping of the new media stream is otherwise unknown to the
RTSP client.
In case the SSRC remains unchanged after a content switch, the RTP
sequence numbering MUST be continuous and monotonically increasing
and the timestamp clock MUST maintain continuity. Additionally, if
the payload type also remains the same, the old media stream and new
media stream MUST NOT contain any packets with decoding dependencies
on unsent packets.
Otherwise, if the SSRC is updated, a random RTP sequence number and
timestamp SHOULD be chosen using the same or similar mechanisms to
those used when initiating a new media session as described in RFC
3550 [RFC3550].
3. Switching to new content with available description
This clause defines all necessary RTSP client and server features for
fast content switching when the client already has the content new
description locally available; for instance, the client may have
previously fetched the SDP using RTSP DESCRIBE or HTTP GET. Clients
should assume that the herein defined fast content switching
procedure is supported for all content items offered by this server.
This feature reduces the RTSP protocol overhead of switching to a
Lohmar, et al. Expires January 14, 2010 [Page 8]
Internet-Draft RTSP-FCS July 2009
single client-server interaction.
The feature-tag indicating this feature is "rtsp-switch". The client
should probe the server capabilities as early as possible in the
communication using the "rtsp-switch" tag in the "Supported" header.
The client SHOULD use the "Require" header with this feature tag
value when requesting this behaviour from the server. The server
MUST use the PLAY method as defined in Section 2.2 and
[I-D.ietf-mmusic-rfc2326bis] when the client requests this feature.
Thus replacing the currently streaming content with the newly
requested media, resulting in a switch of streamed content.
When the RTSP client wants to change the content of the RTSP session,
the RTSP client sends a PLAY request with the aggregated control URI
of the new content to the RTSP server. The aggregated control URI is
defined as in RFC 3550 [RFC3550]
The RTSP client MUST add the media control URIs of the new streams
requested in the "Switch-Stream" header field of the RTSP PLAY
request. Whenever possible, the RTSP client SHOULD map media control
URIs of the same media type (e.g. audio or video) in the old content
to the same media type of the new session. Note, this is only
applicable for media types which are present in both the old and new
content. The server MUST always include the "Switch-Stream" header
in the response, indicating the new media streams being sent. The
"Switch-Stream" header field is defined in Section 2.1.
If the SSRC identifiers have changed, then the server MUST indicate
the new SSRC values of the new media streams within the "RTP-Info"
header in the RTSP PLAY response.
Note: if the new session contains more media components than the
current session, the client MAY switch according to this section,
describing the desired components in the "Switch-Stream" header and
add the missing components using the method defined in Section 6.
If fewer media components are present in the new session than the
existing session, the client and the server remove the unused
components as defined in Section 7.
4. Switching to new content without content description
Clients should assume, that the here defined fast content switching
procedure is supported for all content items offered by this server.
The client uses the RTSP URI of the content session as the request
URI to describe the new content item.
Lohmar, et al. Expires January 14, 2010 [Page 9]
Internet-Draft RTSP-FCS July 2009
Without an SDP or other adequate content description, the client is
unable to specify the streams to which it wishes to subscribe. In
order to initiate a content switch within a single RTSP round trip,
the client MAY perform a PLAY request to initiate a switch via
content URI without specifying individual streams. This allows the
client to request that the server return a content description,
initiate a new session, setup all relevant media streams (or make an
appropriate stream selection), and begin playback. The content URI
used in the PLAY request is the same content URI used in a DESCRIBE
request. In order to signal that it wishes to receive the
description and make a switch, the client MUST include the "SDP-
Requested" header as defined below.
SDP-Requested-Header = " SDP-Requested" COLON "1"
If a server receives a PLAY request and completes all actions
successfully, the server responds with the content description,
Session-ID, RTP-Info or other required transport headers, and a
"Switch-Stream" Section 2.1 descriptor and begins streaming the new
content immediately. Whenever possible, the RTSP server SHOULD map
the media control URIs of the same media type (e.g. audio or video)
in the old content to the same media type of the new session. Note:
this is only applicable for media types which are present in both the
old and new content. In case of RTP transport, the RTP-Info in the
PLAY response MUST contain the SSRC for each stream. The server MAY
issue a new session ID in the response, or it may re-use the existing
session ID. The client MUST be prepared for either case.
If the server is not yet able to begin streaming, it responds with a
202 (Accepted) success code and an appropriate session description.
The client may then perform a switch as described in Section 3
specifying the streams it would like to receive. This condition can
occur if the server requires further client input regarding stream
setup prior to beginning playback - for instance if the content
requested is available in multiple alternate languages and the server
does not have the information necessary to choose a language.
If the server is not yet able to begin transmitting all the media
streams, it MAY begin a subset of the streams and respond with a 206
(Partial Data) success code and a session description. The "Switch-
Stream" header and the "RTP-Info" header will indicate which streams
have been selected for playback. The client MAY then add additional
media components as described in Section 6.
If fewer media components are present in the new content than are
currently in use, then the server responds with a 200 (OK). The
client MUST then remove the "unused" media components as defined in
Section 7.
Lohmar, et al. Expires January 14, 2010 [Page 10]
Internet-Draft RTSP-FCS July 2009
The client and the server SHOULD release the resources for the unused
streams without explicit TEARDOWN signalling.
The feature tag "rtsp-switch-req-sdp" is defined to describe support
for this feature. The client SHOULD probe the server capabilities as
early as possible in the communication using the "Supported" header
and SHOULD use the "Require" header with this feature tag value when
requesting this behaviour from the server. The server MUST use the
PLAY method semantics defined in Section 2.2 and
[I-D.ietf-mmusic-rfc2326bis] when the client requests this feature.
5. Switching Media within an RTSP session
Some content may be available for streaming in different
representations. An example of such a use case is the live streaming
of a sport event with multiple camera views. The session description
available at the receiver describes multiple options for one or
several media types (e.g. video, audio, or subtitles). Upon initial
setup of the session, the player (or the user) selects the preferred
combination of the presentation to be consumed and sets up the
corresponding media streams. At a later point, the user may trigger
a switch to a different media stream carrying an alternative
representation of the media.
The PLAY request is sent with the "Switch-Stream" header field as
defined in Section 2.1 indicating the URIs of both the old media
stream and the new replacement stream. Upon receiving a PLAY request
with a "Switch-Stream" header field for an active session, an RTSP
server that supports this feature switches to the new media stream
using the same transport parameters described in the initial SETUP
request for the old media stream. After successfully processing the
request, the RTSP server MUST reply with an "RTP-Info" header
indicating all active media streams in the changed session, including
those that are unchanged. The "RTP-Info" header MAY include the
SSRCs for each active media stream; it MUST contain all new SSRCs of
the changed streams if the SSRCs have changed. The response MAY also
include the "Switch-Stream" header, indicating the stream switches
that were successful. If the "Switch-Stream" header field is not
present in a successful response and the RTSP server was identified
to support the media switching functionality, the receiver MUST
assume that all requested switches were successful.
The feature tag "rtsp-switch-stream" is defined to describe support
for this feature. This feature tag is different than the feature tag
"rtsp-switch" described in Section 3 indicating the support for
content (aggregated stream) switch. The client SHOULD use the
"Require" header with this feature tag value when requesting this
Lohmar, et al. Expires January 14, 2010 [Page 11]
Internet-Draft RTSP-FCS July 2009
behaviour from the server.
The server MUST use the PLAY method semantics as defined in
Section 2.2 and [I-D.ietf-mmusic-rfc2326bis]when the client requests
this feature. Note that several media streams of a presentation may
be switched at the same time in a single PLAY request.
6. Adding Media Components to an ongoing session
It may happen that the new content stream consists of more media
components than the ongoing content stream. In such a case, it is
RECOMMENDED that the client switch to the new content with the
already established resources and then add further components.
The client SHOULD pipeline the setup requests for the new components
after the content switching request. The client MUST issue a PLAY
request after the successful establishment of the new media
components to start all media components. If the server has
successfully added the media component, the "RTP-Info" header in the
RTSP PLAY response MUST contain the synchronization information for
all media components.
The session id value of the already established session MUST be
included in the SETUP request to indicate the relation of the new
media component to the established session.
7. Removing Media Components from an ongoing session
A RTSP client wishing to terminate the streaming of a specific media
stream MAY send a PLAY request with a "Switch-Stream" header
Section 2.1 indicating the URI of the media stream to be torn down as
the "old-stream". No URI for the "new-stream" should be specified.
Upon receiving a PLAY request with a "Switch-Stream" header field
indicating that one or more media streams are to be terminated, the
server MUST stop streaming the indicated media streams and SHOULD
release the unused resources, (e.g. RTP/RTCP UDP ports). The other
media streams MUST NOT be interrupted.
After successfully processing the request, the server MUST reply with
a success response message and a "Session" header field, even if the
session contains no more media streams.
The RTSP client MUST only use TEARDOWN to completely tear down the
whole session.
Lohmar, et al. Expires January 14, 2010 [Page 12]
Internet-Draft RTSP-FCS July 2009
8. IANA Considerations
The feature tags "rtsp-switch", "rtsp-switch-req-sdp" and "rtsp-
switch-stream" need to be registered with IANA.
9. Security Considerations
Same as for RTSP [I-D.ietf-mmusic-rfc2326bis].
10. Acknowledgements
This document has benefited greatly from the discussions and comments
from all those participating in 3GPP TSG SA4. In particular, the
following individuals have contributed to this specification: Gamze
Seckin, Imed Bouazizi, Frederic Gabin, Igor Curcio, Francois Martin
11. References
11.1. 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-22 (work in
progress), July 2009.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
11.2. Informative References
[3GPP.26.234]
3GPP, "Transparent end-to-end Packet-switched Streaming
Service (PSS); Protocols and codecs", 3GPP TS 26.234
4.5.0, January 2003.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
Lohmar, et al. Expires January 14, 2010 [Page 13]
Internet-Draft RTSP-FCS July 2009
Authors' Addresses
Thorsten Lohmar
Ericsson GmbH
Ericsson Allee 1
Herzogenrath 52134
Germany
Phone: +49-2407-5757816
Fax: +49-2407-575400
Email: Thorsten.Lohmar@ericsson.com
Jamie Gordon
RealNetworks, Inc.
2601 Elliott Avenue
Seattle, WA 98121
USA
Phone: +1-206-674-2700
Fax:
Email: jgordon@real.com
Torbjoern Einarsson
Ericsson AB
Faeroegatan 6
Stockholm 164 80
Sweden
Phone:
Fax:
Email: Torbjorn.Einarsson@ericsson.com
Lohmar, et al. Expires January 14, 2010 [Page 14]
