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).