A General Mechanism for RTP Header Extensions
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, avt mailing list <email@example.com>, avt chair <firstname.lastname@example.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.