RFC 5168

XML Schema for Media Control

📅 published March 2008, from ietf

RFC 5168 💖 XML Schema for Media Control

Okay bestie, so this is RFC 5168 🎀, an XML Schema for media control that was written in March 2008 🌸. The authors are O. Levin from Microsoft Corporation, R. Even from Polycom, and P. Hagendorf from RADVISION ✨. It's Informational, which means it shares info with the Internet community and does not set an Internet standard 🦋. The title block doesn't list anything it obsoletes or updates, so it's standing on its own, no cap 💅.

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 🎀

Okay so this document defines an Extensible Markup Language (XML) Schema for video fast update 📸. It's for a tightly controlled environment and was developed by Microsoft, Polycom, and Radvision, and it's used by multiple vendors 🫶. It describes a method that's been deployed in Session Initiation Protocol (SIP) based systems for the last three years, and real-time interactive apps from different vendors use it in an interoperable way 🔥. Here's the tea: new implementations are discouraged from using this method, except for backward compatibility purposes 🙈. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel 👑.

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 XML Schema for video fast update requests in a tightly controlled environment 🎬, developed by Microsoft, Polycom, and Radvision and used by multiple vendors. Using this schema for interactive video apps in SIP [5] environments was designed to improve user experience 💖. It's 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 it, 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 over the SIP signaling path, the way this document describes, is inferior to using the RTP Control Protocol (RTCP) feedback method [7] 😬. Why? The command flows through all the proxies in the signaling path, which adds delay to the messages and causes unnecessary overload on the proxies 💀. RTCP messages flow end-to-end and don't go through the signaling proxies 🦋. The RTCP feedback document [7] also adds other required control functions, like 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] 📚.

3. Background 🌸

SIP typically uses the Real-time Transport Protocol (RTP) [6] for transferring real-time media 🎥.

RTP is augmented by a control protocol (RTCP) so you can monitor data delivery in a way that scales to large multicast networks 📡. The RTCP feedback mechanism [8] was introduced to improve basic RTCP feedback time when loss happens across different coding schemes 🛠️. This technique covers signaling loss conditions and the recommended recovery steps 💜.

Just recently, an extension to the feedback mechanism was proposed [7] to express control operations on media streams that come from application logic, rather than from loss conditions 🧚. Note that in decomposed systems, the new mechanism will require proprietary communications between the applications/call control components and the media components 🙈.

This document describes a technology that's been deployed in SIP-based systems for the last three years and is being used across real-time interactive apps from different vendors in an interoperable manner 💅. This memo documents this technology to describe current practice, and new implementations MUST use the RTCP Full Intra Request command specified in the RTCP-based codec control messages document[7] 👑.

4. The Video Control Commands 💅

Okay so the output of a video codec is a frame 🎞️. A frame can carry complete information about a picture or about a picture segment, and these are known as "Intra" frames ✨. To save bandwidth, other frames can carry only changes relative to previously sent frames, and those are known as "Inter" frames 🦋.

Based on application logic (like needing to present a new video source), the application needs the ability to explicitly request the complete information about a "full" picture from a remote encoder 🎬.

An "Intra" frame may be quite large 😳. To avoid causing network congestion, the current media capacity and network conditions MUST be validated before sending an "Intra" frame when receiving a fast update command, as defined in this document 🚦.

To meet the requirements above, this document defines a video primitive 🌈.

The following command is sent to the remote encoder:

  • Video Picture Fast Update

5. The Schema Definition 🧚

Here's the schema, verbatim, bestie 📜:

   <?xml version="1.0" encoding="utf-8" ?>

   <xs:schema id="TightMediaControl"
    elementFormDefault="qualified"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">

           <xs:element name="media_control">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="vc_primitive"
                                           type="vc_primitive"
                                           minOccurs="0"
                                           maxOccurs="unbounded" />
                     <xs:element name="general_error"
                                           type="xs:string"
                                           minOccurs="0"
                                           maxOccurs="unbounded" />
                  </xs:sequence>
               </xs:complexType>
           </xs:element>

           <!-- Video control primitive.  -->

           <xs:complexType name="vc_primitive">
                   <xs:sequence>
                     <xs:element name="to_encoder" type="to_encoder" />
                      <xs:element name="stream_id"
                                       type="xs:string"
                                       minOccurs="0"
                                       maxOccurs="unbounded" />
                           </xs:sequence>
           </xs:complexType>

           <!-- Encoder Command:
                Picture Fast Update
           -->

           <xs:complexType name="to_encoder">
                   <xs:choice>
                           <xs:element name="picture_fast_update"/>
                   </xs:choice>
           </xs:complexType>

   </xs:schema>

6. Error Handling 🙈

Currently, only a single general error primitive is defined 🫧. It MAY be used for indicating errors in free-text format. The general error primitive MAY report problems about XML document parsing, an inadequate level of media control support, an inability to perform the requested action, etc. 🧾

The general error primitive MUST NOT be used for indicating errors other than those related to media control parsing or to resultant execution. The general error primitive MUST NOT be sent back as a result of getting an error primitive. Not me sending errors about errors 💀.

When receiving the general error response, the user agent client (UAC) that sent the request SHOULD NOT send further fast update requests in the current dialog 🛑.

According to RFC 2976 [3], the only allowable final response to a SIP INFO containing a message body is a 200 OK 🎀. If SIP INFO is used to carry the request, the error message should be carried in a separate INFO request 💌.

10. Security Considerations ✨

okay, this section is where we get a little dramatic, bestie 😭 the video control command from this doc can make the video sender push more data within the allowed bandwidth (see Section 4). so like, it's giving power, and power needs boundaries 💅

this doc only defines one control message 🎀 if anyone changes the content of that message, the video sender will ignore the request and send an error response. and that can totally mean no video stream showing up on screen 💀 the control message itself doesn't carry anything sensitive though, so no secrets are getting leaked here 🫶

an eavesdropper could inject messages or change them 👀 which could mean extra data floating around the network, or the video image just... disappearing. the fix is data integrity validation, which stops anyone from sneaking in or editing messages. iconic behavior from the security team 👑

if the video media goes over a secure transport, it's recommended to secure the signaling with TLS, as explained in [5] 🔐 and honestly, in most cases securing the media means you need a secure signaling path too. you can't really lock one door and leave the other wide open 🚪✨

the security considerations of [3] and [5] also apply here 🧚 so go check those out too, periodt.

11. References

11.1. Normative References

  • [1] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
  • [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [5] 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.
  • [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
  • [7] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.

11.2. Informative References

  • [8] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.

Authors' Addresses 🎀

these are the lovely people who wrote this 🫶

Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA

EMail: oritl@microsoft.com


Roni Even
Polycom
94 Derech Em Hamoshavot
Petach Tikva,   49130
Israel

EMail: roni.even@polycom.co.il


Pierre Hagendorf
RADVISION
24, Raul Wallenberg St.
Tel-Aviv,   69719
Israel

EMail: pierre@radvision.com

Copyright (C) The IETF Trust (2008).

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.

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.

Intellectual Property 🌈

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.

📦 where this page comes from