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
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5
Change-Id: Ic473fe05c55e8df3eddedf0260ec04b6fefc501f
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
The global g_smsc struct pointer is defined twice in the same file.
Let's keep the earlier definition.
Related: OS#5568
Change-Id: If96a44450563d45b707bdd4165cf3cf269db9906
The timer "mgw X2" (RTP stream establishing timeout)
is set by default to 30 seconds.
When an MT call is ringing and remains unanswered, it
is this timer that will expire, and the call is terminated.
Up to now this results in a CC_CAUSE of Resource Unavailable
and if osmo-sip-connector is in use, the SIP agent will
get 503 Service Unavailable.
While "resource unavailable" may be technically correct, in
that the MGW did not return an rtp stream in time, returning
"No User Responding" (resulting in SIP 480) is probably a
more accurate description of what actually happened,
allowing the switch to inform the caller.
Change-Id: I4a9cfc388ec9ecb743d154a114a6db638eac4701
Move it closer to the other MNCC_F_* entries, so that it's more
likely that it gets updated when new flags are added.
Change-Id: If1a12a696b87184c9eee14f475594c317927427b
Related: OS#5282
In c6921e5068, 0x4000 was added to the
possible MNCC field flags, but before this commit, using it would
result in an ERROR of "Unknown MNCC field mask 0x....."
Related: OS#5282
Change-Id: I9e7d224e7f2d6d2824b2466752b6e8c994ac5a3d
This helps to merge similar code from smpp_mirror and smpp_* in follow-up patches.
Related: OS#5568
Change-Id: I8f7ac2c00d16660925dd0b03aa1a0973edf9eb70
As part of preparation for libosmo-netif migration let's move common SMPP code
into separate build-time library and use it for both smpp_mirror and OsmoMSC
renaming the files if necessary.
While at it we also fix id/password legth limits in smpp_mirror and drop unused
fields from ESME struct.
Related: OS#5568
Change-Id: I61910651bc7c188dc2fb67d96189a66a47e7e8fb
This allows us to drop single-use parameters from osmo_esme to facilitate further code changes.
Related: OS#5568
Change-Id: I34bd4c145b0f6287a323e2350808feb59f1d3187
Having smpp_smsc_stop() called from within smpp_smsc_start() instead of
explicitly inside smpp_smsc_restart() is confusing and could lead to
hard-to-trace bugs. Let's get this fixed first before going further.
Related: OS#5568
Change-Id: I353f5b82c9f5308d93e926538d4ef7e24d0b0339
Some functions act on a struct sdp_audio_codecs but begin with the name
sdp_audio_codec (singular). That's confusing.
Related: SYS#5066
Change-Id: Id87eb350c1f17f8dbf776909824bfa06634c1d04
A problem with SDP fmtp handling is visible in this patch: when cmp_fmtp
is true, we compare fmtp strings 1:1, which is not how things should be
done. The intention is to fix fmtp handling in a later patch.
At least there now is a flag to bypass fmtp comparison altogether.
Related: SYS#5066
Change-Id: I18d33e189674229501afec950aa1c732386455a2
libsqlite3 that ships with some distributions may have secure_delete
activated by default. This means all database records are overwritten
with zeros on DELETE. We don't needs this extra overhead.
Change-Id: I9da6499a38096c8df2025bb9d35ec789864b7c5e
The Binary format changed when libdbi was removed. If we let osmo-msc run on an
unconverted database, the results are unpredictable, certainly undesirable.
Change-Id: I887b6a4374b1c83684f4007e9791ae58bba4e8c1
This is meant as a safeguard against users or user equipment which
doesn't set a reasonable validity period. Using this setting, the
SMSC administrator can set a minimum SMS validity period. Any SMS
submitted with lower validity period will be extended to that minimum.
Change-Id: I192528a6f9059d158fa12876a247d61bd7edaec8
Related: OS#5567
Before this patch, we always ignored any SMPP-provided validity period
and used '0' which is now, and means it expires immediately.
As SMPP allows for validity_period of NULL, use 7 days as SMSC default
in such situations.
Change-Id: Iad9f2697f045ed3bc0eb74c3a9730861f82e6c48
Closes: OS#5567
This introduces some VTY settings that determine if delivered
or expired messages should be removed from he SQL database or not.
Change-Id: Id6174875d5c01c40d987077651b27ae1acbcaa93
The pre-historic sms_queue code used to have very strange aspects,
such as having some parameters (max-failure, max-pending) which could
only be sent from the 'enable' node, but not from a config file.
Before adding more configuration parameters, let's clean this up by
introducing a proper VTY config node for the 'smsc'; move the existing
config commands there and add new ones for max-failure and max-pending.
As the sms_queue data structure is only allocated after the config file
parsing happens, we are introducing a new 'sms_queue_config' data
structure. This encapsulates the public readable/writable config
parameters.
Change-Id: Ie8e0ab1a9f979337ff06544b9ab3820954d9804a
As we're using WAL mode, it is not neccessary to use synchronous=FULL
but rely on synchronous=NORMAL mode while still guaranteeing database
consistency.
To do this, we can fix the typo in one of our two PRAGMA statements,
and remove the other.
See https://www.sqlite.org/pragma.html#pragma_synchronous for the
sqlite3 documentation on that topic.
Change-Id: Ie782f0fe90e7204c4d55cdb3948b728c348367d1
Closes: OS#5566
RelateD: OS#5564, OS#5563
The choice of libdbi was one of the biggest early mistakes in (back
then) OpenBSC development. A database abstraction library that
prevents you from using proper prepared statements. Let's finally
abandon it and use sqlite3 directly, just like we do in osmo-hlr.
I decided to remove the database migration code as it would be relatively
cumbersome to port all of it to direct sqlite3 with prepared statements,
and it is prone to introduction of all kinds of errors. Since we don't
have a body of older database files and comprehensive migration tests,
it is safer to not offer migration code of uncertain quality. The last
schema revision (5) was introduced 5 years ago in 2017 (osmo-msc
v1.1.0), so it is considered an exceptionally rare case. People can
install osmo-msc 1.1.0 through 1.8.0 to upgrade to v5 before using
this new 'direct sqlite3' version of osmo-msc.
Change-Id: Ia334904289f92d014e7bd16b02b3b5817c12c790
Related: OS#5559, OS#5563, OS#5564
Both callers would immediately execute sms_pending_add() after
a successful sms_pending_from(); we can merge those two functions.
Change-Id: Iaf37234b3caafd568dd4fe17739be9ec842c2a8d
This avoids every caller from manually having to remember to
increment the count, the stat_item and llist_{add,del}.
Change-Id: Ice4c73727ef2d7e4118f0ef5fe24cae943c7528f
If the ESME has been disconnected (dead socket) but still is
in memory (other users hold a use count), we shouldn't enqueue
messages to the write queue.
This prevents messages like
DSMPP write_queue.c:112 wqueue(0x7f8bc392f6e0) is full. Rejecting msgb
Change-Id: I10a270f1d555782be272f4d78da43190618a9950
Closes: OS#3278
When the SMPP code free's an ESME it also free's the related write_queue
and the osmo_fd contained therein. So if this happens while we are
in esme_link_read_cb(), we must return -EBADF to make
osmo_wqueue_bfd_cb() of libosmocore avoid further accessing related
memory.
Change-Id: I441d3b05c2f2556c530783a7f66c73adf6d845a1
Closes: OS#5565
This should give us some more insight into what is happening inside
the MSC's VLR in terms of number of subcribers, rate of successful /
unsuccessful GSUP procedures, etc.
Related: OS#1974
Change-Id: I681bcfc1875363478190151f2931cad197323ee8
The function vlr_subscr_rx_imsi_detach() implies that an explicit IMSI
DETACH was received. However, that same function was called in other
situations such as timer expiration or GSUP CANCEL.
Let's clean this up by splitting the function into two parts.
No logical change is introduced to the VLR in this patch.
Change-Id: Iffc02f3062ad591ca372a3c6d866066cf63a8830
It makes the code much more readable if there's at least a one-liner
documenting each function (and struct member).
Change-Id: I6d239369cabdf1703eba7f3606b46b95cbbb1ea7
Looking at 'perf top' of osmo-msc under load shows that there's a
significant amount of time spent in terms of locking (mutex,...)
which is useless as osmo-msc is a single-threaded application.
Unfortunately libdbi doesn't provide a mechanism to perform
sqlite3_config(), so we have to do it directly here, introducing an
explicit build-time dependency (and linkage) to libsqlite3.
Related: OS#5559
Change-Id: I5bbea90d28b6d73b64b9e5124ff59304b90a8a75
The existing rate counters per-minute/hour/day values were never
computed as the related timer was never started...
Change-Id: I27282051a6da5d1e1a25981712fbe4c4a6378dea
With comments, clarify the code paths where a CM Service use count has
not yet been placed on the conn (just send CM Service Reject) and where
the use count is placed (decrement count on CM Service Reject).
Place the CM Service use count slightly earlier:
- it is then correctly present when checking the mobile identity in
cm_serv_reuse_conn(), avoiding the crash reported in OS#5532.
- there is only one place incrementing the use count instead of two.
Related: OS#5532
Change-Id: I6c735b79b67108bcaadada3f01c7046e262f939b
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
We need to set the codec as present in order for
msc_a_up_call_assignment_complete() to configure properly the CN-side of
he leg with the IUFP codec, which should be the desired default in order
to avoid transcoding.
Change-Id: Ib8086462239e2df748cf47ea7b37a07f1f3b85a8