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/.
Osmocom Mailing List osmocom at lains.meHi, Can I see your configuration files? Particularly the OsmoNITB (OpenBSC) one. Here's mine: https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50 Thanks, Filipe Laíns <https://github.com/FFY00> On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol <pespin at sysmocom.de> wrote: > Hi, > > I'm also experincing this issue while using limesdr, also using > latest dependencies (soapysdr, limesuite, etc.) and latest osmo-trx. > > The call is established correctly, but after a few seconds (or almost > immediately) it is cancelled. > > This explains that the call was closed: > > > <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure: > > cause = 0x01 > > <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without > LAPDm > > context. (sapi 0) > > <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete > indication: > > cause = Normal event, unspecified > > The RTP becoming out of sync most probably also explains too that a > lot of packets are not being received correctly at l1sap layer: > >> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs >> 160 (2295960->2296003) >> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 >> vs 160 (2296003->2295973) >> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 > > Reproducing a conversation relarted to this topic that I had with > Harald, but unfortunately didn't have time to continue on it yet: > > * Pau: > It seems it comes from osmo-bts l1sap_ph_data_ind with len(msgb)==0, > indicating a bad frame. I can reproduce this every time I place a > call between 2 MS with a limesdr. > > * Harald: > well, it's not "a bad frame", but it's a lot of ongoing bad/lost > signaling blocks. > > So first of all, this entire code path is not traversed for voice > (TCH) > block, only for signalling (FACCH/SACCH) blocks. And then, there's the > 's' counter implementing the radio link criterion. It is not formally > specified for the BTS side (see TS 45.008 Section 5.3), but we simply > implement what's specified for the MS side in TS 45.008 Section 5.2. > > "S" is incremented for every good block by two, and decremented for > every bad block. And once it reaches a negative value, the > above-mentioned LINK FAILURE message is sent via RSL. See > > So you must be loosing more than 66.6% of your total number of > signaling > blocks to ever reach this point. > > How do the measurement reports look like? Those are the most valuable > resource when debugging anything related to RF link issues. > > > -- > - Pau Espin Pedrol <pespin at sysmocom.de> > http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180216/bc562b09/attachment.htm>