I'm not sure why so many files (particularly written by Neels)
did contain a GPLv2+ header, instead of the AGPLv3+ which is the
actual overall project license. I consider it a mistake.
In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.
The only GPLv2-or-later file remaining is mncc_internal.c, as it has
more contributors and a longer history.
Change-Id: I8650697592b3160c4d0a7c61ae9c46d4aacb3bef
"[ESTABLISHED] transition to state ESTABLISHED not permitted"
i.e. don't complain when we already are in the established state.
Change-Id: I9b1fd63ed1ee7ed2877a4b2059386354598f4ea4
This is a fixup for the patch
'3G: decapsulate IuUP to AMR at the MGW; allow 3G<-AMR->2G'
I386a6a426c318040b019ab5541689c67e94672a1
After above patch, osmo-msc intelligently decides which codecs to run on
which legs of the RTP streams. In the meantime, it seems the necessary
matching changes to call_leg_local_bridge() had been lost somehow.
Testing 3G to 3G voice now, I noticed that call_leg_local_bridge()
overwrites the intelligent choices made earlier.
The history of an MGW endpoint that should convert from IUFP to plain
AMR, extracted from a pcap, looks like this:
<- CRCX None None
-> CRCX-OK audio 4050 RTP/AVP 112 None
<- MDCX audio 4056 RTP/AVP 112 AMR
-> MDCX-OK audio 4050 RTP/AVP 112 AMR
<- MDCX audio 4056 RTP/AVP 96 VND.3GPP.IUFP
-> MDCX-OK audio 4050 RTP/AVP 96 VND.3GPP.IUFP
So after call_leg_local_bridge(), there is an extra MDCX + MDCX-OK that
switches the codec from 112 AMR back to 96 IUFP.
That is because call_leg_local_bridge() copies the *RAN* side's codec to
both CN sides, which used to be ok when RAN and CN codecs were always
identical.
Instead, adjust only the CN sides of the MGW endpoints, and adjust them
so that both CN sides are identical. osmo-mgw should then be able to
trivially translate the codecs appropriately.
Change-Id: I130bcd77ec57e332370c487a11b0b973b6e1089d
Allow the caller of rtp_stream_alloc() to define what events will be
dispatched to the parent FSM. This allows other state machines to use
rtp_stream. It is required for using RTP stream process with VGCS FSM.
Drop the unused parent_call_leg member.
Change-Id: I0991927b6d00da08dfd455980645e68281a73a9e
Related: OS#4854
So far rtp_stream_commit() triggers an MGCP MDCX message only when
codecs or the RTP address changed.
Do the same for mode changes. ('sendrecv', 'recvonly', 'sendonly',...)
Change-Id: I7a5637d0a7f1df13133e522fc78ba75eeeb2873e
Related: OS#4854
Allow configuring MGW conns with multiple codecs. The new codecs filter
can have multiple results, and MGCP can configure multiple codecs. Get
rid of this bottleneck, that so far limits to a single codec to MGW.
On Assignment Complete, set codec_filter.assignment to the assigned
codec, and use that to set the resulting codec (possibly multiple codecs
in the future) to create the CN side MGW endpoint.
Related: SYS#5066
Change-Id: If9c67b298b30f893ec661f84c9fc622ad01b5ee5
Since call_leg_fsm_releasing_onenter() calls immediatelly
osmo_fsm_inst_term(), it meant we couldn't receive any event in that
state because osmo_fsm disables event dispatching to FSMs being
terminated.
As a result, CALL_LEG_EV_MGW_ENDPOINT_GONE was never received and hence
call_leg_mgw_endpoint_gone() was never called, which means the
mgcp_client used in cl->mgw_endpoint was never put back to the pool.
By first freeing all the children (rtp_streams), we make sure
cl->mgw_endpoint ends up with no conns and sends us the GONE event
before we go ourselves into termination state.
Related: SYS#5987
Change-Id: I2126578c4e64c9f336e8a1f6ee98de970866b8dc
Large RAN installations may benefit from distributing the RTP voice
stream load over multiple media gateways.
libosmo-mgcp-client supports MGW pooling since version 1.8.0 (more than
one year ago). OsmoBSC has already been making use of it since then (see
osmo-bsc.git 8d22e6870637ed6d392a8a77aeaebc51b23a8a50); lets use this
feature in osmo-msc too.
This commit is also part of a series of patches cleaning up
libosmo-mgcp-client and slowly getting rid of the old non-mgw-pooled VTY
configuration, in order to keep only 1 way to configure
libosmo-mgcp-client through VTY.
Related: SYS#5091
Related: SYS#5987
Change-Id: I7670ba56fe989706579224a364595fdd4b4708ff
This happens if for instance an HNBGW drops the RAB-AssignmentRequest
and does nothing with it.
call_leg.c:348:15: runtime error: member access within null pointer of type 'struct rtp_stream'
Related: OS#5401
Change-Id: I67d2d5b2dd3b367c34f929d63c056306ec001431
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I1b68e0aa26d81fbfe26abaa287d2bd5eec2cfd0f
Timer X1 is not defined in libosmo-mgcp-client, so this tdef had no effect.
Change this to X2427.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
(X2 is still used in call_leg.c itself)
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I9804fdb2c24f49910f2386e3788bd1107b8ebc40
Also regard an RTP port as invalid if the IP address is 0.0.0.0.
Achieve this by using osmo_sockaddr_str_is_nonzero() instead of
osmo_sockaddr_str_is_set().
Depends: I73cbcab90cffcdc9a5f8d5281c57c1f87b2c3550 (libosmocore)
Change-Id: I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd
The event is actually never dispatched and useless, because when an RTP stream
releases, the call_leg terminates directly anyway (which wasn't apparent when
starting to design the call_leg FSM yet).
Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
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
Harald Welte
Neels Hofmeyr
Andreas Eversberg
Vadim Yanitskiy
Pau Espin
Oliver Smith