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

From: Cullen Jennings <[email-masked]>
Date: Sat, 01 Apr 2006 10:01:44 -0800

Given the very few number of header extensions proposed, I don't know how
many people need this. Can people who have a application that would make use
of this and that would implement it let the chairs know that they need this?

On 3/30/06 4:16 AM, "Colin Perkins" <[email-masked]> wrote:

> 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
> 
> 
> 
> 
> On 30 Mar 2006, at 01:54, Link, Brian wrote:
>> 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
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

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