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@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