Internet DRAFT - draft-lindquist-sip-rtsp
draft-lindquist-sip-rtsp
Network Working Group J. Lindquist
Internet-Draft J. Maenpaa
Intended status: Informational Ericsson
Expires: December 11, 2010 P. Rajagopal
Motorola
X. Marjou
France Telecom Orange
June 9, 2010
Controlling Session Initiation Protocol (SIP)-Established Content
Delivery Channels Using the Real-Time Streaming Protocol (RTSP)
draft-lindquist-sip-rtsp-02.txt
Abstract
The Session Initiation Protocol (SIP) is widely used for establishing
multimedia sessions, whereas the Real Time Streaming Protocol (RTSP)
is used in streaming media systems. RTSP has a dual role: it
establishes a media session for the delivery of streaming media as
well as controls the streaming session once it has been set up.
Since SIP is also used for session establishment, there exists an
overlap between the functionality provided by SIP and RTSP. In this
document, we describe a model adopted by ETSI TISPAN, 3GPP, and Open
IPTV Forum (OIPF) in which SIP and the SDP offer/answer model are
used to set up a streaming session with an RTSP control channel and
one or more media delivery streams. Such a model is beneficial since
it allows the reuse of current architecture and functionality (e.g.,
authentication, charging, and QoS) established around SIP for RTSP-
based streaming. The model benefits applications such as Internet
Protocol Television (IPTV). In addition to the model, the document
specifies two new variants of RTSP.
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."
Lindquist, et al. Expires December 11, 2010 [Page 1]
Internet-Draft Combining SIP and RTSP June 2010
This Internet-Draft will expire on December 11, 2010.
Copyright Notice
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.
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.
Lindquist, et al. Expires December 11, 2010 [Page 2]
Internet-Draft Combining SIP and RTSP June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Generic SIP-based Video Delivery Architectures . . . . . . . . 8
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Reuse of Features of Existing Architectures . . . . . . . 9
4.1.1. Authentication, Authorization, and Accounting
Capabilities . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Quality of Service and Resource Reservation
Capabilities . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Security Features . . . . . . . . . . . . . . . . . . 10
4.1.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10
4.2. Advanced Media Applications . . . . . . . . . . . . . . . 10
5. High-level Procedures . . . . . . . . . . . . . . . . . . . . 10
5.1. Summary of the Procedures . . . . . . . . . . . . . . . . 11
5.2. Details of the Procedures . . . . . . . . . . . . . . . . 11
5.2.1. Establishment of Content Control and Content
Delivery Channels . . . . . . . . . . . . . . . . . . 11
5.2.2. Modification of Content Delivery Channels . . . . . . 13
5.2.3. Teardown of Content Control Channel and the
Associated Content Delivery Channel(s) . . . . . . . . 15
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Content Control Protocol Accessing Resources
Established by Session Management Protocol . . . . . . . . 16
6.2. Use of Transport Addresses in Content Control and
Session Management Protocols . . . . . . . . . . . . . . . 16
6.3. Session Termination . . . . . . . . . . . . . . . . . . . 17
7. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Combining SIP/SDP and RTSP . . . . . . . . . . . . . . . . . . 18
8.1. Method 1: Lightweight RTSP without Session Setup
Semantics . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. Session Establishment Initiated by UE . . . . . . . . 18
8.1.2. Session Establishment Initiated by Controller . . . . 20
8.1.3. Session Termination . . . . . . . . . . . . . . . . . 22
8.1.4. Discussion on the Requirements . . . . . . . . . . . . 23
8.2. Method 2: Full RTSP . . . . . . . . . . . . . . . . . . . 25
8.2.1. Session Establishment Initiated by UE . . . . . . . . 25
8.2.2. Session Establishment Initiated by Controller . . . . 26
8.2.3. Session Termination . . . . . . . . . . . . . . . . . 27
8.2.4. Discussion on the Requirements . . . . . . . . . . . . 28
9. Establishment of Content Control and Content Delivery
Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Procedures at the SDP Offerer . . . . . . . . . . . . . . 29
9.1.1. UE as the SDP Offerer . . . . . . . . . . . . . . . . 29
9.2. Procedures at SDP Answerer . . . . . . . . . . . . . . . . 31
9.2.1. Controller as SDP Answerer . . . . . . . . . . . . . . 31
9.3. Modification of Content Delivery Channel(s) . . . . . . . 32
Lindquist, et al. Expires December 11, 2010 [Page 3]
Internet-Draft Combining SIP and RTSP June 2010
10. Content Control Protocol . . . . . . . . . . . . . . . . . . . 32
10.1. Lightweight RTSP . . . . . . . . . . . . . . . . . . . . . 32
10.2. Procedures at the UE . . . . . . . . . . . . . . . . . . . 33
10.2.1. Media Setup Procedure . . . . . . . . . . . . . . . . 33
10.2.2. Media Playback Initiation Procedure . . . . . . . . . 33
10.2.3. Media Playback Modification Procedure . . . . . . . . 34
10.2.4. Media Playback Information Retrieval and Setting
Procedure . . . . . . . . . . . . . . . . . . . . . . 34
10.2.5. Media Event Notification Procedure . . . . . . . . . . 34
10.2.6. Media Teardown Procedure . . . . . . . . . . . . . . . 34
10.3. Procedures at Media Server . . . . . . . . . . . . . . . . 34
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Content on Demand Session Establishment Using
Lightweight RTSP (Method 1) . . . . . . . . . . . . . . . 35
11.2. Content on Demand Session Establishment Using Full
RTSP (Method 2) . . . . . . . . . . . . . . . . . . . . . 37
11.3. Content on Demand Session Termination Using
Lightweight RTSP (Method 1) . . . . . . . . . . . . . . . 40
11.4. Content on Demand Session Termination Using Full RTSP
(Method 2) . . . . . . . . . . . . . . . . . . . . . . . . 41
12. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13. Security Considerations . . . . . . . . . . . . . . . . . . . 43
13.1. Man-in-the-middle Attack . . . . . . . . . . . . . . . . . 43
13.2. Session Hijacking . . . . . . . . . . . . . . . . . . . . 43
13.3. Privacy Considerations . . . . . . . . . . . . . . . . . . 43
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
14.1. Registration of the 'TCP/ETSI_RTSP' and
'TCP/TLS/ETSI_RTSP' SDP 'proto' Values . . . . . . . . . . 43
14.2. Registration of the SDP 'etsi_rtsp-uri' Attribute . . . . 44
14.3. Registration of the SDP 'etsi_rtsp-session' Attribute . . 44
14.4. Registration of the SDP 'etsi_rtsp-offset' Attribute . . . 45
14.5. Registration of the SDP 'etsi_rtsp-version' Attribute . . 45
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
16.1. Normative References . . . . . . . . . . . . . . . . . . . 46
16.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Lindquist, et al. Expires December 11, 2010 [Page 4]
Internet-Draft Combining SIP and RTSP June 2010
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] is a widely-used
session establishment and rendezvous protocol. Many existing systems
have established mechanisms such as authentication, charging, and
Quality of Service (QoS) around SIP. The Real Time Streaming
Protocol (RTSP) [RFC2326], in turn, is a protocol for use in
streaming media systems. RTSP allows a client to remote control a
streaming media server by issuing commands such as PLAY and PAUSE.
RTSP has a dual role: it establishes a media session for the delivery
of streaming media as well as controls the streaming session once it
has been set up. Since SIP is also used for session establishment,
there exists an overlap between the functionality provided by SIP and
RTSP.
When using RTSP in systems that have established mechanisms such as
authentication, charging, and QoS around SIP, one needs to implement
these mechanisms for RTSP as well. In this document, we argue that
it would be more efficient to reuse the mechanisms that already exist
for SIP. Therefore, we describe a model adopted by European
Telecommunications Standards Institute (ETSI) Telecommunications and
Internet converged Services and Protocols for Advanced Networking
(TISPAN), in which SIP is used to establish the streaming session.
In this model, SIP with SDP offer/answer exchange [RFC3264] is used
to set up an RTSP media control channel and one or more media
delivery streams. The media delivery streams can be for instance
Real Time Protocol (RTP) streams. Thus, in this approach, RTSP is
used to control the media streams that have been set up with SIP.
The TISPAN specifications allow for both full and partial support of
the RTSP RFC [RFC2326] as part of the IPTV service. In the case of
partial support of RTSP, a lightweight version of RTSP without
session setup semantics is used, whereas in the full support
scenario, full RTSP with session setup semantics is used. In
addition to TISPAN, the 3rd Generation Partnership Project (3GPP)
[3GPP TS 26.237] and the Open IPTV Forum (OIPF) [OIPF Volume 4] use
the same model for using SIP to establish an RTSP control channel.
The solution presented in this document is required by a growing
number of Internet Protocol Television (IPTV) implementations.
It should be noted that a model in which SIP and SDP offer/answer
exchange is used to establish a control channel is by no means a new
one. As an example, SIP with SDP offer/answer is used to establish a
Binary Floor Control Protocol (BFCP) [RFC4582] control channel in
floor controlled conferences [RFC4583]. BFCP is a protocol used to
arbitrate access to shared resources (e.g., media streams) in a
conference.
SIP/RTSP interaction has been discussed several times in the MMUSIC
Lindquist, et al. Expires December 11, 2010 [Page 5]
Internet-Draft Combining SIP and RTSP June 2010
working group of the IETF in the past. The following drafts have
dealt with the topic over the years:
[I-D.ietf-whitehead-mmusic-sip-for-streaming-media],
[I-D.ietf.marjou-mmusic-sdp-rtsp], and
[I-D.ietf-lindquist-mmusic-sip-rtsp]. The purpose of the most recent
draft, [I-D.ietf-lindquist-mmusic-sip-rtsp], was to bring the ETSI
TISPAN solution (and adopted by 3GPP and OIPF), of combining SIP and
RTSP to the attention of the MMUSIC working group. The conclusion of
the discussions triggered by the drafts was that there was no
consensus that SIP/RTSP interaction is something that should be
specified in the MMUSIC working group or any other working group of
the IETF. Hence, the authors decided to prepare an independent
submission (i.e., the present document), whose intended status is
informational, to describe the solution. There is no intention to
change the RTSP protocol defined in [RFC2326]. The present document
serves two purposes. First, it describes the solution for combining
SIP and RTSP adopted by ETSI TISPAN, OIPF and 3GPP. Second, it
allocates new codepoints (i.e., new SDP attributes and new SDP
'proto' field value) for the proposed solution.
This document defines two new ETSI variants of RTSP, which are
referred to as lightweight RTSP and full RTSP. Both of the variants
deal with the overlap between SIP and RTSP. Lightweight RTSP removes
the overlap by removing session setup and teardown semantics from
RTSP. Full RTSP keeps the overlap by imposing a number of
requirements on clients. In addition to removing session setup and
teardown functionalities, lightweight RTSP does not use DNS to
resolve RTSP URLs. Similar to lightweight RTSP, also full RTSP does
not use DNS to resolve RTSP URLs. The use of the variants is
indicated by the new SDP 'proto' field values TCP/ETSI_RTSP (used
when RTSP runs directly on top of TCP) and TCP/TLS/ETSI_RTSP (used
when RTSP runs on top of TLS, which in turn runs on top of TCP)
defined later in this document. The fact whether lightweight or full
RTSP is used is determined based on the received SDP, as will be
described in Section 9.2.1.
The rest of the document is structured as follows. Section 3
describes generic SIP-based video delivery architectures composed of
a UE, a controller, and a media server. Section 4 discusses
architecture and functionality reuse as the main motivation for SIP/
RTSP interaction. Section 5 describes the high-level procedures
required to deliver multimedia streaming content within the
architectural framework described in Section 3. Section 6 states
some requirements for a solution that uses separate protocols to
establish a session and control the delivery of streaming media.
Section 7 discusses the design goals of a combined SIP and RTSP
solution. Section 8 presents possible solutions that fulfill the
requirements stated in Section 6. Section 9 describes the SDP
Lindquist, et al. Expires December 11, 2010 [Page 6]
Internet-Draft Combining SIP and RTSP June 2010
procedures associated with establishing, modifying, and terminating
the content control and content delivery channels. Section 10
defines the RTSP related procedures. Section 12 concludes the
document.
2. Terminology
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].
Content Control Channel: An end-to-end communication channel between
a user equipment (UE) and media server used for carrying media
trick play commands such as play, pause, rewind, etc.
Content Control Protocol: A protocol that is used to control the
delivery of media streams. An example of such a protocol is the
Real Time Streaming Protocol (RTSP).
Content Delivery Channel: And end-to-end communication channel
between the UE and media server for carrying content such as
streaming media.
Content Delivery Protocol: The content delivery protocol is used for
delivering content (e.g., media streams).
Controller: The systems considered in this document use an
architecture composed of a controller and a media server. The
controller monitors the session with the media server and handles
user authentication, charging, resource reservation, checking user
services, and keeping track of streaming (e.g., for keeping
bookmarks), among other things
Media Server: The media server is among other things responsible for
storing media, delivering media flows to users, and transcoding
content to different media formats.
Middlebox: A middlebox is defined as any intermediary device
performing functions other than the normal, standard functions of
an IP router on the datagram path between a source host and
destination host [RFC3234]. In this document, a middlebox refers
to an Application Level Gateway (ALG), firewall, or Network
Address Translator (NAT) device located between a User Equipment
(UE) and a controller.
Lindquist, et al. Expires December 11, 2010 [Page 7]
Internet-Draft Combining SIP and RTSP June 2010
Session Management Protocol: Session management protocol is the
protocol that is used to establish content delivery streams and
the control channel for the content control protocol.
Trick Play: Trick play refers to using controls such as pause, fast
forward, rewind, slow-motion, etc.
3. Generic SIP-based Video Delivery Architectures
The SIP-based video delivery systems considered in this document use
an architecture composed of a controller and a media server. The
services provided by the controller and the media server are used by
User Equipment (UE) devices. We are using such a generalized
architecture to be able to cover different standardized SIP-based
architectures for media and IPTV. The media server is among other
things responsible for storing media, delivering media flows to UEs,
and transcoding content to different media formats. The controller,
in turn, monitors the session with the media server and handles user
authentication, charging, resource reservation, checking user
services, and keeping track of streaming (e.g., for keeping
bookmarks), among other things.
The architecture is illustrated in Figure 1. We refer to the
protocol that is used between a UE and the controller for
establishing content delivery stream(s) and a content control channel
as the session management protocol. This protocol is responsible for
carrying information related to client authentication, charging, and
resource reservation, among other things. Between the UE and the
media server, two protocols, a content control protocol and a content
delivery protocol, are used. The first is used for the purpose of
controlling content delivery and the latter for the delivery of
content. In this document, we do not define which protocol is used
on the interface between the controller and the media server.
Instead, we are using generic commands such as "create session",
"modify session", and "destroy session" in the signaling flows.
Although not shown in Figure 1, the UE may be located behind a
middlebox such as an Application Level Gateway (ALG), firewall, or a
Network Address Translator (NAT).
Lindquist, et al. Expires December 11, 2010 [Page 8]
Internet-Draft Combining SIP and RTSP June 2010
____+--------------+
/ | Controller |
/ +--------------+
Session / |
management--> / |
protocol / |
/ |
+--------+ |
| UE | | <-- Media server control
+--------+ |
\ \ Content |
\ \ <-- delivery |
Content \ \ protocol |
control--> \ \ |
protocol \ \______+--------------+
\___________| Media Server |
+--------------+
Figure 1: Generic SIP-based video delivery architecture
4. Motivation
4.1. Reuse of Features of Existing Architectures
The main motivation for using SIP/SDP to establish an RTSP control
channel is that it makes it possible to reuse existing mechanisms and
features available in SIP based architectures without the need to
implement them for RTSP as well.
4.1.1. Authentication, Authorization, and Accounting Capabilities
Many architectures have established Authentication, Authorization,
and Accounting (AAA) mechanisms around SIP. An interface to AAA
infrastructure for SIP servers is defined in RFC 4740 [RFC4740]. The
Diameter SIP application (a Diameter application is not a software
application, but a protocol based on the Diameter base protocol)
specified in the RFC can be used to authenticate and authorize the
usage of SIP-based multimedia services. SIP has also been extended
to carry charging information [RFC3455]. If SIP is used to establish
RTSP-controlled media streams, the existing AAA interface can be used
to authenticate and authorize the usage of streaming services and to
do accounting.
4.1.2. Quality of Service and Resource Reservation Capabilities
Many systems have also established QoS around SIP. It is possible to
negotiate the QoS mechanism to use for a particular media stream
Lindquist, et al. Expires December 11, 2010 [Page 9]
Internet-Draft Combining SIP and RTSP June 2010
using SIP/SDP, as described in RFC 5432 [RFC5432]. Also resource
management and SIP have been integrated [RFC3312]. The way QoS
admission control is integrated with SIP and how a SIP proxy
interfaces with QoS policy control is described in RFC 3313
[RFC3313]. RTSP-controlled media streams could greatly benefit from
the QoS mechanisms established around SIP.
4.1.3. Security Features
Certain SIP architectures use SIP Application Level Gateways (ALGs)
such as Session Border Controllers (SBCs)
[I-D.ietf-sipping-sbc-funcs] between the access network and a SIP
core network or between two SIP core networks. The SIP/RTSP model
proposed in this document makes it possible to reuse this security
infrastructure for RTSP-based streaming.
4.1.4. NAT Traversal
The content that a user wants to stream may be stored on a remote
user device located behind a Network Address Translator (NAT). The
use of SIP to establish RTSP-controlled content delivery streams
could make endpoint-hosted streaming easier, even if the remote user
device is behind a NAT. If the remote device is running a SIP
application and the user of the remote device has registered from the
device to a SIP proxy, the connection that the remote device
maintains to its SIP proxy can be used by the receiver to send a SIP
INVITE with SDP payload describing an RTSP control channel and
content delivery stream(s) to the remote device. This way the remote
content can be streamed even if the remote device is located behind a
NAT without requiring new infrastructure.
4.2. Advanced Media Applications
Closer interaction between SIP and RTSP would also enable service
blending as in the case of an IPTV system wherein information about
content being viewed can be shared via presence service or the users
can chat about an ongoing program with instant messaging. Also other
"watching apart together" scenarios would become possible. The
ability to transfer a Content on Demand (CoD) session from one
terminal to another is another example.
5. High-level Procedures
The purpose of this section is to describe the high level procedures
required to deliver multimedia streaming content within the
architectural framework described in Section 3. The procedures are
comprised of three main phases - session establishment, session
Lindquist, et al. Expires December 11, 2010 [Page 10]
Internet-Draft Combining SIP and RTSP June 2010
modification, and session termination.
The figures in this section include an optional middlebox [RFC3234]
element, since in some environments, there might be an Application
Level Gateway (ALG), firewall or Network Address Translator (NAT)
device located between the UE and the controller.
5.1. Summary of the Procedures
This section briefly summarizes the overall operation of the session
management and content control protocols.
Establishment of content control and content delivery channels: the
UE uses the session management protocol with the media server in
order to establish the relevant content control channel and one or
more content delivery channels that are to be controlled by the
content control protocol. Once the content control session has been
established, media playback controls are issued directly using the
content control protocol. This includes trick play commands.
Modification of content delivery channel(s): once established, the UE
or media server may add, remove, or modify any of the content
delivery channels using the session management protocol.
Teardown of content control channel and the associated content
delivery channel(s): teardown of content control and the associated
content delivery channel(s) may be initiated by the UE or the media
server using the session management protocol. This releases all
resources associated with the content control channel and the content
delivery channels.
5.2. Details of the Procedures
5.2.1. Establishment of Content Control and Content Delivery Channels
Figure 2 illustrates on a high level the main stages of using the
session management protocol to establish the content control channel
and the content delivery streams. Although not illustrated below,
session establishment may also be initiated by the controller.
Lindquist, et al. Expires December 11, 2010 [Page 11]
Internet-Draft Combining SIP and RTSP June 2010
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| (1) Session establishment, | |
| session management protocol | |
|------------>|---------------->| |
| | | |
| | /-----------\ |
| | /(2) Resource \ |
| | \ reservation / |
| | \-----------/ |
| | | |
| | /-----------\ |
| | / (3) Select \ |
| | \ media server/ |
| | \-----------/ |
| | | (4) Create session |
| | |---------------------->|
| | | (5) OK |
| (6) OK |<----------------------|
|<------------|<----------------| |
| | | |
| | (7) Session establishment, content |
| | control protocol |
|------------>|---------------------------------------->|
| | (8) OK | |
|<------------|<----------------------------------------|
| | /-----------\ |
| | /(9) Resource \ |
| | \ commit / |
| | \-----------/ |
| | | |
| | (10) Media control command |
|------------>|---------------------------------------->|
| | (11) OK | |
|<------------|<----------------------------------------|
| | | |
| | (12) Media | |
|<============|<========================================|
| | | |
Figure 2: Session Establishment
The steps in the signaling flow are as follows:
Lindquist, et al. Expires December 11, 2010 [Page 12]
Internet-Draft Combining SIP and RTSP June 2010
1. The UE uses the session management protocol to establish a
content delivery session with the controller. The session has
at least two streams, one for media control and one or more for
media transmission.
2. The controller reserves resources for the control channel and
media streams.
3. The controller selects an appropriate media server.
4. The controller orders the media server to create a content
delivery session.
5. The media server returns a success response to the controller.
6. The controller returns a success response to the UE.
7. The resource reservation is committed.
8. The UE sends a content control protocol request to the media
server to trigger content control protocol session
establishment. It should be noted that this step is only needed
if the content control protocol contains session setup
semantics.
9. The media server returns a success response to the UE.
10. The UE sends a content control command to the media server.
11. The media server sends a success response to the content control
protocol request back to the UE.
12. The media stream is sent to the client.
5.2.2. Modification of Content Delivery Channels
This section illustrates how a content delivery session is modified.
Session modification is necessary for instance when the user wants to
add media streams to or remove media streams from an ongoing content
delivery session. Although not illustrated below, session
modification may also be initiated by the controller.
An example of session modification is shown in Figure 3.
Lindquist, et al. Expires December 11, 2010 [Page 13]
Internet-Draft Combining SIP and RTSP June 2010
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| (1) Session modification | |
| request, session management | |
| protocol | | |
|------------>|---------------->| |
| | | |
| | /-----------\ |
| | /(2) Resource \ |
| | \ reservation / |
| | \-----------/ |
| | | |
| | /-----------\ |
| | / (3) Select \ |
| | \ media server/ |
| | \-----------/ |
| | | (4) Modify session |
| | |---------------------->|
| | | (5) OK |
| (6) OK |<----------------------|
|<------------|<----------------| |
| | /-----------\ |
| | /(7) Resource \ |
| | \ commit / |
| | \-----------/ |
| | | |
| (8) Content control protocol trick play command |
|------------>|---------------------------------------->|
| | (9) OK | |
|<------------|<----------------------------------------|
| | | |
Figure 3: Session Modification
The steps in Figure 3 are as follows:
1. The UE performs session modification by sending a session
management protocol session modification request to the
controller, as shown in step (1) of Figure 3. The UE initiates
session modification in order to add media streams to or remove
media streams from the ongoing content delivery session.
2. The controller modifies the resources reserved for the content
delivery session according to the session modification request.
3. The controller selects a media server.
Lindquist, et al. Expires December 11, 2010 [Page 14]
Internet-Draft Combining SIP and RTSP June 2010
4. The controller orders the media server to modify the session.
5. The media server returns a success response to the controller.
6. The controller returns a session management protocol success
response to the UE.
7. The controller commits the reservation.
8. The UE starts playback by issuing a content control protocol
request.
9. The media server returns a content control protocol success
response.
5.2.3. Teardown of Content Control Channel and the Associated Content
Delivery Channel(s)
Figure 4 shows on a high level how media streams and the session are
terminated. Although not illustrated below, session termination may
also be initiated by the controller.
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| | Media | |
|<============|<========================================|
| | (1) Media teardown |
|------------>|---------------------------------------->|
| | | |
| | (2) Media stream(s) terminated |
| | | |
| | (3) OK | |
|<------------|<----------------------------------------|
| | | |
| (4) Session termination | |
|------------>|---------------->| |
| | /-----------\ |
| | /(5) Resource \ |
| | \ release / |
| | \-----------/ |
| | | (6) Destroy session |
| | |---------------------->|
| | | (7) OK |
| (8) OK |<----------------------|
|<------------|<----------------| |
| | | |
Figure 4: Session Termination
The steps in the signaling flow are as follows:
Lindquist, et al. Expires December 11, 2010 [Page 15]
Internet-Draft Combining SIP and RTSP June 2010
1. The UE uses the content control protocol to tear down the media
stream(s). It should be noted that this step is only needed if
the content control protocol contains session teardown semantics.
2. The media server stops sending the media stream(s).
3. The media server returns a content control protocol success
response to the UE.
4. The UE uses the session management protocol to terminate the
session.
5. The controller releases the resources that have been reserved for
the media stream(s) and the content control channel.
6. The controller orders the media server to destroy the session.
7. The media server returns a success response to the controller.
8. The controller returns a session management protocol success
response to the UE.
6. Requirements
Based on the signaling flows shown in Section 5, this section
identifies the main requirements for a solution that uses a session
management protocol to establish a control channel for a content
control protocol and one or more content delivery channels (i.e.,
media streams) for content delivery.
6.1. Content Control Protocol Accessing Resources Established by
Session Management Protocol
REQ-1 The content control protocol needs to be able to access and
use resources that have been configured and established by the
session management protocol.
Different protocols are used for setting up the media streams and for
controlling media stream delivery. Thus, there needs to be a way for
the content control protocol to refer to the media streams that were
set up using the session management protocol.
6.2. Use of Transport Addresses in Content Control and Session
Management Protocols
REQ-2 The session management protocol is responsible for negotiating
media transport related information.
The content control protocol and the content delivery protocol should
use the transport addresses that were negotiated for the media
streams and content control channel by the session management
protocol. If these addresses need to be changed, the change must be
negotiated using the session management protocol.
Lindquist, et al. Expires December 11, 2010 [Page 16]
Internet-Draft Combining SIP and RTSP June 2010
Since different protocols are used for session establishment and
content control, both protocol stacks need to have the same view on
the local and remote transport addresses used for the media streams
and the control channel. Therefore, content control protocol
messages should be sent to the transport addresses negotiated by the
session management protocol and media should be sent to the transport
addresses negotiated during session establishment.
Additional problems may arise if the content control protocol is used
to redirect the client to connect to another media server. The main
issue with redirection is middleboxes. A middlebox inspects the
information carried in the session management protocol so that it can
open pinholes for the content delivery channels and for the content
control channel. The middlebox may not inspect the content control
protocol messages. Thus, if the media server uses the content
control protocol to redirect the UE to connect to another media
server, the middlebox state may not get updated. As a result, the
media streams sent by the new media server might never reach the UE
(or the UE may not even be able to contact the new media server).
6.3. Session Termination
REQ-3 The session management protocol and the content control
protocol need to perform session termination in a coordinated way.
This kind of coordination is required to make sure that the session
management protocol will not release resources in the network before
the content control protocol has successfully terminated the media
streams. Therefore, media teardown procedures should be carried out
before the session management protocol is used to terminate the
session. Alternatively, if the content control protocol is not used
to terminate the media streams (which is true when the content
control protocol does not define session teardown semantics), but
only the session management protocol is, the above-mentioned
coordination is not necessary.
7. Design Goals
In the remainder of the document, we will assume that the session
management protocol is SIP and that the content control protocol is
RTSP. This section provides an overview of the design goals of the
combined SIP and RTSP solution. These design goals are listed below:
o The session management protocol should be able to initiate,
modify, and terminate content control and content delivery
channels from the client side and server side using the SDP offer/
answer mechanism.
Lindquist, et al. Expires December 11, 2010 [Page 17]
Internet-Draft Combining SIP and RTSP June 2010
o The content control protocol must be negotiated using the SDP
offer/answer mechanism.
o The content control protocol must allow for trick-play commands
such as PLAY, REWIND, FORWARD, and PAUSE commands.
o The content control protocol must allow for asynchronous media
event notifications (e.g., end-of-stream).
o The content control protocol must work over TCP.
8. Combining SIP/SDP and RTSP
In order to better understand the issues with the reuse of existing
architectures and support of a SIP-based video delivery architecture,
this section provides an overview of existing systems specified by
standardization bodies such as ETSI TISPAN and 3GPP. We will
describe the interaction between SIP/SDP and RTSP protocols for these
systems.
Below, we present two approaches specified by ETSI TISPAN that
fulfill the requirements stated in Section 6 and meet the design
goals listed in Section 7. In both of the approaches, SIP/SDP is
used to establish an RTSP control stream and one or more content
delivery streams. In the first approach, the UE uses RTSP without
session setup and teardown semantics, whereas in the second approach,
the UE uses full RTSP.
8.1. Method 1: Lightweight RTSP without Session Setup Semantics
In the signaling flows shown in the figures below, a lightweight
version of RTSP without session setup semantics is used to control
media streams that have been set up using SIP/SDP. The benefits of
using a lightweight version of RTSP over using the full RTSP include
that since lightweight RTSP does not specify session setup and
teardown semantics, there is no overlap between SIP and RTSP
signaling. Further, less signaling is required and it is easier to
correlate the two protocols.
8.1.1. Session Establishment Initiated by UE
The signaling flow in Figure 5 illustrates how proposed IPTV and
streaming systems (e.g., ETSI TISPAN) use SIP to set up an RTSP
content control channel and RTP content delivery channel(s) in the
context of a Content on Demand (CoD) service. The figure is a
generalized version of the signaling flow specified in [ETSI TS 183
063]. In the figure, a lightweight version of RTSP without session
setup and teardown semantics is used.
Lindquist, et al. Expires December 11, 2010 [Page 18]
Internet-Draft Combining SIP and RTSP June 2010
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| (1) INVITE | |
|------------>|---------------->| |
| | | |
| | /-----------\ |
| | /(2) Resource \ |
| | \ reservation / |
| | \-----------/ |
| | | |
| | /-----------\ |
| | / (3) Select \ |
| | \ media server/ |
| | \-----------/ |
| | | (4) Create session |
| | |---------------------->|
| | | (5) OK |
| (6) 200 OK (INVITE) |<----------------------|
|<------------|<----------------| |
| | /-----------\ |
| | /(7) Resource \ |
| | \ commit / |
| | \-----------/ |
| | | |
| (8) ACK | |
|------------>|---------------->| |
| | (9) PLAY | |
|------------>|---------------------------------------->|
| | (10) 200 OK (PLAY) |
|<------------|<----------------------------------------|
| | (11) RTP | |
|<============|<========================================|
| | | |
Figure 5: RTSP without Session Setup Semantics
The steps in the signaling flow are as follows:
1. The UE sends a SIP INVITE request to the controller to set up at
least two channels, one for RTSP control and one or more for
media transmission. The SDP offer included in the INVITE
contains a media description for the RTSP content control
channel and one or more media descriptions for the content
delivery channels. It is assumed that the client already knows
what resources (i.e., media streams) are associated with the
content it is requesting to view. As an example, the UE may
Lindquist, et al. Expires December 11, 2010 [Page 19]
Internet-Draft Combining SIP and RTSP June 2010
obtain the relevant SDP parameters such as media type, transport
etc. required for establishing the content delivery channels a
priori via HTTP from a content guide server or an Electronic
Programme Guide (EPG) server. The contents of the SDP offer are
defined in Section 9.1.1.
2. Upon receiving the SIP INVITE request, the controller reserves
resources for the RTSP and RTP streams.
3. The controller selects an appropriate media server.
4. Next, the controller orders the media server to create a
streaming session.
5. The media server returns a success response to the controller.
6. The controller returns a SIP 200 OK response to the UE. Among
other things, the SDP answer included in the response contains
an RTSP session ID parameter. The SDP answer also contains a
media description for the RTSP content control channel and one
or more media descriptions for the content delivery channels.
The exact contents of the SDP answer are described in
Section 9.2.1.
7. The resource reservation is committed.
8. The UE returns a SIP ACK to the controller.
9. The UE sends an RTSP PLAY request to the media server. The UE
knows the server IP address and port for RTSP since the
controller returned them in the SIP INVITE 200 OK response. The
session ID parameter the server returned in the SDP answer is
included in the Session header of the request. The contents of
the PLAY requests are described in detail in Section 10.2.2.
10. The media server sends a 200 OK response to RTSP PLAY request
back to the UE.
11. The RTP stream is sent to the client IP address indicated in the
SDP offer.
8.1.2. Session Establishment Initiated by Controller
Figure 6 shows the case when the session establishment is initiated
by the controller instead of the UE.
Lindquist, et al. Expires December 11, 2010 [Page 20]
Internet-Draft Combining SIP and RTSP June 2010
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| (1) INVITE | |
|<------------|<----------------| |
| | | |
| (2) 200 OK (INVITE) | |
|------------>|---------------->| |
| | /-----------\ |
| | /(3) Resource \ |
| | \ reservation / |
| | \-----------/ |
| | | |
| | /-----------\ |
| | / (4) Select \ |
| | \ media server/ |
| | \-----------/ |
| | | (5) Create session |
| | |---------------------->|
| | | (6) OK |
| | |<----------------------|
| | /-----------\ |
| | /(7) Resource \ |
| | \ commit / |
| | \-----------/ |
| | | |
| (8) ACK | |
|<------------|<----------------| |
| | | |
/---------------------------------------------------------\
( Method 1: Steps 9-11 of Figure 5 )
\---------------------------------------------------------/
| | | |
| | | |
/---------------------------------------------------------\
( Method 2: Steps 9-13 of Figure 8 )
\---------------------------------------------------------/
| | | |
| | | |
Figure 6: RTSP Control Stream Established Using SIP/SDP
The steps in the signaling flow are as follows:
1. The controller sends an initial SIP INVITE request to the UE.
The INVITE request does not include an SDP body.
Lindquist, et al. Expires December 11, 2010 [Page 21]
Internet-Draft Combining SIP and RTSP June 2010
2. The UE accepts the INVITE and sends a SIP 200 OK final response
to the controller. The 200 OK carries an SDP offer whose
contents are described in Section 9.1.1
3. The controller reserves resources for the RTSP and RTP streams.
4. The controller selects an appropriate media server.
5. The controller orders the media server to create a streaming
session.
6. The media server returns a success response to the controller.
7. The resource reservation is committed.
8. The controller returns a SIP ACK request to the UE. The ACK
contains an SDP answer the contents of which are described in
Section 9.2.1.
Having received the ACK, the UE can use one of two alternative
methods to start receiving the content stream(s). If Method 1
(lightweight RTSP) is used, steps 9-11 of Figure 5 are executed. If
Method 2 (full RTSP) is used, the UE executes steps 9-13 of Figure 8.
8.1.3. Session Termination
Figure 7 illustrates how a session is terminated when a lightweight
RTSP without session setup and teardown semantics is used.
Lindquist, et al. Expires December 11, 2010 [Page 22]
Internet-Draft Combining SIP and RTSP June 2010
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| | RTP stream | |
|<============|<========================================|
| | | |
| (1) TCP connection for RTSP closed |
| | | |
| (2) BYE | |
|------------>|---------------->| |
| | | |
| | | (3) Destroy session |
| | |---------------------->|
| | | |
| | (4) RTP stream terminated |
| | | |
| | | (5) OK |
| | |<----------------------|
| | | |
| | /-----------\ |
| | /(6) Resource \ |
| | \ release / |
| | \-----------/ |
| (7) 200 OK (BYE) | |
|<------------|<----------------| |
| | | |
Figure 7: Session Termination
The steps in the signaling flow of Figure 7 are described below:
1. The UE closes the TCP connection that is used for RTSP.
2. The UE sends a SIP BYE request to the controller to terminate the
session and to tear down the media stream(s).
3. The controller orders the media server to destroy the session.
4. The media server stops sending the RTP content stream(s).
5. The media server returns a success response to the controller.
6. The controller releases the resources that have been reserved for
the RTP and RTSP streams.
7. The controller returns a SIP 200 OK (BYE) response to the UE.
8.1.4. Discussion on the Requirements
Below, it is described how this method satisfies the requirements
stated in Section 6.
Lindquist, et al. Expires December 11, 2010 [Page 23]
Internet-Draft Combining SIP and RTSP June 2010
8.1.4.1. Requirement 1 - Content Control Protocol Accessing Resources
Established by Session Management Protocol
The RTSP SETUP request is not used in this method. To correlate SIP
and RTSP, a session ID parameter MUST be returned by the controller
in the SDP answer carried in the SIP 200 OK response to the SIP
INVITE request. This session ID is used in the Session header of
RTSP messages such as the PLAY request.
8.1.4.2. Requirement 2 - Use of Transport Addresses in Content Control
and Session Management Protocols
8.1.4.2.1. DNS Lookup for RTSP URL
The UE should not perform a DNS lookup for the RTSP URL that the
controller returns in the SDP answer. Otherwise there is a risk that
a different destination transport address than was returned in the
SDP answer will be used for RTSP messages sent to the media server.
This is problematic if the UE is located behind a middlebox: the
middlebox may drop the packets sent to the new server address.
To solve this issue, the UE MUST use the server IP address and port
returned in the SDP answer (in "c=" and "m=" lines of the RTSP
control channel) as the destination address of RTSP messages.
If there is a need to change the server IP address, a session
modification needs to be performed.
Note that to avoid the issue with DNS lookups, deployments can choose
to deliver IP addresses back to the UE within RTSP URLs.
8.1.4.2.2. Redirection
The media server is selected during SIP session establishment prior
to sending RTSP PLAY and there is no RTSP SETUP request, so no
redirection is expected.
8.1.4.2.3. Correlating Transport Address in SDP Offer with Transport
Header in SETUP
Since RTSP SETUP is not used, there is no correlation issue.
8.1.4.3. Requirement 3 - Session Termination
Since RTSP TEARDOWN is not used, there is no overlap between SIP BYE
and RTSP TEARDOWN requests. Resources are released when the SIP BYE
request is received.
Lindquist, et al. Expires December 11, 2010 [Page 24]
Internet-Draft Combining SIP and RTSP June 2010
8.2. Method 2: Full RTSP
8.2.1. Session Establishment Initiated by UE
Figure 8 shows the way a session is established when full RTSP is
used.
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| (1) INVITE | |
|------------>|---------------->| |
| | | |
| | /-----------\ |
| | /(2) Resource \ |
| | \ reservation / |
| | \-----------/ |
| | | |
| | /-----------\ |
| | / (3) Select \ |
| | \ media server/ |
| | \-----------/ |
| | | (4) Create session |
| | |---------------------->|
| | | (5) OK |
| (6) 200 OK (INVITE) |<----------------------|
|<------------|<----------------| |
| | /-----------\ |
| | /(7) Resource \ |
| | \ commit / |
| | \-----------/ |
| | | |
| (8) ACK | |
|------------>|---------------->| |
| | (9) SETUP | |
|------------>|---------------------------------------->|
| | (10) 200 OK (SETUP) |
|<------------|<----------------------------------------|
| | (11) PLAY | |
|------------>|---------------------------------------->|
| | (12) 200 OK (PLAY) |
|<------------|<----------------------------------------|
| | (13) RTP | |
|<============|<========================================|
| | | |
Figure 8: RTSP Control Stream Established Using SIP/SDP
Lindquist, et al. Expires December 11, 2010 [Page 25]
Internet-Draft Combining SIP and RTSP June 2010
The steps in the signaling flow are as follows:
1. The UE sends a SIP INVITE request to the controller to set up at
least two streams, one for RTSP control and one or more for
media transmission. If there is a firewall or SIP ALG between
the UE and the controller, it forwards the INVITE and inspects
the SDP offer included in the INVITE in order to be able to open
pinholes for the streams. It is assumed that the client already
knows what resources (i.e., media streams) are associated with
the content it is requesting to view. The contents of the SDP
offer are described in Section 9.1.1.
2. Upon receiving the SIP INVITE request, the controller reserves
resources for the RTSP and RTP streams.
3. Next, the controller selects an appropriate media server.
4. The controller orders the media server to create a streaming
session.
5. The media server returns a success response to the controller.
6. The controller sends a SIP 200 OK (INVITE) final response to the
UE. The SDP answer included in the response contains among
other things an RTSP URL. The exact contents of the SDP answer
are described in Section 9.2.1.
7. The resource reservation is committed.
8. The UE returns an ACK to the controller to acknowledge the
reception of the SIP 200 OK (INVITE) final response.
9. The UE sends an RTSP SETUP to the media server to trigger RTSP
session initiation. The UE learned the server IP address and
port for RTSP since the controller returned them in the SDP
answer included in the SIP INVITE 200 OK response. The RTSP URL
of the SETUP request is set to the URL returned in the SDP
answer as described in Section 10.2.1.
10. An RTSP 200 OK response for the RTSP SETUP request is sent back
to the UE. The RTSP network parameters exchanged in the SETUP
request and response are the same as the RTSP network parameters
agreed during the SDP offer/answer exchange. The UE should
store the Session header included in the response for issuing
the RTSP PLAY request.
11. The UE sends an RTSP PLAY request to the media server. The
contents of the PLAY requests are described in Section 10.2.2.
12. The media server sends an RTSP 200 OK for RTSP PLAY back to the
UE.
13. The RTP stream is sent to the client IP address indicated by the
SDP offer and RTSP SETUP.
8.2.2. Session Establishment Initiated by Controller
If the session establishment is initiated by the controller, the
signaling flow is the same as in Figure 6 with the exception that
after receiving the ACK, the UE proceeds by executing steps 9-13 of
Lindquist, et al. Expires December 11, 2010 [Page 26]
Internet-Draft Combining SIP and RTSP June 2010
Figure 8.
8.2.3. Session Termination
The figure below illustrates how a streaming session is terminated in
[ETSI TS 183 063] when full RTSP is being used.
+----+ +-------------+ +------------+ +--------------+
| UE | | (Middlebox) | | Controller | | Media server |
+----+ +-------------+ +------------+ +--------------+
| | | |
| | RTP stream | |
|<============|<========================================|
| | (1) TEARDOWN |
|------------>|---------------------------------------->|
| | | |
| | (2) RTP stream terminated |
| | | |
| | (3) 200 OK (TEARDOWN) |
|<------------|<----------------------------------------|
| | | |
| | (4) TCP connection for RTSP closed |
| | | |
| (5) BYE | |
|------------>|---------------->| |
| | /-----------\ |
| | /(6) Resource \ |
| | \ release / |
| | \-----------/ |
| | | (7) Destroy session |
| | |---------------------->|
| | | (8) OK |
| (9) 200 OK (BYE) |<----------------------|
|<------------|<----------------| |
| | | |
Figure 9: Session Termination
The steps in the signaling flow are as follows:
1. The UE sends an RTSP TEARDOWN request to the media server.
2. The media server stops sending the RTP content stream(s).
3. The media server returns a 200 OK (TEARDOWN) response to the UE.
4. The UE disconnects the TCP connection that was used for RTSP
signaling.
5. The UE sends a SIP BYE request to the controller.
Lindquist, et al. Expires December 11, 2010 [Page 27]
Internet-Draft Combining SIP and RTSP June 2010
6. The controller releases the resources that have been reserved for
the RTP and RTSP streams.
7. The controller orders the media server to destroy the session.
8. The media server returns a success response to the controller.
9. The controller returns a SIP 200 OK (BYE) response to the UE.
8.2.4. Discussion on the Requirements
In this section, we discuss how this method satisfies the
requirements stated in Section 6.
8.2.4.1. Requirement 1 - Content Control Protocol Accessing Resources
Established by Session Management Protocol
Correlating the SIP INVITE transaction and the RTSP SETUP request may
be problematic since there is no RTSP session identifier returned in
the INVITE response.
To solve this problem, the RTSP URL returned in the SDP answer MUST
convey correlation information as specified in [ETSI TS 183 063].
8.2.4.2. Requirement 2 - Use of Transport Addresses in Content Control
and Session Management Protocols
8.2.4.2.1. DNS lookup for RTSP URL
The same discussion applies as for Method 1 (see Section 8.1.4.2.1).
8.2.4.2.2. Redirection
The media server should not redirect the RTSP SETUP request. The
redirection has to be already known prior to the RTSP SETUP since the
SDP answer for the SIP INVITE response needs to contain the final
destination of the media server.
If there is a SIP ALG between the UE and the controller, the SIP ALG
opens pinholes for the media delivery stream(s) based on the
information conveyed in the SDP offer/answer exchange. If an RTSP
REDIRECT request or Redirection status code is later issued on the
RTSP control channel, the SIP ALG may never learn the address of the
new server. This is because the SIP ALG may not inspect RTSP
messages. The result is that new pinholes will not be opened for the
RTSP control channel and the media delivery stream(s) coming from the
new server.
Because of the above-mentioned problems, redirection MUST NOT be
used.
Lindquist, et al. Expires December 11, 2010 [Page 28]
Internet-Draft Combining SIP and RTSP June 2010
Note that if the service provider provides both the service and the
content (i.e., the media server), the service provider is in full
control of the media server's behavior. In that case, there would be
no redirection. However, if the service provider and content
provider are separate, then redirection might be an issue.
8.2.4.2.3. Correlating Transport Address in SDP Offer with Transport
Header in SETUP
The Transport header of the RTSP SETUP request MUST contain the same
information as the SDP offer in the SIP INVITE request.
8.2.4.3. Requirement 3 - Session Termination
Teardown of the streaming session will not always be possible
according to the procedures defined in [RFC2326]. This is because
the UE may not be able to send an RTSP TEARDOWN request or receive a
response to the TEARDOWN request if the resources in the network for
the RTSP session have been released when receiving s SIP BYE request.
To address this issue, SIP session termination and RTSP session
termination MUST be carried out in a coordinated way. When using
both SIP BYE and RTSP TEARDOWN, the media teardown procedures using
RTSP TEARDOWN MUST be executed before the SIP BYE request is sent.
An additional issue is that there may be more nodes than the two end-
points that normally exist in typical RTSP scenarios that can
initiate session termination. An example of such a node is SIP Back-
to-Back User Agent (B2BUA).
9. Establishment of Content Control and Content Delivery Channels
This section describes the procedures to be performed for
establishing an RTSP content control channel and the associated
content delivery channel(s) using the SDP offer/answer model.
9.1. Procedures at the SDP Offerer
9.1.1. UE as the SDP Offerer
The UE, as the SDP offerer, MUST follow the procedures in this
section to establish the content control channel and one or more
content delivery channels. The SDP offer is per SDP specification
[RFC4145]. A media line for the RTSP content control channel is
included with the following values:
Lindquist, et al. Expires December 11, 2010 [Page 29]
Internet-Draft Combining SIP and RTSP June 2010
o The media field MUST have a value of "application".
o The port field MUST indicate a TCP port. The port MUST be set to
a value of 9, which is the discard port.
o The transport field MUST be set to contain either the value "TCP/
ETSI_RTSP" or "TCP/TLS/ETSI_RTSP". The former is used when RTSP
runs directly on top of TCP and the latter when RTSP runs on top
of TLS, which in turn runs on top of TCP.
o The fmt (format) list is ignored for ETSI_RTSP. It MUST contain a
single "*" character.
An "a=setup" attribute MUST be present and set to "active".
An "a=connection" attribute MUST be present and set to "new".
The SDP offer MUST additionally include at least one content delivery
channel description and specify the related m-line(s).
An "a=recvonly" attribute MUST be present.
A "b=" line indicating the bandwidth necessary to handle this content
delivery channel MAY be included.
If a broadcast session is being switched to a unicast session, the
offer MUST include an "etsi_rtsp-offset" attribute to specify the
current playback position. The UE will resume from this position
when issuing an RTSP PLAY request.
The offer MAY optionally include "etsi_rtsp-version" attributes to
specify the RTSP versions that the UE supports. If no "etsi_rtsp-
version" attributes are included, the receiver of the offer MUST
interpret this to mean that the offerer supports only RTSP version
1.0. At the time of writing the document, the ETSI TISPAN solution
for combining SIP and RTSP used RTSP 1.0. Since the intention of
this document is to describe the ETSI TISPAN solution, the document
specifies only the use of RTSP 1.0.
The receiver of the SDP offer MUST interpret the offer so that all
described content delivery channels are under the control of the
content control protocol.
When receiving any SDP answer, the UE MUST examine the media
parameters in the received SDP. The UE MUST use the received SDP
parameters for content control procedures as described in
Section 10.2.
Lindquist, et al. Expires December 11, 2010 [Page 30]
Internet-Draft Combining SIP and RTSP June 2010
9.2. Procedures at SDP Answerer
9.2.1. Controller as SDP Answerer
The controller, as the SDP answerer, MUST follow the procedures in
this section to establish the content control channel and at least
one content delivery channel. The SDP answer is per the SDP
specification [RFC4145]. The media line for RTSP content control
channel is included with the following values:
o The media field MUST have a value of "application".
o The port field MUST be a TCP port and its value MUST be set to the
port allocated at the media server.
o The transport field MUST be set to contain either the value "TCP/
ETSI_RTSP" or "TCP/TLS/ETSI_RTSP".
o The fmt list MUST contain a single "*" character.
An "a=setup" attribute MUST be present and set to "passive".
An "a=connection" attribute MUST be present and set to "new".
The answer MUST include one or more attribute lines representing RTSP
content control specific attributes. These attributes are set as
follows:
o An "etsi_rtsp-uri" attribute MUST be present and set to the RTSP
URL to be used in the RTSP content control requests. The URI can
be in form of an absolute or a relative URI. If an absolute URI
is specified, it is used by the UE as-is in subsequent RTSP
requests. If a relative URI is specified in the form of a media
path, the RTSP absolute URL can be constructed by the UE using the
IP address (from c-line) and port (from m-line) as the base
followed by an etsi_rtsp-uri value for the media path.
o If the controller supports Method 1 (lightweight RTSP), the
controller MUST include an "etsi_rtsp-session" attribute
representing the session ID of the RTSP session. If the
controller uses Method 2 (full RTSP), such attribute MUST NOT be
included. The UE will determine whether to use Method 1 or Method
2 based on the presence or absence of the "etsi_rtsp-session"
attribute. If the attribute is received in the SDP answer, the UE
MUST use Method 1. Otherwise the UE MUST use Method 2. The value
of the "etsi_rtsp-session" attribute has the following format:
a=etsi_rtsp-session:<session ID> [<timeout>]. The timeout
parameter is optional. It specifies a numeric timeout interval in
seconds. The UE uses the value of the parameter for sending RTSP
keepalives (e.g., GET_PARAMETER requests) to the server. If no
timeout parameter is included, the UE MUST use a default value of
60 seconds
Lindquist, et al. Expires December 11, 2010 [Page 31]
Internet-Draft Combining SIP and RTSP June 2010
o Optionally, the answer MAY include an "etsi_rtsp-offset" attribute
to specify the current playback position. The UE will resume from
this position when issuing an RTSP PLAY request.
o The answer MAY optionally include "etsi_rtsp-version" attributes
to specify the RTSP versions that the controller supports. If no
"etsi_rtsp-version" attributes are included, the receiver of the
answer MUST interpret this to mean that the answerer supports only
RTSP version 1.0. After the offer/answer exchange has finished,
the UE and the controller MUST use the highest RTSP version
supported by both parties. If, during the streaming session, the
UE attempts to use an RTSP version that is not supported by the
controller (or vice-versa) the RTSP request MUST be rejected with
the error code '505 RTSP Version Not Supported'.
9.3. Modification of Content Delivery Channel(s)
Modification of the content delivery channels including adding,
removing or modifying media parameters associated with the content
delivery channels may be initiated by the UE or the Controller.
The UE and the Controller MUST not modify the RTSP control channel
m-line description in the SDP if the content delivery streams
controlled by RTSP are not removed (port not set to zero in m-lines).
10. Content Control Protocol
This section describes procedures that a UE can use for controlling
the content delivery channels that have been established using either
full RTSP or a lightweight version of RTSP.
10.1. Lightweight RTSP
When using Method 1 (lightweight RTSP), all RTSP requests MUST use
the same session ID as specified in the SDP etsi_rtsp-session
attribute during content control session establishment.
When the lightweight RTSP is used, the following methods MUST be
supported for media playback control and media event notifications:
o RTSP PLAY (UE -> media server)
o RTSP PAUSE (UE -> media server)
o RTSP GET_PARAMETER (UE -> media server)
o RTSP SET_PARAMETER (UE -> media server)
o RTSP ANNOUNCE (media server -> UE)
o RTSP OPTIONS (UE -> media server)
Lindquist, et al. Expires December 11, 2010 [Page 32]
Internet-Draft Combining SIP and RTSP June 2010
10.2. Procedures at the UE
10.2.1. Media Setup Procedure
The UE sends an RTSP SETUP request only when Method 2 (full RTSP) is
being used. If Method 1 (lightweight RTSP) is being used, the UE
MUST NOT send an RTSP SETUP request. When sending an RTSP SETUP
request, the UE MUST populate the header fields as follows:
o The RTSP URL MUST be set to the media RTSP URL received in the SDP
answer from the controller. If the RTSP URL contains a domain
address, the UE MUST NOT perform a DNS lookup. Instead, the
target transport address (by transport address, we refer to IP
address and transport protocol port number) of the RTSP SETUP
request MUST be set to the IP address obtained from the connection
line ("c=") in the SDP answer and the port specified in the media
line ("m=") of the RTSP control stream.
If full RTSP is being used, the UE MUST, on receiving a 200 OK
response to the SETUP request, retrieve and store the Session header
for the purpose of issuing an RTSP PLAY request later.
10.2.2. Media Playback Initiation Procedure
The UE MUST follow the procedures in this section to initiate media
playback using the RTSP PLAY method. The RTSP fields in the RTSP
PLAY message MUST be filled as follows:
o The RTSP URL will be set to the value retrieved from the
etsi_rtsp-uri attribute in the SDP answer from the controller in
the case of an absolute URI. If the value of the etsi_rtsp-uri is
a relative URI that is in the form of a media path, then the RTSP
absolute URL is constructed by the UE using the SDP IP address
(from c-line) and port (from m-line) as the base followed by a
etsi_rtsp-uri value for the media path (e.g.,
rtsp://10.5.1.72:22554/TV3/823527). If the value of the
etsi_rtsp-uri is an absolute URL, the UE MUST NOT perform a DNS
lookup. The target transport address of the RTSP PLAY message
MUST be set to the IP address obtained from the connection line
("c=") in the SDP answer and the port from the media line ("m=").
o The Range parameter MAY be present and set to the value retrieved
from the SDP etsi_rtsp-offset attribute.
o If using Method 2 (full RTSP), a Session header MUST be included.
The value of the header MUST be set to the same value as in the
RTSP SETUP request.
Lindquist, et al. Expires December 11, 2010 [Page 33]
Internet-Draft Combining SIP and RTSP June 2010
10.2.3. Media Playback Modification Procedure
The UE MUST follow the procedures in this section to modify media
playback. The direction and/or speed of media playback is modified
by including a Scale header within the RTSP PLAY request as specified
in [RFC2326].
10.2.4. Media Playback Information Retrieval and Setting Procedure
The UE MAY retrieve the following information using the RTSP
GET_PARAMETER request:
o position: the position in the media in seconds.
o scales: the allowed scales that can be used in the PLAY request.
o duration
The UE MAY also set the position parameter by sending an RTSP
SET_PARAMETER request. An empty body is allowed for RTSP keepalives.
10.2.5. Media Event Notification Procedure
If the UE receives an RTSP ANNOUNCE with a notice-code that it does
not recognize, it should ignore the request.
10.2.6. Media Teardown Procedure
A TEARDOWN request is only allowed if Method 2 (full RTSP) is being
used. If Method 1 (lightweight RTSP) is being used, a TEARDOWN
request MUST NOT be sent. The contents of a TEARDOWN request MUST be
set as follows:
o The RTSP URL header MUST be set to the media RTSP URL obtained
from the session initiation. If a domain address is used in the
RTSP URL, the UE MUST NOT perform a DNS lookup. The target
transport address of the RTSP SETUP request MUST be set to the IP
address obtained from the connection line ("c=") in the SDP answer
and the port from the media line ("m=").
o The value of the Session header MUST be set to the same value as
in the SETUP request.
10.3. Procedures at Media Server
The media server MUST answer as defined in [RFC2326] and [RFC3261].
The media server may use an RTSP ANNOUNCE to notify the UE of any
asynchronous events related to the media stream (e.g., end-of-
stream).
Lindquist, et al. Expires December 11, 2010 [Page 34]
Internet-Draft Combining SIP and RTSP June 2010
11. Examples
The examples below illustrate how the SDP offer/answer model can be
used to establish an RTSP content control channel and a video stream
controlled by RTSP.
11.1. Content on Demand Session Establishment Using Lightweight RTSP
(Method 1)
This section shows examples of SIP and RTSP messages used to
establish a content on demand session using Method 1 (lightweight
RTSP). The corresponding signaling flow is shown in Figure 5.
Figure 10 shows the SIP INVITE request sent in step (1) of Figure 5.
INVITE sip:vod1234@10.2.6.123 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
Max-Forwards: 70
To: <sip:vod1234@10.2.6.123>
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 INVITE
Contact: user1 <sip:user1@10.5.1.72:5060;transport=udp>
Content-Length: 156
Content-Type: application/sdp
v=0
o=- 1180443107599999 1 IN IP4 10.5.1.72
s=-
t=0 0
m=application 9 TCP/ETSI_RTSP *
c=IN IP4 10.5.1.72
a=setup:active
a=connection:new
m=video 10002 RTP/AVP 33
c=IN IP4 10.5.1.72
b=AS:17000
a=recvonly
Figure 10: SIP INVITE request with SDP offer
Figure 11 shows the SIP 200 OK (INVITE) response sent in step (6) of
Figure 5.
Lindquist, et al. Expires December 11, 2010 [Page 35]
Internet-Draft Combining SIP and RTSP June 2010
SIP/2.0 200 OK
To: <sip:vod1234@iptv.example.com>;tag=f2ad5t6i-4b
From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 INVITE
Content-Length: 349
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
Record-Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
proxy.iptv.example.com:5060;maddr=130.100.86.35;lr>
Contact: <sip:10.2.6.123:5060>
Content-Type: application/sdp
v=0
o=- 2890844526 2 IN IP4 10.5.1.72
s=-
t=0 0
m=application 554 TCP/ETSI_RTSP *
c=IN IP4 10.2.6.123
a=setup:passive
a=connection:new
a=etsi_rtsp-session:56465465
a=etsi_rtsp-uri:rtsp://foo.com/TV3/TimeShift/823527
a=etsi_rtsp-offset:0
m=video 4002 RTP/AVP 33
c=IN IP4 10.2.6.123
b=AS:0
a=sendonly
Figure 11: SIP 200 OK response (INVITE) with SDP answer
Figure 12 shows the SIP ACK request sent in step (8) of Figure 5.
ACK sip:10.2.6.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443108219999156
Max-Forwards: 70
Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
To: <sip:vod1234@10.2.6.123>;tag=f2ad5t6i-4b
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 ACK
Content-Length: 0
Figure 12: SIP ACK request
Lindquist, et al. Expires December 11, 2010 [Page 36]
Internet-Draft Combining SIP and RTSP June 2010
Figure 13 shows the RTSP PLAY request sent in step (9) of Figure 5.
PLAY rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
CSeq: 2
Session: 56465465
Scale: 1
Range: npt=0-
Figure 13: RTSP PLAY request
Figure 14 shows the RTSP 200 OK (PLAY) response sent in step (10) of
Figure 5.
RTSP/1.0 200 OK
CSeq: 2
Session: 56465465
Figure 14: RTSP 200 OK response (PLAY)
11.2. Content on Demand Session Establishment Using Full RTSP (Method
2)
This section shows examples of SIP and RTSP messages used to
establish a content on demand session using Method 2 (full RTSP).
The corresponding signaling flow is shown in Figure 8.
Figure 15 shows the SIP INVITE request sent in step (1) of Figure 8.
Lindquist, et al. Expires December 11, 2010 [Page 37]
Internet-Draft Combining SIP and RTSP June 2010
INVITE sip:vod1234@10.2.6.123 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
Max-Forwards: 70
To: <sip:vod1234@10.2.6.123>
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 INVITE
Contact: user1 <sip:user1@10.5.1.72:5060;transport=udp>
Content-Length: 156
Content-Type: application/sdp
v=0
o=- 1180443107599999 1 IN IP4 10.5.1.72
s=-
t=0 0
m=application 9 TCP/ETSI_RTSP *
c=IN IP4 10.5.1.72
a=setup:active
a=connection:new
m=video 10002 RTP/AVP 33
c=IN IP4 10.5.1.72
b=AS:17000
a=recvonly
Figure 15: SIP INVITE request with SDP offer
Figure 16 shows the SIP 200 OK (INVITE) response sent in step (6) of
Figure 8.
Lindquist, et al. Expires December 11, 2010 [Page 38]
Internet-Draft Combining SIP and RTSP June 2010
SIP/2.0 200 OK
To: <sip:vod1234@iptv.example.com>;tag=f2ad5t6i-4b
From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 INVITE
Content-Length: 349
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443107619999155
Record-Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
proxy.iptv.example.com:5060;maddr=130.100.86.35;lr>
Contact: <sip:10.2.6.123:5060>
Content-Type: application/sdp
v=0
o=- 2890844526 2 IN IP4 10.5.1.72
s=-
t=0 0
m=application 554 TCP/ETSI_RTSP *
c=IN IP4 10.2.6.123
a=setup:passive
a=connection:new
a=etsi_rtsp-uri:rtsp://foo.com/TV3/TimeShift/823527
a=etsi_rtsp-offset:0
m=video 4002 RTP/AVP 33
c=IN IP4 10.2.6.123
b=AS:0
a=sendonly
Figure 16: SIP 200 OK response (INVITE) with SDP answer
Figure 17 shows the SIP ACK request sent in step (8) of Figure 8.
ACK sip:10.2.6.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443108219999156
Max-Forwards: 70
Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
To: <sip:vod1234@10.2.6.123>;tag=f2ad5t6i-4b
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 1 ACK
Content-Length: 0
Figure 17: SIP ACK request
Figure 18 shows the RTSP SETUP request sent in step (9) of Figure 8.
Lindquist, et al. Expires December 11, 2010 [Page 39]
Internet-Draft Combining SIP and RTSP June 2010
SETUP rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=10002-10003
Figure 18: RTSP SETUP request
Figure 19 shows the RTSP 200 OK (SETUP) response sent in step (10) of
Figure 8.
RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=10002-10003;
server_port=4002-4003
Figure 19: RTSP 200 OK response (SETUP)
Figure 20 shows the RTSP PLAY request sent in step (11) of Figure 8.
PLAY rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
CSeq: 2
Session: 12345678
Scale: 1
Range: npt=0-
Figure 20: RTSP PLAY request
Figure 21 shows the RTSP 200 OK (PLAY) response sent in step (12) of
Figure 8.
RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Figure 21: RTSP 200 OK response (PLAY)
11.3. Content on Demand Session Termination Using Lightweight RTSP
(Method 1)
This section shows examples of SIP messages used to terminate a
content on demand session using Method 1 (lightweight RTSP). The
Lindquist, et al. Expires December 11, 2010 [Page 40]
Internet-Draft Combining SIP and RTSP June 2010
corresponding signaling flow is shown in Figure 7.
Figure 22 shows the SIP BYE request sent in step (2) of Figure 7.
BYE sip:10.2.6.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
Max-Forwards: 70
Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 2 BYE
Content-Length: 0
Figure 22: SIP BYE request
Figure 23 shows the SIP 200 OK (BYE) response sent in step (7) of
Figure 7.
SIP/2.0 200 OK
To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 2 BYE
Content-Length: 0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
Figure 23: SIP 200 OK response (BYE)
11.4. Content on Demand Session Termination Using Full RTSP (Method 2)
This section shows examples of SIP and RTSP messages used to
terminate a content on demand session using Method 2 (full RTSP).
The corresponding signaling flow is shown in Figure 9.
Figure 24 shows the RTSP TEARDOWN request sent in step (1) of
Figure 9.
TEARDOWN rtsp://foo.com/TV3/TimeShift/823527 RTSP/1.0
CSeq: 3
Session: 12345678
Lindquist, et al. Expires December 11, 2010 [Page 41]
Internet-Draft Combining SIP and RTSP June 2010
Figure 24: RTSP TEARDOWN request
Figure 25 shows the RTSP 200 OK (TEARDOWN) response sent in step (3)
of Figure 9.
RTSP/1.0 200 OK
CSeq: 3
Figure 25: RTSP 200 OK response (TEARDOWN)
Figure 26 shows the SIP BYE request sent in step (5) of Figure 9.
BYE sip:10.2.6.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
Max-Forwards: 70
Route: <sip:3Zqkv5baiCsip%3Auser1%40iptv.example.com@
pcscf.iptv.example.com:5060;maddr=130.100.86.35;lr>
To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
From: user1 <sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 2 BYE
Content-Length: 0
Figure 26: SIP BYE request
Figure 27 shows the SIP 200 OK (BYE) response sent in step (9) of
Figure 9.
SIP/2.0 200 OK
To: <sip:vod1234@10.2.6.123>;tag=f2adcfg0-4i
From: "user1"<sip:user1@iptv.example.com>;tag=1180443107619999153
Call-ID: C-1180443107619999154@10.5.1.72
CSeq: 2 BYE
Content-Length: 0
Via: SIP/2.0/UDP 10.5.1.72:5060;branch=z9hG4bK-1180443149349999157
Figure 27: SIP 200 OK response (BYE)
12. Conclusion
This document described the steps taken at ETSI TISPAN to achieve
better interaction between the SIP and RTSP protocols. We see such
an interaction beneficial since it makes it possible to reuse much of
Lindquist, et al. Expires December 11, 2010 [Page 42]
Internet-Draft Combining SIP and RTSP June 2010
the architecture and functionality (e.g., authentication, charging,
and QoS) that have already been established around SIP also for RTSP
streaming. The document described a model in which SIP/SDP is used
to establish an RTSP control channel and one or more content delivery
streams. The fact that this model has already been adopted by
standardization bodies such as ETSI TISPAN, 3GPP, and Open IPTV Forum
proves that there exists a clear need in the industry for a solution
like this. Two approaches for combining SIP and RTSP were described.
The first approach removes session setup and teardown semantics from
the RTSP protocol, whereas the second approach tries to keep both SIP
and RTSP as intact as possible
13. Security Considerations
RFC 4145 [RFC4145] discusses security issues related to the
establishment of TCP connections using the SDP offer/answer model.
Security issues related to the SDP offer/answer model and SDP are
discussed in the SDP offer/answer model RFC [RFC3264], and the SDP
RFC [RFC4566], respectively.
13.1. Man-in-the-middle Attack
Numerous attacks are possible if an attacker can modify SDP offers or
answers in transit. These attacks are discussed in the SDP offer/
answer model RFC [RFC3264].
13.2. Session Hijacking
A session ID parameter is used to correlate SIP and RTSP. Session
hijacking may be possible if the session ID is exposed to a third
party.
13.3. Privacy Considerations
If the identity of a client is to remain hidden, the instructions in
[RFC3261] can be followed to generate anonymous SIP header field
values.
14. IANA Considerations
14.1. Registration of the 'TCP/ETSI_RTSP' and 'TCP/TLS/ETSI_RTSP' SDP
'proto' Values
This document defines the following two new values for the SDP
'proto' field under the Session Description Protocol (SDP) Parameters
registry:
Lindquist, et al. Expires December 11, 2010 [Page 43]
Internet-Draft Combining SIP and RTSP June 2010
+-------------------+-----------+
| Value | Reference |
+-------------------+-----------+
| TCP/ETSI_RTSP | RFCAAAA |
| TCP/TLS/ETSI_RTSP | RFCAAAA |
+-------------------+-----------+
Table 1: Values for the SDP 'proto' field
14.2. Registration of the SDP 'etsi_rtsp-uri' Attribute
This document defines the following SDP att-field under the Session
Description Protocol (SDP) Parameters registry:
Contact name: Jouni.Maenpaa@ericsson.com
Attribute name: etsi_rtsp-uri
Long-form attribute name: ETSI RTSP URI
Type of attribute: Media Level
Subject to charset: No
Purpose of the attribute: Contains the RTSP URL that is to be used
in the RTSP content control requests.
Allowed attribute values: A string specifying an RTSP URL
14.3. Registration of the SDP 'etsi_rtsp-session' Attribute
This document defines the following SDP att-field under the Session
Description Protocol (SDP) Parameters registry:
Contact name: Jouni.Maenpaa@ericsson.com
Attribute name: etsi_rtsp-session
Long-form attribute name: ETSI RTSP Session
Type of attribute: Media Level
Subject to charset: No
Lindquist, et al. Expires December 11, 2010 [Page 44]
Internet-Draft Combining SIP and RTSP June 2010
Purpose of the attribute: Contains the session ID of the RTSP
session. May also specify optionally a keepalive interval for
RTSP.
Allowed attribute values: a=etsi_rtsp-session:<session ID>
[<timeout>]. The "session ID" attribute is a token specifying an
RTSP session ID. The optional "timeout" parameter specifies an
RTSP keepalive interval in seconds.
14.4. Registration of the SDP 'etsi_rtsp-offset' Attribute
This document defines the following SDP att-field under the Session
Description Protocol (SDP) Parameters registry:
Contact name: Jouni.Maenpaa@ericsson.com
Attribute name: etsi_rtsp-offset
Long-form attribute name: ETSI RTSP Offset
Type of attribute: Media Level
Subject to charset: No
Purpose of the attribute: Specifies the current playback position in
seconds.
Allowed attribute values: A token
14.5. Registration of the SDP 'etsi_rtsp-version' Attribute
This document defines the following SDP att-field under the Session
Description Protocol (SDP) Parameters registry:
Contact name: Jouni.Maenpaa@ericsson.com
Attribute name: etsi_rtsp-version
Long-form attribute name: ETSI RTSP Version
Type of attribute: Media Level
Subject to charset: No
Lindquist, et al. Expires December 11, 2010 [Page 45]
Internet-Draft Combining SIP and RTSP June 2010
Purpose of the attribute: Specifies the RTSP protocol version.
Allowed attribute values: As an example, if the sender supports RTSP
version 1.0, the value of the attribute is "1.0". If the sender
supports RTSP 2.0, the value is "2.0".
15. Acknowledgements
The authors would like to acknowledge those who have made
contributions to combining SIP and RTSP over the years. Among those
who have provided valuable feedback are Sam Ganesan from Motorola,
Magnus Westerlund from Ericsson, Steven Whitehead from Verizon,
Marie-Jose Montpetit from MIT Media Labs, Mikhael Said, Hadriel
Kaplan from Acme Packet and David Ress from Nortel.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
September 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
16.2. Informative References
[3GPP TS 26.237]
"3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; IP
Lindquist, et al. Expires December 11, 2010 [Page 46]
Internet-Draft Combining SIP and RTSP June 2010
Multimedia Subsystem (IMS) based Packet Switch Streaming
(PSS) and Multimedia Broadcast/Multicast Service (MBMS)
User Service; Protocols (Release 8)", 3GPP TS 26.237
V8.1.1 (2009-03).
[ETSI TS 183 063]
"Telecommunications and Internet Converged Services and
Protocols for Advanced Networking (TISPAN); IMS-based IPTV
Stage 3 Specification", ETSI TS 183 063 v2.1.0 (2008-06).
[I-D.ietf-lindquist-mmusic-sip-rtsp]
Lindquist, J., Maenpaa, J., Rajagopal, P., and X. Marjou,
"Session Description Protocol (SDP) Offer/Answer Model For
Media Control Protocol",
draft-lindquist-mmusic-sip-rtsp-00 Jun 2009.
[I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
draft-ietf-sipping-sbc-funcs-09 (work in progress),
February 2010.
[I-D.ietf-whitehead-mmusic-sip-for-streaming-media]
Whitehead, S., Montpetit, M., Marjou, X., Ganesan, S., and
J. Lindquist, "Media Playback Control Protocol
Requirements",
draft-whitehead-mmusic-sip-for-streaming-media-05
(expired) May 2008.
[I-D.ietf.marjou-mmusic-sdp-rtsp]
Marjou, X., Lindquist, J., Rajagopal, P., Said, M., and S.
Ganesan, "Session Description Protocol (SDP) Offer/Answer
Model For Media Control Protocol",
draft-marjou-mmusic-sdp-rtsp-01 (expired) Feb 2008.
[OIPF Volume 4]
"Open IPTV Forum - Release 1 Specification; Volume 4 -
Protocols", V1.0 (January 6, 2009).
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
Lindquist, et al. Expires December 11, 2010 [Page 47]
Internet-Draft Combining SIP and RTSP June 2010
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313,
January 2003.
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format
for Binary Floor Control Protocol (BFCP) Streams",
RFC 4583, November 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
Canales-Valenzuela, C., and K. Tammi, "Diameter Session
Initiation Protocol (SIP) Application", RFC 4740,
November 2006.
[RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of
Service (QoS) Mechanism Selection in the Session
Description Protocol (SDP)", RFC 5432, March 2009.
Authors' Addresses
Jan Lindquist
Ericsson
Tellusborgsvaegen 83-87
Hagersten 12637
Sweden
Email: jan.lindquist@ericsson.com
Jouni Maenpaa
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Jouni.Maenpaa@ericsson.com
Lindquist, et al. Expires December 11, 2010 [Page 48]
Internet-Draft Combining SIP and RTSP June 2010
Priya Rajagopal
Motorola
900 Chelmsford street ; T1;09
Lowell, MA 01891
USA
Email: priyarajagopal@motorola.com
Xavier Marjou
France Telecom Orange
2, avenue Pierre Marzin
Lannion 22307
France
Email: xavier.marjou@orange-ftgroup.com
Lindquist, et al. Expires December 11, 2010 [Page 49]
