Add a network -> callwaiting VTY command as boolean.
When this is enabled (default) there is no change to
operation previous to this commit.
When this switch is disabled with "no call-waiting" in vty
then when a call arrives, we will check if we have an active
call transaction for this subscriber, no matter if it is
establishing, established, or alerting, in any of these cases we
will return USER BUSY to the calling party.
Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: Ia2b24ffd7f9cbb271fcdb979b851f3a07b9d6d3e
Related: OS#4138
in osmo-msc/Makefile.am, osmo-msc was actually missing the LIBASN1C_LIBS even
though it included LIBASN1C_CFLAGS. Probably libasn1c is implicitly linked from
libranap.so, but doesn't hurt to name it.
When building without Iu support, the LIBOSMORANAP* and LIBASN1C* vars are
empty, so no need to explicitly switch on BUILD_IU, just name them.
Change-Id: I39ae5e3f0f7661ca9ee5c17a500be28c461d7ec7
DB counters has been used to save osmo_counters & osmo_rate_ctr to a local
sqlite databases every 60 seconds.
This is quite slow e.g. 1000 subscriber might slow the msc down.
Change-Id: Id64f1839a55b5326f74ec04b7a5dbed9d269b89c
Get rid of the legacy name bscconfig.h from osmo-nitb times.
Remove the #include from some of the files that aren't actually using it.
Instead of '#include "../../config.h"', use plain '#include "config.h"'
because we're anyway passing $top_srcdir as -I during compilation.
Change-Id: Id4f683be1f36f0630c83da54e02868aae847aeec
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.
Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
It was observed that the SGs server is started before
the actual VTY configuration is parsed. For example:
sgs
local-port 9999
local-ip 127.0.0.1
vlr-name vlr.example.net
produces the following debug output:
<0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118
DLSS7 NOTICE <001e> osmo_ss7.c:1284 0: ASP Restart for server not implemented yet!
DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:9999
DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=127.0.0.1:9999
DMNCC DEBUG <0004> msc_main.c:604 Using internal MNCC handler.
The first startup is triggered by sgs_iface_init(), before reading
the VTY configuration, so the logging style is different. The next
two calls to sgs_server_open() are triggered during reading of the
VTY configuration by cfg_sgs_local_port() and cfg_sgs_local_ip().
Let's avoid starting the SGs server three times, and do it once,
after the VTY configuration is parsed. Also, keep the possibility
to change the binding parameters at run-time.
Change-Id: Ie0c31205ac48be7e50d0380a89833771b2708da4
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)
Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
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
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
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
First step towards allowing to configure the MNCC socket path by config file.
Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee
Change-Id: Ifc87c1cacaa809d04fc23e8ccd761bee4509c805
For hysterical raisins, there are some header files that contain few
declarations, and where the name doesn't reflect the content. Combine them to
new msc_common.h:
- common.h
- common_cs.h
- osmo_msc.h
Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
Otherwise they end up in the NULL ctx.
Depends: libosmocore Change-Id Id58ca18eb826b8f4183a7cf0dbb2b38cba702a09
Change-Id: I5d5b456eb85fbdb0ca2140c56ebf3d207b4a0bba
Tracking NULL memory contexts allows one to detect memory chunks,
allocated outside the application's root context, which in most
cases are results of some mistake.
In b874486e8e the repotring of
NULL-context state was introduced, but without asking talloc
to track the use of NULL memory contexts it doesn't make sense.
Change-Id: I4b5e3946ee21c7d0ed6c66b1059dbce5ad312f88
This is a follow up change before enabling the track of NULL talloc
contexts. Since there is no other way to deinitialize libosmovty,
let's free its root context on exit. Otherwise one would see
lots of memory chunks on exit...
Change-Id: I278f85f023210de6b4626d4493d10d20996f606a
osmo-hlr has recently (as of Change-Id
Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library
implementation of libosmo-gsup-client.
We can remove the local implementation in osmo-msc and use the
system-installed shared library instead.
Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
Since the logging allocations now also show up in the root context report, some
tests need adjusted talloc checks.
In msc_vlr_tests, also output the number of talloc blocks before tests are
started to show that the number didn't change after the tests.
Change-Id: Iae07ae60230c7bab28e52b5df97fa3844778158e
All that is left in libcommon now are the GSUP and OAP client implementations.
These are duplicated in osmo-sgsn.git and make sense to remain somewhat
separate from libmsc. So now they get their own little lib.
Change-Id: Ic71aa119c233b6a0ae169a5b2a53819903d2be82
Drop tall_bsc_ctx; in mncc_sock_init(), talloc the mncc_sock_state from
gsm_network.
In tests or utils, move from using an extern tall_bsc_ctx to a local root
context pointer.
Change-Id: I92c252be1d1e7634f1653de47d37c99d77d9501c
Apply more concise logging categories in each main scope. The bulk goes to
msc_main.c, obviously, while tests and utils get a slimmed down bunch of
logging categories.
Change-Id: I969a0662ba273f3721b6820d02151b7a5b8014b8
From openbsc.git, we still have osmo-msc's VTY definitions spread across
various places. Combine:
- Move the go_parent_cb() and is_config_node() to msc_main.c, drop
common_vty.c.
- Move all of vty_interface_layer3.c into msc_vty.c.
- Move all of common_cs_vty.c into msc_vty.c.
- Move bsc_vty_init_extra() into msc_vty_init().
- Drop some unused definitions
No functional nor cosmetic changes have been made in the moved code, plain
copy-paste moving (even though the unidiff might look like edits in some
places). I might have adjusted some blank lines though.
Change-Id: Ia818c00ab613a19a34080b160d763b55c19f76b1
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)
Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ibcd1cc38f170895305ae176a5574384c74a33939
This belongs into the BSC and has no relevance in the MSC, as the MSC
has no clue about dynamic timeslots.
Related: OS#2528
Change-Id: Iaa41d22db81120572d4cd2c0c4c75d258947a42f
osmo-msc still had large amounts of dead code that came along from
openbsc.git. This commit removes a lot of it, mostly stuff relevant
only to the BSC side of things (or even GPRS).
Change-Id: I247def85da2dc3ec461389fb74414a0d964e7e3c
Related: OS#2528
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
Related: OS#1694
Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
The commandline option -m has already been deprecated before the
split. Use the split as an opportunity to get rid of this option.
Change-Id: Ie23d492a839aae85470e39b0d0ad8f57b0d38f7e
We usually have both A and IuCS on 0.23.1, using differing SSNs.
0.23.2 was used only if there was a separate cs7 instance for Iu, which is not
practical, and even if used does not conflict with 0.23.1 (since it would be on
a different STP).
Just use 0.23.1 for all SCCP clients.
This needs adjustment of
https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
Change-Id: I3d5466eff5680cb5aa95a76a9e179fdf88ce8aa0
osmo-msc doesn't use any API/symbols of libasn1c directlry. Rather,
we use libosmo-ranap which in turn uses libasn1c. Let the linker
work out that dependency.
This fixes the following dpkg-shlibdeps warning:
Change-Id: I2f840884d8f1cc542de1e26acd3d4215bd2fd899
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-msc/usr/bin/osmo-msc was not linked against libasn1c.so.0 (it uses none of the library's symbols)
After osmo-mgw changes I8e0b2d2a399b77086a36606f5e427271c6242df1 and
I99f7faab637cfcc22ece64a1dbcbe590f2042187, apply linking of new
libosmo-mgcp-client and renames to drop the "gw" from mgcp_client_*.
Also rename the gsm_network.mgcpgw to mgw, to indicate that the MGCP client is
used to contact the MGW (Media Gateway).
Depends: I8e0b2d2a399b77086a36606f5e427271c6242df1 (osmo-mgw)
I99f7faab637cfcc22ece64a1dbcbe590f2042187 (osmo-mgw)
Change-Id: I093ad02ca0e532f659447c785e09678b3e6f220d