[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5168

                                                               O. Levin
   Internet Draft                                             RADVISION
   Document: draft-levin-mmusic-xml-media-control-02           S. Olson
                                                              Microsoft
                                                                R. Even
                                                                Polycom
   Expires: September 2003                                   April 2003


                       XML Schema for Media Control


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 document defines an XML Schema for Media Control in a tightly
   controlled environment. The current version includes commands for
   managing of video streams only. Implementation of this schema for
   interactive video applications in SIP environments significantly
   improves user experience.














   Levin, et al.       Expires: September 2003                      1
                       XML Schema for Media Control




Table of Contents

STATUS OF THIS MEMO......................................................1

ABSTRACT...............................................................1

INTRODUCTION...........................................................3

BACKGROUND............................................................3

THE VIDEO CONTROL COMMANDS..............................................3

THE SCHEMA DEFINITION....................................................4

ERROR HANDLING..........................................................5

EXAMPLES...............................................................6

THE SCHEMA APPLICATIONS..................................................7

CONVENTIONS USED IN THIS DOCUMENT..........................................7

IANA CONSIDERATIONS......................................................7
 APPLICATION/MEDIA_CONTROL+XML MIME TYPE.........................................8
 URN FOR XML SCHEMA.......................................................9
SECURITY CONSIDERATIONS.................................................10

AUTHOR'S ADDRESSES......................................................10

REFERENCES............................................................10





















   Levin, et al.         Expires: March 2003                        2
                       XML Schema for Media Control

Introduction
   This document defines an XML Schema for Media Control in a tightly
   controlled environment. The current version includes commands for
   managing of video streams only. Implementation of this schema for
   interactive video applications in SIP [7] environments significantly
   improves user experience. Both end users and conferencing servers
   SHOULD implement this approach.

Background
   SIP typically uses RTP [6] for 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.
   An RTCP feedback mechanism [4] has been introduced in order to
   improve basic RTCP feedback time in case of loss conditions across
   different coding schemes. (Previously, a subset of this
   functionality was defined for H.261 [5] only).
   The above mentioned techniques address signaling of loss conditions
   and the recommended recovery steps. Currently, there is no standard
   way to express required operations on media streams as a result of
   application logic rather then a result of loss conditions.
   Of course, each command SHALL be validated by the remote entity
   against current media capacity and network conditions before being
   executed.

The Video Control Commands
   Output of a video CODEC is a frame. The frame can carry complete (in
   time) information about a picture or about a picture segment. These
   frames are known as ôIntraö frames. In order to save bandwidth,
   other frames can carry only changes relative to previously sent
   frames. Frames carrying relative information are known as ôInterö
   frames.

   Some CODECs (such as H.261 [2] and H.263 [3]), in addition to a
   ôfullö picture, have a notion of picture slices:  MB (Macro Block)
   and GOB (Group Of Blocks).

   Based on application logic (such as a presentation of a new video
   source), the application needs to have an ability to explicitly
   request from a remote encoder the complete (in-time) information
   about a ôfullö picture or a specific slice of the picture.

   Additionally, in case the encoder is aware of upcoming changes in
   the transmitted stream (that would result in synchronization lost by
   the decoder), the encoder needs to be able to request the decoding
   side to freeze the picture, i.e. to stop presenting the changes,
   until a new stable image is encoded and transmitted.

   In order to achieve these requirements, the following video
   primitives are defined below:

   Video Picture Fast Update Request
   Video GOB Fast Update Request (first_GOB, no_of_GOBs)
   Video MB Fast Update Request (first_GOB, first_MB, no_of_MBs)
   These commands are to be sent to a remote encoder.

   Levin, et al.         Expires: March 2003                        3
                       XML Schema for Media Control


   Video Picture Freeze Request
   This command is to be sent to a remote decoder.

The Schema Definition

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

   <xsd:schema id="TightMediaControl"
   targetNamespace="urn:ietf:params:xml:ns:media_control"
   elementFormDefault="qualified" xmlns="
   urn:ietf:params:xml:ns:media_control"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

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

        <!-- Video control primitive. Each primitive is directed either
   to a remote encode or to a remote decoder. -->
        <xsd:complexType name="vc_primitive">
           <xsd:sequence>
              <xsd:choice>
                  <xsd:element name="to_encoder" type="to_encoder" />
                  <xsd:element name="to_decoder" type="to_decoder" />
              </xsd:choice>
              <xsd:element name="stream_id" type="xsd:string"
   minOccurs="0" maxOccurs="unbounded" />
           </xsd:sequence>
           <xsd:attribute name="type" type="primitive_type"
   use="optional" default="cmd" />
           <xsd:attribute name="stream" type="stream_type"
   use="optional" default="all" />
        </xsd:complexType>

        <xsd:simpleType name="primitive_type">
                <xsd:restriction base="xsd:string">
                        <xsd:enumeration value="cmd" />
                        <xsd:enumeration value="ind" />
                        <xsd:enumeration value="req" />
                        <xsd:enumeration value="rsp" />
                </xsd:restriction>
        </xsd:simpleType>

        <xsd:simpleType name="stream_type">
                <xsd:restriction base="xsd:string">
                        <xsd:enumeration value="mid" />

   Levin, et al.         Expires: March 2003                        4
                       XML Schema for Media Control

                        <xsd:enumeration value="all" />
                </xsd:restriction>
        </xsd:simpleType>

        <!-- Decoder commands:
             Currently only picture freeze is defined.
        -->
        <xsd:complexType name="to_decoder">
           <xsd:sequence>
              <xsd:element name="picture_freeze" />
           </xsd:sequence>
        </xsd:complexType>


        <!-- Encoder Commands:
             Picture request
             Group of Blocks request
             Macro Block request
        -->


        <xsd:complexType name="to_encoder">
            <xsd:choice>
                <xsd:element name="picture_fast_update" />
                <xsd:element name="gob_fast_update">
                    <xsd:complexType>
                        <xsd:attribute name="first_gob"
   type="xsd:nonNegativeInteger" use="optional" default="0" />
                        <xsd:attribute name="no_of_gobs"
   type="xsd:nonNegativeInteger" use="optional" default="1" />
                    </xsd:complexType>
                </xsd:element>
                <xsd:element name="mb_fast_update">
                   <xsd:complexType>
                       <xsd:attribute name="first_gob"
   type="xsd:nonNegativeInteger" use="optional" default="0" />
                           <xsd:attribute name="first_mb"
   type="xsd:nonNegativeInteger" use="optional" default="1" />
                       <xsd:attribute name="no_of_mbs"
   type="xsd:nonNegativeInteger" use="optional" default="1" />
                   </xsd:complexType>
                </xsd:element>
            </xsd:choice>
        </xsd:complexType>

   </xsd:schema>

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


   Levin, et al.         Expires: March 2003                        5
                       XML Schema for Media Control

   The error primitive MUST NOT be used for indication of errors other
   then related to the media control parsing and the resultant
   execution.
   The error primitive MUST NOT be sent back as a result of getting an
   error primitive.

Examples

   In the following example the ôFreezeö and the full picture ôFast
   Updateö commands are issued towards the remote video decoder(s) and
   remote video encoder(s) respectively for all video streams.

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

   <media_control>

     <vc_primitive>
       <to_decoder>
         <picture_freeze>
         </picture_freeze>
       </to_decoder>
     </vc_primitive>

     <vc_primitive>
       <to_encoder>
         <picture_fast_update>
         </picture_fast_update>
       </to_encoder>
     </vc_primitive>

   </media_control>

   If an error occurs during the parsing of the XML document, the
   following XML document would be sent back to the originator of the
   original Media Control document.

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

   <media_control>

     <general_error>
      Parsing error: The original XML segment is:...
     </general_error>

   </media_control>


   The following example demonstrates the full format of the defined
   schema. The ôFreezeö command is issued towards the remote video
   decoder(s) to be applied to streams with ômidö [9] values ô1ö and
   ô2ö.  The GOB ôFast Updateö command is issued towards the remote
   video encoder to be applied to a video stream with ômidö value ô3ö.



   Levin, et al.         Expires: March 2003                        6
                       XML Schema for Media Control

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

   <media_control>

     <vc_primitive stream=ômidö>
       <to_decoder >
         <picture_freeze>
         </picture_freeze>
       </to_decoder>

       <stream_id>1</stream_id>
       <stream_id>2</stream_id>

     </vc_primitive>

     <vc_primitive stream=ômidö>
       <to_encoder>
         <mb_fast_update first_gob=ô2ö first_mb=ô3ö no_of_mbs=ô4ö>
         </mb_fast_update>
       </to_encoder>

       <stream_id>3</stream_id>

     </vc_primitive>

   </media_control>

The Schema Applications

   As the first step, the defined XML document will be conveyed using a
   SIP INFO method [8] with the ôContent-Typeö set to
   ôapplication/media_control+xmlö. This approach benefits from the SIP
   built-in reliability.

   The authors plan registering the defined schema with IANA according
   to the guidelines specified in [10] and issuing a separate SIPPING
   usage document(s). The document(s) will describe procedures for
   conveying an XML document defined according to the Schema by means
   of SIP INFO and SIP NOTIFY.

   The authors hope that the XML schema, documented in this document,
   will provide a base for a standard Tight Media Control protocol
   definition within the IETF. It is expected that in future SIP will
   define standard means for running this protocol as a part of SIP
   architecture.

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 [1].

IANA Considerations


   Levin, et al.         Expires: March 2003                        7
                       XML Schema for Media Control

Application/media_control+xml MIME type

      MIME Media Type Name: application

      MIME subtype name: media_control+xml

      Required parameters: None

      Optional parameters: charset

        See RFC 3023 [10] for a discussion of the charset parameter on
        XML-derived MIME types.  Since this MIME type is used
        exclusively in SIP, the use of UTF-8 encoding is strongly
        encouraged.

      Encoding considerations: 8-bit text

      Security considerations:

        Security considerations specific to uses of this this MIME type
        are discussed in RFC xxxx [[Note to RFC editor: replace xxxx
        with the RFC number of this document when published]].  RFC
        1874 [9] and RFC 3023 [10] discuss security issues common to
        all uses of XML.

      Interoperability considerations:

        The use of this MIME body is intended to be generally
        interoperable.  No unique considerations have been identified.

      Published specification: RFC xxxx [[Note to RFC editor: replace
   xxxx with the RFC number of this document when published]]

      Applications which use this media type:

        This media type is used to convey information regarding media
        control commands and responses between SIP endpoints
        particularly for allowing a Video Fast Update intra-frame
        request.

      Additional information:

         Magic Number(s): None.

         File Extension(s): None.

         Macintosh File Type Code(s): None.

         Object Identifier(s) or OID(s): None.

      Intended usage: Limited Use

      Other Information/General Comment: None.


   Levin, et al.         Expires: March 2003                        8
                       XML Schema for Media Control

      Person to contact for further information:

         Name: Sean Olson

         E-Mail: seanol@microsoft.com

         Author/Change Controller:

        The specification of this MIME type is an individual submission
        to the MMUSIC working group of the IETF. Change control of this
        specification is under control of the IETF WG.


URN for XML schema

      URI: urn:ietf:params:xml:ns:media_control

      Description:

      This is the XML namespace URI for XML elements defined by
      [RFCXXXX] to describe information exchanged between SIP endpoints
      for media control. It is used in the
      application/media_control+xml body type.

      Registrant Contact:

         Name: Sean Olson

         E-Mail: seanol@microsoft.com

         Author/Change Controller:

        The specification of this URN sub-namespace is an individual
        submission to the MMUSIC working group of the IETF. Change
        control of this specification is under control of the IETF WG.

      XML:

            BEGIN
              <?xml version="1.0"?>
              <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                        "http://www.w3.org/TR/xhtml-basic/xhtml-
   basic10.dtd">
              <html xmlns="http://www.w3.org/1999/xhtml">
              <head>
                <meta http-equiv="content-type"
                   content="text/html;charset=utf-8"/>
                <title>Namespace for Tight Media Control</title>
              </head>
              <body>
                <h1>Namespace for Tight Media Control</h1>
                <h2>application/media_control+xml</h2>
                <p>See <a href="[[[URL of published
   RFC]]]">RFCXXXX</a>.</p>

   Levin, et al.         Expires: March 2003                        9
                       XML Schema for Media Control

              </body>
              </html>
            END

