[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-01.txt

At 21:31 -0600 2/03/06, Alan Johnston wrote: 
Hi Dave,

One question I had that this draft didn't seem to address is why creating a simple IANA registry of RTP header extension values would not solve this problem. Is it concern that the 16 bit address space would somehow not be large enough?

Thanks,
Alan


My sense is that there is a spectrum of use of extensions that may occur here:

* globally documented and applicable to any RTP stream, in theory. Examples are the two I have shown so far (transmission time, and SMPTE time-code). Document these at the IETF and register with IANA.

* industry/domain-specific techniques. It's possible, for example, that the use of RTP on say, some kinds of cellular networks, might benefit from a header extension mostly applicable to that domain. Document it under a suitable doamin name (e.g. org.3gpp or 3gpp2), and use it there. That's under the management of those domains and their specs.

* experiments or vendor-specific stuff. document that under your vendor name, and use it there. At least people will be able to ask "why is there all this com.apple.quicktime.advertising extension stuff all over the streams I see?" (for example).


Now, we could indeed achieve the first by simply documenting how to register an extension type, but my sense is that we may learn quite a bit by making the second two possible. I may be wrong.

Also, the given design attempts to be space-efficient (not individually long-aligned) for small extensions; you can say something potentially useful in two bytes. Indeed, I am a little surprised that no-one has queried using the size to represent an extension of 1-16 bytes; is 0-15 more useful? A 0-byte extensions is essentially a way of doing a "packet tag", just marking some packets.

So, two reasons:  more open, and more compact for small extensions.

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, Internet-Drafts at ietf.org 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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt