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
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.
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@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.
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
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.
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@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.
-
Harald Welte -
Keith -
Sonny Lafuente -
Vadim Yanitskiy