[PATCH 8/9] Fixed (nanoBTS) delay problems, if RTP stream jitters too much

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Jacob Erlbeck jerlbeck at sysmocom.de
Mon Feb 10 09:22:47 UTC 2014


Dear Andreas,

On 02.02.2014 13:09, Andreas Eversberg wrote:
> 
> holger mentioned that you also had a problem with speech frames in
> conjunction with ipaccess BTS. was it a similar problem? how did you
> solve this?

that BTS silently drops frames that do not have a RTP timestamp of
T0 + 160 * k, where T0 is the first timestamp (I ignore the modulo
here). In addition it ceases to transmit audio from RTP if there is a
pause (e.g. no RTP for >1s) but the timestamps are not incremented
accordingly (probably because they've been considered to be too late).
In short: that BTS expects proper timestamps.

I've solved this by optionally allowing the MGCP daemon to enforce the
160*k requirement by rounding the timestamp towards the next valid one.
In addition, when SSRCs are patched, the new timestamp offset is
calculated based on (monotonic) system time that has passed between the
last packet of the old SSRC and the first of the new. Since the RTP
timestamp problems only happened when the network side switched streams
(and thus luckily SSRCs), this was sufficient.

In theory, the BTS should be able to detect SSRC changes and reset its
timing accordingly. But since this is not the case with that BTS, those
workarounds are neccessary :-(

Cheers

Jacob





More information about the OpenBSC mailing list