A General Mechanism for RTP Header Extensions
RFC 5285

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    avt mailing list <avt@ietf.org>, 
    avt chair <avt-chairs@tools.ietf.org>
Subject: Protocol Action: 'A General Mechanism for RTP Header 
         Extensions' to Proposed Standard 

The IESG has approved the following document:

- 'A General Mechanism for RTP Header Extensions '
   <draft-ietf-avt-rtp-hdrext-16.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-16.txt

Technical Summary

    This document provides a general mechanism to use the header-
    extension feature of RTP (the Real Time Transport Protocol).  It
    provides the option to use a small number of small extensions in each
    RTP packet, where the universe of possible extensions is large and
    registration is de-centralized.  The actual extensions in use in a
    session are signaled in the setup information for that session.

Working Group Summary

    This document is a product of the AVT Working Group. While this
document was in progress, concerns were raised about the potential impact
of making RTP header extensions easier to specify on the RTP architecture
and on interoperability. The issue was debated at IETF 66 without coming
to a definite conclusion. RTP profiles are an alternative to header
extensions, but present significant problems of signalling which are just
beginning to be resolved. By the time WGLC came, the AVT WG consensus was
to accept the header extension mechanism provided in this document. To
mitigate the risk of interoperability problems, the document specifies
normatively that the information carried in RTP header extensions defined
according to this document MUST be such that a receiver can safely ignore
this information and still be able to process the payload content.

Document Quality

    This document has been in progress since June, 2005. Colin Perkins
suggested useful changes at multiple stages. Dave Oran performed a final
review which identified some technical points which were quickly resolved.
Two extensions are currently being defined based on the proposed
mechanism, and others are under consideration. Interest in implementations
is beginning to appear.

Personnel

  The Document Shepherd is Tom Taylor

Note to RFC Editor
 
Remove the sentence that says:
   In general, the URI SHOULD also be de-referencable by any system that
   sees or receives the SDP containing it.