The mncc_rtp_create_pending and mncc_rtp_connect_pending members
were unused, let's remove them.
Related: OS#2528
Change-Id: I417e23ec53323ddd8e1e5d18952566fe8fd6ac24
When we receive bearer capabilities from MNCC and encode thme into
a CC message, we have to also update our "cache" inside 'struct
gsm_trans'. Only that way, the BSSMAP ASSIGNMENT code is aware of
the actual current/present bearer capabilities such as permitted speech
codecs.
This will in practise only work if the related CC/MNCC message with
berer_cap IE will happen before the MSC performs the BSSMAP ASSIGNMENT
procedure. Our logic still needs to change in a way that the CC/MNCC
code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and
in that case triggers a new follow-up BSSMAP ASSIGNMENT.
Change-Id: I6838dc0c8c4c2c6bba385da548c92f3fc91060c1
Closes: OS#2854
When we receive a MNCC_SETUP_REQ primitive from the external MNCC
handler, we must not only encode it into the TS 04.08 CC SETUP, but
also keep it around in the "trans" structure representing this voice
call, as it is needed e.g. at BSSMAP ASSIGNMENT time.
Change-Id: Ib6919d148ff6687112e8166dbde947be19e70a76
Related: OS#2322
Closes: OS#2929
There is no encoding of speech version / preference on Abis, only
on L3. L3 is carried on Um, Abis and A. Hence, referrin to Abis
in function names and comments is irritating.
Change-Id: Id226cd1414ca2a92356801bc71f43102d03ba37e
We cannot use conn->a.conn_id after conn has been free'd inside
msc_clear_request(). Let's store conn_id before that call to
ensure we avoid an use-after-free situation.
A more elegant (but more intrusive) solution would be to
move the SCCP connection clearing into the FSM itself.
Change-Id: Ibe41aa503e9f7cbeb05dce4b1a20b3eac85e619f
Closes: OS#2922
As in GSM/3GPP networks emergency calls carry no explicit destination
number/address, add a VTY commadn to patch in some destination handler
in the EMERGENCY SETUP before delivering to [internal or external] MNCC.
Change-Id: I7c9f43ba312fadda2b9a9483b3cf50e4abca9599
When we receive a msgb-wrapped primitive from the SCCP provider (stack),
it transfers msgb ownership to us (the SCCP user). The existing code
passed the msgb ownership down into all the various downstream
functions, which each then had to take care of msgb free'ing.
Not all of the paths did eventually free the msgb. And at least one
path used data from the primitive *after* the free
Let's restructure this in a way that no msgb ownership is transferred
down the call chain. Instead, there's one common msgb_free() in
sccp_sap_up(). We can do this as nobody is queueing or otherwise
keeping the msgb.
Change-Id: Ie65616ccb55ec58a0224bbe3c8e004e6029ef3e6
SUMMARY: AddressSanitizer: heap-use-after-free /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:538 in sccp_sap_up
Having all BSSAP related logs in the "DMSC" category is overly
generic, and dosn't provide useful granularity.
Change-Id: Id1e52dad03840dfd026fb23f3845a8771c8cc308
There's little point in resolving the gsm_subscriber_connection in each
and every function handling connection-oriented messages. We can
resolve it once and dispatch the already-resolved conn into the
function, instead of passing the raw sccp_user and a_conn_info.
Change-Id: Iea85527ea4d4cde7b36cc28a8027362c1570518f
Clean up the log statements in a_iface*.c, which was very inconsistent.
For example "BSC sending" is very confusing. We are receiving from the BSC,
and it did already send the message, it is no longer in the process of
sending it if we have already received it in the MSC.
Change-Id: Id50e964d86713ae506d4e7657159797e09501d99
During normal operation, regular messages occurring during processing
of a call / transaction should not be higher than LOGL_INFO.
Change-Id: Ibd04ade47b249406696c7d0b660474afc4f4adee
If the BSC is contacting us for the first time and sending a BSSMAP
RESET, then we should simply ACK that and transition into the
"connected" state, where connection-oriented and connectionless
procedures are permitted.
This patch is a bit large for such a seemingly simple behavioural
change, but the existing data model didn't permit a more
straight-forward implementation.
Change-Id: Ie67e7ed20a6c42afe99bafef96d85a4e083dd057
Closes: OS#2914
Using this argument we can create the state machine in the
"already connected" state, i.e. without starting an outbound
RESET procedure.
Change-Id: Ibf569d57300965cd47084fa0bff54aa67679e2a1
It is quite important to have some way of runtime state introspection
about the major objects inside osmo-msc. This patch adds some basic
capabilities to dump the most important information about
subscriber_connections and transactions (like calls/sms).
OsmoMSC> show connection
--ConnId ------------Subscriber RAN --LAC Use --Tokens CSA A5 State
00000001 IMSI:26242000000006 A 23 1 00000004 --- /0 SUBSCR_CONN_S_COMMUNICATING
Change-Id: I1c457c1eac20188f67b8379a36cfda3a085fcef4
The MGCP FSM implements a timeout when waiting for the RAN to complete
the call (assignment complete, alerting, connect...). This timeout
is currently set to 10sec. This means if the other end did not pick
up after 10sec, the MGCP connection will be lost while the phone keeps
ringing. When the other end finally picks up, the call gets
disconnected.
This behavior is odd and requires a proper fix. For now increasing the
timeout to 120sec. will decrese the probability that he problem occurs.
- Increas RAN timeout to 120sec (2 min).
Change-Id: I5a11d53f9701d9b11b18d7026ff2241c7c0b57f5
Check and handle gracefully any error which might appear in
osmo_gsup_encode() - mark corresponding functions with
warn_unused_result attribute to make sure this failure is always checked
against.
Change-Id: I4551212011fb0bd898c020a183756ed7a9afb9e5
Related: OS#2864
That's a preparation step for properly splitting main function of
different tests in follow-up function.
Change-Id: I68a2e94cf79fcb83286eef981a8d88bdbe10ef69
Related: OS#2864
For each test print:
* the test number
* IMSI
Unfortunately tests are organized in such a way that we don't know the
number of particular test in advance. Nevertheless, it make sense to
always print it regardless of -v option presense.
Related: OS#2864
Change-Id: I2e1d7701f5322d2311f32b796148a8b414f53b8e
Having while(0) as a body for for() cycle generate too much WTF while
looking at the code while not serving any obvious purpose. Let's just
drop it to avoid confusing developers.
Change-Id: I1f571ec319ff3231fd9acd4066e470476c3b1f78
Related: OS#2864
Don't fail tests using thwart_rx_non_initial_requests() via
OSMO_ASSERT. Instead log extended error which will fail the test
eventually but allows to gather additional info helpful for debugging.
Change-Id: I2607cb1ac60941dbc22fca532ed2b3738bfbcc63
Related: OS#2864
Print the IMSI used for each test. This enables expansion to tests with
several IMSIs in follow-up patches.
Change-Id: I7958608e5136351f7b7c0c57fe79791d989ce9c3
Related: OS#2864
This makes test routines more flexible and allows to easier re-use them
for tests with different IMSIs.
Change-Id: I74d46fdb7e87dc04c6b82a0b6f3ce6bef60bde58
Related: OS#2864
We don't usually put space before in-place increment or decrement. Let's
make code look similar to other Osmocom projects.
Change-Id: I5962431ad16c97e412939dc1b8949f6361a5c26e
in the current implementation we still use osmo-bsc_mgcp, which
has many problems and is also obsoleted by osmo-mgw.
integrate osmo-mgw and re-implement the current switching using
an osmo fsm.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062
Closes: OS#2605
Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
conn_id is modeled as int, but should be uint32_t.
- change conn_id from int to uint32_t
Change-Id: Ibf14d7c9a547c4eeb873975e7dcddef223e7df46
Related: OS#2769
Using following semantic patch:
@@ expression A, B, C; @@
- osmo_strlcpy(A, B, sizeof(A));
+ OSMO_STRLCPY_ARRAY(A, B);
Which was applied using following command:
spatch --dir src -I src --sp-file strlcpy.spatch --in-place --recursive-includes
All the calls to osmo_strlcpy() which use destination buffer obtained
via sizeof() were replaced with the corresponding wrapper macro.
Change-Id: I67b482dedfa11237ac21894fc5930039e12434ab
Related: OS#2864
According to TS 24.007 Section 11.2.3.2.3, it is possible that uplink L3
messages are duplicated in some scenarios, particularly during
assignment/handover procedure.
To avoid L3 entities from seeing duplicated messages, there's a modulo-2
or modulo-4 message sequence counter, based on which the MSC can detect
and suppress such duplicate messages.
It appears that even our unit tests were wrong in that regard so far.
Rather than manually adjusting each and every message, let's make sure
that the sequence number generation always increments as expected, and
that during matching of incoming messages, sequence numbers are masked
out.
Note: the tests will only pass from libosmocore Change-Id
Iec875a77f5458322dfbef174f5abfc0e8c09d464 onwards, due to
gsm48_hdr_msg_type() being broken in earlier versions.
Change-Id: Id15e399ab7e1b05dcd426b292886fa19d36082b1
Closes: #2908
Make the submit_to_sms() funcion aware of the message mode. If the
message does not require real-time "transactional/forward mode" we
can store it in the SMS database even if subscriber B cannot be
found in the VLR at this point in time.
This should should make the esme_ms_sms_storeforward test in
osmo-gsm-tester pass (a tweak to this test's expectations will
be needed as well, because the test currently assumes that an
invalid phone number for subscriber B will fail immediately,
rather than cause the message to eventually expire).
Change-Id: Ic3d78919568ad9252b4d19c3ddab5068d1c52db2
Related: OS#2354
This leads to faster recovery in case of link loss.
It also makes the TTCN-3 test suite run much faster, as each test case
will inherently terminate the GSUP connection.
Change-Id: I16821a26f2c6ff4d0a76926c9212127ab6f6fedf
There's no point of ever asking a MS to perform ciphering using an
algorithm it advertises no support for. Let's hence use CLASSMARK
information to figure out the intersection between MSC policy (VTY
command) and MS-reported CLASSMARK.
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
NOTE: Like the previous code, OsmoMSC does *not yet check* whether
the configured cipher is compatible with the MS capabilities as
reported in CLASSMARK! The network hence might choose an algorithm
not supported by the phone. Fixing this is subject to another patch.
Closes: OS#2460
Change-Id: I79a4e2892eb5fbecc3d84e11dceffb7149db264b
The VLR code seems to have the assumption that there is one particular
algorithm to be used, as opposed to one of a set of algorithms.
What's missing is basically to decide when/where to pick the best
algorithm within the capabilities of the phone (classmark) and the
network configuration (net->a5_encryption_mask). So far, libvlr has no
notion of classmark. Rather, libmsc has.
Why does the VLR care about the particular algorithm at all? The VLR
should probably simply decide if it should use encryption or not, and if
so, the MSC will figure which algorithm to use.
Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
Delete expired SMS whenever we are done processing an SMS-related signal.
In order to minimize additional latency only one SMS is removed at a time.
Change-Id: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Related: OS#2354
Accept any SMS and store it in the database, even if the receiver of
the message cannot be determined when the message arrives at the MSC.
This fixes https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
Change-Id: I833c3abd290d2bc5fceec7457e3933c9600e6c24
Depends: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Depends: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Depends: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a
Related: OS#2354
We already delete SMS which have been sent successfully. However, there
are plans to accept SMS for any subscriber in order to fix the problem
described in https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
This means we may end up storing SMS which never get sent, e.g. because
the B subscriber doesn't actually exist. This could lead to a higher
degree of SMS database growth over time, and therefore we need a way
to keep database size under control.
As a first step, introduce a DB function which removes an expired SMS,
and add a VTY command which removes all expired SMS from the DB.
Later commits will build upon this to remove expired SMS automatically.
The SMS expiry time period is currently hard-coded to 2 weeks.
We could make this configurable in the future if desired.
Change-Id: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Related: OS#2354
Harald Welte
Philipp Maier
Max