<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello again,</p>
<p>Thanks for the reply. Here is my nitb configuration:</p>
<p>e1_input<br>
e1_line 0 driver ipa<br>
e1_line 0 port 0<br>
network<br>
network country code 1<br>
mobile network code 1<br>
short name LimeSDR<br>
long name LimeSDR<br>
auth policy accept-all<br>
location updating reject cause 13<br>
encryption a5 0<br>
neci 1<br>
paging any use tch 0<br>
rrlp mode none<br>
mm info 1<br>
handover 0<br>
handover window rxlev averaging 10<br>
handover window rxqual averaging 1<br>
handover window rxlev neighbor averaging 10<br>
handover power budget interval 6<br>
handover power budget hysteresis 3<br>
handover maximum distance 9999<br>
timer t3101 10<br>
! timer t3103 0<br>
! timer t3105 0<br>
! timer t3107 0<br>
timer t3109 4<br>
! timer t3111 0<br>
timer t3113 60<br>
! timer t3115 0<br>
! timer t3117 0<br>
! timer t3119 0<br>
timer t3122 10<br>
! timer t3141 0<br>
dtx-used 0<br>
subscriber-keep-in-ram 0<br>
bts 0<br>
type sysmobts<br>
band DCS1800<br>
cell_identity 0<br>
location_area_code 2<br>
training_sequence_code 7<br>
! base_station_id_code 63<br>
ms max power 23<br>
cell reselection hysteresis 4<br>
rxlev access min 0<br>
periodic location update 30<br>
! radio-link-timeout 32<br>
channel allocator ascending<br>
rach tx integer 9<br>
rach max transmission 7<br>
channel-descrption attach 1<br>
channel-descrption bs-pa-mfrms 5<br>
channel-descrption bs-ag-blks-res 1<br>
ip.access unit_id 1801 0<br>
oml ip.access stream_id 255 line 0<br>
neighbor-list mode automatic<br>
! codec-support fr efr afs<br>
! amr tch-f modes 2<br>
! amr tch-f start-mode 1<br>
! amr tch-h modes 2<br>
! amr tch-h start-mode 1<br>
gprs mode none<br>
trx 0<br>
rf_locked 0<br>
arfcn 525 <br>
nominal power 23<br>
max_power_red 0<br>
rsl e1 tei 0<br>
timeslot 0<br>
phys_chan_config CCCH+SDCCH4<br>
hopping enabled 0<br>
timeslot 1<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 2<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 3<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 4<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 5<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 6<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
timeslot 7<br>
phys_chan_config TCH/F<br>
hopping enabled 0<br>
mncc-int<br>
default-codec tch-f amr<br>
default-codec tch-h amr<br>
<br>
</p>
<p>And here is my osmo-bts-trx configuration:</p>
<p>phy 0<br>
instance 0<br>
osmotrx rx-gain 1<br>
osmotrx ip local 127.0.0.1<br>
osmotrx ip remote 127.0.0.1<br>
bts 0<br>
band DCS1800<br>
ipa unit-id 1801 0<br>
oml remote-ip 127.0.0.1<br>
gsmtap-sapi ccch<br>
gsmtap-sapi pdtch<br>
trx 0<br>
phy 0 instance 0<br>
</p>
<p>I do however doubt that the LimeSDR is at fault for the voice calls failing, as on an older osmo-bts-trx ver. 0.6.0.21-9982b, I get the same RTP errors (<0007> l1sap.c:96 RTP clock out of sync with lower layer: 0 vs 160 (456369->456369)) but voice calls
do work (at least somewhat)<br>
<br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2018.02.16 22:07, Osmocom Mailing List wrote:<br>
</div>
<blockquote type="cite" cite="mid:1518811648.11238.2@smtp.migadu.com">
<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" moz-do-not-send="true">https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50</a></div>
<div><br>
</div>
<div>Thanks,</div>
</div>
</div>
</div>
<div id="geary-signature">
<div style="white-space: pre;">Filipe Laíns <<a href="https://github.com/FFY00" target="_blank" moz-do-not-send="true">https://github.com/FFY00</a>></div>
</div>
<div id="geary-quote"><br>
On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol <a class="moz-txt-link-rfc2396E" href="mailto:pespin@sysmocom.de">
<pespin@sysmocom.de></a> 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" moz-do-not-send="true">pespin@sysmocom.de</a>>
<a href="http://www.sysmocom.de/" moz-do-not-send="true">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" moz-do-not-send="true">Sent via
<b>Migadu.com</b>, world's easiest email hosting</a></p>
</blockquote>
<br>
</body>
</html>