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/.
Harald Welte laforge at gnumonks.orgOn Wed, Feb 13, 2019 at 07:24:40PM +0100, Gullik Webjorn wrote:
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
> (1619189->1619249)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs 160
> (1619505->1619436)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
> (1619471->1619531)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82591360 vs 160
> (1619587->1619475)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2080 vs 160
> (1619557->1619613)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82594400 vs 160
> (1620892->1620862)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 1440 vs 160
> (1620862->1620900)
>
> Very large value, is this a typecast / intsize problem ??
no. it looks like for some reason you are loosing tons of uplink TCH frames
in you setup. Every 20 milliseconds we expect one TCH block equalling
160 sample clocks at the 8kHz audio sample rate used in GSM.
There may be some underflow/overflow issues in the modulo arithmetic of frame numbers.
The important fac is not so much what exact figures you see here, but that
you see such messages regularly at all. There's something very wrong here.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)