|
From: | Patai Tamas |
Subject: | [Linphone-developers] ORTP: receiver side user timestamp trouble |
Date: | Fri, 6 Jan 2006 14:26:28 +0100 |
Hi,
I would like to describe my doubts about a special
kind of behaviour of the oRTP stack. Please let me know if I'm not right or send
me suggestions about it.
There is one thing about the receiver side user
timestamp the application has to provide to the stack that is not clear to me
and can cause problems sometimes:
If this timestamp is not accurately updated by the
application then packets can be missed (this can
easily happen I guess, when there is no signal transmission at all).( This case
if this ts increased too fast then the rtp packets with timestamp too old to
this ts will be skipped)
This can then also affect the jitter calculation as
this user timestamp can oscillate around its real value or increasingly
differ from it.
The other issue is when the user timestamp is not
related to the packet timestamp: increased by not the received packet size (as
we cannot know it for shure), but the frame size. In this case the
application gets packets containing less or more frames then the
original as the packets are divided according to the user ts.
This can be a big disadvantage when I want to
accurately synchronice the send and the receive processes: when I want to save
the sent and received audio in the same time with the knowledge of the time
offset between them. For example implementing a high precision echo or round
trip delay measurement in the audio band (that is different from the RTD the
RTCP report provides).
So I would suggest not to use user timestamp for
packet reception, but always return a packet if available and do not divide
it into parts to match the user timestamp.
any suggestion or answer appreciated
Tamas Patai
|
[Prev in Thread] | Current Thread | [Next in Thread] |