SIP Working Group Shanmugalingam Sivasothy Internet Draft Institut Telecom SudParis Intended status: Informational Gyu Myoung Lee Expires: September 2009 Institut Telecom SudParis/ICU Noel Crespi Institut Telecom SudParis March 4, 2009 SIP extensions for media control draft-siva-sip-media-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 September 4, 2009. Copyright Notice Copyright (C) The IETF Trust (2009). Siva, et al. Expires September 4, 2009 [Page 1] SIP extensions for media control March 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 and solution space 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 September 4, 2009 [Page 2] SIP extensions for media control March 2009 Table of Contents 1. Introduction ................................................ 4 2. Terminology ................................................. 5 3. Use Case Scenario ........................................... 5 3.1. Scope .................................................. 5 3.2. Use Case ............................................... 5 4. Rational for considering SIP................................. 6 5. Proposed solution using SIP for both session and media control 6 5.1. Overview of proposed solution........................... 6 5.2. Demonstration .......................................... 7 5.3. Detailed procedures of Session and media control........ 8 6. Alternative solution spaces for proposed use-cases.......... 10 7. Advantages ................................................. 11 8. Security Considerations..................................... 11 9. IANA Considerations ........................................ 11 10. References ................................................ 11 10.1. Normative References.................................. 11 10.2. Informative References................................ 12 Author's Addresses ............................................ 12 Intellectual Property Statement................................ 13 Disclaimer of Validity ........................................ 13 Siva, et al. Expires September 4, 2009 [Page 3] SIP extensions for media control March 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 - develop the rationale for using SIP - evaluate, at a high-level, a SIP in the context of converged media services, and - identify, if appropriate, the future developments. Siva, et al. Expires September 4, 2009 [Page 4] SIP extensions for media control March 2009 2. Terminology See [RFC3261] and [RFC2326] for terminology. In addition the following terms are defined: Trick Play: Play, stop, pause, rewind and fast forward of streaming media. TBD 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 - clarify the frame / scope the discussion - illustrate some of usage scenarios - identify some of the key attributes that characterize these Siva, et al. Expires September 4, 2009 [Page 5] SIP extensions for media control March 2009 Scenario - Advertisement/Recommendation Services 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. Rational for considering SIP TBD 5. Proposed solution using SIP for both session and media control 5.1. Overview of proposed solution 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 can be mapped to the SIP message. Media control message such as play, pause is transferred from UE using UPDATE message. 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. Siva, et al. Expires September 4, 2009 [Page 6] SIP extensions for media control March 2009 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. In early stage of session, UPDATE message can be sent in order to change session parameters. However, this aspect is not considered for changing the session-media state at this moment. 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. 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. 5.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. 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 Siva, et al. Expires September 4, 2009 [Page 7] SIP extensions for media control March 2009 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. 5.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 | | | Siva, et al. Expires September 4, 2009 [Page 8] SIP extensions for media control March 2009 |------------------------------- > | | | | |<> | | | | |--------------->|<> | | | | |------------ >| | | | | | OK | | | |< ===============================| | | | 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 | | | |------------------------------ | <> | | | | |------------ >| | | | | | Siva, et al. Expires September 4, 2009 [Page 9] SIP extensions for media control March 2009 | | | | | Media Session started | |<===============================================================>| | | UPDATE | | |------------------------------- > | | | | |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 6. Alternative solution spaces for proposed use-cases Siva, et al. Expires September 4, 2009 [Page 10] SIP extensions for media control March 2009 - In ordinary case, media control event can be passed to IMS provider and then IPTV application triggers the SIP Push to send the information to UE. - 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. 7. Advantages - IMS based Telco become an efficient context provider who may know the media control. - 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. - This method is relatively simple and easy to adopt in the SIP environment. 8. Security Considerations This document does not require any specific security considerations. 9. IANA Considerations This document has no actions for IANA. 10. References 10.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 September 4, 2009 [Page 11] SIP extensions for media control March 2009 [RFC2326] Schulzrinne H., Rao, A., Lanphier R., "Real Time Streaming Protocol (RTSP)", RFC 3261, April 1998. 10.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 SudParis 9 rue Charles Fourier, 91011, Evry, France Phone: Email: Shanmugalingam.Sivasothy@it-sudparis.eu Gyu Myoung Lee Institut TELECOM SudParis/ICU 9 rue Charles Fourier, 91011, Evry, France 119 Munjiro, Yuseong-gu, Daejeon, 305-732, KOREA Phone: +33 (0)1 60 76 41 19 Email: gm.lee@it-sudparis.eu, gmlee@icu.ac.kr Siva, et al. Expires September 4, 2009 [Page 12] SIP extensions for media control March 2009 Noel Crespi Institut TELECOM SudParis 9 rue Charles Fourier, 91011, Evry, France Phone: +33 (0)1 60 76 46 23 Email: noel.crespi@it-sudparis.eu Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2009). Siva, et al. Expires September 4, 2009 [Page 13] SIP extensions for media control March 2009 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Siva, et al. Expires September 4, 2009 [Page 14]