SIP Working Group Shanmugalingam Sivasothy
Internet Draft Telecom SudParis
Intended status: Informational Gyu Myoung Lee
Expires: January 2010 Telecom SudParis
Noel Crepsi
Telecom SudParis
July 13, 2009
SIP extensions for media control
draft-siva-sip-media-01.txt
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 13, 2009.
Siva, et al. Expires January 13,2010 [Page 1]
SIP extensions for media control July 2009
Copyright Notice
Copyright (c) 2009 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 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.
Siva, et al. Expires January 13,2010 [Page 2]
SIP extensions for media control July 2009
Abstract
This draft presents a requirement and proposes a solution to
integration of Session Initiation Protocol (SIP), to the Real Time
Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP]
especially in the context of converged media services or IPTV
services. The document develops a rationale for using SIP with
streaming media applications. One service on top of IPTV service is
sketched out, which required SIP optimally.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Siva, et al. Expires January 13,2010 [Page 3]
SIP extensions for media control July 2009
Table of Contents
1. Introduction ................................................ 5
2. Terminology ................................................. 6
3. Use Case Scenario ........................................... 6
3.1. Scope .................................................. 6
3.2. Use Case ............................................... 6
4. Proposed solution using SIP for both session and media control 7
4.1. Overview of proposed solution .......................... 7
4.2. Demonstration .......................................... 8
4.3. Detailed procedures of Session and media control........ 9
5. Alternative solution spaces for proposed use-cases ......... 11
6. Advantages ................................................. 12
7. Security Considerations..................................... 12
8. IANA Considerations ........................................ 12
9. References ................................................. 12
9.1. Normative References................................... 12
9.2. Informative References................................. 13
Author's Addresses ............................................ 13
Siva, et al. Expires January 13,2010 [Page 4]
SIP extensions for media control July 2009
1. Introduction
Internet Protocol based Television services (IPTV) are gaining
popularity in telecom business circle specially telecom vendors and
telecom operators. This service gives high revenue to telecom
operators, in turn to telecom vendors, which lose revenue in the
traditional voice services. In user point of view, they are able to
access high quality video easily using IPTV. High penetration of
broadband connectivity, improvement of multimedia codecs, and
deployment of flexible triple play service delivery architecture by
the operators contribute to the success of IPTV. This growth imposes
challenging new requirements for converged media services in terms
of flexibility and efficiency.
In order to realize the IPTV services based on IMS, IMS user deploys
minimum four protocols such as HTTP, RTP, RTSP and SIP. One of the
hurdles today to deliver the SIP services over corporate networks is
firewall and NAT traversal. Opening the network other than
HTTP/HTTPS still is a question for a network administrator. In some
cases, opening the network for RTP and SIP is achieved using SIP and
RTP aware firewall or session border controller. Rather than one
opening for RTSP, it is desirable to have one unified session
control protocol. In client side, having separate persistent
connectivity for RTSP, SIP and RTP is not advisable in terms of
performance. Therefore, reducing the number of protocol is a right
option. At last in the context of IMS based IPTV architecture, SIP
is used to manage the session. Extending SIP to manage the media
control is a viable solution than deploying other protocol for media
control.
This document proposes rational for using SIP for a signaling
protocol for streaming media applications.
Note: The purpose of this document is to propose in detail one
specific approach to using SIP for streaming-media applications. And,
our intent is to stimulate discussion within the IETF community and
catalyze future work in this area. To this end, our strategy has
been to
o develop the rationale for using SIP
o evaluate, at a high-level, a SIP in the context of converged
media services, and
Siva, et al. Expires January 13,2010 [Page 5]
SIP extensions for media control July 2009
o identify, if appropriate, the future developments.
2. Terminology
See [RFC3261] and [RFC2326] for terminology.
In addition the following terms are defined: Trick Play: Play, stop,
pause, restart and fast forward of streaming media.
Note: we also use several terminologies in [TS182027] in order to
explain architectural aspects of IPTV and IMS.
3. Use Case Scenario
This section describes one value added services on top of streaming
media application - use case scenario. This scenario illustrates the
variety of conditions and Environments in which streaming media
application needs to operate.
3.1. Scope
The scope of streaming media applications for this document includes
applications with the following characteristics: content-on-demand,
streaming media, unicast-media streams, live or recorded content,
ubiquitous access (any-device, any-access).
Explicit exclusions include non-streaming (e.g., downloaded media);
though of interest this is out of scope for the present document.
3.2. Use Case
Use cases are used with the purpose of clarifying the "streaming
media Application" and to explore the space of applications. The
objective is to
o clarify the frame / scope the discussion
o illustrate some of usage scenarios
o identify some of the key attributes that characterize these
Scenario - Advertisement/Recommendation Services
Siva, et al. Expires January 13,2010 [Page 6]
SIP extensions for media control July 2009
Information of relevant videos (recommendation) or advertisement
need to be displayed on the screen of video display when user pauses
video session or video content is about to finish.
4. Proposed solution using SIP for both session and media control
4.1. Overview of proposed solution
SIP is used to setup or modify or terminating a session. In addition,
SIP UPDATE allows a client to update parameters of session.
The solution needs to satisfy the requirements for session setup,
media setup and media control. Session setup and media setup are
carried out using INVITE message. Trick plays and media control
features is mapped to the SIP message, which is UPDATE method. Media
control message such as play, pause is transferred from UE using
UPDATE message. Therefore, the semantics of SIP session is not
changed.
In order to differentiate many media control messages, SIP-MEX - new
header is defined and included into UPDATE message.
Even though, trick plays and media control features has to be
handled by SIP, some information has to be passed back to UE from
network when some events happen such as pause. Therefore, new header
(SIP-MEX) in UPDATE method with new XML body is used in our proposed
solution for tricks plays and media control features. This criterion
is used to select the UPDATE method. SIP-MEX is not standardized and
is used for carrying the media event information.
SIP session typically follows the cycle of many session-media states.
Session-media states are started, paused, restarted, and end.
Restarted happens after media pauses. Mostly, UPDATE is used to
change session media state. It means when session is started,
issuing an UPDATE command can trigger the state from started to
paused. Likewise, paused state can be trigged to restarted state by
UPDATE command. These UPDATE will not change the session parameters
instead change session-media state of a session.
UPDATE will contain SIP-MEX header with value: pause/restart. One
important change is that content-type is application/XML not SDP.
When UPDATE message is sent from UAC to UAS, it will carry new SIP
header called as SIP-MEX. The content type of the response message
is XML, which is simple and flexible enough to change. .
Siva, et al. Expires January 13,2010 [Page 7]
SIP extensions for media control July 2009
Main difficulty is how to identify that both ends support UPDATE
message and understand session-media state. According to RFC 3261,
Allow header in the initial invite message and its response can be
used to verify that both end supports UPDATE message. Session-media
state is understandable by UAS if UAS insert SIP-MEX header into the
response of UPDATE message which has SIP-MEX initially.
The fast forward and fast backward can be added into session-media
states. Parameters, which describe the fast forward and fast
backward, can be sent in XML via UPDATE message. In this document,
efforts are not devoted to discuss about these cases.
4.2. Demonstration
The proposed solution is demonstrated in IPTV context, whose
architecture is defined in [TS182027].Our mechanisms mainly work
within UE and SCF in the IPTV services. When UE sends the UPDATE
message with Pause details, SCF replies with information, which is
going to be displayed. Information of trick functions is sent in SIP
body. In reply, XML info is sent back to the UE. Based on the
unified session control protocol, IPTV architecture will have one
modification, which is removing the Xc interface between UE and IPTV
media control function. It is not focus of this document.
Based on the design, SCF behaves in UA mode and coordinates the MCF
via y2 interface. Details of the interface between SCF and MCF are
not discussed here. Optionally, SCF can perform in B2BUA mode
between user and MCF. In this case, MCF should be SIP aware. These
two options are used; because connectivity to MCF and MDF depends on
content providers ability.
SCF implements the function, which is responsible to send
information (advertisement/recommendation) to the UE when Pause
event arrived. Moreover, way the SCF finds the information or
advertisement is beyond the scope, SCF may use semantic web services
and context enabler services. In the trick function, for example
Pause event, UE will send the UPDATE message with SIP-MEX header,
which contains of PAUSE event. In response, OK message will carry
relevant information in XML format to UE.
Siva, et al. Expires January 13,2010 [Page 8]
SIP extensions for media control July 2009
4.3. Detailed procedures of Session and media control
In the context of on demand service, scenario can be explained as
follows. User selects the corresponding the media content from UE,
which is identified by URI. Let assume that address of the media
content is movie1@vod.ims.eu.
Once SCF receive the INVITE message, SCF instruct the media content
delivery function to deliver the media. SCF may have one or two
different interfaces to the media content delivery function.
In Figure 1, SCF is connected to MCF using non-SIP protocol. When
Pause happens in UE, UE directly send UPDATE message to SCF. OK
message is sent to directly to UE with XML information. Since Figure
1 does not show full description of message flow, important message
is shown in dotted line.
UE IMSCore SCF MCF MDF
| | | | |
| INVITE | | | |
|--------------->| INVITE | | |
| |--------------->|<<MESSAGE1>> | |
| | |--------------->|<<MESSAGE2>> |
| | | |------------ >|
| Media Session started |
|<===============================================================>|
| |
| UPDATE | | |
|------------------------------- > | |
| | |<<MESSAGE1>> | |
| | |--------------->|<<MESSAGE2>> |
| | | |------------ >|
| | | | |
| OK | | |
|< ===============================| | |
| |
| Media Session Paused |
|<===============================================================>|
| |
| UPDATE | | |
|------------------------------- > | |
| | |<<MESSAGE1>> | |
| | |--------------->|<<MESSAGE2>> |
| | | |------------ >|
| OK | | |
Siva, et al. Expires January 13,2010 [Page 9]
SIP extensions for media control July 2009
|< ===============================| | |
| Media Session Restarted |
|<===============================================================>|
|
| BYE | BYE |
|--------------> |-------------- >|<<MESSAGE1>> | |
| | |-------------- >|<<MESSAGE2>> |
| |------------->|
| Media Session Stopped |
|<===============================================================>|
Figure 1. Sequence diagram when SCF connect to MCF through non-SIP
protocol
Alternatively, connectivity between SCF and MCF can be SIP enabled.
In this case, SCF can behave like B2BUA or proxy mode, but we choose
B2BUA. Because SCF needs to send some information as response to UE
when pause event happened. In the proxy mode, MCF will generate the
OK response and SCF cannot modify the SDP of the OK message. This
model can be used when MCF is responsible to deliver advertisement
or information to UE. Alternative scenario, where SCF is in B2BUA
and SCF is connected to MCF via SIP interface, is clearly shown in
Figure 2.
UE IMSCore SCF MCF MDF
| | | | |
| INVITE | | | |
|--------------->| INVITE | | |
|--------------->| | | |
| | INVITE | | |
| |< --------------| | |
| | INVITE | |
| |------------------------------ | <<MESSAGE2>> |
| | | |------------ >|
| | | | |
| | | | |
Media Session started |
|<===============================================================>|
| |
| UPDATE | |
|------------------------------- > |
|
Siva, et al. Expires January 13,2010 [Page 10]
SIP extensions for media control July 2009
| | |UPDATE | |
| | |--------------->|<<MESSAGE2>> |
| | | |------------ >|
| | | | |
| OK | | |
|< ===============================| | |
| |
| Media Delivery Paused |
|<===============================================================>|
|
| UPDATE | |
|------------------------------- > | |
| | |UPDATE | |
| | |--------------->|<<MESSAGE2>> |
| | | |------------ >|
| OK | | |
|< ===============================| |
| Media Delivery Restarted |
|<===============================================================>|
|
| BYE | BYE | | |
|--------------> |-------------- >| | |
| | | | |
| |<-- ------------| | |
| | |<<MESSAGE2>> |
| |-------------------------------->|----------- |
| Media Delivery Stopped |
|<===============================================================>|
Figure 2. Sequence diagram when SCF connect to MCF through SIP
protocol
5. Alternative solution spaces for proposed use-cases
o In ordinary case, media control event can be passed to IMS
provider by the content provider and then IPTV application
triggers the SIP Push to send the information to UE.
Siva, et al. Expires January 13,2010 [Page 11]
SIP extensions for media control July 2009
o Second solution is that SIP is for session management and RTSP is
for media signaling. When user pause the VOD service, client can
pull information from web server according to currently watching
video information. But on the other hand, using proposed unified
session control protocol, one advantage is that both ends can
send the information to each other compared to HTTP. It means
that network enable pause is possible. Even if network enabled
pause takes place, server can send information to client in
UPDATE message.
6. Advantages
o IMS based Telco become an efficient context provider who may know
the media control.
o Easy to implement: Our solution tries to push information to
screen where already existing TV is displaying the video.
Therefore, we use same dialog (UPDATE/OK) to carry this push
information.
o This method is relatively simple and easy to adopt in the SIP
environment.
7. Security Considerations
This document does not require any specific security considerations.
8. IANA Considerations
This document has no actions for IANA.
9. References
9.1. Normative References
[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.
Siva, et al. Expires January 13,2010 [Page 12]
SIP extensions for media control July 2009
[RFC2326] Schulzrinne H., Rao, A., Lanphier R., "Real Time
Streaming Protocol (RTSP)", RFC 3261, April 1998.
9.2. Informative References
[IDRTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
Narasimhan A., "Real Time Streaming Protocol 2.0 (RTSP)",
work in progress, November 2008.
[TS182027] ETSI TISPAN, "IPTV architecture; IPTV function supported
by the IMS subsystem", TS 182.027 (2008-11) available on
http://portal.etsi.org/docbox/tispan/Open/NGN_LATEST_DRAFT
S/RELEASE3/02070-ngn-r3v310.pdf
[1] S. Shanmugalingam, G. M. Lee, and N. Crespi, "Unified Session
Control Protocol for IPTV Services", in International
Conference on Advanced Communication Technology, Korea, Feb
2009. pp. 961-965.
[2] ITU-T IPTV-GSI, available on http://www.itu.int/ITU-T/gsi/iptv
Author's Addresses
Shanmugalingam Sivasothy
Institut TELECOM, TELECOM SudParis
9 rue Charles Fourier, 91011, Evry, France
Phone:
Email: Shanmugalingam.Sivasothy@it-sudparis.eu
Gyu Myoung Lee
Institut TELECOM, TELECOM SudParis
9 rue Charles Fourier, 91011, Evry, France
Phone: +33 (0)1 60 76 41 19
Email: gm.lee@it-sudparis.eu
Siva, et al. Expires January 13,2010 [Page 13]
SIP extensions for media control July 2009
Noel Crespi
Institut TELECOM, TELECOM SudParis
9 rue Charles Fourier, 91011, Evry, France
Phone: +33 (0)1 60 76 46 23
Email: noel.crespi@it-sudparis.eu
Siva, et al. Expires January 13,2010 [Page 14]