Fundamentally, neither the RTP time codes nor NTP is sufficient for precise synchronization. If you want accurate and fast synchronization between devices, then you have to use something like PTP, since NTP takes much too long to synchronize and does not do it to a sufficient resolution.
/Joe
Chuck Harrison <cfharr at erols.com> 3/2/2006 1:32 PM >>>
I believe that there *are* significant use cases for something
like Dave's "payload format independent capability". Long-time
participants in this forum will have heard my refrain before:
RTP's original design never addressed or intended to address the
issue of long-term phase correlation among sender and receiver
sample clocks. In neither theory nor practice are RTP media
sources or sinks expected to be phase synchronous to NTP time,
and drift does occur.
There is a large class of applications wherein the resulting
artifacts (dropped/repeated video frames, audio pops, drifting
inter-track synchronization) are negligible and the current
RTP architecture is sufficient. There is also a class of
applications (largely but not exclusively of "professional"
type) which do not tolerate such artifacts well and would benefit
from additional features supporting phase synchronization of
sources and receivers.
This task is nontrivial, as different use cases call for different
types of "pulling" or "pushing" sync. Existing practice in
professional video and audio production studios offers insight
into the type of time alignment capabilities that are likely to
be useful.
I do not know whether Dave's view of the issue is as broad as I
state here, but I concur with his assessment that this is a
"generic" capability that could beneficially apply to many if
not all of the payload formats transported over RTP.
I do recognize that 3G gateway implementors may be impatient
regarding the development of a "big picture" solution. But that's
why I started posting to avt on this topic about 5 years ago ;-).
Peace,
Chuck Harrison
David R Oran wrote:
I'm wondering if this might be better abstracted into a payload-
format independent capability and use a framework like that in draft-
wenger-avt-avpf-ccm-02.txt?
Dave.
On Mar 1, 2006, at 5:10 PM, Ejzak, Richard P (Richard) wrote:
Hi all,
The editors of RFC 3267 bis are preparing a new draft for the
upcoming meeting and we propose to add an optional capability to
perform time alignment for AMR and WB-AMR. Unless there are
significant objections to this addition, the editors propose to add
time alignment to the new draft next week. Please provide any
comments or concerns with the proposed new capability.
Time alignment is useful in certain gateway-to-gateway scenarios
and certain gateway-to-VoIP-terminal scenarios. It is the ability
for a receiving gateway to request that the encoder shift the time
reference for encoding and packetization by a specified amount.
[...]
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt