Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-03.txt

From: "Even, Roni" <[email-masked]>
Date: Wed, 19 Jul 2006 14:20:50 +0300

Dave,

I saw your answer and re-read the text in the draft. I am a bit worried
about this approach. Since you define here extension mechanism that has
semantics that should be known between heterogeneous implementations and
could be negotiated yet it is not clear how developer will know the
meaning of theses header extensions. I would prefer to see those as
RFCs. 

Roni Even

> 
> >
> >5. I am not sure why you need the <month> value. If you register the
> >name with IANA then this defines the uniqueness and an RFC specifies
the
> >meaning of the extension.
> 
> The idea is that these are NOT registered when the URL is not using
> the IETF.  Including them in the IETF ones would be only "to show the
> style and good form".
> 
> >Roni Even
> >
> >
> >
> >
> >
> >_______________________________________________
> >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: lazzaro <[email-masked]>
Date: Wed, 19 Jul 2006 10:09:55 -0700

> meaning of theses header extensions. I would prefer to see those as

If an application doesn't know the meaning of the header extension,
it would want to negotiate to not receive it, I would think.  That one
piece of information -- here is the name of the extension, which you
can use to figure out if you are aware of the extension or not -- is  
enough.

---

There is a track record of this sort of extension philosophy (extensions
with a known syntax but potentially unknown semantics, apart from
fields that let one skip over it) working well in media standards.
Two examples:

[1] MIDI System Exclusive messages.  Manufacturers define them,
and are encouraged to document them in their product manuals, but
do not register them with the MMA.

[2] AIFF and WAV metadata chunks.  Manufacturers with special
metadata needs for audio can use these chunks to annotate the
audio in a file, while keeping basic file compatibility with the huge
base of programs that read and write AIFF and WAV.

In both of these cases, if the old standards didn't have ways to allow
the creation of new time-lined metadata (which is what these extensions
really are) without interaction with a standards process, manufacturers
with a new idea that required new metadata to work would have broken
compatibility and defined a new media format.

Indeed, in the case of AIFF/WAV, we've reached the point where the
built-in flexibility isn't enough, and we've seen new files formats  
like CAF
files from Apple that make a clean break with AIFF and WAV.  I think we
need to maintain a pragmatic mindset to safeguard RTP from this outcome,
which is why I've been chiming in in favor of hdrext so often ...

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

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 20 Jul 2006 12:25:44 -0700

I believe this header extensions goes on a packet by packet basis. A
sender might prefer not to use this extension for some packets.

For the proposed 'toffset' extension, a sender would prefer to avoid the
extension whenever an RTP packet's to be filled in 'toffset' field value
is zero. Toffset could be zero for majority of video packets in an RTP
stream. Avoiding this header extension whenever Toffset value is zero
reduces the RTP packet size by 8 bytes.

It would be better to clarify that the above is allowed. i.e., agreeing
for an extension via the SDP signlaing does not necessarily manadate the
presence of the header extension in each and every packet of the RTP
stream.

Thanks,
Hari

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, June 15, 2006 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-03.txt 
> 
> 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-03.txt
> 	Pages		: 17
> 	Date		: 2006-6-15
> 	
> 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-03.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-avt-rtp-hdrext-03.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-avt-rtp-hdrext-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 20 Jul 2006 23:56:38 +0300

Hi,
Your response 
"And a receiver who doesn't support a header extension can simply
skip past it, or negotiate not to receive it.  If an extension is adding
5 or 10 octets per packet, the overheads of sending a separate stream --
in a bandwidth sense, a port sense, a sender and receiver overhead
sense -- is significant."

My suggestion was to send a multiplex stream like DTMF as in RFC2833. If
we use header extension then maybe we should change RFC2833 to be
carried as header extensions.

Roni

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 21 Jul 2006 00:01:24 +0300

Hi,
I am not sure I follow you examples but they all look like payload
format specific and not applicable to all profiles. As far as I
understand they are part of the payload specification like for example
parameter sets in H.264.
Roni Even

> From: lazzaro [mailto:[email-masked]]
> Sent: Thursday, July 20, 2006 8:46 PM
> To: [email-masked]
> Cc: John Lazzaro
> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-hdrext-03.txt
> 
> 
> On Jul 20, 2006, at 12:14 AM, Even, Roni wrote:
> 
> > I still am not convinced. All the examples are for proprietary
> > extensions.
> 
> 
> In the MMA and AIFF/WAV world's, today's proprietary extensions
> often become (1) tomorrow's MMA-standardized extensions, or
> (2) new de-facto standards everyone reverse engineers and supports.
> 
> 
> Examples:
> 
> [1] Logic Control (a protocol for a mixing desk to control a digital
> audio workstation (DAW)) implemented the control protocol layered on
> top of MIDI, using a mix of SysEx extensions and a remapping
> of some standard MIDI commands.  Originally it was proprietary
> to Emagic (who wrote the DAW named Logic) and Mackie (who
> designed the first Logic Control console).  Logic Control was so
> proprietary the console initialization included cryptographic
handshake
> to prevent interoperability.
> 
> Times changed, Apple bought Emagic, now the Logic Control
> Protocol is documented by Apple, and many DAWs and many
> hardware manufacturers support it.
> 
> If there wasn't a way to do SysEx commands in MIDI, Logic
> and Emagic probably would have abandoned MIDI for
> their controller project, and DAW console control standardization
> would have taken more years to converge to stability.
> 
> 
> [2] Sonic Foundry's ACID program was the first program that
> let users make music by time-stretching and pitch-shifting
> audio files as loops.  It's file format for loops were WAV files
> that used the metadata to encode the time-stretch and pitch-shift
> hints.  By using WAV files, it let users use their favorite audio
> editors for making the WAV files -- these programs know to
> preserve WAV metadata they don't understand on input and
> output.  Once ACID was successful, other programs came
> on line, and they were able to "import" ACIDized WAV file
> libraries because the were legal wavefiles (some competitors
> reversed engineered the hints, other competitors just replaced
> them with their own hinting systems).  And so, at the beginning
> ACID benefited from extending WAV (program editor support
> came for free) and later on competitors did (ACID users did not have
> to throw away expensive content libraries in order to switch).
> 
> So, there's historical evidence that a heathy ecosystem can
> be based on this type of extension philosophy.
> 
> 
> 
> > I can think of a different solution of defining a payload type for
> > generic data and multiplexing it with the standard stream (like your
> > second example). A receiver who will not support this payload type
> > will
> > still can receive the main payload type.
> 
> 
> And a receiver who doesn't support a header extension can simply
> sense -- is significant.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 20 Jul 2006 23:56:38 +0300

Hi,
Your response 

Roni