1 Jun
2016
1 Jun
'16
9:51 p.m.
On Jun 1, 2016 9:37 PM, "Holger Freyther" <holger(a)freyther.de> wrote:
but
I think I recently saw a piece of documentation that SQN (and
timestamp) should only be incremented if data is being sent.
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
On 01 Jun 2016, at 17:18, Max
<msuraev(a)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
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.