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.commailto: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.demailto: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.demailto: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.orgmailto: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.
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@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@gmail.com 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 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 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 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.
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.
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 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
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
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.demailto: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.demailto: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 hostinghttps://migadu.com?s=sent_via
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.
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@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@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
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.
allright! will try your config tonight for the voice. :)
thanks Pespin.
DUO
On Feb 19, 2018 6:46 PM, "Pau Espin Pedrol" pespin@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@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
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@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@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@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
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.
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@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.
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.
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).
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).
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.
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.
-
Norbertas Kremeris -
Osmocom Mailing List -
Pau Espin Pedrol -
Rafael Diniz -
Sandi Suhendro