MediaCtrl Zhou, Ed. Internet-Draft Huawei Technologies, Inc. Intended status: Standards Track October 15, 2009 Expires: April 18, 2010 draft-zhipeng-mediactrl-dynamic-adaptation-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 18, 2010. 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. Abstract This document describes controls and service flow for Media Server on the scenarios and requirements for dynamic adaptation of the terminal types, media format and transport bit rate (Dynamic Bandwidth Zhou Expires April 18, 2010 [Page 1] Internet-Draft October 2009 Allocation), etc. To fulfill the requirements above, an Adaptor entity is introduced in the architecture in the case of the dynamic media adaptation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Dynamic Adaptations . . . . . . . . . . . . . . . . . . . . . 4 3.1. Dynamic Bandwidth Allocation . . . . . . . . . . . . . . . 4 3.2. Dynamic Bandwidth Allocation with Dynamic Media Format Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Dynamic Terminal Adaptation with dynamic Media Format Adaptation . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Transcoder . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Media Adaptor . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Interface between MA and MS . . . . . . . . . . . . . . . 9 4.2. Media Adaptor Interface XML Schema . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Zhou Expires April 18, 2010 [Page 2] Internet-Draft October 2009 1. Introduction Nowadays the application is much variable and plentiful. For the deployment of content service, the Media Server should always support multiple media types and multiple terminal types, such as PC or Mobile Phone. In fact the concerns of media type and terminal type are much relative since the service for PC and Mobile Phone will always adopt different media type according to the machine capability in the applications, exp. in the video area. Terminal adaptation and Media adaptation will bring much economical benefit for the service deployment if the server owns the ability of dynamic adaptation. This document gives the solutions for the Media Server's dynamic adaptation based on the scenarios in [RFC5567] (An Architectural Framework for Media Server Control). 2. Conventions and 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 [RFC2119]. This document inherits terminology defined in the MediaCtrl Architecture[RFC5567].In addition, the following terms are defined for use in this document and for use in the context of the MediaCtrl Work group in the IETF. Terminal Adaptation: The server SHALL support multiple media format for the same content and will dynamically select a suitable media format to a terminal according to the terminal type and its device capability. Media Adaptation: The server SHALL support multiple media format and variant bit rate and will be able to adjust the media format or bit rate when detecting the bandwidth or other communication conditions are changing distinctly. Media Adaptor(MA): A functional entity to fulfill dynamic adaptation between UA and Server. It will forward the media stream from a selected Media Server to the UA. Transcoder: A functional entity to transform the media from one format to another format, such as transforming a H.264 video of CIF Zhou Expires April 18, 2010 [Page 3] Internet-Draft October 2009 size to H.263 video of QCIF size. 3. Dynamic Adaptations This section addresses several scenarios and relevant methods on the Dynamic Adaptation of Media Server. 3.1. Dynamic Bandwidth Allocation The figure 1 below depicts the general procedure for bit rate adjusting during the media service. UA MS | | |<============== One-way RTP stream at rate a ============| | | | RTCP(SR) | |<--------------------------------------------------------| | RTCP(RR) | |-------------------------------------------------------->| | | | |--+ Rate | | | Adjusting | |<-+ | | |<============== One-way RTP stream at rate b ============| | | . . . . Figure 1. Dynamic Bandwidth Allocation Since the real bandwidth on a Connectionless Link will always jitter during the service and hence bring much bad experience for the User. If the extent of jittering is quite a bit serious, the Dynamic Bandwidth Allocation method is much preferred. To monitor the network conditions, the MS will occasionally send RTCP SR(Sender Report) to the UA; UA will return the RTCP RR(Receiver Report) to the MS.The SR will carry a TimeStamp;the RR will contains the LSR(Last SR) and DLSR(Delay since last SR), hence the MS will get out the RTT(Round-Trip Time). Meantime, the RR contains the "fraction lost" element and the "interarrival jitter" element to indicate the packet lost rate and the jittering rate,see [RFC3550]. By determining the RTT value and the information contained in the RR, the MS will get known of the network's condition. If the MS judges that the network bandwidth has taken a big change, then it will Zhou Expires April 18, 2010 [Page 4] Internet-Draft October 2009 adjust the bit rate of the media stream according to a policy. For example, in the MS, an interval threshold and a count threshold will be set. Once the accumulated occasions that the RTT is less than the interval threshold has achieved the count threshold, the MS will adjust the bit rate to a small value. Similarly, once the accumulated occasions that the interval is more than the interval threshold has achieved the count threshold, the MS will adjust the bit rate to a bigger value. The MS will initiate the UA to accept the media stream on the updated bit rate. 3.2. Dynamic Bandwidth Allocation with Dynamic Media Format Adaptation In the Dynamic Bandwidth Allocation process, it can also fulfill the Dynamic Media Format Adaptation, such as transform the media stream from CIF size media to QCIF size media when the bandwidth has decreased or on the contrary transform the media stream from QCIF size media to CIF size media when the bandwidth has increased. According to the method described in section 3.1, the MS can get known of the network's status. If the MS judges that the network bandwidth has taken a big change, then it will adjust the bit rate of the media stream and switch the media format as well according to a policy. The Figure 2 below depicts the procedure. UA MS | | |<==== One-way RTP stream (format A,rate a)=======| | | | RTCP(SR) | |<------------------------------------------------| | RTCP(RR) | |------------------------------------------------>| | | | |--+ Rate Adjusting & | | | Media Format | |<-+ Switching | | |<==== One-way RTP stream (format B,rate b)=======| | | . . . . Figure 2. Dynamic Media Format Adaptation Zhou Expires April 18, 2010 [Page 5] Internet-Draft October 2009 3.3. Dynamic Terminal Adaptation with dynamic Media Format Adaptation Currently the adaptation to multiple terminals is essential required for the Media Server since the media processing capability is a key feature for most types of terminals including smart phones or laptops. While there are plenty of media types and countless devices with very variant processing capability, so the server should has very strong media adaptation capability to serve for each kind of terminal. Generally, it will support most of the popular media formats. UA-1 MS UA-2 | | | | | Capability Adaptation | | |<----------------------------->| | |= Media (Format A at rate a)==>| | Capability Adaptation | | |<----------------------------->| | | | | |<= Media (Format B at rate b)==| | | | | . . . . . . Figure 3. Dynamic Adaptation to Terminals For the streaming service of a media file, the MS can transform the media file in different format (such as the H.264 or flash format) respectively and then encapsulate the media of each format into packets (e.g. RTP packets) and last store them in the server. Just by inserting the index (such as offset from the media start) properly in each file, the MS can easily provide general steaming service of that file according to the instruction of the UA(such as play, locate, backward or forward). Since the MS has prepared well multiple media formats for the media file, it can adapt to multiple format requirements when serving for different terminals. 3.4. Transcoder The Media Server can either be fixed with the transcoding ability or just depend on an independent Transcoder entity, shown in Figure 4 and 5. Zhou Expires April 18, 2010 [Page 6] Internet-Draft October 2009 +----+----+ | UA-1 |<----------+ +----+----+ | +----+-----+ | |Transcoder| +----+----+ | +----+-----+ | UA-2 |<----------+------------>| Media | +----+----+ | | Server | | +----+-----+ +----+----+ | | UA-3 |<----------+ +----+----+ Figure 4. Media Server with Combined Transcoder +-----+-----+ +------->| Media |<------+ | | Server | | | +-----+-----+ | | | | | +-----+-----+ | +-----+-----+ | +-----+-----+ | UA |<-------+------->| Media |<------+------>| Transcoder| +-----+-----+ | | Server | | | | | +-----+-----+ | +-----------+ | | | | | +-----+-----+ | | | Media | | +------->| Server |<------+ +-----+-----+ Figure 5. Media Server with Independent Transcoder For the case that there is an independent Transcoder entity besides the Media Server, the process of Media Format adaptation can be illustrated as Figure 6 below. Zhou Expires April 18, 2010 [Page 7] Internet-Draft October 2009 UA MS Transcoder | | | | |=== Media in Format A at rate a=>| | |<== Media in Format A at rate b==| | |<== Media in Format B at rate a==| | |<== Media in Format B at rate b==| | |<== Media in Format C at rate b==| | Capability Adaptation | | |<------------------------------>| | | | | |<= Media in Format C at rate b==| | . . . . . . Figure 6. Adaptation Provision with Transcoder 4. Media Adaptor In last section, several scenarios and processes for Dynamic Adaptation have been depicted. Hence, an Adaptor can be deployed between the UAs and Servers to fulfill the function as dynamic adjustment in the real time service. The topology is shown in Figure 7 below. +----+----+ +----------->| Media |<-----+ | | Server | | | +----+----+ | | | | | +---+---+ +----+----+ +----+----+ | +----+-----+ | UA |<------>| Media |<----->| Media |<-----+------>|Transcoder| +---+---+ | Adaptor | | Server | | | | +----+----+ +----+----+ | +----------+ | | | | | +----+----+ | | | Media | | +----------->| Server |<-----+ +----+----+ Figure 7. The Media Serving Architecture with a Media Adaptor Generally, the Media Adaptor should conduct the dynamic adaptation as described before and just select the proper media stream from a Media Server and then forward the stream to the UA during the real time media service. This architecture is beneficial for the modular design and deployment if the adaptation function is splitted from the Zhou Expires April 18, 2010 [Page 8] Internet-Draft October 2009 Media Server to the specific Media Adaptor. Regarding the architecture above, the interface between UA and Media Adaptor should be as normal as the interface between UA and Media Server in the previous figures. Hence the interface between Media Adaptor and Media Server is invisible to the UA and should be defined in this document and it can be rather simple as proposed. For example, the Media Adaptor will hold constant media streams of several formats at several bit rates with Media Servers, and will select and forward the proper media stream to the UA once the Media Adaptor detects the big change of bandwidth between UA and Media Adaptor. 4.1. Interface between MA and MS This section gives the general useful controls between Media Adaptor and Media Server, including: Start, Change, Stop.These controls are useful for the media switch. For VOD service, the instructions will also include the Forward and Backward. Two types of message are defined as below. One is "mediaAdaptationRequest", the other one is "mediaAdaptationResponse".In the Request, it will contain the instruction such as "Play" or 'Stop" and the SDP packet which will indicate the detail information including the media title and media format, etc.( TODO: to be optimized in the later versions.) Zhou Expires April 18, 2010 [Page 9] Internet-Draft October 2009 // contains the relevant information of the Media Stream Zhou Expires April 18, 2010 [Page 10] Internet-Draft October 2009 4.2. Media Adaptor Interface XML Schema Zhou Expires April 18, 2010 [Page 11] Internet-Draft October 2009 5. Security Considerations This document describes the architectural framework and relevant processes to be used for the requirements of all kinds of dynamic adaptations in the media service. The requirement of security can refer to the[RFC5567]. 6. IANA Considerations IANA Considerations to be included in later versions of this document. 7. Acknowledgements Many thanks to all the members in this area and my colleagues as this document has absorbed many precious ideas and experiences. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 8.2. Informative References [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009. Zhou Expires April 18, 2010 [Page 12] Internet-Draft October 2009 [I-D.ietf-mediactrl-mrb] Boulton, C. and L. Miniero, "Media Resource Brokering", draft-ietf-mediactrl-mrb-01 (work in progress), September 2009. Author's Address Zhipeng Zhou (editor) Huawei Technologies, Inc. Floor 2, Building A, NO.48, Ning Nan AV., Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-82276771 Email: zhouzp@huawei.com Zhou Expires April 18, 2010 [Page 13]