Hi all,

The topic of inter-session synchronization in the presence of wallclock
and sampleclock drift came up as a peripheral issue during discussion
of draft-lakaniemi-avt-rtp-evbr-02. This is an area I am somewhat
familiar with, and I think it would benefit from more attention.

I don't think Colin's assertion that RTCP-SR cross-session sync is
well developed, and proven to work, should be taken to promote
complacency.

There are deeply rooted difficulties in inter-stream synchronization
in the presence of phase noise (clock drift is "DC" phase noise),
which become most apparent when designing systems that need some
combination of tight synchronization, low jitter, low latency,
fast startup, and efficient bandwidth use. These difficulties can
be modelled mathematically and have been present even in legacy
analog systems (motion picture, television, and multitrack audio
production) for many decades; they are multiplied severalfold in
digital studio systems (e.g. those based on SMPTE 259M SDI,
IEEE 1394 Firewire, Layer 2 Ethernet, etc.). The difficulties are
even greater in the high-latency WAN environment in which RTP is
intended for deployment.

I could argue that the difficulties of inter-session digital sync
have not been solved in ANY generic sense: every implementation
must make a "good enough" tradeoff among the desired performance
parameters, in the face of the underlying channel and source
characteristics. For those who aren't too experienced in digital
media hardware, I may need to mention that many applications
(e.g. low distortion multi-microphone audio) require sync and
jitter performance in the 0.01 * sample_period range. "Sample
accurate" is a long ways from nirvana.

For anyone addressing an application which pushes up against the
mathematical limits of synchronization performance I would point
out two items here:

(1) Inter-station wallclock sync can be very important. NTP has
not proven adequate for high-quality media sync. IEEE P1588
"Precision Time Protocol" is a fielded system for high quality
network wallclock distribution. It is the basis of IEEE 802.1as,
a draft standard targeting the home audiovisual market. These
standards dovetail nicely with the RTP model in that they address
modularly the issue of maintaining an accurate distributed
wallclock.

(2) RTCP-SR timestamping has two functions: network jitter
characterization (it timestamps the delivery of packets to a
network interface) and clock synchronization. The text of
RFC 3550 emphasizes the jitter characterization function, and
implies that the wallclock timestamp and mediaclock timestamp
are *independently* set as closely as possible to the time
of packet delivery. In such an implementation, the granularity
of the media timestamp wreaks havoc with precision clock
recovery. I strongly recommend that the media timestamp in
the RTCP-SR packet be set first, and that the full
available wallclock precision be used to match that specific
(integer) media clock instant.

For some reason, the history of media synchronization (going
back at least to Vitaphone) is one of doggedly re-inventing
the wheel because "it can't be that hard". It may not be hard,
but it *is* subtle; there is a huge legacy of mathematical and
engineering analysis that can be helpful.

Cheers,
  Chuck
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt