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 provider’s 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 | | | | |--------------->|<> | | | | |--------------->|<> | | | | |------------ >| | Media Session started | |<===============================================================>| | | | UPDATE | | | |------------------------------- > | | | | |<> | | | | |--------------->|<> | | | | |------------ >| | | | | | | OK | | | |< ===============================| | | | | | Media Session Paused | |<===============================================================>| | | | UPDATE | | | |------------------------------- > | | | | |<> | | | | |--------------->|<> | | | | |------------ >| | OK | | | Siva, et al. Expires January 13,2010 [Page 9] SIP extensions for media control July 2009 |< ===============================| | | | Media Session Restarted | |<===============================================================>| | | BYE | BYE | |--------------> |-------------- >|<> | | | | |-------------- >|<> | | |------------->| | 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 | | | |------------------------------ | <> | | | | |------------ >| | | | | | | | | | | Media Session started | |<===============================================================>| | | | UPDATE | | |------------------------------- > | | Siva, et al. Expires January 13,2010 [Page 10] SIP extensions for media control July 2009 | | |UPDATE | | | | |--------------->|<> | | | | |------------ >| | | | | | | OK | | | |< ===============================| | | | | | Media Delivery Paused | |<===============================================================>| | | UPDATE | | |------------------------------- > | | | | |UPDATE | | | | |--------------->|<> | | | | |------------ >| | OK | | | |< ===============================| | | Media Delivery Restarted | |<===============================================================>| | | BYE | BYE | | | |--------------> |-------------- >| | | | | | | | | |<-- ------------| | | | | |<> | | |-------------------------------->|----------- | | 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]