[Linphone-developers] ORTP: receiver side user timestamp trouble

[Patai Tamas]

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