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

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

> -----Original Message-----
> 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
> 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.
> 
> 
> ---
> 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

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

---

From: lazzaro <[email-masked]>
Date: Thu, 20 Jul 2006 14:37:45 -0700

> understand they are part of the payload specification like for example

In my examples, both MIDI and AIFF/WAV are essentially the RTP
of their industries -- MIDI as a serial-line networking standard,
AIFF and WAV as older media file formats.  I wasn't referring to
MIDI or AIFF/WAV (i.e. uncompressed audio) as RTP payload formats.

Rather, the point was, in their industries, MIDI and AIFF/WAV
play a role like RTP's role in ours, and companies innovate by
extending them like we extend RTP with payload and profiles
and (currently under debate) header extensions.  Except, their
extension systems don't require industry-wide consensus of
the semantics and internal syntax of the extensions as we
do for RTP payload formats and (currently under debate) header
extensions.

> My suggestion was to send a multiplex stream like DTMF as in RFC2833.

Well, its certainly true that the RFC 2198 method of putting
many encodings in one packet, combined with making all
potential header extensions into payload formats, could be
used as an alternative way to implement header extensions.

It's not my place to defend one design over the other, so
I'll leave it to Dave Singer (or someone else if they wish) to
address this issue.

---
John Lazzaro

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Jul 2006 09:46:22 +0200

Hi John,

In most senses what exist for MIDI is also true for RTP. Anyone can 
create a payload format. It doesn't require IETF approval. However most 
does it because it provides everyone with a stable reference and some 
stamp of this is well done. But if you have something to transport over 
RTP you can define that format and register a vendor or personal tree 
media type to identify that format.

What is being discussed is if we should allow anyone to basically modify 
RTP's more fundamental properties without any checks. The header 
extension mechanism was defined to allow for experimentation with 
profiles. It has both advantages and disadvantages to allow multiple and 
  basically anyones header extensions.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Jul 2006 16:32:54 -0400

Magnus Westerlund <[email-masked]> writes:
>RTP's more fundamental properties without any checks. The header extension
>mechanism was defined to allow for experimentation with profiles. It has
>both advantages and disadvantages to allow multiple and basically anyones
>header extensions.

One issue with the call to "make it part of a new profile" is the problems
being discussed in the irtf rtpsec mailing list - negotiating from a sea of
profiles starts to be a real problem.  There are no good (or if you prefer,
too many so-so) ways to indicate a willingness to handle multiple profiles.
Even now this is causing problems when someone has to handle one of
AVP/AVPF/SAVP/SAVPF - do you offer all of the separately?  Which takes
precedence?  How huge does the SDP become? (Witness Magnus' 10KB+ totally
valid SDP example.)  Add even one more variable to the profile mix and
suddenly you have 8 to worry about.  I don't see making it part of profiles
unless we get a better way to offer profile alternatives.  And sdp-ng is
not around the corner, and even if it was it wouldn't necessarily solve the
problem since people want this without needing sdp-ng.

That isn't to say there aren't issues with actually using
header-extensions, but be careful what you propose in their stead.  And at
least a well-defined extension mechanism provides a relief valve.  IMHO.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]