Subject: [AVT] What a shame these guys seem to have never heard of RTP

From: "David R. Oran" <[email-masked]>
Date: Wed, 12 Dec 2001 18:27:08 -0500

http://www.techtv.com/news/culture/story/0,24195,3363342,00.html

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

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 12 Dec 2001 17:39:06 -0700

>http://www.techtv.com/news/culture/story/0,24195,3363342,00.html

Yes, it's interesting (and disappointing) that they felt that changes were 
needed at layer 2 (Ethernet) - presumably because they wanted QOS 
guarantees.  However, it seems very likely that regular switched Ethernet 
would give them the QOS that they wanted.  And then it's disappointing that 
they (apparently) decided to build their own protocol on top of this, 
instead of using RTP.  (It wasn't clear from the article if they even use IP.)

It would be great if someone were to develop an alternative system using 
RTP/UDP/IP over regular Ethernet, and could show that QOS is not a problem.

         Ross.

---

From: Chuck Harrison <[email-masked]>
Date: Wed, 12 Dec 2001 21:33:22 -0800

David, all -

The flip side of this coin is that it is a "shame" that RTP protocol
implementers do not yet understand the real-world performance
requirements of professional audio. (Likewise for professional
audio-visual production.)

An older, and more widely deployed, digital-audio-over-Ethernet
system is CobraNet from Peak audio. http://www.peakaudio.com/
It, also, is a layer-2 protocol; it provides inter-channel
synchronization of separately-generated audio streams to 1-sample
accuracy and a network latency variation of less than 1/4 sample
clock on 48KHz AES-3 audio. This is adequate for many (but not
all) pro audio applications. I am not aware that any RTP-based
system has been demonstrated with performance within two orders
of magnitude of this.

I tried to start a conversation on precision audiovisual timing
requirements early this year, but the two internet-drafts I
produced have expired without any discussion.

Coincidentally, I have just encountered some interest in this
topic at the SMPTE standards meetings which are ongoing this
week near Seattle. If any readers of this list are interested
in developing the RTP features needed to serve this application
space, I encourage them to contact me. Perhaps we could get a
critical mass together.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  +1 360 863 8340 (voice)  PST = GMT-0800

---

From: Stephen Casner <[email-masked]>
Date: Wed, 12 Dec 2001 23:39:53 -0800 (PST)

Chuck,

> audio-visual production.)

I disagree.  There may not be RTP implementations that provide the
performance you would like, but I don't think it is a limitation of
RTP.

> accuracy

Assuming that the separate sources have a common reference clock of
sufficient accuracy and resolution, and that the implementations are
able to accurately measure the relationship between the sample clock
and the reference clock, then the RTCP SR packet allows the sample
clocks of two streams to be associated to 1-sample accuracy.

> and a network latency variation of less than 1/4 sample
> all) pro audio applications.

I'm not sure what you mean by this.  Ethernet packet arrivals have
more jitter than that.  The network latency variation needs to be
removed with a jitter buffer whether the packets are over raw ethernet
or over IP/UDP/RTP.  The jitter after the buffer depends only on the
local clock.

> I am not aware that any RTP-based

I'm not aware of one either, but I'm also not aware of anyone trying
to build one.  Most of the energy directed to RTP has been for
applications such as IP telephony.

> produced have expired without any discussion.

Sorry there was not more response.  Finding enough energy in the
working group to address all the things that people would like to
cover is a problem.

Your draft on synchronization was a good idea paper / problem
statement, but a lot more work would be needed to generate a solution.

It is not clear whether the solution should be an extension to
RTP/RTCP or a separate control protocol in a manner analogous to the
way RTSP works in conjunction with RTP.  Parts of the solution might
fit into RTCP, but I believe not all.  RTSP addresses similar
problems, although it is probably not the right base for a solution to
your problem.

Your second draft was about key exchange over RTP.  There are other
methods developed and in development for key management.  I don't
think creating a new method based on RTP is a good idea.

> space, I encourage them to contact me. Perhaps we could get a

It is worth thinking about.  But the answer may not be "RTP
features".
							-- Steve

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 13 Dec 2001 01:09:11 -0800

Steve,

> performance you would like, but I don't think it is a limitation of

You may be right. In particular, the fact that most OS's do not
provide a usefully-accurate NTP wallclock is not RTP's fault.

[...]
> or over IP/UDP/RTP.
CobraNet uses a layer-2 "beat packet" which transits a switched
Ethernet environment with relatively low jitter. 

>  The jitter after the buffer depends only on the
> local clock.

RTP does not provide any tools for either "pull" or "master sync"
modes of operation; only the "push" mode is explicitly supported.
In general, "push" operation requires the receiver to regenerate
the media clock using some type of phase locked loop which
attenuates the transport jitter but typically has residual jitter
much larger than professional applications require. RTP does not
preclude the use of out-of-band methods for establishing
"house sync" or "genlock", but I have proposed that such functions
are so essential for satisfactory interoperation here that "pro"
applications would benefit from standards-based support.

> statement, but a lot more work would be needed to generate a solution.

Yes, my goal was to attract some people interested in helping
with the work. My drafts exhibited a rather amateur level of
RTP understanding. Perhaps I put the cart before the horse, and
it would have been better received if I had found some help
*before* composing the internet-drafts.

> Your second draft was about key exchange over RTP. [...]
Separate issue; no connection. The timing docs I wrote are:

 draft-harrison-avt-precision-av-00 , Precision AV Timing
 draft-harrison-avt-tis-00 , Payload format for Timing Information
 draft-harrison-avt-interlock-01 , Timebase Interlock in RTP
(I don't think I submitted all of these.)

Anyhow, I am still interested in the application area. If anyone
with real RTP expertise wants to work on developing a better
polished draft, I'd be happy to participate.

Comments received before ~ 12 Noon PST will be shared with some
folks here at the SMPTE meetings.

Cheers,
  Chuck

---

From: Stephen Casner <[email-masked]>
Date: Thu, 13 Dec 2001 09:40:46 -0800 (PST)

Chuck,

> applications would benefit from standards-based support.

I want to draw a distinction between "out-of-band" (with respect to
RTP) and "standards-based".  I agree that it makes sense to
standardize the necessary mechanisms, but a good part of the solution
is likely to be outside of RTP in a control/setup protocol that
establishes what the sync dependencies should be, communicates the
offsets among the timebases that are in lockstep, etc.

I'm guessing that the main requirement you need is a way to establish
the reference clock for all sources to use.  If that is communicated
via packets, then a PLL is needed as part of that path as well.  But I
have implemented a prototype T3-over-IP circuit emulation that meets
the 20ppm requirement for that system (in fact, more like 5ppm
relative to its crystal).  It may be that your requirements are
tighter, but I mention this only to counter blanket assumptions that
phase locking across a packet network can't be done.

> Separate issue; no connection. The timing docs I wrote are:

Sorry.  That and draft-harrison-avt-precision-av-00 were the two I
found in my drafts directory.

> polished draft, I'd be happy to participate.

I am interested in sync issues and may be able to provide useful
explanations of how I think RTP is intended to work, but can't commit
time to write a draft.
							-- Steve