This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.
This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.
Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
when the VTY write the config file ist prints the configuration line
for emergency-call in network and in msc, however the presence of the
configuration line in network leads to a parsing error on msc startup.
The vty command probably got moved to node msc and it was forgotten
to remove the printing from network.
Change-Id: I4f3dac27723e7852f8f049fcfca5cccdc027734d
Related: OS#4548
From ASAn on gcc 10.1.0:
+=================================================================
+==269368==ERROR: AddressSanitizer: odr-violation (0x559114a5b880):
+ [1] size=4 'asn1_xer_print' /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+ [2] size=4 'asn1_xer_print' /git/osmo-iuh/src/iu_client.c:85:5
+These globals were registered at these points:
+ [1]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x55911456d221 in _sub_I_00099_1 (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x48d221)
+ #2 0x5591145e8e9c in __libc_csu_init (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x508e9c)
+
+ [2]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x7f6207d8db91 in _sub_I_00099_1 (/build/new/out/lib/libosmo-ranap.so.3+0x47db91)
+ #2 0x7f62096eb0f1 in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x110f1)
+
+==269368==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
+SUMMARY: AddressSanitizer: odr-violation: global 'asn1_xer_print' at /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+==269368==ABORTING
Related: OS#4556
Change-Id: I702e9748eaaf2279c3764ba67f80f00ae9f2526f
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ifc89fffac0443d94f3e49555684975b293ef90fb
Do not crash when a Paging Response could not be associated with a VLR
subscriber.
Related: OS#4449
Change-Id: Ie117949dd6da86afaa1a0a6ac57bf2111f6cff43
Since the split of OsmoNiTB, OsmoMSC does not deal with the radio
access network directly. Therefore the only purpose of T3212 is to
control subscriber expiration in the local VLR. The timeout value
indicated in System Information Type 3 needs to be configured
separately in the BSC/RNC.
This means that we don't need to store it in deci-hours anymore.
Let's move T3212 to the group of VLR specific timers, so it can
be configured and introspected using the generic 'timer' command,
and deprecate the old '[no] periodic location update' command.
It should be also noted that in the old code subscriber expiration
timeout was actually set to twice the T3212 value plus one minute.
After this change, we apply the configured value 'as-is', but
keep the old behaviour for 'periodic location update' command.
Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
These timers so far were implemented as a list of unsigned integers,
which has never been initialized to any reasonable defaults. Since
they are used as state timeouts in several FSMs, we might end up
staying in some state forever.
Let's migrate to generic osmo_tdef API and use default values from
table 11.2 of 3GPP TS 24.008. This way the user can introspect and
change their values from the VTY / configuration file.
Change-Id: Ia8cf98da0aea0e626c5ff088a833d7359c43847f
Related: OS#4368
This change introduces several new VTY commands letting the user
a possibility to introspect and reconfigure some of the existing
timers implemented using libosmocore's osmo_tdef API.
At the moment this covers the following timers:
- MGW specific timers:
- X1 - MGCP response timeout,
- X2 - RTP stream establishing timeout,
- RAN specific timers (same names for GERAN and UTRAN):
- X1 - Authentication and Ciphering timeout,
- X2 - RAN connection release sanity timeout,
- X3 - Handover procedure timeout.
The following commands are introduced:
- 'enable' node:
- show timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN]
- 'config-msc' node:
- timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)]
Both MNCC and SCCP related timer definitions are empty at the
moment. Achieved by using osmo_tdef_group API of libosmovty.
Change-Id: I6024c104b6101666c8aa1108a043910eb75db9a5
Related: OS#4368
There was one libmsc commit to openbsc that was
thus far missing in osmo-msc.
This commit completes the work on delayed response
from an ESME. Without this patch, the SMR sends
an RP-ACK to the mobile station, and subsequently a
DELIVER_SM_REPONSE from the ESME provokes either a second
RP-ACK, or an RP-ERROR; both of which result in
"unhandled at this state (IDLE)" from the SMR
After this patch, we have two things corrected:
1) RP-ERROR respects Deliver-SM error cause.
2) No more "unhandled as this state" error from the SMR
Extract from original commit message:
--------
libmsc: annotate esme route in the sms object from deliver_to_esme()
Annotate this esme route, so we can use it to return -EINPROGRESS to
skip sending premature RP-ACK to the mobile station, in case we're
handling sms routes through SMPP.
--------
Fixes: #OS4351
Change-Id: Ic34d398e0a850856e20380ae35e5c2ae5e3c539b
This commit also, (for what it is worth) removes a
difference to the same file in openbsc, which I found
while looking for changes that affected SMPP delivery.
This is essentially a "forward-port" of [1]
[1] https://gerrit.osmocom.org/#/c/openbsc/+/3899/
Change-Id: I350c19f5bb70b2656171c096334c2ee83f49df7e
d34ed5768c introduced
comparison of GSM411_RP_CAUSE_MO_NUM_UNASSIGNED with
GSM48_CC_CAUSE_UNASSIGNED_NR
For consistency lets use the GSM411_RP constants
in SMS related code.
Change-Id: Ie54966560f66d2dcde905feb2eb19ef90406acd1
During the last congress, we have noticed that OsmoMSC crashes
on receipt of malformed MM Identity Response messages:
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
00.. .... = Control Channel: not further specified (0x0)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
Length: 11
GSM A-I/F DTAP - Identity Response
Protocol Discriminator: Mobility Management messages (5)
.... 0101 = Protocol discriminator: Mobility Management messages (0x5)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
01.. .... = Sequence number: 1
..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19)
Mobile Identity - Format Unknown
Length: 8
.... 1... = Odd/even indication: Odd number of identity digits
.... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash
[Expert Info (Warning/Protocol): Unknown format 7]
[Unknown format 7]
[Severity level: Warning]
[Group: Protocol]
The value '111'B is not a valid Mobile Identity type, and shall be
considered as reserved according to 3GPP TS 24.008, section 10.5.1.4.
Later on it was discovered that '000'B also crashes OsmoMSC in the same way.
The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp().
Let's keep that assert in there, and make sure that:
- on receipt of MM Identity Response, Mobile Identity type
matches the one in MM Identity Request;
- on receipt of RR Ciphering Mode Complete, Mobile Identity
contains IMEI(SV) if present.
Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825
TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743
Fixes: OS#4340
We shall not include additional BCD length octet into the value part
of SM-RP-OA (Originating Address) IE. Instead, there should be
ToA/NPI header (1 octet).
Since we do not get ToN/NPI fields from the VLR/HLR, let's assume
the following default values:
1... .... = Extension: No extension
.001 .... = Type of number: International (1)
.... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d
TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Related: OS#4324
Add a char buffer of 1024 characters length as space for SDP to pass to /
receive from MNCC.
Actually support receiving MNCC without such an SDP tail. The main reason for
this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would
stop working for older osmo-msc.
Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged
(save the protocol number bump) without having to implement SDP.
The SDP part in the MNCC protocol will be used in upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f.
This patch must be merged at the same time as osmo-sip-connector patch
Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching
MNCC protocol version number.
Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch
I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP
messages. Obviously, libosmo-mgcp-client already contains similar code, but
that is unfortunately heavily glued to the actual MGCP implementation. The
simplest solution is to create this separate implementation, copy-pasting from
the existing libosmo-mgcp-client code as is convenient.
This API is added here to probe whether it works well. When it does, the
intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our
MGCP client and MGCP server APIs using this same API.
Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
Do not free the CC transaction when an MT subscriber is already being Paged.
Instead, invoke another paging request, which paging.c will correctly add to
the list of pending paging response callbacks to run.
A ttcn3 test is linked in the related patch (s.b.).
Related: OS#4240
Related: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
Change-Id: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
When the CRCX OK returns an invalid RTP address, abort the call; fixes
MSC_Tests.TC_invalid_mgcp_crash.
The original crash happened when adding this error handling without this commit
I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for
osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require
new fsm deferred dealloc, check for term"). With this error handling added,
even though avoiding a crash, the test does not pass yet, because instead of
rejecting the call, it currently composes an Assignment Command without a
Transport Layer Address. Fix that.
Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete
Layer 3 Information and the Assignment Complete messages.
An upcoming patch improves codec negotiation and requires the BSS supported
codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great
lengths to compose those IEs).
Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover
support, I forgot to remove it.
Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the
MGW providing (or failing to provide) an RTP port for the RAN side. From an
earlier stage of the code, the cleanup for this situation was extremely
complex, and hence the choice was to simply wait for the call to time out and
fail. But since we have implemented safe deallocation of nested FSMs in
libosmocore, the situation has become rather trivial: simply free the CC
transactions, and all the rest will immediately release, and terminate
correctly without crashing.
A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also
needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch
I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP
message ends up causing a failure in the on_success() branch of
mgcp_client_endpoint_fsm.c.
Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
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
libosmo-mgcp-client recently introduced osmo_mgcpc_ep_cancel_notify() to cancel
notification if a notify target FSM deallocates. Use it for sanity in
rtp_stream FSM cleanup, the notify target for endpoint FSMs.
Depends: I41687d7f3a808587ab7f7520f46dcc3c29cff92d (osmo-mgw)
I14f7a46031327fb2b2047b998eae6ad0bb7324ad (osmo-mgw)
Change-Id: I351bb8e8fbc46eb629bcd599f6453e2c84c15015
Before:
RAN decode: BSSMAP: Rx BSSMAP DT1 COMPLETE LAYER 3
After:
RAN decode: BSSMAP: COMPLETE LAYER 3
This caught my attention while I was writing up a script to parse osmo-msc
logging to produce ladder diagrams.
Change-Id: I387dde8f2eb3edb35d22ce52dc0ed580978dea36
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early
return so far skipped logging of that MNCC message. Add this logging.
Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.
Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
When pagig for a CS-Call via SGs times out, the MME expects to be
informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this
message is sent, but only for CS-Fallback calls.
Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877
Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a
Related: OS#3614
Neels Hofmeyr
Philipp Maier
Pau Espin
Keith Whyte
Harald Welte
Martin Hauke