Subject: RE: [AVT] General extensible RTP header extension mechanism

From: "Link, Brian" <[email-masked]>
Date: Wed, 29 Mar 2006 16:54:19 -0800

Sorry for chiming in so late on this question.

I think the answer is yes. This mechanism provides a good alternative to
the practice of burying associated metadata into the media format bit
stream. This has often been done in media data sent over fixed-bandwidth
channels. Once this is done, a decoder for the media format is required
to extract the metadata. Also, depending on the media format, the
metadata may need to be added at the time of encoding the media so that
the bit-rate required for the metadata is taken into account. But the
metadata may not be known at that time. Inserting metadata at a later
time can require a decode and re-encode to meet bit-rate requirements.

I appreciate the argument that in some cases a more appropriate, higher
level mechanism is available. When that is the best solution, it should
be used. For cases where a higher level mechanism isn't available, it is
better to provide a mechanism at the RTP level then leave developers to
shoe horn into even lower levels.

Regards,
Brian

> -----Original Message-----
> From: Dave Singer [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 4:45 PM
> To: [email-masked]
> Subject: [AVT] General extensible RTP header extension mechanism
> 
> It has been pointed out to me that we ought to discuss the question
> -- do we *want* to make it easy to use the header extension 
> mechanism in RTP, in general, non-colliding and yet 
> non-registering ways?  This draft permits that; is it desirable?
> 
> Obviously, I think so.  But other may differ.  Before the 
> chairs ask whether to move this along in Dallas, does anyone 
> else have an opinion?
> 
> 
> At 11:35  -0800 22/02/06, Dave Singer wrote:
> >This draft has no open questions and I hope I have dealt with the 
> >issues raised to date.  It's a general technique applicable 
> to any RTP 
> >stream, so it's worth a review from anyone using, or interested in, 
> >RTP.  We'd like to move this along, as the SMPTE time-codes 
> rely on it.
> >
> >
> >
> >At 18:50  -0500 9/02/06, [email-masked] wrote:
> >>A New Internet-Draft is available from the on-line Internet-Drafts 
> >>directories.
> >>This draft is a work item of the Audio/Video Transport Working 
> >>Group of the IETF.
> >>
> >>	Title		: A general mechanism for RTP Header Extensions
> >>	Author(s)	: D. Singer
> >>	Filename	: draft-ietf-avt-rtp-hdrext-01.txt
> >>	Pages		: 17
> >>	Date		: 2006-2-9
> >>
> >>This document provides a general mechanism to use the header-
> >>    extension feature of RTP (the Real Time 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 
> unregistered.
> >>    The actual extensions in use in a session are signaled 
> in the setup
> >>    information for that session.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-01.txt
> >
> >--
> >David Singer
> >Apple Computer/QuickTime
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> -- 
> David Singer
> Apple Computer/QuickTime
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you
are not the intended recipient, delete this message.  If you are
not the intended recipient, disclosing, copying, distributing, or
taking any action based on this message is strictly prohibited.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Mar 2006 13:16:22 +0100

Okay, we've had some discussion on the list and it seems there is  
general consensus that this approach is useful. It would perhaps be  
helpful if some of the discussion could be reflected in the draft as  
an extended applicability statement, to make the uses and non-uses of  
the extension explicit - Dave, can you try to draft something to  
expand section 3 of the draft?

Colin