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

From: lazzaro <[email-masked]>
Date: Thu, 2 Mar 2006 07:51:22 -0800

Dave Singer <[email-masked]>
> 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?

I would say "yes".  I think we need to be
more cognizant of the fact that in addition
to the mature RTP areas (content-streaming,
VoIP), RTP is constantly being considered
as the base protocol for new application areas.

When folks are evaluating RTP for these sorts
of uses, and RTP doesn't meet their needs, they're
quite happy to break RTP in whatever way needed
to get the job done -- in a new application area,
there's nothing pre-existing to be compatible with.

I think a header extension increases the odds that
these sorts of "first-movers" define a new header
extension, rather than start modifying RTP or
RTCP itself to meet their needs ...

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

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

---

From: Philippe Gentric <[email-masked]>
Date: Thu, 2 Mar 2006 17:21:38 +0100

lazzaro <[email-masked]> wrote on 2006-03-02 16:51:22:

> I would say "yes". 

I would also say yes, 
if we can be resonably certain it is OK for existing implementations.

Did anyone try to scan existing products (e.g. known streaming media 
players),
check if they are resistant to this type of thing ?
(they should, but that is just theory right ?-)

A simple way to try for streaming clients would be to setup a RTSP server 
with a specific "tweaked" content (hinted file) 
with dummy such extended headers

can someone put such a server online  and use this list to distribute the 
RTSP URL(s) ?

Philippe Gentric, Philips

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Mar 2006 17:20:37 +0000

On 2 Mar 2006, at 15:51, lazzaro wrote:
>> 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?
>

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. That we are on our first standard header extension after  
15 years of RTP development, should perhaps be seen as a sign that  
other extensions might be preferred in the majority of cases (this is  
not arguing against the SMPTE time code extension: that does seem to  
be a good use of the mechanism, but it's the only one I've seen to  
date).

Colin

---

From: lazzaro <[email-masked]>
Date: Thu, 2 Mar 2006 15:20:09 -0800

On Mar 2, 2006, at 9:20 AM, Colin Perkins wrote:
> 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