Hello again,

Thanks for the reply. Here is my nitb configuration:

e1_input
 e1_line 0 driver ipa
 e1_line 0 port 0
network
 network country code 1
 mobile network code 1
 short name LimeSDR
 long name LimeSDR
 auth policy accept-all
 location updating reject cause 13
 encryption a5 0
 neci 1
 paging any use tch 0
 rrlp mode none
 mm info 1
 handover 0
 handover window rxlev averaging 10
 handover window rxqual averaging 1
 handover window rxlev neighbor averaging 10
 handover power budget interval 6
 handover power budget hysteresis 3
 handover maximum distance 9999
 timer t3101 10
! timer t3103 0
! timer t3105 0
! timer t3107 0
 timer t3109 4
! timer t3111 0
 timer t3113 60
! timer t3115 0
! timer t3117 0
! timer t3119 0
 timer t3122 10
! timer t3141 0
 dtx-used 0
 subscriber-keep-in-ram 0
 bts 0
  type sysmobts
  band DCS1800
  cell_identity 0
  location_area_code 2
  training_sequence_code 7
!  base_station_id_code 63
  ms max power 23
  cell reselection hysteresis 4
  rxlev access min 0
  periodic location update 30
!  radio-link-timeout 32
  channel allocator ascending
  rach tx integer 9
  rach max transmission 7
  channel-descrption attach 1
  channel-descrption bs-pa-mfrms 5
  channel-descrption bs-ag-blks-res 1
  ip.access unit_id 1801 0
  oml ip.access stream_id 255 line 0
  neighbor-list mode automatic
!  codec-support fr efr afs
!  amr tch-f modes 2
!  amr tch-f start-mode 1
!  amr tch-h modes 2
!  amr tch-h start-mode 1
  gprs mode none
  trx 0
   rf_locked 0
   arfcn 525
   nominal power 23
   max_power_red 0
   rsl e1 tei 0
   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 6
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 7
    phys_chan_config TCH/F
    hopping enabled 0
mncc-int
 default-codec tch-f amr
 default-codec tch-h amr


And here is my osmo-bts-trx configuration:

phy 0
 instance 0
  osmotrx rx-gain 1
 osmotrx ip local 127.0.0.1
 osmotrx ip remote 127.0.0.1
bts 0
 band DCS1800
 ipa unit-id 1801 0
 oml remote-ip 127.0.0.1
 gsmtap-sapi ccch
 gsmtap-sapi pdtch
 trx 0
  phy 0 instance 0

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)




On 2018.02.16 22:07, Osmocom Mailing List wrote:
Hi,

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 
<pes...@sysmocom.de><mailto:pes...@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 <pes...@sysmocom.de<mailto:pes...@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<https://migadu.com?s=sent_via>

Reply via email to