<p dir="ltr"><br>
On Jun 1, 2016 9:37 PM, "Holger Freyther" <<a href="mailto:holger@freyther.de">holger@freyther.de</a>> wrote:<br>
><br>
><br>
> > On 01 Jun 2016, at 17:18, Max <<a href="mailto:msuraev@sysmocom.de">msuraev@sysmocom.de</a>> wrote:<br>
> ><br>
> > Hi.<br>
> ><br>
><br>
> > Right now in osmobts when sending/receiving frames with osmo_rtp_* it's<br>
> > assumed that no frame is lost and timestamp is always advanced in 160ms<br>
> > steps. In practice (especially when DTX is in place) frames do get lost<br>
> > so we have to adjust the step to compensate.<br>
> ><br>
><br>
><br>
> > However the result sound not much better than using hardcoded value<br>
> > which suggest that I might be doing FN -> ms conversion (or smth else)<br>
> > wrong. Any ideas/advices?<br>
><br>
> 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.<br>
><br>
> 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.<br>
></p>
<p dir="ltr">It's in the RTP RFC.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">A proper RTP library or rather a jitter buffer should handle this automatically, but I'm not sure how does ortp handle it.</p>
<p dir="ltr">Please excuse typos. Written with a touchscreen keyboard.</p>
<p dir="ltr">--<br>
Regards,<br>
Alexander Chemeris<br>
CEO Fairwaves, Inc.<br>
<a href="https://fairwaves.co">https://fairwaves.co</a></p>