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(a)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