29 May
2020
29 May
'20
8:45 a.m.
Hi Community,
Does anyone here tried to upgrade the your working OSMO environment to its latest version?
I have the experience where I upgraded my working osmo to the latest version and I have
encountering some problem between the connection of osmo-nitb and osmo-sip-connector. For
the latest sip connector update it will communicate the connection going to osmo-msc.
Since I don’t use the osmo-msc instead I am using the osmo-nitb for the standalone
project. Below is the error I have experiencing right now in the osmo-sip-connector and
osmo-nitb.
SIP Connector Logs:
<0001> mncc.c:845 Incompatible version(5) expected 6
<0001> mncc.c:936 Reconnected to /tmp/msc_mncc
<0001> mncc.c:841 Got hello message version 5
<0001> mncc.c:845 Incompatible version(5) expected 6
<0001> mncc.c:936 Reconnected to /tmp/msc_mncc
<0001> mncc.c:841 Got hello message version 5
<0001> mncc.c:845 Incompatible version(5) expected 6
OSMO-NITB Logs:
Fri May 29 13:13:16 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection
Fri May 29 13:13:16 2020 <0001> gsm_04_08.c:463 Clearing all currently active
transactions!!!
Fri May 29 13:13:21 2020 <0006> mncc_sock.c:271 MNCC Socket has connection with
external call control application
Fri May 29 13:13:21 2020 <0006> mncc_sock.c:84 MNCC Socket has LOST connection
Fri May 29 13:13:21 2020 <0001> gsm_04_08.c:463 Clearing all currently active
transactions!!!
Here are the configuration file of osmo-nitb and osmo-sip-connector and how we run the
command.
SIP Connector:
Command to run: ./osmo-sip-connector -c ~/osmo-sip-connector.cfg
Config File:
#
sip
local 192.168.1.166 5062
remote 192.168.1.166 5060
sofia-sip log-level 2
mncc
socket-path /tmp/msc_mncc
app
OSMO NITB:
Command to run: ./osmo-nitb -C -c ~/osmo-nitb.cfg -T -P -l /home/hlr.sqlite3 -M
/tmp/msc_mncc
Config File:
line vty
no login
!
e1_input
e1_line 0 driver ipa
e1_line 0 port 0
no e1_line 0 keepalive
network
network country code 94
mobile network code 1
short name 1
long name 1
auth policy accept-all
authorized-regexp .*
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 t3109 1
timer t3105 1
timer t3113 60
timer t3103 1
timer t3122 10
timer t3101 10
dyn_ts_allow_tch_f 0
subscriber-keep-in-ram 1
bts 0
type sysmobts
band GSM900
cell_identity 1
location_area_code 1
base_station_id_code 63
ms max power 0
cell reselection hysteresis 4
rxlev access min 0
periodic location update 30
radio-link-timeout 32
channel allocator descending
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
early-classmark-sending forbidden
ip.access unit_id 1000 0
oml ip.access stream_id 255 line 0
neighbor-list mode automatic
codec-support fr hr efr amr
amr tch-h modes 0
amr tch-h start-mode auto
gprs mode gprs
gprs 11bit_rach_support_for_egprs 0
gprs routing area 1
gprs network-control-order nc0
gprs cell bvci 2
gprs cell timer blocking-timer 3
gprs cell timer blocking-retries 3
gprs cell timer unblocking-retries 3
gprs cell timer reset-timer 3
gprs cell timer reset-retries 3
gprs cell timer suspend-timer 10
gprs cell timer suspend-retries 3
gprs cell timer resume-timer 10
gprs cell timer resume-retries 3
gprs cell timer capability-update-timer 10
gprs cell timer capability-update-retries 3
gprs nsei 101
gprs ns timer tns-block 3
gprs ns timer tns-block-retries 3
gprs ns timer tns-reset 3
gprs ns timer tns-reset-retries 3
gprs ns timer tns-test 30
gprs ns timer tns-alive 3
gprs ns timer tns-alive-retries 10
gprs nsvc 0 nsvci 101
gprs nsvc 0 local udp port 23000
gprs nsvc 0 remote udp port 23000
gprs nsvc 0 remote ip 127.0.0.2
gprs nsvc 1 nsvci 0
gprs nsvc 1 local udp port 0
gprs nsvc 1 remote udp port 0
gprs nsvc 1 remote ip 0.0.0.0
no force-combined-si
trx 0
rf_locked 0
arfcn 74
nominal power 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
trx 1
rf_locked 0
arfcn 65
nominal power 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 fr
default-codec tch-h amr
nitb
subscriber-create-on-demand
subscriber-create-on-demand random 100000 199999
no assign-tmsi
smpp
local-tcp-ip 127.0.0.1 2776
system-id password
policy closed
smpp-first
esme root
password password
default-route
Thank you.
Sonny
29 May
29 May
10:19 a.m.
Hello Sonny,
thank you for such a detailed report.
Does anyone here tried to upgrade the your working
OSMO environment to its latest version?
I guess almost everybody (at least in development team) nowadays is
using the new CNI stack with separate components (BSC, MSC, HLR),
because osmo-nitb has been deprecated years ago. We don't really want
to look back all the time and keep compatibility layers for osmo-nitb
in other components. This means that you're mostly on your own with
osmo-nitb.
Since I don’t use the osmo-msc instead I am using the
osmo-nitb for the standalone project
I would still recommend you to use the new stack, since we have fixed
tons of bugs and implemented many new features. But if it's not
possible, you could try to downgrade osmo-sip-connector.
Alternatively, you could implement handling of the new MNCC protocol
version (6) in osmo-nitb. I believe it's just a few minutes of work,
basically: updating some structures and bumping protocol version in
the header file. Patches are welcome ;)
Good luck!
With best regards,
Vadim Yanitskiy.
6:13 p.m.
Hi Sonny,
On Fri, May 29, 2020 at 06:45:31AM +0000, Sonny Lafuente wrote:
Since I don’t use the osmo-msc instead I am using the
osmo-nitb for the standalone project. Below is the
error I have experiencing right now in the osmo-sip-connector and osmo-nitb.
Sorry but - everyone is free to shoot themselves into the foot. If you
are using software that is abandoned,
deprecated and unmaintained for several years now (osmo-nitb), you
cannot expect any support for this by the community - particularny not
if you want to combine it a much more modern osmo-sip-connector.
Either you use ancient osmo-nitb with ancient lcr or osmo-sip-connector
(and no support), or you use a CNI based network with separate BSC, STP,
MGW, MSC, HLR, ... - which will also give you many years worth of
bugfixes.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
6:44 p.m.
Sonny,
I had been thinking about dealing with this for sometime now, as Vadim
says, not a big job,
I had just wondered whether to "upgrade" the mncc support in osmo-nitb
or else to make a configuration variable in osmo-sip-connector for
"mncc-version" and make the new code dependent on that. Probably the
first option would be most acceptable as why burden the
osmo-sip-connector with code to support something obsolete? On the other
hand you add some code to osmo-nitb just to throw it away, (the nitb
won't use any of the new fields in the MNCC version 6.)
Partly I never did either, as I don't want to bother code reviewers with
supporting osmo-nitb.
I totally am with what Harald says, at the same time, it has kind of
annoyed me that we still publish packages for osmo-nitb and
osmo-sip-connector and that combination has not worked now for some time.
So, in the meantime, if you MUST use osmo-nitb, unless you still have a
package for your OS around, (check in your apt cache?) I'd suggesting
building osmo-sip-connector version 1.3. It's a fairly easy build.
If you really really have a pressing reason why you cannot move to the
new core network stack and you absolutely cannot find a solution, Tell
me something about your use case, either PM or here on the list, I can
help out one way or another.
k.
30 May
30 May
1:25 a.m.
Hi Keith,
Thank you for this. I just downgraded the osmo-sip-connector just to support the version
of osmo-nitb.
Regards,
Sonny
On May 30, 2020, at 12:44 AM, Keith <keith(a)rhizomatica.org> wrote:
Sonny,
I had been thinking about dealing with this for sometime now, as Vadim
says, not a big job,
I had just wondered whether to "upgrade" the mncc support in osmo-nitb
or else to make a configuration variable in osmo-sip-connector for
"mncc-version" and make the new code dependent on that. Probably the
first option would be most acceptable as why burden the
osmo-sip-connector with code to support something obsolete? On the other
hand you add some code to osmo-nitb just to throw it away, (the nitb
won't use any of the new fields in the MNCC version 6.)
Partly I never did either, as I don't want to bother code reviewers with
supporting osmo-nitb.
I totally am with what Harald says, at the same time, it has kind of
annoyed me that we still publish packages for osmo-nitb and
osmo-sip-connector and that combination has not worked now for some time.
So, in the meantime, if you MUST use osmo-nitb, unless you still have a
package for your OS around, (check in your apt cache?) I'd suggesting
building osmo-sip-connector version 1.3. It's a fairly easy build.
If you really really have a pressing reason why you cannot move to the
new core network stack and you absolutely cannot find a solution, Tell
me something about your use case, either PM or here on the list, I can
help out one way or another.
k.
1:27 a.m.
Hi Vadim,
Thank you for the information. I just downgraded the version of my sip-connector just to
support the version of my osmo-nitb.
Regards,
Sonny
On May 29, 2020, at 4:19 PM, Vadim Yanitskiy <axilirator(a)gmail.com> wrote:
Hello Sonny,
thank you for such a detailed report.
Does anyone here tried to upgrade the your
working OSMO environment to its latest version?
I guess almost everybody (at least in development team) nowadays is
using the new CNI stack with separate components (BSC, MSC, HLR),
because osmo-nitb has been deprecated years ago. We don't really want
to look back all the time and keep compatibility layers for osmo-nitb
in other components. This means that you're mostly on your own with
osmo-nitb.
Since I don’t use the osmo-msc instead I am using
the osmo-nitb for the standalone project
I would still recommend you to use the new stack, since we have fixed
tons of bugs and implemented many new features. But if it's not
possible, you could try to downgrade osmo-sip-connector.
Alternatively, you could implement handling of the new MNCC protocol
version (6) in osmo-nitb. I believe it's just a few minutes of work,
basically: updating some structures and bumping protocol version in
the header file. Patches are welcome ;)
Good luck!
With best regards,
Vadim Yanitskiy.
1453
days inactive
1453
days old
5 comments
4 participants
participants (4)
-
Harald Welte -
Keith -
Sonny Lafuente -
Vadim Yanitskiy