On Jun 1, 2016 9:37 PM, "Holger Freyther" holger@freyther.de wrote:
On 01 Jun 2016, at 17:18, Max msuraev@sysmocom.de wrote:
Hi.
Right now in osmobts when sending/receiving frames with osmo_rtp_* it's assumed that no frame is lost and timestamp is always advanced in 160ms steps. In practice (especially when DTX is in place) frames do get lost so we have to adjust the step to compensate.
However the result sound not much better than using hardcoded value which suggest that I might be doing FN -> ms conversion (or smth else) wrong. Any ideas/advices?
Don't do it. I don't find the relevant spec within the time frame I had
but I think I recently saw a piece of documentation that SQN (and timestamp) should only be incremented if data is being sent.
Either in the RTP RFC, RTP AMR RFC or the A over IP spec.. I think I saw
it while going through the documents Harald had pointed while I introduced my ideas for the SIP connector.
It's in the RTP RFC.
Sequence number is incremented by 1 with every packet, even if the packet is sent after a long pause (due to DTX). This way you know when you miss a packet.
Timestamp is measured in samples and this is incremented by a number of samples since the last packet. This way you know when to start playing the packet in case of DTX.
A proper RTP library or rather a jitter buffer should handle this automatically, but I'm not sure how does ortp handle it.
Please excuse typos. Written with a touchscreen keyboard.
-- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co