idnits 2.17.1 draft-levin-mmusic-xml-media-control-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 7, 2008) is 5916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2976 (ref. '3') (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC O. Levin 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational R. Even 5 Expires: August 10, 2008 Polycom 6 P. Hagendorf 7 RADVISION 8 February 7, 2008 10 XML Schema for Media Control 11 draft-levin-mmusic-xml-media-control-13 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document defines an Extensible Markup Language (XML) Schema for 45 video fast update in a tightly controlled environment, developed by 46 Microsoft, Polycom, Radvision and used by multiple vendors. This 47 document describes a method that has been deployed in Session 48 Initiation Protocol (SIP) based systems for over the last three years 49 and being used across real-time interactive applications from 50 different vendors in interoperable manner. New implementations are 51 discouraged from using the described method described except for 52 backward compatibility purposes. New Implementations are required to 53 use the new full intra request command in the RTP Control Protocol 54 (RTCP) channel. 56 Table of Contents 58 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. The Video Control Commands . . . . . . . . . . . . . . . . . . 4 62 5. The Schema Definition . . . . . . . . . . . . . . . . . . . . 5 63 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. The Fast Update command for the full picture . . . . . . . 6 66 7.2. Reporting an error . . . . . . . . . . . . . . . . . . . . 6 67 8. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9.1. Application/media_control+xml media type registration . . 7 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 11. Version History . . . . . . . . . . . . . . . . . . . . . . . 8 72 11.1. Changes since -04 . . . . . . . . . . . . . . . . . . . . 8 73 11.2. Changes since -03 . . . . . . . . . . . . . . . . . . . . 9 74 11.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 9 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 Intellectual Property and Copyright Statements . . . . . . . . . . 11 81 1. Conventions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119 [2]. 87 2. Introduction 89 This document defines an Extensible Markup Language (XML) Schema for 90 video fast update request in a tightly controlled environment, 91 developed by Microsoft, Polycom, Radvision and used by multiple 92 vendors. Implementation of this schema for interactive video 93 applications in Session Initiation Protocol (SIP) [5] environments 94 was designed in order to improve user experience. This mechanism is 95 being used by both end user video conferencing terminals and 96 conferencing servers in shipping products. This document describes 97 the current method, but new implementations are discouraged from 98 using this method, except for backward compatibility with legacy 99 systems. Shipping products and new products SHOULD use the full 100 intra request described in [7]. 102 Sending video fast update using the SIP signaling path, as described 103 in this document, is inferior to using the RTP Control Protocol 104 (RTCP) feedback method[7], since the command flows through all the 105 proxies in the signaling path adding delay to the messages and 106 causing unnecessary overload to the proxies. RTCP messages flow end 107 to end and not through the signaling proxies. The RTCP feedback 108 draft[7] also adds other required control functions, such as flow 109 control command which is missing from this document. 111 3. Background 113 SIP typically uses the Real-time Transport Protocol (RTP) [6] for 114 transferring of real time media. 116 RTP is augmented by a control protocol (RTCP) to allow monitoring of 117 the data delivery in a manner scalable to large multicast networks. 118 The RTCP feedback mechanism [8] has been introduced in order to 119 improve basic RTCP feedback time in case of loss conditions across 120 different coding schemes. This technique addresses signaling of loss 121 conditions and the recommended recovery steps. 123 Just recently an extension to the feedback mechanism has been 124 proposed [7] to express control operations on media streams as a 125 result of application logic rather than a result of loss conditions. 126 Note that in the decomposed systems the implementation of the new 127 mechanism will require proprietary communications between the 128 applications/call control components and the media components. 130 This document describes a technology that has been deployed in SIP 131 based systems for over the last three years and being used across 132 real-time interactive applications from different vendors in 133 interoperable manner. This memo documents this technology for the 134 purpose of describing current practice and new implementation MUST 135 use the RTCP full intra request command specified in the RTCP based 136 codec control messages document[7]. 138 4. The Video Control Commands 140 Output of a video codec is a frame. The frame can carry complete 141 information about a picture or about a picture segment. These frames 142 are known as "Intra" frames. In order to save bandwidth, other 143 frames can carry only changes relative to previously sent frames. 144 Frames carrying relative information are known as "Inter" frames. 146 Based on application logic (such as need to present a new video 147 source), the application needs to have an ability to explicitly 148 request from a remote encoder the complete information about a "full" 149 picture. 151 An "intra" frame may be of large size. In order to prevent causing 152 network congestion, the current media capacity and network conditions 153 MUST be validated before sending an "intra" frame when receiving a 154 fast update command, defined in this document. 156 In order to meet the presented requirements, a video primitive is 157 defined by this document. 159 The following command is sent to the remote encoder: 161 o Video Picture Fast Update 163 5. The Schema Definition 165 167 171 172 173 174 178 182 183 184 186 188 189 190 191 195 196 198 202 203 204 205 206 207 209 6. Error Handling 211 Currently, only a single general error primitive is defined. It MAY 212 be used for indicating errors in free text format. The general error 213 primitive MAY report problems regarding XML document parsing, 214 inadequate level of media control support, inability to perform the 215 requested action, etc. 217 The general error primitive MUST NOT be used for indication of errors 218 other than related to media control parsing or to resultant 219 execution. The general error primitive MUST NOT be sent back as a 220 result of getting an error primitive. 222 When receiving the general error response, the user agent client 223 (UAC) that sent the request SHOULD NOT send further fast update 224 requests in the current dialog. 226 According to RFC 2976 [3], the only allowable final response to a SIP 227 INFO containing a message body is a 200 OK. If SIP INFO is used to 228 carry the request, the error message should be carried in a separate 229 INFO request. 231 7. Examples 233 7.1. The Fast Update command for the full picture 235 In the following example the full picture "Fast Update" command is 236 issued towards the remote video decoder(s). 238 240 242 243 244 245 246 248 250 7.2. Reporting an error 252 If an error occurs during the parsing of the XML document, the 253 following XML document would be sent back to the originator of the 254 original Media Control document. 256 258 260 261 Parsing error: The original XML segment is:... 262 264 266 8. Transport 268 The defined XML document is conveyed using SIP INFO method [3] with 269 the "Content-Type" set to "application/media_control+xml". This 270 approach benefits from the SIP built-in reliability. 272 9. IANA Considerations 274 This document registers a new media type. 276 9.1. Application/media_control+xml media type registration 278 Type name: application 279 Subtype name: media_control+xml 280 Required parameters: None 281 Optional parameters: charset 283 Indicates the character encoding of enclosed XML. 285 Encoding considerations: 8bit 286 Uses XML, which can employ 8-bit characters, depending on the 287 character encoding used. See RFC 3023 [4], Section 3.2. 288 Security considerations: Security considerations specific to uses 289 of this type are discussed in RFC xxxx [[Note to RFC editor: 290 replace xxxx with the RFC number of this document when 291 published]]. RFC 1874 [1] and RFC 3023 [4] discuss security 292 issues common to all uses of XML. 293 Interoperability considerations: None. 294 Published specification: RFC xxxx [[Note to RFC editor: replace 295 xxxx with the RFC number of this document when published]] 296 Applications that use this media type: This media type is used to 297 convey information regarding media control commands and responses 298 between SIP endpoints particularly for allowing a Video Fast 299 Update intra-frame request. 301 Additional information: 303 Magic Number(s): None. 304 File Extension(s): None. 305 Macintosh File Type Code(s): None. 307 Person and email address to contact for further information: 309 Name: Roni Even 310 E-Mail: even.roni@gmail.com 312 Intended usage: LIMITED USE 314 Restrictions on usage: None. 316 Author: Roni Even. 318 Change Controller: Roni Even. 320 10. Security Considerations 322 The video control command transported using the method described in 323 the document may cause the sender of the video data to send more data 324 within the allowed bandwidth as described in section 4. 326 The document defines one control message; changing the content of the 327 message will cause the video sender to ignore the request and send an 328 error response. This may prevent the display of a video stream. The 329 control message itself does not carry any sensitive information. 331 An eavesdropper may inject messages or change them which may lead to 332 either more data on the network or loss of video image. Using data 333 integrity validation will prevent adding or changing of messages. 335 If the video media is sent over a secure transport it is recommended 336 to secure the signaling using TLS as explained in [5]. In most cases 337 securing the media will require a secure signaling path. 339 Security considerations of [3] and [5] apply here. 341 11. Version History 343 11.1. Changes since -04 345 This version defines only the picture fast update command since the 346 rest of the commands are not use by shipping products. The document 347 now states that RTCP feedback is to be used in new implementations. 349 11.2. Changes since -03 351 This version reflects the deployment experience since the defined 352 mechanism has been implemented and tested among the vendors 353 represented by the authors of this document. 355 The XML schema is identical to version -03. 357 11.3. Changes since -02 359 This version contains editorial changes only. 361 The XML schema is identical to version -02. 363 12. References 365 12.1. Normative References 367 [1] Levinson, E., "SGML Media Types", RFC 1874, December 1995. 369 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 370 Levels", BCP 14, RFC 2119, March 1997. 372 [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 374 [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 375 RFC 3023, January 2001. 377 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 378 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 379 Session Initiation Protocol", RFC 3261, June 2002. 381 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 382 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 383 RFC 3550, July 2003. 385 [7] Wenger, S., "Codec Control Messages in the RTP Audio-Visual 386 Profile with Feedback (AVPF)", draft-ietf-avt-avpf-ccm-10 (work 387 in progress), December 2006. 389 12.2. Informative References 391 [8] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 392 "Extended RTP Profile for Real-time Transport Control Protocol 393 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 395 Authors' Addresses 397 Orit Levin 398 Microsoft Corporation 399 One Microsoft Way 400 Redmond, WA 98052 401 USA 403 Email: oritl@microsoft.com 405 Roni Even 406 Polycom 407 94 Derech Em Hamoshavot 408 Petach Tikva, 49130 409 Israel 411 Email: roni.even@polycom.co.il 413 Pierre Hagendorf 414 RADVISION 415 24, Raul Wallenberg St. 416 Tel-Aviv, 69719 417 Israel 419 Email: pierre@radvision.com 421 Full Copyright Statement 423 Copyright (C) The IETF Trust (2008). 425 This document is subject to the rights, licenses and restrictions 426 contained in BCP 78, and except as set forth therein, the authors 427 retain all their rights. 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 432 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 433 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 434 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Intellectual Property 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Acknowledgment 463 Funding for the RFC Editor function is provided by the IETF 464 Administrative Support Activity (IASA).