Subject: [AVT] General extensible RTP header extension mechanism

From: Dave Singer <[email-masked]>
Date: Wed, 1 Mar 2006 16:45:02 -0800

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 02 Mar 2006 21:31:30 -0600

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

Dave Singer wrote:

> 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.
>
>
>
>> This draft is a work item of the Audio/Video Transport Working Group 
>> of the IETF.
>>

---

From: Dave Singer <[email-masked]>
Date: Fri, 3 Mar 2006 09:27:01 -0800

At 21:31  -0600 2/03/06, Alan Johnston wrote:
>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.

>>in, RTP.  We'd like to move this along, as the SMPTE time-codes 
>>rely on it.
>>
>>
>>

-- 
David Singer
Apple Computer/QuickTime

---

From: Randell Jesup <[email-masked]>
Date: 03 Mar 2006 17:21:20 -0500

Dave Singer <[email-masked]> writes:
>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.
>

        I very much like the idea of compact extensions.  (I never
understood the reasoning for padding everything out to 32-bit boundaries in
a _network_ protocol.  It can make sense (at times) internally for memory
alignment on 32-bit CPUs/memory systems, and to save 2 bits in lengths.
But that doesn't sound like a valid reason for RTP as a protocol.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)