SIP Working Group Shanmugalingam Sivasothy Internet Draft Telecom SudParis Intended status: Informational Gyu Myoung Lee Expires: September 2010 Telecom SudParis Noel Crespi Telecom SudParis March 8, 2010 Framework of media control for IPTV services draft-siva-iptv-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 September 8, 2010. Siva, et al. Expires September 8, 2010 [Page 1] Framework of media control for IPTV services March 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 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 September 8, 2010 [Page 2] Framework of media control for IPTV services March 2010 Abstract This draft presents a requirement for media control to support IPTV services. For this, this document provides several use cases for IPTV trick mode operations and propose solutions on how to use existing SIP for session and media control. 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 September 8, 2010 [Page 3] Framework of media control for IPTV services March 2010 Table of Contents 1. Introduction...................................................5 2. Use Cases for IPTV services....................................6 2.1. Classification of IPTV services...........................6 2.2. Use cases and service scenarios for IPTV services.........6 3. Requirements for media control to support IPTV service operation ..................................................................7 3.1. Basic concept of media control for IPTV services..........7 3.2. Requirements for media control............................8 4. Protocol solutions for media control to support IPTV services..9 4.1. Overview of protocol solutions............................9 4.2. New solutions for trick mode operation....................9 4.3. Demonstration............................................11 4.4. Detailed procedures of Session and media control.........11 5. Alternative solution spaces for proposed use-cases............14 6. Advantages....................................................14 7. Security Considerations.......................................15 8. IANA Considerations...........................................15 9. References....................................................15 9.1. Normative References.....................................15 9.2. Informative References...................................15 Author's Addresses...............................................16 Siva, et al. Expires September 8, 2010 [Page 4] Framework of media control for IPTV services March 2010 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 IP Multimedia Subsystem (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 creating one opening for RTSP, it is desirable to have one unified session control protocol. In the 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, 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 Siva, et al. Expires September 8, 2010 [Page 5] Framework of media control for IPTV services March 2010 - evaluate, at a high-level, SIP in the context of converged media services, and - identify, if appropriate, the future developments. 2. Use Cases for IPTV services 2.1. Classification of IPTV services Live TV Live TV comprises a one-way transmission of content from one point (the source) to two or more points (the receivers), whereas the end- user has no control over the content or timing of what he receives, apart from the ability to select a particular channel. Time-shifted TV Time shifted service provides TV contents to the user which are already been broadcasted. Some contents such as news, weather forecast or popular shows used to be popular and users want to watch them on their feasible time. Service providers store them along the network and serve up on getting the request. VoD Content is prepared and delivered by the content provider for retrieval, which is received and stored in VoD server. If necessary, trans-coding can also be performed to accommodate content with storage device characteristics. End-user can then select and retrieve such contents from this storage at any time, according to the constraints provided by the content protection metadata. 2.2. Use cases and service scenarios for IPTV services Live TV Home users can watch digital TV with the help of IP network which carries TV traffic from service provider to home and digital Set- top-box (STB) which converts IP packets into viewable TV format. Multicast channel is used to serve TV channel from proxy server to customer end. Service providers should be tactful to handle bunches of linear TV requests from many users with minimum service delivery latency. Multicast supports many users with single channel. When users want to watch TV, they perform multicast join operation to the stream which is currently serving in proxy server. If the multicast Siva, et al. Expires September 8, 2010 [Page 6] Framework of media control for IPTV services March 2010 channel is not available in the current proxy it is required to retrieved from other proxy servers or from head end server at top. Most of the popular channels are static i.e., current proxy has stream of them in advance. However, it is not feasible to make all the channels static on one proxy from resource point of view. Thus, channels other than static are dynamic and take some time before starting playing in user end. Time-shifted TV Users can watch time-shifted TV content through television set or small hand held devices such as Smartphones. People want to watch news while they are in home or outside. In home they can watch live news via television set using STB. However, when they are outside somewhere far from home they should watch using different means. They can watch using Smartphones or other handheld devices. Processing capability and content display format may be different in those devices. Therefore, it is required to adapt content as per the capability of requesting devices. Proxy server may need to perform content adaptation. VoD VoD service acquires video contents in head end server. Users can access VoD service using their TV set in their home or using handheld devices when they are in mobility. A user who is in home watching live TV channel can request some interesting video. Some users who are travelling in car or public transportation can also request the same service. VoD service can be resource intensive when many users access the service at the same time. Therefore, proxy server should use some resource scheduling technique to serve large number of users with limited VoD bandwidth. Batching can be performed to group multiple requests in to a single one. Such scheduling techniques optimize available resource to accommodate many service requesters. 3. Requirements for media control to support IPTV service operation 3.1. Basic concept of media control for IPTV services The linear TV with trick mode enables the end-user to pause linear TV. For the ability to skip content and for other capabilities (e.g., instant replay), the use of Personal Video Recorder (PVR) is required. PVR provides capability of end-user-controlled electronic Siva, et al. Expires September 8, 2010 [Page 7] Framework of media control for IPTV services March 2010 device that records linear TV and stores it in a digital storage facility, either in standalone set-top boxes or in the network. When the end-user's IPTV terminal has its own storage capability and the end-user requests any trick mode function, the programmed content is recorded by the storage function and may be displayed later according to the end-user's selection or the constraints provided by the content protection metadata. If the end-user requests the trick mode service without any local storage capability (e.g., embedded in his or her IPTV terminal), then the programmed content is recorded in the storage facility managed by the service provider. The selected content can then be displayed later by the end-user, according to the constraints provided by the content protection metadata. This capability can support "time-shifting", "trick modes". IPTV terminal device should have the following capabilities: - provide the interface for user to access the contents without time limitation, including pause, rewind, fast forward, etc - provide the interface for user to enable or disable the service of TV with trick mode provide the interface to set the expiration time 3.2. Requirements for media control Main requirements of media control in IPTV trick mode operation are associated with media storage. Three explicit situations have been investigated for media storage for more interactive and asynchronous viewing in the IPTV architecture. 1. Telco's TV setup boxes or Home gateways. 2. Regional server near to DSLAM, which terminates multicast and unicast. 3. TV Head End Servers which stores one copy of the content while delivering the live TV. In addition, media delivery method has changed from multicast to P2P distribution or cooperative P2P and multicast system. Siva, et al. Expires September 8, 2010 [Page 8] Framework of media control for IPTV services March 2010 These two requirements should be addressed when designing the media control protocol for IPTV services in the context of asynchronous viewing. 4. Protocol solutions for media control to support IPTV services 4.1. Overview of protocol solutions The following protocol solutions are useful for trick mode operation. . 1. RTSP: It is basic solution for Trick mode operation in VoD Services, because end-to-end nature is preserved in most of cases. It means that client and server remains same during the trick mode operation. RTSP protocol generally supports following trick mode operation: playback, stop, pause, fast forward and rewind at different speeds. 2. SIP: SIP is used for controlling multimedia communication sessions, for example in IMS-based IPTV services. 3. IGMP: Live TV environment works on multicast content delivery. Therefore, IGMP messages(join and leave) are used for trick mode operation. 4.2. New solutions for trick mode operation The media control in Time-shift TV gets benefits from P2P SIP. Basic idea is to use the SIP for session and media control. In this section, we mainly focus on Time-shifted TV, where storage facility can be in different places, we consider that regional server keeps the content of the each channel. Each Regional servers and head-ends forms P2P network in order to deliver efficiently. Each client request has Time and Channel parameters for video content. SIP is used to setup or modify or terminating a session. In addition, SIP UPDATE allows a client to update parameters of session. Siva, et al. Expires September 8, 2010 [Page 9] Framework of media control for IPTV services March 2010 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 are 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. 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. Siva, et al. Expires September 8, 2010 [Page 10] Framework of media control for IPTV services March 2010 4.3. 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 information 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. 4.4. 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 receives the INVITE message, SCF instructs 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 messages are shown in the dotted line. Siva, et al. Expires September 8, 2010 [Page 11] Framework of media control for IPTV services March 2010 UE IMSCore SCF MCF MDF | | | | | | INVITE | | | | |--------------->| INVITE | | | | |--------------->|<> | | | | |--------------->|<> | | | | |------------ >| | Media Session started | |<===============================================================>| | | | UPDATE | | | |------------------------------- > | | | | |<> | | | | |--------------->|<> | | | | |------------ >| | | | | | | OK | | | |< ===============================| | | | | | Media Session Paused | |<===============================================================>| | | | UPDATE | | | |------------------------------- > | | | | |<> | | | | |--------------->|<> | | | | |------------ >| | | | OK | | | |< ===============================| | | | Media Session Restarted | |<===============================================================>| | | | BYE | BYE | | |--------------> |-------------- >|<> | | | | |-------------- >|<> | | |------------->| | | Media Session Stopped | | | |<===============================================================>| Figure 1. Sequence diagram when SCF connect to MCF through non-SIP protocol Siva, et al. Expires September 8, 2010 [Page 12] Framework of media control for IPTV services March 2010 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 | | | |------------------------------- > | | | | |UPDATE | | | | |--------------->|<> | | | | |------------ >| | | | | | | OK | | | |< ===============================| | | | | | Media Delivery Paused | |<===============================================================>| | | | UPDATE | | | |------------------------------- > | | | | |UPDATE | | | | |--------------->|<> | | | | |------------ >| | OK | | | |< ===============================| | | | Media Delivery Restarted | |<===============================================================>| | Siva, et al. Expires September 8, 2010 [Page 13] Framework of media control for IPTV services March 2010 | 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 - 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. - 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 enabled pause is possible. Even if network enabled pause takes place, server can send information to client in UPDATE message. 6. Advantages The approach proposed in section 4 gives the following advantages: - IMS based Telco becomes 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. Siva, et al. Expires September 8, 2010 [Page 14] Framework of media control for IPTV services March 2010 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. [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 Siva, et al. Expires September 8, 2010 [Page 15] Framework of media control for IPTV services March 2010 [3] Meeyoung Cha, Pablo Rodriguez, Sue Moon, and Jon Crowcroftz, "On Next-Generation Telco-Managed P2P TV Architectures", In Proceedings of the 7th International Workshop on Peer-to-Peer Systems (IPTPS’08), Tampa Bay, FL, February 2008. 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 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 September 8, 2010 [Page 16]