We may never be able to deliver this SMS if it depends on the ESME, as we will
not resubmit the SMS to the ESME. Better to reject it at this time and have the MS
try again later.
Change-Id: I2c50904349dd4ed229b60b8468d776b817c0bd44
Related: OS#4740
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
This change is similar to I6b68a0f0b32eb126e0f7e914a314130254d28467.
If we 100% sure that trans == NULL, it makes more sense to use
generic LOGP(DLSMS, LOGL_*, ...) call, so the logs can reflect
more information than such dummy prefix:
trans(NULL NULL callref-0x0 tid-0) ...
Change-Id: I3c1e633aee5dd7cd0d367404a3def9cffe0b3baa
According to 3GPP TS 29.002, section 7.6.8.7, MMS (More Messages to Send)
is an optional IE of MT-ForwardSM-Req message which is used by SMSC to
indicate that there are more (multi-part) MT SMS messages to be sent.
The MSC needs to use this indication in order to decide whether to
keep the RAN connection with a given subscriber open.
Related Change-Id: (TTCN) I6308586a70c4fb3254c519330a61a9667372149f
Change-Id: Ic46b04913b2e8cc5d11a39426dcc1bfe11f1d31e
Related: OS#3587
As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)",
if the TP-User-Data is coded using the GSM 7-bit default alphabet,
the TP-User-Data-Length field indicates the *number of septets*
within the TP-User-Data field to follow. Otherwise, i.e. in case
of 8-bit or UCS-2 encoded data, the *number of octets* is indicated.
Since we store the original TP-UDL value (as received), we might
need to convert septets to octets before passing it to memcpy().
Otherwise this would lead to a buffer overrun.
Also, as we receive TPDU from untrusted source (i.e. subscriber),
the TP-UDL value needs to be checked against the corresponding
maximum (160 septets or 140 octets) and truncated if needed.
Please note that buffer overrun is still possible, e.g. when an
indicated TP-UDL value is grather than the remaining TPDU length.
Preventing this would require adding an additional check.
Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688
Depends-on: (core) I54f88d2908ac47228813fb8c049f4264e5145241
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
Avoid deprecation warning: use gsm48_decode_bcd_number2() instead of
gsm48_decode_bcd_number().
Validate the return value and add error handling.
Change-Id: Ibef71c46d72d2d43123e68f73e5ed554a69243d8
According to GSM 04.07, the TI flag takes one bit and can be
either of the following:
'0'B - transaction is allocated by sender of a message,
'1'B - transaction is allocated by receiver of a message.
Since we store transaction ID in gsm_trans structure, we also store
TI flag (as a part of transaction ID), which in this context means:
'0'B - transaction is allocated by us (OsmoMSC),
'1'B - transaction is allocated by some MS.
In 100% cases, trans_assign_trans_id() is used to assign transaction IDs
to transactions allocated by us (i.e. OsmoMSC) for MT connections. And
there is no need to use it for MO transactions, because they basically
already do contain a valid transaction ID assigned by the MS.
Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
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
Initially, it was assumed that if there is no active RAN connection,
we can just start counting from 0x00, as there are no other SMS
related transactions, and transaction itself is allocated using
talloc_zero(). Until now it was looking good, but...
As soon as we establish RAN connection with subscriber, we already
have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also
remains 0x00 - it isn't being increased!
It means that we can face a SM-RP-MR conflict (or collision) if
another MT SMS would arrive to the MSC (from SMSC over GSUP)
when this transaction is still active, i.e. the first SMS is
still being sent, because conn->next_rp_ref++ would
return 0x00 again.
Moreover, there might be already a MO SMS transaction, and using
the conn->next_rp_ref counter wouldn't prevent us from having
duplicate SM-RP-MR value.
Let's get rid of this per-connection counter, and introduce a
function instead, that would iterate over existing transactions
and look for an unused SM-RP-MR value.
This change makes the following test cases pass:
- TC_gsup_mt_sms_rp_mr,
- TC_gsup_mo_mt_sms_rp_mr.
Discovered by: Neels Hofmeyr
Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc
Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120
Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
Previously, SM-RP Message Reference was assigned to MT transactions
only, but not to MO transactions. As a result, this could lead to
having a few transactions with duplicate SM-RP-MR value, because
in case of MO SMS, trans->sms.sm_rp_mr would remain 0x00.
Let's parse SM-RP-MR from MO SMS messages in gsm0411_rcv_sms(),
and assign it to the new transaction after allocation.
Change-Id: I4d07354175444f9764fb0dd6ea188a64494d79fe
Move code which allocates transaction for SMS and initializes
corresponding FSM into separate function (shared by MT and MO code
paths) to avoid code duplication and simplify further modifications.
Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
The likely reason why it was disabled is due to
paging_cb_mmsms_est_req() logging pointers which results in unstable log
output. Fixing this allows us to track SMS-related regressions properly.
Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
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
Following previous rename of gsm_subscriber_connection:
Some functions and #defines are still called like "msc_conn" or just "msc_",
while they are clearly about a RAN conn.
To avoid confusion with the future separate concepts of MSC roles and a RAN
connection, rename all those to match the common "ran_conn" prefix.
Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
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
In I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092 I've introduced a
regression. According to GSM TS 04.11, section 2.3, SAPI 3 shall
be used for both MO/MT SMS transmissions. Due to a mistake,
caused by misunderstanding of the meaning of trans->dlci, SAPI 3
was not assigned to SM transactions if there is already an active
RAN connection with subscriber. Let's fix this.
Let's also drop this misleading comment:
/* FIXME: specify SACCH in case we already have active TCH */
because it's a task of the BSC/BTS to decide which lchan to use.
Change-Id: I08d0801a89d377441e95fb8e3dd27c8d587f89e9
Related: OS#3716
According to GSM TS 04.11, the SMC (Short Message Control) state
machine is a part of CM-sublayer of L3, that is responsible for
connection management (establisment and releasing), and SM-RP
(Relay Protocol) message delivery.
For some reason, the connection establisment request from SMC
(GSM411_MMSMS_EST_REQ) was not handled properly - it was
always assumed that connection is already established.
This is why the code initiating a MT (Mobile Terminated) SMS
transfer had to establish a radio connection with subscriber
manually.
Let's benefit from having the SMC state machine, and offload
connection establishment to it. This change makes the local
implementation closer to GSM TS 04.11, and facilitates the
further integration of GSUP transport.
NOTE: the expected unit test output is changed, because now we
always allocate a transaction first, and then establish a
connection, not vice versa.
Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
It's much better to have both RP-DATA header parsing and validation
code in a single function. There is no need to pass all the header
fields (DA, OA, UI) to gsm411_rx_rp_ud() because they are not
used there.
Change-Id: Iaf295949148e2a613c5403d1f7a926fcd6849c15
Passing a message buffer containing the whole encoded message, and
a pointer to the RP header (struct gsm411_rp_hdr) is redundant.
Change-Id: I0eb5c7c485ab7d109966431bd875fa74e00936d7
When using smpp-first, after the ESME accepts our STATUS REPORT,
we were sending it locally into gsm340_rx_sms_submit() anyway.
In the case of the ESME mirroring the report back to us, this
would result in two copies of the status report in the SMS
database, which were also both then delivered to the MS.
This causes no visible error to the user but is a waste of radio
resources.
With this patch, we check if it is the sms_report that has had
receiver set in sms_route_mt_sms() and not the original SMS we
are reporting on, which of course already has receiver set.
Change-Id: I3529b89535800eaa1127721d613fa7bbcb8b23be
In the old days, OsmoNITB couldn't process any SMS that wasn't between
two subscribers on the same NITB.
We've long re-worked the internals in order to process SMS with
arbitrary sender MSISDN (e.g. from SMPP). However, the VTY command
"subscriber ... sms" was never updated, it seems.
Change-Id: I62b17e0a67989484415f0df2c8cb4ff1f94dbf2b
Closes: OS#3151
The DLCI field of the DTAP header indicates the SAPI as well as the
data link (main DCCH or SACCH). We must make sure to use the correct
DLCI when sending DTAP to the BSC.
We achieve this by
* storing the DLCI in the msgb->cb while parsing the DTAP header
* storing the received DLCI (from msgb->cb) in the transaction for
mobile-originated transactions
* using the trans->dlci to sent msgb->cb when transmitting L3
* filling the DTAP DLCI value from msgb->cb when transmitting DTAP
For MSC-originated transactions, we choose a DLCI value corresponding
to the service (SAPI=0 for CC, SAPI=3 for SMS) and store that in
trans->dlci.
Closes: OS#3150
Change-Id: If511b20f52575054cab1346d99a8cb68d827fdbf
Move gsm48_* functions from common_cs.c to libmsc/gsm_04_08.c.
Drop sms_next_rp_msg_ref(), it is just a bunch of bloat around "next_rp_ref++".
Apply the "++" instead, in gsm_04_11.c.
libcommon-cs is now empty, to be removed in subsequent commit.
Change-Id: Ibc410803ce8e273b626124ab9fc934f04df3ae50
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
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
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
When hunting a conn use count bug, it was very hard to figure out who's (not)
using the conn. To ease tracking down this bug and future bugs, explicitly name
what a conn is being reserved for, and track in a bit mask.
Show in the DREF logs what uses and un-uses a conn. See the test expectation
updates, which nicely show how that clarifies the state of the conn in the
logs.
On errors, log them, but don't fail hard: if one conn use/un-use fails, we
don't want to crash the entire MSC before we have to.
Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
Wen there's no SMPP support compiled in, and routing was successful,
we shouldn't return an uninitialized value.
Change-Id: I4abbbb5ab336a7e8da08d682f396baec3b56fa3a
Fixes: Coverity CID#174176
Set the time on the status report to the time the message was delivered, as
this may not be the same as the time when we are delivering the report to the
originating MS.
Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
gsm_04_11.c sms_report_alloc()
Use the sms->text, not the sms->user_data to construct the report body.
This also prevents the potential output of non printable characters to
the log and or vty.
Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu()
When we construct the status report PDU, use sms->src
instead of sms->dst as the destination address
This way we tell the MS that the message was delivered
to the destination and not to itself.
This is relevant for phones that display a textual
representation of the delivery report.
Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
Pau Espin
Keith Whyte
Pablo Neira Ayuso
Harald Welte
Neels Hofmeyr