view Side-By-Side changes
MMUSIC WGO.Levin/RADVISIONLevin Internet Draft RADVISION Document: draft-levin-mmusic-xml-media-control-02 S.Olson/Microsoft draft-levin-mmusic-xml-media-control-01Olson Microsoft R.Even/Polycom P. Monfort/France TelecomEven Polycom Expires: September 2003MarchApril 2003 XML Schema for Media Controldraft-levin-mmusic-xml-media-control-01Status 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 inprogress".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 THISMEMO...................................................1 ABSTRACT..............................................................1 INTRODUCTION..........................................................3MEMO......................................................1 ABSTRACT...............................................................1 INTRODUCTION...........................................................3 BACKGROUND............................................................3 THE VIDEO CONTROLCOMMANDS............................................3COMMANDS..............................................3 THE SCHEMADEFINITION.................................................4DEFINITION....................................................4 ERRORHANDLING........................................................6 EXAMPLES..............................................................6HANDLING..........................................................5 EXAMPLES...............................................................6 THE SCHEMAAPPLICATIONS...............................................7APPLICATIONS..................................................7 CONVENTIONS USED IN THISDOCUMENT.....................................7DOCUMENT..........................................7 IANA CONSIDERATIONS......................................................7 APPLICATION/MEDIA_CONTROL+XML MIME TYPE.........................................8 URN FOR XML SCHEMA.......................................................9 SECURITYCONSIDERATIONS...............................................8CONSIDERATIONS.................................................10 AUTHOR'SADDRESSES....................................................8 REFERENCES............................................................8ADDRESSES......................................................10 REFERENCES............................................................10 Levin, et al. Expires:SeptemberMarch 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 conditionsregardless encoding scheme specifics.across different coding schemes. (Previously, a subset of this functionality was defined for H.261 [5] only). Theexistingabove mentioned techniques addressindicationsignaling of loss conditions and the recommended recoveryfrom detected loss conditions. This document introduces asteps. Currently, there is no standard way toperformexpress required operations on media streams as a result of applicationlogic. Any requested operationlogic rather then a result of loss conditions. Of course, each command SHALL be validated by the remote entity against current media capacity andknownnetwork conditions before beingperformed.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"ô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"ôInterö frames. Some CODECs (such as H.261 [2] and H.263 [3]), in addition to a"full"ôfullö picture, have a notion of picture slices: MB (Macro Block) and GOB (Group Of Blocks). Based ontheapplication logic (such as a presentation of a new video source), the application needs to havethean ability to explicitlyaskrequest from a remote encoderfor athe complete (in-time) information about a"full"ôfullö picture or a specific slice of the picture. Additionally,whenin 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 tosignalrequest the decoding side to freeze the picture, i.e. to stop presenting thechangeschanges, until a new stable image is encoded and transmitted.Levin, et al. Expires: September 2003 3 XML Schema for Media ControlIn order tomeetachieve these requirements, the following video primitives aredefined: -defined below: Video Picture FastUpdate. -Update Request Video GOB Fast Update Request (first_GOB,no_of_GOBs). -no_of_GOBs) Video MB Fast Update Request (first_GOB, first_MB,no_of_MBs).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 PictureFreeze.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" />Levin, et al. Expires: September 2003 4 XML Schema for Media Control<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> <!-- DecoderCommands:commands: Currently onlyPicture Freezepicture freeze is defined. --> <xsd:complexType name="to_decoder"> <xsd:sequence> <xsd:element name="picture_freeze" /> </xsd:sequence> </xsd:complexType> <!-- Encoder Commands: PictureFast Updaterequest Group of BlocksFast Updaterequest Macro BlockFast Updaterequest --> <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>Levin, et al. Expires: September 2003 5 XML Schema for Media ControlError 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"ôFreezeö and the full picture"Fast Update"ô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>Levin, et al. Expires: September 2003 6 XML Schema for Media ControlThe following example demonstrates the full format of the defined schema. The"Freeze"ôFreezeö command is issued towards the remote video decoder(s) to be applied to streams with"mid"ômidö [9] values"1"ô1ö and"2".ô2ö. The GOB"Fast Update"ôFast Updateö command is issued towards the remote video encoder to be applied to a video stream with"mid"ômidö value"3".ô3ö. Levin, et al. Expires: March 2003 6 XML Schema for Media Control <?xml version="1.0" encoding="utf-8" ?> <media_control> <vc_primitivestream="mid">stream=ômidö> <to_decoder > <picture_freeze> </picture_freeze> </to_decoder> <stream_id>1</stream_id> <stream_id>2</stream_id> </vc_primitive> <vc_primitivestream="mid">stream=ômidö> <to_encoder> <mb_fast_updatefirst_gob="2" first_mb="3" no_of_mbs="4">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"ôContent-Typeö set to"application/xml".ô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 documentLevin, et al. Expires: September 2003 7 XML Schema for Media ControlThe 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.ilPatrick Monfort France Telecom, R&D DMI/SGV 38-40 Av du Leclerc 92794 Issy Les Moulineaux Phone: +33-1-45-29-43-95 France Email: patrick.monfort@rd.francetelecom.comReferences 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ôThe SIP INFOMethod",Methodö, RFC2976, Internet Engineering Task Force, October 2000.Levin, et al. Expires: September 2003 8 XML Schema for Media Control9 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:SeptemberMarch 2003910 ----