[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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-15.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-15.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 SDPFrom ietf-announce-bounces at ietf.org Mon Jun 23 10:02:51 2008
Return-Path: <ietf-announce-bounces at ietf.org>
X-Original-To: ietf-announce-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id F241B3A69EA;
Mon, 23 Jun 2008 10:02:50 -0700 (PDT)
X-Original-To: ietf-announce at ietf.org
Delivered-To: ietf-announce at core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30)
id C30313A697D; Mon, 23 Jun 2008 10:02:48 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
Subject: Protocol Action: 'A general mechanism for RTP Header
Extensions' to Proposed Standard
Message-Id: <20080623170248.C30313A697D at core3.amsl.com>
Date: Mon, 23 Jun 2008 10:02:48 -0700 (PDT)
Cc: Internet Architecture Board <iab at iab.org>, avt mailing list <avt at ietf.org>,
avt chair <avt-chairs at tools.ietf.org>,
RFC Editor <rfc-editor at rfc-editor.org>
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces at ietf.org
Errors-To: ietf-announce-bounces at ietf.org
The IESG has approved the following document:
- 'A general mechanism for RTP Header Extensions '
<draft-ietf-avt-rtp-hdrext-15.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-15.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 contain containing it.
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
ing it.
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce