XML Schema for Media Control
RFC 5168
Document | Type |
RFC - Informational
(March 2008; No errata)
Was draft-levin-mmusic-xml-media-control (individual in rai area)
|
|
---|---|---|---|
Authors | Pierre Hagendorf , Orit Levin , Roni Even | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5168 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | (None) |
Network Working Group O. Levin Request for Comments: 5168 Microsoft Corporation Category: Informational R. Even Polycom P. Hagendorf RADVISION March 2008 XML Schema for Media Control Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. Levin, et al. Informational [Page 1] RFC 5168 Media Control March 2008 Table of Contents 1. Introduction ....................................................2 2. Conventions .....................................................2 3. Background ......................................................3 4. The Video Control Commands ......................................3 5. The Schema Definition ...........................................4 6. Error Handling ..................................................5 7. Examples ........................................................5 7.1. The Fast Update Command for the Full Picture ...............5 7.2. Reporting an Error .........................................5 8. Transport .......................................................6 9. IANA Considerations .............................................6 9.1. Application/media_control+xml Media Type Registration ......6 10. Security Considerations ........................................7 11. References .....................................................8 11.1. Normative References ......................................8 11.2. Informative References ....................................8 1. Introduction This document defines an Extensible Markup Language (XML) Schema for video fast update request in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. Implementation of this schema for interactive video applications in Session Initiation Protocol (SIP) [5] environments was designed in order to improve user experience. This mechanism is being used by both end user video conferencing terminals and conferencing servers in shipping products. This document describes the current method, but new implementations are discouraged from using this method, except for backward compatibility with legacy systems. Shipping products and new products SHOULD use the Full Intra Request, described in [7]. Sending video fast update using the SIP signaling path, as described in this document, is inferior to using the RTP Control Protocol (RTCP) feedback method [7], since the command flows through all the proxies in the signaling path adding delay to the messages and causing unnecessary overload to the proxies. RTCP messages flow end-to-end and not through the signaling proxies. The RTCP feedback document [7] also adds other required control functions, such as the flow control command, which is missing from this document. 2. Conventions 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 [2]. Levin, et al. Informational [Page 2] RFC 5168 Media Control March 2008 3. Background SIP typically uses the Real-time Transport Protocol (RTP) [6] for the transferring of real-time media. RTP is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks. The RTCP feedback mechanism [8] has been introduced in order to improve basic RTCP feedback time in case of loss conditions across different coding schemes. This technique addresses signaling of lossShow full document text