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

[lazzaro <lazzaro at eecs.berkeley.edu>]

On Mar 2, 2006, at 9:20 AM, Colin Perkins wrote:
> My concern is that this draft will encourage people to use an RTP  
> header extension when a new RTP payload format or profile would be  
> preferred, due to lack of understanding of the extension mechanisms  
> we provide.


16 bytes of data payload is not all that much ...
with any luck, this restriction on header extension
size will limit the number of folks trying to shoehorn
a payload format into a header extension.

Then again, more than a few people reading the
last paragraph are now shaking their head and
saying "famous last words" :-).

Here is an example to show why I think its OK ...

One could easily imagine a MIDI RTP header extension
would have been proposed in lieu of RTP MIDI, if it
were proposed today --- there is a correlate in the
file-format world, Apple Loops are AIFF audio files
that can optionally code embedded MIDI commands.

Except, with a 16-byte extension size, the MIDI RTP
header extension design would have probably encoded a
single MIDI command (with timing offset from the
RTP timestamp, and a few bytes of meta-data).
Which would have meant multiple instances of
the header extension per RTP packet for most
real-world applications (one per MIDI command),
even for a 20 ms audio packet rate.

I would think that the designer would realize the
flaw in this approach, and move to start an RTP
payload format design instead of a header extension.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt