Subject: Re: [AVT] RTCP for synchronization

From: Colin Perkins <[email-masked]>
Date: Tue, 6 Sep 2005 17:18:37 +0100

On 7 Jul 2005, at 11:43, <[email-masked]> <[email-masked]>  
wrote:
> 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 glitch in the inter-frame timing for the video, which may be less  
noticeable.

> 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?

Not really, this is a known limitation of RTP. The least bad work  
around is probably to send an RTCP SR packet immediately you send the  
first media packet. Note that you will always need to be robust to  
loss of RTCP SR packets.

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

Right - this is the problem.

> 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
> :)

It's not possible for other participants to determine the absolute  
playout time at another receiver using just the RTP/RTCP mechanisms.

Colin

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