14 Feb
2018
14 Feb
'18
6:40 p.m.
Hello all,
I have run into some problems while building and running osmo-nitb, osmo-bts-trx and
osmo-trx on Ubuntu 16.04. I am trying to create a self-contained gsm network box. I have
successfully built libosmocore, libosmo-abis, libosmo-netif, libosmo-sccp, openbsc,
osmo-bts and osmo-trx all from git sources, and i am also using linux call router. All
make checks pass corrently without issues.
As for the SDR side, i am have the latest UHD, SoapySDR and SoapyUHD, and latest LimeSuite
library for LimeSDR support.
SMS send/receive works correctly without any issues. Calling, however, works neither with
osmo-nitb as standalone, neither with osmo-nitb with -m parameter + LCR. when trying to
call, the receiving phone rings, but when trying to answer it randomly either gets stuck
and does not answer, drops the call instantly or actually takes the call (and the elapsed
seconds counter starts counting), but all you can hear is random noises coming both from
the calling and from receiving phones, while the calling phone still shows that the call
has not been answered, as in still calling.
this is the debug info from osmo-trx:
<0000> rsl.c:606 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
<0011> lapd_core.c:920 Store content res. (dl=0xb668cec8)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12405
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8 state
LAPD_STATE_MF_EST)
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0000> rsl.c:606 (bts=0,trx=0,ts=3,ss=0) Tx CHAN ACT ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
(2291865->2291921)
<0011> lapd_core.c:920 Store content res. (dl=0xb66a83dc)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2292212->2292182)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2292208->2292246)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2292246->2292212)
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12917
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc state
LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
(2292814->2292870)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293165->2293131)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293178->2293221)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293221->2293191)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293200->2293239)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293239->2293204)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293404->2293447)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293447->2293417)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293417->2293455)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293455->2293421)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293443->2293486)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293486->2293456)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293469->2293507)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293507->2293473)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293677->2293720)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2293720->2293681)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293789->2293832)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2293832->2293794)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2293967->2294014)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294014->2293984)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293989->2294027)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294027->2293993)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294240->2294283)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294283->2294253)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294257->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294296->2294262)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294262->2294305)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2294305->2294266)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2294283->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294331->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 480 vs 160
(2294318->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294335->2294374)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294374->2294340)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294409->2294452)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2294452->2294413)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2294929->2294976)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294976->2294946)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294951->2294989)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294989->2294955)
<0000> rsl.c:689 (bts=0,trx=0,ts=2,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=2,ss=0) Sending RTP delete indication: cause =
Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2295705->2295748)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2295752->2295718)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2295817->2295860)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2295869->2295835)
<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
(2295978->2296016)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2296016->2295982)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2296030->2296073)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2296077->2296043)
<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
<0000> rsl.c:580 (bts=0,trx=0,ts=3,ss=0) Tx RF CHAN REL ACK
osmo-nitb -c config.cfg -C -m -P
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: call re-establishment (ra=0x4f,
neci=0x01, chreq_reason=0x02)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=2,ss=0) ChanModify for speech:
SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: answer to paging (ra=0x27, neci=0x01,
chreq_reason=0x01)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=3,ss=0) ChanModify for speech:
SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING state
ACTIVE CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING state
ACTIVE CAUSE=0x01(Radio Link Failure)
versions of software:
osmo-nitb --version
OpenBSC version 1.0.0.14-98a2ba
~/Desktop/osmo/openbsc$ git log -1
commit 98a2ba4c57e95d2ce1e1e8147ea5a8d51788a191
Author: Vadim Yanitskiy <axilirator@gmail.com><mailto:axilirator@gmail.com>
Date: Wed Jan 10 22:25:17 2018 +0600
((*))
|
/ \ OsmoBTS
OsmoBTS version 0.7.0.77-54be
~/Desktop/osmo/osmo-bts$ git log -1
commit 54be46949e93e07e9e57b706388ebb832e5fad0a
Author: Pau Espin Pedrol <pespin@sysmocom.de><mailto:pespin@sysmocom.de>
Date: Fri Feb 9 12:08:38 2018 +0100
osmo trx:
~/Desktop/osmo/osmo-trx$ git log -1
commit 77ce99ac6720896f504a0581a5c57b2929a13cef
Author: Pau Espin Pedrol <pespin@sysmocom.de><mailto:pespin@sysmocom.de>
Date: Mon Feb 5 13:05:06 2018 +0100
older osmo-bts-trx does actually work at least somewhat, but then voice transmission stops
after 10-20 seconds, or sometimes even after 4 minutes of talking, while . The older
version is:
commit 9982b95069c58a3cb9b97bb6bc75932db81886ad
Author: Harald Welte <laforge@gnumonks.org><mailto:laforge@gnumonks.org>
Date: Tue Oct 24 18:42:30 2017 +0200
"OsmoBTS version 0.6.0.21-9982b-dirty"
I would, however, like to use a newer, preferably the master branch version from git.
Any help in dealing with this issue would be very greatly appreciated.
15 Feb
15 Feb
5:23 p.m.
Hi Norbertas,
Im wondering does your osmo-trx is running stable with LimeSDR? not having
glitch or stop in the middle or send timed out?
if yes, I assume it was osmo-trx still having problem.... im very curious
if you using latest osmo-trx and stable.
The other problem also your configuration. you need to give details.
DUO
On Thu, Feb 15, 2018 at 12:40 AM, Norbertas Kremeris <n.kremeris(a)live.com>
wrote:
Hello all,
I have run into some problems while building and running osmo-nitb,
osmo-bts-trx and osmo-trx on Ubuntu 16.04. I am trying to create a
self-contained gsm network box. I have successfully built libosmocore,
libosmo-abis, libosmo-netif, libosmo-sccp, openbsc, osmo-bts and osmo-trx
all from git sources, and i am also using linux call router. All make
checks pass corrently without issues.
As for the SDR side, i am have the latest UHD, SoapySDR and SoapyUHD, and
latest LimeSuite library for LimeSDR support.
SMS send/receive works correctly without any issues. Calling, however,
works neither with osmo-nitb as standalone, neither with osmo-nitb with -m
parameter + LCR. when trying to call, the receiving phone rings, but when
trying to answer it randomly either gets stuck and does not answer, drops
the call instantly or actually takes the call (and the elapsed seconds
counter starts counting), but all you can hear is random noises coming both
from the calling and from receiving phones, while the calling phone still
shows that the call has not been answered, as in still calling.
this is the debug info from osmo-trx:
<0000> rsl.c:606 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK
<0011> lapd_core.c:920 Store content res. (dl=0xb668cec8)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12405
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb668cec8
state LAPD_STATE_MF_EST)
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0009> pcu_sock.c:668 PCU socket not connected, dropping message
<0000> rsl.c:606 (bts=0,trx=0,ts=3,ss=0) Tx CHAN ACT ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
(2291865->2291921)
<0011> lapd_core.c:920 Store content res. (dl=0xb66a83dc)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<0000> rsl.c:1639 CRCX does not specify a remote IP
<0000> rsl.c:1646 CRCX does not specify a remote port
<0000> rsl.c:1650 speech mode: 16
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=1, V(R)=2 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2292212->2292182)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=2, V(R)=3 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2292208->2292246)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2292246->2292212)
<0000> rsl.c:1636 connect_ip 16777343
<0000> rsl.c:1643 connect_port 12917
<0000> rsl.c:1650 speech mode: 0
<0000> rsl.c:1656 payload type: 3
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0xb66a83dc
state LAPD_STATE_MF_EST)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 2080 vs 160
(2292814->2292870)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293165->2293131)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293178->2293221)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293221->2293191)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293200->2293239)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293239->2293204)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293404->2293447)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293447->2293417)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293417->2293455)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293455->2293421)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293443->2293486)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2293486->2293456)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293469->2293507)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2293507->2293473)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293677->2293720)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2293720->2293681)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2293789->2293832)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2293832->2293794)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2293967->2294014)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294014->2293984)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2293989->2294027)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294027->2293993)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294240->2294283)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294283->2294253)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294257->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294296->2294262)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294262->2294305)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2294305->2294266)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2294283->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294331->2294296)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 480 vs 160
(2294318->2294331)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294335->2294374)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294374->2294340)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2294409->2294452)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594080 vs 160
(2294452->2294413)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1760 vs 160
(2294929->2294976)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 160
(2294976->2294946)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160
(2294951->2294989)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2294989->2294955)
<0000> rsl.c:689 (bts=0,trx=0,ts=2,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=2,ss=0) Sending RTP delete indication:
cause = Normal event, unspecified
<0000> rsl.c:580 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2295705->2295748)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2295752->2295718)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2295817->2295860)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2295869->2295835)
<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
(2295978->2296016)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2296016->2295982)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160
(2296030->2296073)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594240 vs 160
(2296077->2296043)
<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
<0000> rsl.c:580 (bts=0,trx=0,ts=3,ss=0) Tx RF CHAN REL ACK
osmo-nitb -c config.cfg -C -m -P
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: call re-establishment
(ra=0x4f, neci=0x01, chreq_reason=0x02)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=2,ss=0) ChanModify for
speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1852 BTS 0 CHAN RQD: reason: answer to paging (ra=0x27,
neci=0x01, chreq_reason=0x01)
<000a> bsc_api.c:415 Sending (bts=0,trx=0,ts=3,ss=0) ChanModify for
speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING
state ACTIVE CAUSE=0x01(Radio Link Failure)
<0004> abis_rsl.c:1358 (bts=0,trx=0,ts=3,ss=0) CONNECTION FAIL: RELEASING
state ACTIVE CAUSE=0x01(Radio Link Failure)
versions of software:
osmo-nitb --version
OpenBSC version 1.0.0.14-98a2ba
~/Desktop/osmo/openbsc$ git log -1
commit 98a2ba4c57e95d2ce1e1e8147ea5a8d51788a191
Author: Vadim Yanitskiy <axilirator(a)gmail.com> <axilirator(a)gmail.com>
Date: Wed Jan 10 22:25:17 2018 +0600
((*))
|
/ \ OsmoBTS
OsmoBTS version 0.7.0.77-54be
~/Desktop/osmo/osmo-bts$ git log -1
commit 54be46949e93e07e9e57b706388ebb832e5fad0a
Author: Pau Espin Pedrol <pespin(a)sysmocom.de> <pespin(a)sysmocom.de>
Date: Fri Feb 9 12:08:38 2018 +0100
osmo trx:
~/Desktop/osmo/osmo-trx$ git log -1
commit 77ce99ac6720896f504a0581a5c57b2929a13cef
Author: Pau Espin Pedrol <pespin(a)sysmocom.de> <pespin(a)sysmocom.de>
Date: Mon Feb 5 13:05:06 2018 +0100
older osmo-bts-trx does actually work at least somewhat, but then voice
transmission stops after 10-20 seconds, or sometimes even after 4 minutes
of talking, while . The older version is:
commit 9982b95069c58a3cb9b97bb6bc75932db81886ad
Author: Harald Welte <laforge(a)gnumonks.org> <laforge(a)gnumonks.org>
Date: Tue Oct 24 18:42:30 2017 +0200
"OsmoBTS version 0.6.0.21-9982b-dirty"
I would, however, like to use a newer, preferably the master branch
version from git.
Any help in dealing with this issue would be very greatly appreciated.
--
Best Regards,
DUO
16 Feb
16 Feb
2:14 p.m.
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
9:07 p.m.
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 <pespin(a)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:
Sent via Migadu.com, world's easiest email hosting
<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
19 Feb
19 Feb
8:57 a.m.
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
<pespin@sysmocom.de><mailto:pespin@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 <pespin@sysmocom.de<mailto: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
Sent via Migadu.com, world's easiest email
hosting<https://migadu.com?s=sent_via>
11:20 a.m.
Hi,
I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
similar setup since OsmoNITB is being deprecated and most development
work is happening in split componenets nowadays.
I attach my configs in case you want to start giving a try to the split
components.
--
- 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
12:31 p.m.
Dear Pespin,
please advise if this need run all? even for just voice service?
osmo-hlr -l hlr.db -c osmo-hlr.cfg
osmo-msc -c osmo-msc.cfg
osmo-mgw -c osmo-mgw-for-msc.cfg
osmo-mgw -c osmo-mgw-for-bsc.cfg
osmo-ggsn -c osmo-ggsn.cfg
osmo-sgsn -c osmo-sgsn.cfg
osmo-stp -c osmo-stp.cfg
osmo-bsc -c osmo-bsc.cfg
osmo-hnbgw -c osmo-hnbgw.cfg
osmo-bts-trx -c osmo-bts.cfg
osmo-pcu -c osmo-pcu.cfg
is it completed or I miss some to run?
we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw
for 2g voice only?
please advise. Thanks
DUO
On Mon, Feb 19, 2018 at 10:20 AM, Pau Espin Pedrol <pespin(a)sysmocom.de>
wrote:
Hi,
I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
similar setup since OsmoNITB is being deprecated and most development work
is happening in split componenets nowadays.
I attach my configs in case you want to start giving a try to the split
components.
--
- 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
--
Best Regards,
DUO
12:46 p.m.
is it completed or I miss some to run?
Looks fine to me.
we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for 2g voice only?
Indeed you can drop those if you don't want data access, and osmo-hnbgw
if you are not using 3g.
--
- 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
1:12 p.m.
allright!
will try your config tonight for the voice. :)
thanks Pespin.
DUO
On Feb 19, 2018 6:46 PM, "Pau Espin Pedrol" <pespin(a)sysmocom.de> wrote:
is it completed or I miss some to run?
Looks fine to me.
> we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for
> 2g voice only?
Indeed you can drop those if you don't want data access, and osmo-hnbgw if
you are not using 3g.
--
- 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
20 Feb
20 Feb
3:35 a.m.
Dear Pespin.
Still no voice on my side using your configuration. :-(
best,
Sandi
On Mon, Feb 19, 2018 at 12:12 PM, Sandi Suhendro <djks74(a)gmail.com> wrote:
allright!
will try your config tonight for the voice. :)
thanks Pespin.
DUO
On Feb 19, 2018 6:46 PM, "Pau Espin Pedrol" <pespin(a)sysmocom.de> wrote:
--
Best Regards,
DUO
is it completed or I miss some to run?
Looks fine to me.
> we can use without osmo-pcu, osmo-ggsn and osmo-sgsn also osmo-hnbgw for
> 2g voice only?
Indeed you can drop those if you don't want data access, and osmo-hnbgw
if you are not using 3g.
--
- 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
21 Feb
21 Feb
5:43 a.m.
Thanks Pau!
I'm trying to use the configs you sent with osmo stack installed in my
PC, and the BTS running the a NuRAN LC15. From the osmo-bsc log, I get:
20180221013938451 DLINP <0013> input/ipa.c:265 accept()ed new link from
10.42.123.100 to port 3002
20180221013938451 DLINP <0013> bts_ipaccess_nanobts.c:416 Unable to find
BTS configuration for 1000/0/0, disconnecting
20180221013938451 DLINP <0013> input/ipaccess.c:161 Unable to set signal
link, closing socket.
Any idea what am I doing wrong?
Rafael Diniz
On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
Hi,
I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
similar setup since OsmoNITB is being deprecated and most development
work is happening in split componenets nowadays.
I attach my configs in case you want to start giving a try to the split
components.
5:51 a.m.
Try set the ip you see is same in config, example as default is 127.0.0.1.
DUO
On Feb 21, 2018 11:47 AM, "Rafael Diniz" <rafael(a)riseup.net> wrote:
Thanks Pau!
I'm trying to use the configs you sent with osmo stack installed in my
PC, and the BTS running the a NuRAN LC15. From the osmo-bsc log, I get:
20180221013938451 DLINP <0013> input/ipa.c:265 accept()ed new link from
10.42.123.100 to port 3002
20180221013938451 DLINP <0013> bts_ipaccess_nanobts.c:416 Unable to find
BTS configuration for 1000/0/0, disconnecting
20180221013938451 DLINP <0013> input/ipaccess.c:161 Unable to set signal
link, closing socket.
Any idea what am I doing wrong?
Rafael Diniz
On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
Hi,
I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
similar setup since OsmoNITB is being deprecated and most development
work is happening in split componenets nowadays.
I attach my configs in case you want to start giving a try to the split
components.
7:36 a.m.
New subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
I advanced here in putting the new split stack working. By mistake I put
different ip.access unit_id between bts and bsc... sorry my last email.
But still no luck.
Osmo-BSC gives me:
PART(T=Cause,L=4,D=00000300)
20180221033117954 DLSCCP <001e> sccp_scoc.c:1548 Received CO:RELRE for
local reference 1
20180221033117954 DLSCCP <001e> sccp_scoc.c:1581
SCCP-SCOC(1)[0x55decef19a70]{ACTIVE}: Received Event RCOC-RELEASED.ind
20180221033117954 DLSCCP <001e> sccp_user.c:156 Delivering
N-DISCONNECT.indication to SCCP User 'msc-0'
20180221033117954 DMSC <0008> osmo_bsc_sigtran.c:223 N-DISCONNECT.ind(1,
cause=768)
20180221033117954 DMSC <0008> osmo_bsc_sigtran.c:364 sccp connection
(id=1) not cleared (gsm subscriber connection still active) --
forcefully clearing it now!
20180221033117954 DMSC <0008> a_reset.c:175
A-RESET(msc-0)[0x55decef17b30]{CONN}: Received Event 1
20180221033117954 DLSS7 <001d> sccp_scrc.c:391
sccp_scrc_rx_scoc_conn_msg: HDR=(CO:RELCO,V=0,LEN=0),
PART(T=Routing Context,L=4,D=00000000),
PART(T=Destination Reference,L=4,D=00000002),
PART(T=Source Reference,L=4,D=00000001)
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:278
m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for
dpc=185=0.23.1: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-msc-0 proto=m3ua
20180221033117954 DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is
M3UA for dpc=185=0.23.1
20180221033117954 DLSS7 <001d> m3ua.c:507
XUA_AS(as-clnt-msc-0)[0x55decef16d80]{AS_ACTIVE}: Received Event
AS-TRANSFER.req
20180221033117954 DLSCCP <001e> sccp_scoc.c:972
SCCP-SCOC(1)[0x55decef19a70]{ACTIVE}: state_chg to IDLE
20180221033117954 DLSCCP <001e> sccp_scoc.c:420
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Terminating (cause =
OSMO_FSM_TERM_REQUEST)
20180221033117954 DLSCCP <001e> sccp_scoc.c:420
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Freeing instance
20180221033117954 DLSCCP <001e> fsm.c:344
SCCP-SCOC(1)[0x55decef19a70]{IDLE}: Deallocated
20180221033117954 DLINP <0013> stream.c:279 connected write
20180221033117954 DLINP <0013> stream.c:204 sending data
20180221033117954 DLINP <0013> stream.c:279 connected write
20180221033117954 DLINP <0013> stream.c:204 sending data
20180221033118184 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 DATA INDICATION
20180221033118184 DRSL <0004> bsc_api.c:803 Got data in non active
state(RELEASE REQUESTED), discarding.
20180221033118184 DLINP <0013> input/ipaccess.c:285 Bad signalling
message, sign_link returned error: Operation not permitted.
20180221033118419 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 DATA INDICATION
20180221033118419 DRSL <0004> bsc_api.c:803 Got data in non active
state(RELEASE REQUESTED), discarding.
20180221033118419 DLINP <0013> input/ipaccess.c:285 Bad signalling
message, sign_link returned error: Operation not permitted.
20180221033118654 DRLL <0000> abis_rsl.c:2169 (bts=0,trx=0,ts=0,ss=1)
SAPI=0 RELEASE INDICATION
20180221033120655 DRSL <0004> abis_rsl.c:1764 (bts=0,trx=0,ts=0,ss=1)
T3111 expired: releasing RF Channel
20180221033120656 DRSL <0004> abis_rsl.c:872 (bts=0,trx=0,ts=0,ss=1) RF
Channel Release
20180221033120657 DRSL <0004> abis_rsl.c:942 (bts=0,trx=0,ts=0,ss=1) RF
CHANNEL RELEASE ACK
20180221033120657 DRSL <0004> abis_rsl.c:85 (bts=0,trx=0,ts=0,ss=1)
state RELEASE REQUESTED -> NONE
Thanks!
Rafael Diniz
On 02/19/2018 07:20 AM, Pau Espin Pedrol wrote:
Hi,
I am not using OsmoNITB, but OsmoBSC+OsmoMSC. I encourage you to move to
similar setup since OsmoNITB is being deprecated and most development
work is happening in split componenets nowadays.
I attach my configs in case you want to start giving a try to the split
components.
11:23 a.m.
New subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
Hi Rafael,
I have no idea on what's wrong unless you provide more information on
what's exactly not working.
To give you some hints: In my configs, 192.168.30.1 is my laptop
(running all the core network) and 192.168.30.100 is my BTS (which
depending on the BTS is also in my laptop, so I assign 2 IPs to one
iface for simplicity of my configs).
--
- 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
2:09 p.m.
New subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
Hi Pau,
Can I use loopback addresses or should I use local network addresses?
Today I'll debug more the issue, but as soon as I make it work, I
publish my config files too.. I'm pretty certain I'm doing something wrong.
Btw, osmo-bsc_mgcp still need to be called together with current git
osmo-msc and osmo-mgw, right?
Thanks a lot, your config files are really helping.
Rafael Diniz
On 02/21/2018 07:23 AM, Pau Espin Pedrol wrote:
Hi Rafael,
I have no idea on what's wrong unless you provide more information on
what's exactly not working.
To give you some hints: In my configs, 192.168.30.1 is my laptop
(running all the core network) and 192.168.30.100 is my BTS (which
depending on the BTS is also in my laptop, so I assign 2 IPs to one
iface for simplicity of my configs).
4:36 p.m.
New subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
On 21/02/18 14:09, Rafael Diniz wrote:
Hi Pau,
Can I use loopback addresses or should I use local network addresses?
Unless I'm forgetting some detail, it shuld be fine to run everything
with loopback addresses.
Btw, osmo-bsc_mgcp still need to be called together
with current git
osmo-msc and osmo-mgw, right?
As far as I know latest osmo-msc already requires osmo-mgw.
--
- 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
23 Feb
23 Feb
4:26 a.m.
New subject: osmo-nitb and osmo-bts-trx problems with voice, no connection
Worked - I have voice! Thanks Pau.
But GPRS is not ok yet. I'm running osmo-bts-lc15 and osmo-pcu in the
LC15, and the core network in my development pc.
osmo-sgsn gives me:
20180223001319967 DMM <0002> gprs_sgsn.c:726
MM(724056406933460/ccb930f7) Subscriber data update
20180223001319967 DMM <0002> sgsn_auth.c:219
MM(724056406933460/ccb930f7) Updating authorization (unknown ->
authenticate)
20180223001319967 DMM <0002> sgsn_auth.c:236
MM(724056406933460/ccb930f7) Missing auth tuples, authorization not possible
20180223001319967 DMM <0002> sgsn_auth.c:248
MM(724056406933460/ccb930f7) Got authorization update: state unknown ->
rejected
20180223001319967 DMM <0002> gprs_gmm.c:1140
MM(724056406933460/ccb930f7) Not authorized, rejecting ATTACH REQUEST
with cause 'IMSI unknown in HLR' (2)
20180223001319967 DMM <0002> gprs_gmm.c:489 MM(724056406933460/ccb930f7)
<- GPRS ATTACH REJECT: IMSI unknown in HLR
But I added the IMSIs in HLR with
subscriber imsi 724056406933460 create
subscriber imsi 724056406933460 update msisdn 12345678
I run (nightly builds):
osmo-stp -c osmo-stp.cfg
osmo-bsc -c osmo-bsc-lc15.cfg
osmo-msc -c osmo-msc.cfg
osmo-hlr -l hlr.db -c osmo-hlr.cfg
osmo-mgw -c osmo-mgw-msc.cfg
osmo-mgw -c osmo-mgw-bsc.cfg
osmo-sgsn -c osmo-sgsn.cfg
sudo osmo-ggsn -c osmo-ggsn.cfg
Attached goes my configuration files.
Cheers,
Rafael Diniz
On 02/21/2018 12:36 PM, Pau Espin Pedrol wrote:
On 21/02/18 14:09, Rafael Diniz wrote:
Hi Pau,
Can I use loopback addresses or should I use local network addresses?
Unless I'm forgetting some detail, it shuld be fine to run everything
with loopback addresses.
Btw, osmo-bsc_mgcp still need to be called
together with current git
osmo-msc and osmo-mgw, right?
As far as I know latest osmo-msc already requires osmo-mgw.
2261
days inactive
2270
days old
16 comments
5 participants
participants (5)
-
Norbertas Kremeris -
Osmocom Mailing List -
Pau Espin Pedrol -
Rafael Diniz -
Sandi Suhendro