INTERNET-DRAFT Rahul Banerjee <draft-banerjee-rtp-vod-00.txt> BITS, Pilani Venkatesan V BITS, Pilani Bharani M BITS, Pilani Swaminathan P BITS, Pilani Rajesh Kumar Reddy BITS, Pilani November 22, 2002 An extension of RTP and RTCP protocols For Video-on-Demand systems <draft-banerjee-rtp-vod-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract: This memorandum specifies an extension to RTP and RTCP as specified in RFC 1889 [1] specifically designed to extend support to Video-on-Demand systems in particular and unicast systems in general. It is presented through an experimental Video-on-Demand Architecture that supports dynamic changes in the distribution pattern and load balancing to optimize the service quality provided to the user. draft-rtp-vod-00.txt [Page 1]
INTERNET-DRAFT November 22, 2002 Contents: 1 Introduction ................................................2 2 Overview of the architecture ................................3 2.1 Components of the VoD architecture ..........................3 2.2 Working of the VoD system ...................................3 3 Overview of dynamic scheduling concept ......................5 4 The protocol ................................................6 5 Packet formats ..............................................9 5.1 The RTP-Ext header format....................................9 5.2 The fixed part of the RTCP-Ext header........................10 5.3 The RTCP-Ext packet format...................................11 6 Appendix ....................................................13 6.1 Parameters...................................................13 6.2 Load Calculations............................................14 6.3 Algorithm for evaluating the distribution pattern............14 6.4 Full address of authors .....................................15 7 Security Considerations......................................15 8 Copyright statement..........................................15 9 References ..................................................16 1. Introduction: RTP and RTCP as specified in RFC 1889 [1], although having support for both multicast and unicast applications, when used for a unicast application, need to be tailored specifically to needs of the unicast application. Applications such as Video-on-Demand which are specifically unicast applications would not need to use some of the features provided by the existing specification of RTP and RTCP. In addition, the set of protocols need to be tailored in specific implementations in order to meet the needs of specific applications. The protocol extensions suggested in this draft are best explained using an experimental architecture for Video-on-Demand systems. Video- on-Demand is a typical example of a unicast application. The rest of the draft is explained on the basis This article presents the existing architecture for VoD system and introduces changes in the existing architecture for achieving better quality in the video at the client end. The article is organized as follows: introduction of the existing architecture, overview of the new architecture, protocol for communication in the new architecture, existing protocols tailored for the new architecture and mathematical models for estimation of optimum parameters. draft-rtp-vod-00.txt [Page 2]
INTERNET-DRAFT November 22, 2002 2. Overview of the architecture: 2.1 Components of the VoD architecture: The existing architecture of VoD system has the following components: 1. Client: The client is the machine, which sends a request for a video file. The client has the player software, which runs the received video file. The client also has a buffer which buffers the data received from the video server. 2. Control Server: The control server(s) takes care of the control operations involved in the transfers of the data. When a request is received from a client machine for a video file, the control server that runs the Load Balancing Tool (LBT) estimates the least loaded video server and assigns that video server to serve the client. The control server is the central point from which all the video servers can be accessed. 3. Video Server: The video server contains the video files. The video server also maintains a database of the video files present in it. When a client connects to the system, the video server sends the list of video files present in it. The client then sends a request for a video file. When video server is selected to serve the client, it transfers data in chunks to the client. 2.2 Working of the VoD system: The process starts with the client sending a request for a video file. The Load Balancing Tool (LBT) evaluates the least loaded video server among the video servers having the requested video file. When the admission control succeeds, the selected video server starts serving the client. It sends the video file in chunks to the client. The transmission follows the RTP and RTCP [1]. Once a video server is assigned to serve a client, it continues to serve the client until the end of transmission or until the point the transmission stops under some error condition. draft-rtp-vod-00.txt [Page 3]
INTERNET-DRAFT November 22, 2002 +----------------------+ | Client sends request | | for video file | +----------------------+ | | | | | +--------------+ +---------------+ +-------------+ +--->| LBT estimates| |Least loaded | |VS servers | |least loaded |---->|server assigned|-->|client until | |server | |to client | |EOT | +--------------+ +---------------+ +-------------+ fig. 1 The sequence is shown in fig.1. The encircled region shown the part which is static. In this context, the word æstaticÆ means that once the LBT estimates the least loaded server and a video server is assigned to serve the client, the same video server keeps serving the client until the EOT. The various processes that run to accomplish the VoD function are the following: * client: This process runs in the client machine. This process communicates with the video server sending request for video files and getting the response back. * player: This process runs in the client machine. This is the software which plays the data received from the video server and stored in the buffer. * video server: this is the process that communicates with the control server for regulating the transmission and with the client for the actual data transfer. * Meta data manager (MDM): this process runs in the video server which is involved with the database of video files present in the video server. * Control server: this process is responsible for all control functions such as accessing data and files in the video server. * Load Balancing Tool: this process runs on the control server. This process evaluates the load on the video servers when a client sends a request for a video file. draft-rtp-vod-00.txt [Page 4]
INTERNET-DRAFT November 22, 2002 3. Overview of dynamic scheduling concept: According to the existing architecture and implementation, once a video server is assigned to serve a client, it keeps serving the client until the end of the transmission or until the point the transmission stops due to some error. This model though simple, does not take into account the dynamically changing load on the video servers. The model just evaluates the load on the video server at the point of admission and hence forth ignores the change in load with time on the video server. Though the admission control policy takes care that the number of clients served does not exceed a number where the QoS demands cannot be met, a better response time can be achieved at the client end if the number of clients server by a video server decreases. This goes by the equation : Response time = k * 1/no of clients where 'k' is proportionality constant. The new system is based on this principle, to minimize the response time whenever possible. The new schema, deals with the dynamically changing load on a video server, and proposes an alternative method so that load gets distributed over time and all the video servers have minimum possible clients to serve. We see that the response time is inversely proportional to the number of clients connected to it. When the number of clients served by a video server decreases, better response time is achieved for those clients. Though the processor efficiency is maximum when the maximum number of clients it can serve are allowed, the best response time is not achieved. In applications like Video-on-Demand, where there are more than one servers (video server), response time is one of the most important parameter. By distributing the load among the video servers, the efficiency for the group of video servers remains the same and the response time at the individual clients either becomes better or remains the same. The control server evaluates the load on the video servers periodically. Hence, there must be periodic exchange of information between the video servers and the control server. The video server sends information about the load present on it at regular intervals of time. The control server gets the load information from different video servers, evaluates the load on these video servers, finds a distribution pattern and sends a response back to the video servers. During the time the control server calculates the distribution pattern, there is a delay involved. This gives a pause at the client end which is undesirable. In order to avoid this delay, the video servers keep streaming the video to the client during the time the control server evaluates the distribution pattern. When the control server sends back the response to the video server and if there is a shift in the video server for a particular client, the client starts draft-rtp-vod-00.txt [Page 5]
INTERNET-DRAFT November 22, 2002 receiving data from the newly assigned video server. The entire load shifting process is discussed in sec.4 Better response time is achieved at the cost of the overload in distributing the load and a few additional functions to be performed by the client. 4. Protocol: (1)For the dynamic scheduling to happen the video servers must send information about their load to the control server every fixed interval of time. This information is sent as an RTCP packet with server statistics (SERVSTAT) report in it. The estimation of time interval is discussed in the appendix. This SERVSTAT report carries information about the load on the video server. The control server receives the SERVSTAT report from all the video servers in the system. These reports give a picture of the load distribution in the system. The video server after sending the SERVSTAT packet keeps streaming video to the clients. +-------+ +------->| CS |<------+ SERVSTAT | +-------+ | SERVSTAT | | | | +-------+ +-------+ | VS-A | | VS-B | +-------+ +-------+ +-------+ |client | +-------+ (2)The control server on receiving the SERVSTAT report from all the video servers evaluates the distribution pattern. For this evaluation, it uses the load information sent by the video servers. The estimation of the distribution pattern is discussed in appendix (3)If for a particular client, a different video server (video server A) is scheduled, then the control server sends a DEL report to the video server (video server A) which is serving the client. draft-rtp-vod-00.txt [Page 6]
INTERNET-DRAFT November 22, 2002 +-------+ | CS | +-------+ | | DEL +-------+ | +-------+ | VS-A |<-------+ | VS-B | +-------+ +-------+ +-------+ |client | +-------+ (4)The video server A on receiving the DEL packet from the control server, responds by sending a SWITCH packet to the client. This SWITCH report carries information about the new video server (video server B) the client has to receive video from. The video server informs the client about the change in the server through a SWITCH packet. +-------+ | CS | +-------+ +-------+ +-------+ | VS-A | | VS-B | +-------+ +-------+ | | | SWITCH | | +-------+ +------->|client | +-------+ (5)The client receives information about the new video server it has to get data from the SWITCH packet. Now the client sends a REQ packet to the new video server it has to receive data from. The client now has to send an offset from where the server B starts streaming. For this value, the client decides the size of the data it has to buffer before it can start playing data from the new video server. The client adds the size of the data it has to buffer to the current offset of the file it has received and sends the resulting value in the REQ packet. The buffer size varies from one client to another. So different client add different value to the current offset. draft-rtp-vod-00.txt [Page 7]
INTERNET-DRAFT November 22, 2002 +-------+ | CS | +-------+ +-------+ +-------+ | VS-A | +---->| VS-B | +-------+ | +-------+ | | REQ | +-------+ |client | +-------+ (6)The video server B on receiving the REQ packet starts streaming the video file from the requested offset onwards. The client buffers the data received from the video server B. It also simultaneously receives data from the video server A. It plays data which is buffered from video server A. When the client receives the first data chunk which overlaps with the data from video server B it sends a BYE packet to video server A. Then it starts playing data buffered from the video server B. When video server A receives the BYE packet from the client it stops its transmission. The server A keeps transmitting data until it receives the BYE packet. Hence there will a overlap in data received from server A and server B. The client ignores the data packets from server A. Since the client starts playing data from server B only after buffering sufficient amount (during which it receives and plays data from server A) the delay due to slow transmission from B is avoided. +-------+ | CS | +-------+ +-------+ +-------+ | VS-A |<------+ | VS-B | +-------+ | +-------+ | BYE | | +-------+ |client | +-------+ (7)Once the client sends a BYE packet to the server A, it buffers and plays data only from server B. The client has now switched from video server A to video server B. After the next time interval, the video servers send their SERVSTAT packet and the cycle continues. draft-rtp-vod-00.txt [Page 8]
INTERNET-DRAFT November 22, 2002 5. Packet Formats: The format of the different packets involved in the communication between different components is given below 5.1 The RTP-Ext header format The RTP-Ext header is of fixed length and contains the following fields. However, it has the option to be extended by using a header extension bit. The format of this is the same as the RTP header extension as described in RFC-1889 [1]. The RTP-Ext header is of the following fixed format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=2 |P|X| --- | PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The header is of length 20 octets. The header may be extended using the extension bit but it is recommended not to use this field. However implementations should be prepared to parse and ignore header extensions that are not supported by them. The details of header extensions are the same as described in RFC-1889. The fixed part of the header has the following fields Version (V): 3 bits This field identifies the version of RTP-Ext. The value defined by this draft version is 1. Padding (P): 1 bit This bit indicates that there are one or more padding octets at the end of the payload which are not part of payload. The last octet of the padding indicates how many octets should be ignored. Extension bit (X): 1 bit This bit indicates that an extension header as suggested in section 5.3.1 of RFC-1889 follows the fixed length header. draft-rtp-vod-00.txt [Page 9]
INTERNET-DRAFT November 22, 2002 Reserved Field: 4 bit There is a three bit reserved field left unspecified for experimental purposes. Although implementations can ignore this field, it is strongly recommended that this field be set to zero on the sender side. Similarly the receiver makes sure this value if zero. This is to make sure malicious parties do not misuse this field. Payload type (PT): 7 bits This field identifies the payload format and is application specific. The mapping of these codes to the corresponding codes could be a static binding or could be a dynamic one which is appropriately communicated to the receiver before start of the streaming. Sequence number: 16 bits The sequence number is a 16-bit value that is used to detect packet loss and packets that arrive out of order. The initial value is unpredictable for security reasons and to minimize clash with older packets left over from a previous stream. The value wraps around on reaching the maximum value. Time stamp: 32 bits The time stamp is needed for jitter calculations. It is not necessary that this timestamp reflect the actual time at which the packet is send nor is it required that the sender and receiver should be synchronized. ( Refer to RFC-1889 sec 5.1 ) Source Identifier: 32 bits This is a 32 bit address that is chosen randomly to identify the source of the packet. This is described in RFC-1889. The other details of the server can be known from the SDES packet 5.2 The fixed part of the RTCP-Ext header There is a fixed length portion of the RTCP-Ext header that is common among all the packet types and spans 3 octets. This is similar to the RTP-Ext header. The fixed part of the RTCP-Ext header will therefore look like this. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=2 |P|N| ----- | PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The field unique to this header in contrast to the RTP-Ext header are Next header (N): 1 bit draft-rtp-vod-00.txt [Page 10]
INTERNET-DRAFT November 22, 2002 RTCP-Ext could make a compound packet formed out of many RTCP-Ext packets. In such a scenario, the N bit indicates whether this header is followed by another RTCP-Ext header. The flag is set to indicate anther header following this one and cleared to indicate that this one is the final one. Packet Type (PT): 7 bit This field identifies the type of current RTCP-Ext header. This could be one of the types like SR, RR, SDES, SERVSTAT, BYE, DEL, etc. 5.3 The RTCP-Ext packet format As discussed earlier the RTCP-Ext packet has a fixed length header prefix followed by type specific data. The type of the packet as indicated by the packet type could be any of SR, RR, SDES, BYE or APP as defined in RFC 1889. In addition three packet types are additionally defined to take care of the dynamic scheduling aspect of the architecture. The control server evaluates the loads on these video servers based on reports obtained from them and makes required modifications to the distribution pattern. These three packet types facilitate this communication. These packet types are SERVSTAT: This packet is sent at periodic intervals by the video servers to the control server to allow it to calculate the load on the video servers and the required changes to the distribution pattern. This calculation could use the number of clients being served and total capacity of the servers. In addition to the 3 octets common among all RTCP-Ext headers the remaining structure of the SERVSTAT packet is 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N Clients | Server Load | Server Capacity | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Offset | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ àà.. The fields in the packet are described below. N Clients: 8 bits The number of clients currently being served by the video server. draft-rtp-vod-00.txt [Page 11]
INTERNET-DRAFT November 22, 2002 Server Load: 8 bits This is a metric which indicates the extent to which the server is loaded. Server Capacity: 16 bits This is a metric which indicates the capacity of the server. Refer the Appendix 6.2 for the description of this metric Client Identifier: 32 bits A 32 bit identifier of the client. This is a randomly chosen value and is in fact, the value used as the source identifier in any packet originating from the client. Stream Identifier: 32 bits A 32 bit identifier that uniquely identifies any of the files that are available with the video server. File Size: 32 bits This is the size of the video file in bytes. This is used in a calculation by the control server. File offset: 32 bits A 32 bit value indicating the current offset of the file which is being served by the server. DEL packet: This packet is sent by the control server to a video server when it is intended that the distribution pattern has to change. Assuming that the client is currently receiving steaming data from a video server A and it is intended that the client instead get the data from video server B, the control server sends a DEL packet to the video server A instructing it to put these changes to effect. The packet has the following format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Client Identifier: 32 bits This identifies the client, which is involved in the switching process. draft-rtp-vod-00.txt [Page 12]
INTERNET-DRAFT November 22, 2002 Stream Identifier: 32 bits The identifier of the stream that is being served by the video server to the indicated client. New Server Identifier: 32 bits The identifier (IP Address) of the new video server to which the client is expected to switch. SWITCH: This packet is sent by a video server to its client instructing it to initiate a switch from this server to another. In the case described above, video server A sends a SWITCH packet to its client instructing it to switch to video server B. The packet has the following format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Server Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Identifier: 32 bits The identifier of the stream being accessed by the client New Server Identifier: The identifier (IP Address) of the new server to which the client is expected to switch. 6. Appendix: 6.1 Parameters: These are parameters whose value cannot be estimated using formulae. These parameters depend on the VoD system nature and the human response to video. The following parameters fall into the category: 1.the time interval between the exchange of the information and response packet. This parameter depends on the nature of the VoD system. For systems where there are large number of clients and shorter video files, the time interval should be small, so that the video server loads are checked and distributed more frequently. For VoD systems where there are larger video files and smaller number of clients the interval can be made larger so that the distribution pattern can be revised less frequently. 2.The load difference between the video servers for a shift has to be draft-rtp-vod-00.txt [Page 13]
INTERNET-DRAFT November 22, 2002 performed. This is a very critical parameter. Let the load of server A be æLAÆ and that of server B be æLBÆ. Let æxÆ be shift in load from server A to server B. This shift is permitted only if, (LB + x) <= (LA û x) The above equation says that the shift is permitted only if the total load on server B after the shift is less that or equal to the load on the server A. But the equation if strictly followed does not always provide a significant improvement in the response time. 6.2 Load Calculations: Number of bytes transferred = æBTÆ Number of bytes left = æBLÆ Offset = æOFÆ File size = æFSÆ Video Server capacity = æCPÆ Video Server Capacity is one or more (e.g. processor speed) of the measure used to evaluate the capacity of a machine. BT = OF BL = FS û BT load due to a client/video pair = BL / CP load on a video server = (BL1/CP) + (BL2/CP) + àà. + (BLn/CP) 6.3 Algorithm for evaluating the distribution pattern: for all client/video æxÆ server by a VS æaÆ { for all VS æyÆ { if VS æyÆ has video file æxÆ { /* calculate load on video server æaÆ after the shift */ v1 = load of æaÆ û load due to file æxÆ /* calculate load on video server æyÆ after the shift */ v2 = load of æyÆ û load due to file æxÆ /* if the load on the new server is still less than that of the old server permit shift*/ if(v2 < v1) { send DEL packet to VS æaÆ with server identifier of VS æyÆ /* update load value in both the servers */ load of æaÆ = v1 load of æyÆ = v2 } draft-rtp-vod-00.txt [Page 14]
INTERNET-DRAFT November 22, 2002 } } } 6.4 Address of the Authors: Rahul Banerjee Professor, CS/IS Department, BITS,Pilani-333031 rahul@bits-pilani.ac.in Venkatesan V BITS, Pilani venkatesan796@yahoo.com Bharani M BITS, Pilani bharani.m@lycos.net Swaminathan P BITS, Pilani swami_1406@yahoo.co.uk Rajesh Kumar Reddy BITS, Pilani krk_rajesh@yahoo.com 7.Security Considerations: RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification, and any appropriate RTP profile. There is one more additional security factor that has to be taken care of. Any machine can send a command to the video server to transfer the control to a different one. There is no way in the method above to verify that the message is from the control server. To avoid this one possible solution is the ôcall backö mechanism where the video server on receiving a DEL packet sends a confirmation packet to the control server. If control server was the one which sent the DEL packet then it sends an acknowledgement and the video server responds to the DEL packet. Had the DEL packet been from some other machine, then the video server does not receive any acknowledgement. 8. Full Copyright Statement draft-rtp-vod-00.txt [Page 15]
INTERNET-DRAFT November 22, 2002 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 9.References: [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889. draft-rtp-vod-00.txt [Page 16]