Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.
The string representations change, which has cosmetic effects on the test suite
expectations.
Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
during code review, I completely overlooked this:
We've added the 'ipa-name', which identifies the MSC on the GSUP link to the
HLR, under the 'msc' section, while all other GSUP/HLR related config is under
the 'hlr' section.
Before we roll that out in a release, move it over to 'hlr'.
Related: OS#3355
Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
Probably fixes this segfault:
at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:957
file=file@entry=0x5611d8f10c28 "../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c", line=line@entry=1467)
at ../../../src/libosmocore/src/fsm.c:580
parent_event_failure=parent_event_failure@entry=6, parent_event_data=parent_event_data@entry=0x0, vlr=0x5611d98862b0,
msc_conn_ref=msc_conn_ref@entry=0x5611d9aa8150, type=VLR_LU_TYPE_REGULAR, tmsi=4294967295, imsi=0x7ffd756c1cf0 "262423403004874",
old_lai=0x7ffd756c1ce0, new_lai=0x7ffd756c1ce8, authentication_required=true, ciphering_required=true, is_r99=false, is_utran=false,
assign_tmsi=true) at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:1467
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:443
The segfault is indirectly caused by 1fbf45c291,
'enrich context for vlr_subscr_name and ran_conn fi name', which sets auth_fsm
context, on a non-NULL auth_fsm that has been deallocated.
Change-Id: I3c528eed295be2ee673ea295804372f388a0dccd
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx
FSM instance, so that the call gets torn down immediately. Before this, the
non-call would idle around without anything happening.
Related: OS#3236
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore)
Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
If a call is already busy and another call is coming in, do not try to
immediately assign an lchan (before this patch, it fails because there already
is an mgcp_ctx for the conn). Leave the second CC transaction waiting.
When a call is hung up, as soon as the old mgcp_ctx is discarded, look for
other CC transactions that are waiting. If there is one, trigger assignment, so
a new mgcp_ctx is set up for the new call.
This fixes the following scenario:
- from A, call B.
- from C, call B; B rings during ongoing call.
- in B, pick up the call, choose to drop the old call.
After this patch, and with osmo-bsc patch with change-id
I0c00ec2c120e5008281755adcd4944a3ce4d8355
we are now able to talk to the new caller.
I currently haven't tested yet what happens if there is *three* peers trying to
talk to the same number, running out of lab phones (not really, just not
bothering now). Possibly we should be taking over the particular call indicated
by the CC TI; instead, the current patch version takes on whichever waiting
call it finds first. This is fine if *one* additional call comes in on an
ongoing call, and this is already a huge improvement to what we had before.
Related: OS#3735
Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
The flag is set to true when an assignment has been started, and it is only
relevant for a CC transaction. So fix naming and place in cc struct.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
In rare cases, a conn is already associated with a subscriber. So far, we
abort()ed on that, bringing the entire osmo-msc down. Rather log an error and
keep the service running.
In vlr.ops.subscr_assoc, add success/failure return value, and abort the
LU/PARQ on error.
I haven't figured out in detail yet why/how a subscriber would re-launch a
LU/PARQ on a conn that is already associated, so far it is merely clear that we
do not want to crash the MSC if that happens. A log is in OS#3742.
Related: OS#3742, OS#3743
Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
Do not break the currently ongoing call when rejecting a second incoming
caller.
There may be multiple (up to seven) simultaneous CC transactions, and there is
one mgcp_ctx for the currently active RTP stream.
Release the MGCP context only when the active CC transaction is releasing.
Before this patch, any CC transaction release would destroy the single MGCP
context, possibly breaking the currently ongoing call (another CC trans).
This also fixes a possible use-after-free if there were pending MGCP message
responses for the MGCP context; they are canceled properly for a released
transaction, but since one transaction would free the other transaction's MGCP
state, the clean up did not take place and possibly caused an mgcp client
response handling to access a freed mgcp_ctx.
Related: OS#3735
Change-Id: I1f8746e7babfcd3028a4d2c0ba260c608c686c76
Use local variables instead of writing trans->conn-> all the time.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Change-Id: I99717b3b72a9d7cbc95455ea25b2018ec1755308
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS
processing, storage (in SQLite DB), and routing (via SMPP).
In real networks this is done by the external entity called
SMSC (SMS Centre), while the MSC is doing re-encapsulation
of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU)
between SM-RL (Relay Layer) and MAP.
Since OsmoMSC itself is not a 'Network in The Box' anymore, it
makes sense to replicate the 'traditional' behaviour of MSC.
The problem is that this behaviour cannot co-exist with the
current implementation, so the key idea is to rip out the
local SMS storage and routing from OsmoMSC, and (re)implement
it in a separate process (OsmoSMSC?).
As a temporary solution, this change introduces a 'kill-switch'
VTY option that enables routing of SMS messages over GSUP
towards ESME (through VLR and HLR), but breaks the local
storage and routing. This is why it's disabled by default.
As soon as we move the SMS processing and storage away from
OsmoMSC, this behaviour would be enabled by default, and
the VTY option would be hidden and deprecated. At the moment,
this option basically does nothing, and will take an effect
in the follow-up changes.
Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b
Related: OS#3587
We can check if we're parsing the config file by checking
whether vty->type equals VTY_FILE. This avoids the use of
an extra local variable to track the parsing state.
Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75
Fixes: 1051c42088
Related: OS#3355
When the VLR subscriber information is shown on the VTY it shows IMSI
and TMSI, but not IMEI and IMEISV. Since in some cases this information
might be helpful, lets display it as well.
Change-Id: Iedd75dbb9850388ec1fedb984ed0b8bf4c62e780
Always use LAC which is part of Cell Global ID otherwise we might end up
in a situation where separately stored LAC differs.
Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data
to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part
of LAI which is part of CGI so there should be no case when those values
differ for a given subscriber.
Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
When a subscriber is displayed the RAN type is not included in the
overview. Meanwhile the MSC supports multiple different ran types it
becomes important to see in which RAN the subscriber is currently
active.
Change-Id: I000cafd5e41b9951d51b6bd6672ee68a224b8212
Related: OS#3615
When a VLR subscriber is displayed on the VTY we get a lot of meta
information, but there are also some flags to handle the internal
subscriber status e.g. conf_by_radio_contact_ind. Lets display those
flags as well as this information can be very helpful when debugging
problems in the VLR
Change-Id: I59a9145a4daad50d68de3fd5c3291f027256917f
Do not show the VTY command's own use count during 'show subscriber <ID>'.
When using 'show subscriber msisdn 2023', I was surprised to see a use count of
2 and suspected a use count leak. With 'show subscriber cache' however, the use
count is 1.
So I realized it is the vty command's own use count that makes it two, besides
the lu_complete=true one.
Change-Id: Id02b57b7ed299b010b9f8b9e809548eb1e6aa699
Avoid leaking details on accessing data structure for LAC value into
test output: that's irrelevant clutter which forces unnecessary test
output modifications.
Change-Id: I4a1d7884cf47ad513d7d6fb27c5c6f1b829dff2e
To avoid leaking structure details into test we sometimes have to
separate value description from actual value. Introduce new macro which
makes that possible and convert old one into trivial wrapper around it.
Change-Id: Ic462297edac4c55689f93cc45771c8b5e2aed864
There is no state transition from INIT to WAIT_IMEI, only to WAIT_SUB_PRES.
If there were code to skip WAIT_SUB_PRES, the allowed state transitions would
have to be the same as for WAIT_SUB_PRES, i.e. also WAIT_IMEI_TMSI and
WAIT_TMSI_CNF. For now just opt for the status quo.
Change-Id: I18ef9e8c96b52401d98f49dc410f13681231b533
sub_pres_vlr_fsm_start() only ever has an effect if ms_not_reachable_flag ==
true. But there simply is no code that sets this flag. So
sub_pres_vlr_fsm_start() is currently dead code.
Also, examining the FSM, if it should ever be set to true, this would halt the
LU/CM Service/Paging response, since the FSM would merely change its state
without dispatching asynchronous messages. No chance of finishing.
Short of dropping the code entirely, first just mark it. The point being that
this models some FSM definition from 3GPP specs, and we have a couple other
"if (0)" branches in the VLR...
Change-Id: I198d442e9ed288f37c7d4e5ec87b82dc53114e99
They were on DEBUG during early development stages, and it's high time that I
drop those back to NOTICE.
Change-Id: I3b46e9107a7a1d81a44d2a2eb855c10960a1ab6b
The 'ipa-name' option can now only be set via the configuration file
because changing the IPA name at run-time conflicts with active
GSUP connections and routes configured in the HLR. The osmo-msc
program must be restarted if its IPA name needs to change.
Change-Id: I6cff91793e646e0396e8f1bc87d0f52709e5f12a
Related: OS#3355
Two reasons:
- the caller of msc_mgcp_ass_complete() from Iu, iucs_rx_rab_assign(), failed
to be adjusted, breaking IuCS, as an --enable-iu --enable-werror build shows.
Unfortunately our gerrit verification doesn't --enable-werror for osmo-msc.
- the condition of requiring ST_MDCX_RAN is faulty, breaking GSM CS.
This reverts commit 212c0c9bda.
Change-Id: I8348675c2f7c8856ea1682d05ee54160d4cfeb96
Provide software version information to the GSUP peer. The version now
shows up in logs like this: Software_Version='osmo-msc-1.2.0.120-1263b'
Change-Id: I2eba32569349facdbb1fda201067c62cc804ccf4
Depends: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
Related: OS#3355
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.
Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
sub_pres_vlr_fsm_start() starts the FSM, invokes the START event, and then this
FSM invariably always directly terminates when vsub->ms_not_reachable_flag ==
false.
So if it is false, there is not much use in instantiating a whole FSM instance
that just terminates again, we might as well directly issue the
parent-term-event and save some logging space.
The same condition is already in place in the vlr_proc_acc_fsm.c in
_proc_arq_vlr_node2_post_vlr() for CM Service Request and Paging Response. Now
also skip this for LU.
Change-Id: Id2303a795dfd381f76e94ff8ff2f495926ca8ba0
When a subscriber is cancelled, fake an IMSI detach to
ensure that the subscriber gets removed from the VLR.
I am not entirely sure if this change is correct but
it does make TTCN3 test MSC_Tests.TC_gsup_cancel pass.
Change-Id: I5918106e4a94ba2e6c61bcd7b90d3bf0565513cc
Related: OS#2886
It is a message that is initially permitted, but it is in fact not handled in
the L3 code but already before, upon receiving
BSS_MAP_MSG_CIPHER_MODE_COMPLETE.
Change-Id: I0079f07271ca76bd457d0e700f3a736eb9066b47
BSSMAP Assignment Complete: sort MGCP handling upon Assignment Complete to the
proper locations. a_iface_bssap.c is not the right place to invoke the MGCP
related procedures.
- in a_iface_bssap.c only decode the IEs.
- call ran_conn_assign_compl() and pass decoded values.
- drop msc_assign_compl(), it was dead code; instead:
- add ran_conn_assign_compl()
- pass on all MGCP related info to msc_mgcp_ass_complete()
- move all MGCP ctx related handling from a_iface_bssap.c to msc_mgcp.c.
I'm dropping some comments to save some time, because if I adjust them IMHO
they would still anyway restate the obvious.
ran_conn_assign_compl() is now quite a thin shim, but it makes sense to have
it:
- This is the place that should tear down the ran_conn in case assignment
failed, left for a future patch.
- In the light of upcoming inter-MSC handover, ran_conn_assign_compl() will be
the place where the Assignment Complete message might be relayed to a remote
MSC.
Change-Id: I8137215c443239bddf3e69b5715839a365b73b6c
BSSMAP Assignment Complete:
Do not invoke ran_conn_rx_sec_mode_compl(), that's just weird.
Instead this should call msc_assign_compl(), which is currently dead code and
does nothing ... and there are some more strings attached, being resolved in a
subsequent patch.
Change-Id: I448fdb783364628005437b3d866d1a076a9767d7
So far the only way to use external MNCC is to pass the -M cmdline arg:
osmo-msc -M /path/to/socket
However, the osmo-msc.service file for systemd is installed by 'make install',
and hence it is quite impractical to depend on such a config item to be
required in the service file:
- It defies any scheme an operator may have in place to compose the
osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs
separate action to add to the installed service file.
- After a make install or package upgrades / re-installations, this option will
be plain overwritten silently, or lead to the need for resolving file
conflicts.
The initial spark for this came from configuring the 35c3 GSM from cfg
templates.
Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most
sense to have a common 'mncc' keyword to start MNCC config commands with. To
put it in terms of VTY online help:
OsmoMSC(config-msc)# mncc ?
internal Use internal MNCC handler
external Use internal MNCC handler
guard-timeout Set global guard timeout
So far only the 'guard-timeout' exists, I want to add 'internal' and 'external'
in a subsequent commit.
Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it
still works from old config files, but online documentation will omit it.
On 'write', write back the new format instead.
Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee
Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
First step towards allowing to configure the MNCC socket path by config file.
Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee
Change-Id: Ifc87c1cacaa809d04fc23e8ccd761bee4509c805
It needs to work whether SMPP,Iu are enable or disabled, hence a bit more
wildcarding than one might expect.
Change-Id: I3a8c50d8d555b6b948d97d6412e17594ee439de0
Separate 'make python-test' into separate make targets, to sensibly add VTY
transcript tests in an upcoming commit.
Feature: even though ./configure was called without --enable-external-tests,
each of the {ctrl,vty}x{python,transcript} tests can be invoked individually by
e.g. 'make vty-python-test'.
Both 'vty-transcript-test' and 'ctrl-transcript-test' are still empty, a
subsequent patch adds a vty-transcript-test.
All of this in preparation of tweaking the 'mncc' vty configuration, to be able
to track it in a vty transcript test.
Change-Id: I688657e56ae469c07b9f25ba37275d38dbd457e2