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