[AVT] RTCP for synchronization

[<skillzero at gmail.com>]

I have a few questions RTCP sender/receiver reports for synchronization:

1. Section 6.1 of RFC 3550 indicates that an RR packet must be sent
instead of an SR packet if no data has been sent yet. The problem for
me is that I need to establish the NTP/RTP timing relationship before
I start playing audio. Otherwise, the receiver would either need to
start playing out-of-sync then later correct when it receives an SR
(glitch in the audio) or it would need to wait until it has received
an SR to start playing (initial samples dropped). I'm playing
prerecorded music so either option has noticeable effects.

Is there a specific reason an SR isn't legal for a soon-to-be sender?
Is there a better way to handle this, other than doing something like
sending silence packet(s) first such that an SR would be legal?

2. My receiving clients were previously also RTP senders so they were
sending and receiving RTCP SR's and RR's and this allowed me to
calculate  an accurate, absolute time (figure 2 in RFC 3550) when an
audio sample should be presented so all clients played in-sync. My
receiving clients no longer send RTP data and therefore no longer send
SR's or receive RR's to determine the round-trip time.

Is it possible with RTP/RTCP for non-senders to determine an accurate,
absolute presentation time (at least with respect to other receivers
of this RTP stream)? I can get close by using the NTP/RTP relationship
from the SR combined with the RTP timestamp offset estimate I
maintain, but since this RTP timestamp offset is only an estimate
(jitter, etc. affect it), it doesn't play sample-accurate between
clients; there is a slight reverb effect when the speakers are next to
each other.

The documents I've read so far all seem to use a separate protocol
(MBUS, NTP, etc.) to either publish the playout delay or synchronize
clocks. It seems like RTP has all the facilities to do this via SR/RR
packets, but it doesn't seem to be allowed by the spec for my
situation. Or I just misunderstand it, which is actually quite likely
:)

Thoughts?

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt