<div id="geary-body"><div><div id="geary-body"><div>Hi,</div><div><br></div><div>Can I see your configuration files? Particularly the OsmoNITB (OpenBSC) one.</div><div><br></div><div>Here's mine: <a href="https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50">https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50</a></div><div><br></div><div>Thanks,</div></div><div id="geary-signature"></div></div></div><div id="geary-signature"><div style="white-space: pre;">Filipe Laíns <<a href="https://github.com/FFY00" target="_blank">https://github.com/FFY00</a>></div></div><div id="geary-quote"><br>On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol <pespin@sysmocom.de> wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">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:

<blockquote><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 
</blockquote>
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.


<div>-- 
</div>- Pau Espin Pedrol <<a href="mailto:pespin@sysmocom.de">pespin@sysmocom.de</a>>         <a href="http://www.sysmocom.de/">http://www.sysmocom.de/</a>
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
</div></blockquote></div><P><a style="display:block;margin-top:20px;font-family:sans-serif;text-align:center;padding:10px;font-size:12px;white-space: pre-line !important;background-color:#fafafa;color:#007DCC;" href="https://migadu.com?s=sent_via">Sent via <b>Migadu.com</b>, world's easiest email hosting</a></P>