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
gsm340_gen_oa() returns a negative value if the output buffer that the
caller passes is too small, so we have to check the return value of this
function.
Fixes: CID 174178
Fixes: CID 174179
Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
This patch adds gsm340_sms_send_status_report_tpdu() to build a
status-report. Moreover, set sms->report field if we see a SMPP
SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies
that this is a delivery report.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| | SUBMIT-SM |
| | esm_class = Delivery Ack |
| |<-------------------------------|
| | SUBMIT-SM-RESP |
| |------------------------------->|
| | |
| SMS-STATUS-REPORT | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | |
There is a FIXME message in this patch, that I just copied from
gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC.
Change-Id: Ib70e534840308ed315f7add440351e649de3f907
If the mobile phone requests a status report via SMS, send a DELIVER_SM
with esm_class = Delivery Receipt to ESME to indicate that the SMS has
been already delivered to its destination.
MS GSM 03.40 SMSC SMPP 3.4 ESME
| | |
| SMS-DELIVER | |
|<----------------------------| |
| GSM 04.11 RP-ACK | |
|---------------------------->| |
| | DELIVER-SM |
| | esm_class = Delivery Receipt |
| |------------------------------->|
| | DELIVER-SM-RESP |
| |<-------------------------------|
| | |
This patch implements "Appendix B. Delivery Receipt Format" as specified
in the SMPP 3.4 specs. This string is conveyed in the SMS message as
data, and it is only meaningful to the ESME, for logging purposes. The
"submit date" and "done date" are not yet set, and other fields are just
sent with dummy values, so they are left to be finished as future work.
The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP
messages inconditionally now since this information is required by
delivery-reports to associate the status-report with the original SMS.
Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
Move the sms message-type-identifier (mti) handling away from the
routing logic. This patch allows us to reuse the sms_route_mt_sms()
function in a follow up patch for sms reports send through SMPP
DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is
Ic1a9023074bfa938099377980b6aff9b262fab2a.
Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
No need to cache the sms object, just cache what we need into the
smpp_cmd structure. This simplifies what that I introduced in
93ffbd0029 ("libmsc: send RP-ACK to MS after ESME sends SMPP
DELIVER-SM-RESP").
Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
The following branch:
if (!rc && !gsms->receiver)
rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
at the end of sms_route_mt_sms() always evaluates false.
Just a bit before, in such function, we have this:
if (!gsms->receiver) {
...
#ifdef BUILD_SMPP
...
#else
...
#endif
return rc;
}
So, if there is no receiver, we just stop running code and return the RP
cause via the rc variable. Same applies to the smpp_first check under
the BUILD_SMPP ifdef (that I have removed in this snippet to keep this
commit message small).
Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
Disable large parts of the code that depend on BSC presence. The code sections
disabled by #if BEFORE_MSCSPLIT shall be modified or dropped in the course of
adding the A-interface.
Don't set msg->lchan nor msg->dst.
Don't use lchan in libmsc.
Decouple lac from bts.
Prepare entry/exit point for MSC -> BSC and MSC -> RNC communication:
Add msc_ifaces.[hc], a_iface.c, with a general msc_tx_dtap() to redirect to
different interfaces depending on the actual subscriber connection.
While iu_tx() is going to be functional fairly soon, the a_tx() is going to be
just a dummy for some time (see comment).
Add Iu specific fields in gsm_subscriber_connection: the UE connection pointer
and an indicator for the Integrity Protection status on Iu (to be fully
implemented in later commits).
Add lac member to gsm_subscriber_connection, to allow decoupling from
bts->location_area_code. The conn->lac will actually be set in iu.c in an
upcoming commit ("add iucs.[hc]").
move to libcommon-cs: gsm48_extract_mi(), gsm48_paging_extract_mi().
libmsc: duplicate gsm0808 / gsm48 functions (towards BSC).
In osmo-nitb, libmsc would directly call the functions on the BSC level, not
always via the bsc_api. When separating libmsc from libbsc, some functions are
missing from the linkage.
Hence duplicate these functions to libmsc, add an msc_ prefix for clarity, also
add a _tx to gsm0808_cipher_mode():
* add msc_gsm0808_tx_cipher_mode() (dummy/stub)
* add msc_gsm48_tx_mm_serv_ack()
* add msc_gsm48_tx_mm_serv_rej()
Call these from libmsc instead of
* gsm0808_cipher_mode()
* gsm48_tx_mm_serv_ack()
* gsm48_tx_mm_serv_rej()
Also add a comment related to msc_gsm0808_tx_cipher_mode() in two places.
Remove internal RTP streaming code; OsmoNITB supported that, but for OsmoMSC,
this will be done with an external MGCP gateway.
Remove LCHAN_MODIFY from internal MNCC state machine.
Temporarily disable all paging to be able to link libmsc without libbsc.
Skip the paging part of channel_test because the paging is now disabled.
Employ fake paging shims in order for msc_vlr_tests to still work.
msc_compl_l3(): publish in .h, tweak return value. Use new libmsc enum values
for return val, to avoid dependency on libbsc headers. Make callable from
other scopes: publish in osmo_msc.h and remove 'static' in osmo_msc.c
add gsm_encr to subscr_conn
move subscr_request to gsm_subscriber.h
subscr_request_channel() -> subscr_request_conn()
move to libmsc: osmo_stats_vty_add_cmds()
gsm_04_08: remove apply_codec_restrictions()
gsm0408_test: use NULL for root ctx
move to libbsc: gsm_bts_neighbor()
move to libbsc: lchan_next_meas_rep()
move vty config for t3212 to network level (periodic lu)
remove unneccessary linking from some tests
remove handle_abisip_signal()
abis_rsl.c: don't use libvlr from libbsc
gsm_subscriber_connection: put the LAC here, so that it is available without
accessing conn->bts. In bsc_api.c, place this lac in conn for the sake of
transition: Iu and A will use this new field to pass the LAC around, but in a
completely separate OsmoBSC this is not actually needed. It can be removed
again from osmo-bsc.git when the time has come.
Siemens MRPCI: completely drop sending the MRPCI messages for now, they shall
be added in osmo-bsc once the A-Interface code has settled. See OS#2389.
Related: OS#1845 OS#2257 OS#2389
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7