Security Considerations

   This document doesnÆt introduce new security requirements beyond
   covered in [7].

Author's Addresses

   Orit Levin
   RADVISION
   266 Harristown Road          Phone:  +1-201-689-6330
   Glen Rock, NJ USA            Email:  orit@radvision.com

   Sean Olson
   Microsoft Corporation
   One Microsoft Way            Phone:  +1-425-707-2846
   Redmond, WA USA              Email:  seanol@microsoft.com

   Roni Even
   Polycom
   94 Derech Em Hamoshavot       Phone:  +972-3-9251200
   Petach Tikva, Israel          Email:  roni.even@polycom.co.il

References

   1  RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.
   2  ITU-T Recommendation H.261 (1993), Video codec for audiovisual
      services at p . 64 kbit/s.
   3  ITU-T Recommendation H.263 (1998), Video coding for low bit rate
      communication.
   4  J. Ott et al., ôExtended RTP Profile for RTCP-based Feedback
      (RTP/AVPF)ö, draft-ietf-avt-rtcp-feedback-03.txt, June 2002, IETF
      Draft. Work in progress.
   5  T. Turletti and C. Huitema, "RTP Payload Format for H.261 Video
      Streams, RFC 2032, October 1996.
   6  H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
      A Transport Protocol for Real-time Applications", Internet Draft,
      draft-ietf-avt-rtp-new-11.txt, Work in Progress, November 2001.
   7  J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
      protocol," RFC 3261, Internet Engineering Task Force, June 2002.
   8 S. Donovan, ôThe SIP INFO Methodö, RFC2976, Internet Engineering
     Task Force, October 2000.
   9 Camarillo/Holler/Eriksson/Schulzrinne, "Grouping of m lines in
     SDP", draft-ietf-mmusic-fid-06.txt, Feb 2002, IETF Draft. Proposed
     Standard.
   10 M. Mealling, "The IETF XML Registry", draft-mealling-iana-xmlns-
     registry-04.txt, June 2002, IETF draft. Work in progress.




   Levin, et al.         Expires: March 2003                       10


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/