cellular-infrastructure
/
osmo-msc
mirror of https://gerrit.osmocom.org/osmo-msc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-msc/src/libmsc/gsm_04_11.c

1393 lines
39 KiB
C
Raw Normal View History

Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
/* Point-to-Point (PP) Short Message Service (SMS)
* Support on Mobile Radio Interface
* 3GPP TS 04.11 version 7.1.0 Release 1998 / ETSI TS 100 942 V7.1.0 */
/* (C) 2008 by Daniel Willmann <daniel@totalueberwachung.de>
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
* (C) 2009 by Harald Welte <laforge@gnumonks.org>
sms: Re-order the include files after the separationf OpenBSC and osmocore
2012-11-10 17:11:22 +00:00
* (C) 2010-2012 by Holger Hans Peter Freyther <zecke@selfish.org>
misc: Once again go from "On Waves" to "On-Waves".. Try to get the company name of our sponsor right...
2010-10-06 12:37:09 +00:00
* (C) 2010 by On-Waves
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
* (C) 2011 by Andreas Eversberg <jolly@eversberg.eu>
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
*
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* GNU Affero General Public License for more details.
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
*
License change: We are now AGPLv3+ instead of GPLv2+ The reason for this is quite simple: We want to make sure anyone running a customized version of OpenBSC to operate a network will have to release all custom modifiations to the source code.
2011-01-01 14:25:50 +00:00
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
#include <time.h>
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
#include <netinet/in.h>
rename bscconfig.h to config.h, cleanup 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
2019-03-04 01:46:37 +00:00
#include "config.h"
introduce HAVE_TM_GMTOFF_IN_TM Not all architectures have the tm.tm_gmtoff member. This fixes cygwin builds.
2012-04-08 14:59:24 +00:00
src: use new library libosmogsm and new path to headers in libosmocore libosmogsm is a new library that is distributed in the libosmocore. Now, openbsc depends on it. This patch gets openbsc with this change. This patch also rewrites all include path to the new osmocom/[gsm|core] Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
2011-03-22 15:47:59 +00:00
#include <osmocom/core/msgb.h>
sms: Re-order the include files after the separationf OpenBSC and osmocore
2012-11-10 17:11:22 +00:00
#include <osmocom/core/talloc.h>
cosmetic: use osmo_strlcpy() everywhere Shorten some code and make obvious to the reader that the string copy is done in a safe way. Change-Id: I900726cf06d34128db22a3d3d911ee0d1423b1bd
2017-01-13 02:12:08 +00:00
#include <osmocom/core/utils.h>
sms: Re-order the include files after the separationf OpenBSC and osmocore
2012-11-10 17:11:22 +00:00
#include <osmocom/gsm/gsm_utils.h>
sms: Use the definitions from the libosmogsm Use the code that is shipped inside the libosmogsm library. Right now the signature (besides the static) and the implementation is the same. This makes using the libosmogsm SMC code more easy in the near future. For the gsm340_gen_oa we are now using a small wrapper to generate the proper type and numbering plan.
2012-11-10 17:24:54 +00:00
#include <osmocom/gsm/gsm0411_utils.h>
sms: change rp err cause of smpp_try_deliver errors smpp_try_deliver could fail with rc < 0. In such cases don't send the MS the rp error sms rejected (cause 21). A rejected message should not be sent again. The spec 04 11 recommends sending cause 41 Temporary failure in unknown cases. Add also a log message and rate counter for such cases. Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de> Change-Id: Ia03e50ce2bd9a7d1054cc5a6000fd73bd3497c03
2016-08-21 18:16:33 +00:00
#include <osmocom/gsm/protocol/gsm_04_11.h>
libmsc/gsm_04_11.c: properly handle TP-User-Data-Length 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
2019-04-16 08:18:33 +00:00
#include <osmocom/gsm/protocol/gsm_03_40.h>
sms: Re-order the include files after the separationf OpenBSC and osmocore
2012-11-10 17:11:22 +00:00
rename include/openbsc to include/osmocom/msc Change-Id: I1f96a1285bbd1b4607614856bca935d5c26e2da9
2017-09-04 13:04:35 +00:00
#include <osmocom/msc/debug.h>
#include <osmocom/msc/gsm_data.h>
#include <osmocom/msc/db.h>
#include <osmocom/msc/gsm_subscriber.h>
#include <osmocom/msc/gsm_04_08.h>
#include <osmocom/msc/signal.h>
#include <osmocom/msc/db.h>
#include <osmocom/msc/transaction.h>
#include <osmocom/msc/vlr.h>
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
#include <osmocom/msc/msub.h>
#include <osmocom/msc/msc_a.h>
#include <osmocom/msc/paging.h>
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
#ifdef BUILD_SMPP
#include "smpp_smsc.h"
#endif
move talloc context creation out of on_dso / constructors the various constructors get called in a non-obvious, linker determined order, which makes certain objects disappear from the talloc report. This change moves the talloc context creation into a new talloc_ctx.c file
2009-08-15 00:30:58 +00:00
void *tall_gsms_ctx;
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
static uint32_t new_callref = 0x40000001;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
struct gsm_sms *sms_alloc(void)
{
return talloc_zero(tall_gsms_ctx, struct gsm_sms);
}
void sms_free(struct gsm_sms *sms)
{
/* drop references to subscriber structure */
if (sms->receiver)
vlr_subscr: use osmo_use_count Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-02-19 01:36:35 +00:00
vlr_subscr_put(sms->receiver, VSUB_USE_SMS_RECEIVER);
SMPP: build the smpp interface only in case of ./configure --enable-smpp
2012-11-16 21:15:22 +00:00
#ifdef BUILD_SMPP
SMPP: Introduce ESME reference coounting In case a ESME disappears after SUBMIT-SM but before the MT-SMS is delivered (transaction mode), we have to make sure the esme structure still exists.
2012-11-08 19:11:05 +00:00
if (sms->smpp.esme)
smpp_esme_put(sms->smpp.esme);
SMPP: build the smpp interface only in case of ./configure --enable-smpp
2012-11-16 21:15:22 +00:00
#endif
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
talloc_free(sms);
}
Use libvlr in libmsc (large refactoring) 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
2016-06-19 16:06:02 +00:00
struct gsm_sms *sms_from_text(struct vlr_subscr *receiver,
Permit any Sender MSISDN when sending SMS from VTY 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
2018-04-09 17:19:33 +00:00
const char *sender_msisdn,
libmsc: Allow to set sender id when sending SMS from the VTY Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2012-12-27 23:49:01 +00:00
int dcs, const char *text)
sms: Move the sms_from_text to gsm_04_11 Move the SMS from text code from the VTY interface into the gsm_04_11.c code next to the sms_alloc and sms_free.
2011-01-10 14:21:34 +00:00
{
struct gsm_sms *sms = sms_alloc();
if (!sms)
return NULL;
vlr_subscr: use osmo_use_count Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-02-19 01:36:35 +00:00
vlr_subscr_get(receiver, VSUB_USE_SMS_RECEIVER);
sms->receiver = receiver;
Wrap osmo_strlcpy() calls 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
2018-02-05 11:57:06 +00:00
OSMO_STRLCPY_ARRAY(sms->text, text);
sms: Move the sms_from_text to gsm_04_11 Move the SMS from text code from the VTY interface into the gsm_04_11.c code next to the sms_alloc and sms_free.
2011-01-10 14:21:34 +00:00
Permit any Sender MSISDN when sending SMS from VTY 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
2018-04-09 17:19:33 +00:00
OSMO_STRLCPY_ARRAY(sms->src.addr, sender_msisdn);
sms: Move the sms_from_text to gsm_04_11 Move the SMS from text code from the VTY interface into the gsm_04_11.c code next to the sms_alloc and sms_free.
2011-01-10 14:21:34 +00:00
sms->reply_path_req = 0;
sms->status_rep_req = 0;
sms->ud_hdr_ind = 0;
sms->protocol_id = 0; /* implicit */
sms: Allow to specify the DCS for the SMS.
2011-01-10 14:34:09 +00:00
sms->data_coding_scheme = dcs;
Wrap osmo_strlcpy() calls 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
2018-02-05 11:57:06 +00:00
OSMO_STRLCPY_ARRAY(sms->dst.addr, receiver->msisdn);
sms: Move the sms_from_text to gsm_04_11 Move the SMS from text code from the VTY interface into the gsm_04_11.c code next to the sms_alloc and sms_free.
2011-01-10 14:21:34 +00:00
/* Generate user_data */
sms: Move to gsm_7bit_encode_n in the sms sending code Do not rely on the potential wrong gsm_7bit_encode result but use gsm_7bit_encode_n with maximum available space.
2013-12-26 21:33:02 +00:00
sms->user_data_len = gsm_7bit_encode_n(sms->user_data, sizeof(sms->user_data),
sms->text, NULL);
sms: Move the sms_from_text to gsm_04_11 Move the SMS from text code from the VTY interface into the gsm_04_11.c code next to the sms_alloc and sms_free.
2011-01-10 14:21:34 +00:00
return sms;
}
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
static void send_signal(int sig_no,
struct gsm_trans *trans,
struct gsm_sms *sms,
int paging_result)
{
struct sms_signal_data sig;
sig.trans = trans;
sig.sms = sms;
sig.paging_result = paging_result;
src: use namespace prefix osmo_signal* Summary of changes: s/signal_cbfn/osmo_signal_cbfn/g s/register_signal_handler/osmo_signal_register_handler/g s/unregister_signal_handler/osmo_signal_unregister_handler/g s/dispatch_signal/osmo_signal_dispatch/g
2011-05-06 10:12:31 +00:00
osmo_signal_dispatch(SS_SMS, sig_no, &sig);
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static int gsm411_sendmsg(struct gsm_trans *trans, struct msgb *msg)
ACK sms-submit
2008-12-29 01:54:02 +00:00
{
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "GSM4.11 TX %s\n", msgb_hexdump(msg));
bsc: Start creating 08.08 like API The 08.08 API will interface with the internal BSC code and it is the boundary between MSC and BSC. So nothing that calls the BSC functionality should know about lchan or such.
2010-03-23 06:40:46 +00:00
msg->l3h = msg->data;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
return msc_a_tx_dtap_to_i(trans->msc_a, msg);
ACK sms-submit
2008-12-29 01:54:02 +00:00
}
libmsc/gsm_04_11.c: properly handle MMTS indication 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
2019-05-11 22:38:41 +00:00
/* Handle MMTS (More Messages to Send) indication */
static void gsm411_handle_mmts_ind(const struct gsm_trans *trans)
{
int32_t use_count;
OSMO_ASSERT(trans);
OSMO_ASSERT(trans->msc_a);
use_count = osmo_use_count_by(&trans->msc_a->use_count, MSC_A_USE_SMS_MMTS);
OSMO_ASSERT(use_count >= 0); /* Shall not be negative */
if (trans->sms.sm_rp_mmts_ind && use_count == 0) {
LOG_TRANS(trans, LOGL_INFO, "Multi-part SMS delivery is initiated\n");
msc_a_get(trans->msc_a, MSC_A_USE_SMS_MMTS);
} else if (trans->sms.sm_rp_mmts_ind && use_count > 0) {
LOG_TRANS(trans, LOGL_INFO, "Continuing multi-part SMS delivery\n");
} else if (!trans->sms.sm_rp_mmts_ind && use_count > 0) {
LOG_TRANS(trans, LOGL_INFO, "Multi-part SMS delivery has been completed\n");
msc_a_put(trans->msc_a, MSC_A_USE_SMS_MMTS);
}
}
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Paging callback for MT SMS (Paging is triggered by SMC) */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
static void mmsms_paging_cb(struct msc_a *msc_a, struct gsm_trans *trans)
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
{
struct gsm_sms *sms = trans->sms.sms;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "%s(%s)\n", __func__, msc_a ? "success" : "expired");
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (msc_a) {
/* Paging succeeded */
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Associate transaction with established connection */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
msc_a_get(msc_a, MSC_A_USE_SMS);
trans->msc_a = msc_a;
libmsc/gsm_04_11.c: properly handle MMTS indication 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
2019-05-11 22:38:41 +00:00
/* Multi-part SMS: handle MMTS (More Messages to Send) indication */
gsm411_handle_mmts_ind(trans);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Confirm successful connection establishment */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
gsm411_smc_recv(&trans->sms.smc_inst, GSM411_MMSMS_EST_CNF, NULL, 0);
} else {
/* Paging expired or failed */
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Inform SMC about channel establishment failure */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
gsm411_smc_recv(&trans->sms.smc_inst, GSM411_MMSMS_REL_IND, NULL, 0);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
/* gsm411_send_rp_data() doesn't set trans->sms.sms */
if (sms != NULL) {
/* Notify the SMSqueue and free stored SMS */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
send_signal(S_SMS_UNKNOWN_ERROR, NULL, sms, 0);
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
trans->sms.sms = NULL;
sms_free(sms);
}
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Destroy this transaction */
trans_free(trans);
}
}
static int gsm411_mmsms_est_req(struct gsm_trans *trans)
{
/* Subscriber's data shall be associated */
OSMO_ASSERT(trans->vsub != NULL);
/* Check if connection is already established */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (trans->msc_a != NULL) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "Using an existing connection\n");
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
return gsm411_smc_recv(&trans->sms.smc_inst,
GSM411_MMSMS_EST_CNF, NULL, 0);
}
/* Initiate Paging procedure */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "Initiating Paging due to MMSMS_EST_REQ\n");
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
trans->paging_request = paging_request_start(trans->vsub, PAGING_CAUSE_SIGNALLING_LOW_PRIO,
mmsms_paging_cb, trans, "MT-SMS");
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
if (!trans->paging_request) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Failed to initiate Paging\n");
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Inform SMC about channel establishment failure */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
gsm411_smc_recv(&trans->sms.smc_inst, GSM411_MMSMS_REL_IND, NULL, 0);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
trans_free(trans);
return -EIO;
}
return 0;
}
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
/* Prefix msg with a 04.08/04.11 CP header */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
static int gsm411_cp_sendmsg(struct msgb *msg, struct gsm_trans *trans,
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t msg_type)
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
{
struct gsm48_hdr *gh;
gh = (struct gsm48_hdr *) msgb_push(msg, sizeof(*gh));
/* Outgoing needs the highest bit set */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
gh->proto_discr = GSM48_PDISC_SMS | (trans->transaction_id<<4);
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
gh->msg_type = msg_type;
DTAP: Ensure proper DLCI is used in MSC-originated DTAP 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
2018-04-09 14:35:01 +00:00
OMSC_LINKID_CB(msg) = trans->dlci;
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "sending CP message (trans=%x)\n", trans->transaction_id);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
return gsm411_sendmsg(trans, msg);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
}
/* mm_send: receive MMCCSMS sap message from SMC */
static int gsm411_mm_send(struct gsm411_smc_inst *inst, int msg_type,
struct msgb *msg, int cp_msg_type)
{
struct gsm_trans *trans =
container_of(inst, struct gsm_trans, sms.smc_inst);
int rc = 0;
switch (msg_type) {
case GSM411_MMSMS_EST_REQ:
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
rc = gsm411_mmsms_est_req(trans);
add more debugging to SMS layer
2009-08-14 08:42:43 +00:00
break;
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
case GSM411_MMSMS_DATA_REQ:
rc = gsm411_cp_sendmsg(msg, trans, cp_msg_type);
libmsc/gsm_04_11.c: cosmetic: restructure gsm411_mm_send() Change-Id: I22e99f40ab2252a0b716969091e4d24b3b4268a2
2019-05-11 20:23:00 +00:00
return rc; /* gsm411_cp_sendmsg() takes msg ownership */
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
case GSM411_MMSMS_REL_REQ:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "Got MMSMS_REL_REQ, destroying transaction.\n");
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
trans_free(trans);
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
break;
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Unhandled MMCCSMS msg 0x%x\n", msg_type);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
rc = -EINVAL;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
libmsc/gsm_04_11.c: cosmetic: restructure gsm411_mm_send() Change-Id: I22e99f40ab2252a0b716969091e4d24b3b4268a2
2019-05-11 20:23:00 +00:00
msgb_free(msg);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
return rc;
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
}
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
/* mm_send: receive MNCCSMS sap message from SMR */
int gsm411_mn_send(struct gsm411_smr_inst *inst, int msg_type,
struct msgb *msg)
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
{
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
struct gsm_trans *trans =
container_of(inst, struct gsm_trans, sms.smr_inst);
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
/* forward to SMC */
return gsm411_smc_send(&trans->sms.smc_inst, msg_type, msg);
more layering /abstraction of sms protocol
2009-07-04 15:39:00 +00:00
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static int gsm340_rx_sms_submit(struct gsm_trans *trans, struct gsm_sms *gsms)
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
{
if (db_sms_store(gsms) != 0) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Failed to store SMS in Database\n");
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
return GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
}
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* dispatch a signal to tell higher level about it */
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_SUBMITTED, NULL, gsms, 0);
actual code running at end of har2009
2009-08-17 07:39:55 +00:00
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
return 0;
}
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* generate a TPDU address field compliant with 03.40 sec. 9.1.2.5 */
sms: Use the definitions from the libosmogsm Use the code that is shipped inside the libosmogsm library. Right now the signature (besides the static) and the implementation is the same. This makes using the libosmogsm SMC code more easy in the near future. For the gsm340_gen_oa we are now using a small wrapper to generate the proper type and numbering plan.
2012-11-10 17:24:54 +00:00
static int gsm340_gen_oa_sub(uint8_t *oa, unsigned int oa_len,
SMPP: add small utility program 'smpp_mirror' This program binds as ESME transceiver to a SMSC and simply mirrors back all SMS that it receives.
2012-11-23 22:35:01 +00:00
const struct gsm_sms_addr *src)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
{
sms: Use the definitions from the libosmogsm Use the code that is shipped inside the libosmogsm library. Right now the signature (besides the static) and the implementation is the same. This makes using the libosmogsm SMC code more easy in the near future. For the gsm340_gen_oa we are now using a small wrapper to generate the proper type and numbering plan.
2012-11-10 17:24:54 +00:00
/* network specific, private numbering plan */
SMPP: add small utility program 'smpp_mirror' This program binds as ESME transceiver to a SMSC and simply mirrors back all SMS that it receives.
2012-11-23 22:35:01 +00:00
return gsm340_gen_oa(oa, oa_len, src->ton, src->npi, src->addr);
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
sms: Rename gsm340_gen_tpdu() to gsm340_gen_sms_deliver_tpdu() Rename gsm340_gen_tpdu() to gsm340_gen_sms_deliver_tpdu() to show that it generates SMS-DELIVER TPDU and is not a generic function.
2014-03-08 22:54:28 +00:00
/* generate a msgb containing an 03.40 9.2.2.1 SMS-DELIVER TPDU derived from
* struct gsm_sms, returns total size of TPDU */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static int gsm340_gen_sms_deliver_tpdu(struct gsm_trans *trans, struct msgb *msg, struct gsm_sms *sms)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
{
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t *smsp;
uint8_t oa[12]; /* max len per 03.40 */
uint8_t octet_len;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
unsigned int old_msg_len = msg->len;
libmsc: gsm340_gen_oa_sub() may return negative value 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
2017-08-10 07:38:58 +00:00
int oa_len;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
/* generate first octet with masked bits */
smsp = msgb_put(msg, 1);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* TP-MTI (message type indicator) */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
*smsp = GSM340_SMS_DELIVER_SC2MS;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* TP-MMS (more messages to send) */
if (0 /* FIXME */)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
*smsp |= 0x04;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* TP-SRI(deliver)/SRR(submit) */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
if (sms->status_rep_req)
*smsp |= 0x20;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
/* TP-UDHI (indicating TP-UD contains a header) */
if (sms->ud_hdr_ind)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
*smsp |= 0x40;
SMPP: add small utility program 'smpp_mirror' This program binds as ESME transceiver to a SMSC and simply mirrors back all SMS that it receives.
2012-11-23 22:35:01 +00:00
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
/* generate originator address */
SMPP: add small utility program 'smpp_mirror' This program binds as ESME transceiver to a SMSC and simply mirrors back all SMS that it receives.
2012-11-23 22:35:01 +00:00
oa_len = gsm340_gen_oa_sub(oa, sizeof(oa), &sms->src);
libmsc: gsm340_gen_oa_sub() may return negative value 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
2017-08-10 07:38:58 +00:00
if (oa_len < 0)
return -ENOSPC;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
smsp = msgb_put(msg, oa_len);
memcpy(smsp, oa, oa_len);
/* generate TP-PID */
smsp = msgb_put(msg, 1);
*smsp = sms->protocol_id;
/* generate TP-DCS */
smsp = msgb_put(msg, 1);
*smsp = sms->data_coding_scheme;
/* generate TP-SCTS */
smsp = msgb_put(msg, 7);
gsm340_gen_scts(smsp, time(NULL));
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
/* generate TP-UDL */
smsp = msgb_put(msg, 1);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
*smsp = sms->user_data_len;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
/* generate TP-UD */
Handle SMS with UCS2 and binary userdata
2009-08-15 01:01:46 +00:00
switch (gsm338_get_sms_alphabet(sms->data_coding_scheme)) {
case DCS_7BIT_DEFAULT:
Beautify septet->octet calculation (do not use ceil)
2009-08-13 01:39:07 +00:00
octet_len = sms->user_data_len*7/8;
if (sms->user_data_len*7%8 != 0)
octet_len++;
Fix gsm_7bit_{en,de}code function and sms user_data calculations With the 7bit alphabet the user_data_len field needs to be in septets (characters) and not in octets occupied.
2009-08-12 19:17:06 +00:00
/* Warning, user_data_len indicates the amount of septets
* (characters), we need amount of octets occupied */
Beautify septet->octet calculation (do not use ceil)
2009-08-13 01:39:07 +00:00
smsp = msgb_put(msg, octet_len);
memcpy(smsp, sms->user_data, octet_len);
Handle SMS with UCS2 and binary userdata
2009-08-15 01:01:46 +00:00
break;
case DCS_UCS2:
case DCS_8BIT_DATA:
smsp = msgb_put(msg, sms->user_data_len);
memcpy(smsp, sms->user_data, sms->user_data_len);
break;
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Unhandled Data Coding Scheme: 0x%02X\n",
sms->data_coding_scheme);
Handle SMS with UCS2 and binary userdata
2009-08-15 01:01:46 +00:00
break;
Fix gsm_7bit_{en,de}code function and sms user_data calculations With the 7bit alphabet the user_data_len field needs to be in septets (characters) and not in octets occupied.
2009-08-12 19:17:06 +00:00
}
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
return msg->len - old_msg_len;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
/* As defined by GSM 03.40, Section 9.2.2.3. */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static int gsm340_gen_sms_status_report_tpdu(struct gsm_trans *trans, struct msgb *msg,
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
struct gsm_sms *sms)
{
unsigned int old_msg_len = msg->len;
uint8_t oa[12]; /* max len per 03.40 */
uint8_t *smsp;
libmsc: gsm340_gen_oa_sub() may return negative value 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
2017-08-10 07:38:58 +00:00
int oa_len;
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
/* generate first octet with masked bits */
smsp = msgb_put(msg, 1);
/* TP-MTI (message type indicator) */
*smsp = GSM340_SMS_STATUS_REP_SC2MS;
/* TP-MMS (more messages to send) */
if (0 /* FIXME */)
*smsp |= 0x04;
/* TP-MR (message reference) */
smsp = msgb_put(msg, 1);
*smsp = sms->msg_ref;
libmsc: gsm340_gen_oa_sub() may return negative value 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
2017-08-10 07:38:58 +00:00
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
/* generate recipient address */
LIBMSC: Place correct dst address in status report 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
2017-08-14 13:06:33 +00:00
oa_len = gsm340_gen_oa_sub(oa, sizeof(oa), &sms->src);
libmsc: gsm340_gen_oa_sub() may return negative value 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
2017-08-10 07:38:58 +00:00
if (oa_len < 0)
return -ENOSPC;
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
smsp = msgb_put(msg, oa_len);
memcpy(smsp, oa, oa_len);
/* generate TP-SCTS (Service centre timestamp) */
smsp = msgb_put(msg, 7);
libmsc: Use actual delivery time in delivery reports. 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
2017-08-16 20:45:07 +00:00
gsm340_gen_scts(smsp, sms->created);
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
/* generate TP-DT (Discharge time, in TP-SCTS format). */
smsp = msgb_put(msg, 7);
libmsc: Use actual delivery time in delivery reports. 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
2017-08-16 20:45:07 +00:00
gsm340_gen_scts(smsp, sms->created);
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
/* TP-ST (status) */
smsp = msgb_put(msg, 1);
/* From GSM 03.40, Section 9.2.3.15, 0x00 means OK. */
*smsp = 0x00;
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_INFO, "sending status report for SMS reference %x\n",
sms->msg_ref);
libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report 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
2017-08-07 13:01:40 +00:00
return msg->len - old_msg_len;
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static int sms_route_mt_sms(struct gsm_trans *trans, struct gsm_sms *gsms)
sms: Move the routing of the sms to a separate function The "default-route" for SMPP will be used after a local subscriber look-up. Sometimes we want to route everything to SMPP. Make this possible by changing this routine.
2015-07-06 13:54:25 +00:00
{
int rc;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
struct msc_a *msc_a = trans->msc_a;
struct gsm_network *net = msc_a_net(msc_a);
sms: Move the routing of the sms to a separate function The "default-route" for SMPP will be used after a local subscriber look-up. Sometimes we want to route everything to SMPP. Make this possible by changing this routine.
2015-07-06 13:54:25 +00:00
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
#ifdef BUILD_SMPP
/*
* Route through SMPP first before going to the local database. In case
* of a unroutable message and no local subscriber, SMPP will be tried
* twice. In case of an unknown subscriber continue with the normal
* delivery of the SMS.
*/
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (smpp_route_smpp_first()) {
rc = smpp_try_deliver(gsms, msc_a);
libmsc: use GSM411_RP_CAUSE_MO_NUM_UNASSIGNED as return value Instead of hardcoded value of 1 plus comment of the right hand side of the statement. Change-Id: I865bdbd6da17a0389044a8e749deeeebcb9cae06
2017-05-03 16:59:05 +00:00
if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED)
smpp: fix return cause Return cause 38 when default SMPP route is unavailable. This is better than cause 1. Change-Id: If3241d50a78fa611981e55fef6ae4c72b0a2a167
2017-07-05 09:46:55 +00:00
/* unknown subscriber, try local */
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
goto try_local;
if (rc < 0) {
fix various missing line endings in logging Change-Id: I013eb0eeb5673c06034465020e5dc5230f45ddf5
2019-05-06 21:45:09 +00:00
LOG_TRANS(trans, LOGL_ERROR, "SMS delivery error: %d\n", rc);
sms: change rp err cause of smpp_try_deliver errors smpp_try_deliver could fail with rc < 0. In such cases don't send the MS the rp error sms rejected (cause 21). A rejected message should not be sent again. The spec 04 11 recommends sending cause 41 Temporary failure in unknown cases. Add also a log message and rate counter for such cases. Tweaked-By: Neels Hofmeyr <nhofmeyr@sysmocom.de> Change-Id: Ia03e50ce2bd9a7d1054cc5a6000fd73bd3497c03
2016-08-21 18:16:33 +00:00
rc = GSM411_RP_CAUSE_MO_TEMP_FAIL;
/* rc will be logged by gsm411_send_rp_error() */
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_DELIVER_UNKNOWN_ERROR));
sms: Add a way to always route SMS through SMPP systems default-route would only be looked at after there has been no subscriber in the local database. Depending on the setup this is not what one wants. This has been discussed at the OsmoDevCon and there have been hacks in some branches. Let's introduce a VTY command to select if SMPP should be consulted first and then fallback to the current behavior.
2015-07-06 14:41:30 +00:00
}
return rc;
}
try_local:
#endif
sms: Move the routing of the sms to a separate function The "default-route" for SMPP will be used after a local subscriber look-up. Sometimes we want to route everything to SMPP. Make this possible by changing this routine.
2015-07-06 13:54:25 +00:00
/* determine gsms->receiver based on dialled number */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
gsms->receiver = vlr_subscr_find_by_msisdn(net->vlr, gsms->dst.addr, VSUB_USE_SMS_RECEIVER);
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
if (gsms->receiver)
return 0;
sms: Move the routing of the sms to a separate function The "default-route" for SMPP will be used after a local subscriber look-up. Sometimes we want to route everything to SMPP. Make this possible by changing this routine.
2015-07-06 13:54:25 +00:00
#ifdef BUILD_SMPP
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
/* Avoid a second look-up */
if (smpp_route_smpp_first()) {
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_NO_RECEIVER));
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
return GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
}
sms: Do not go through the routing a second time If we have tried SMPP first and it was not routable, and then tried the local delivery there is no point in trying SMPP with the same parameters again. Leave early and return unknown sub to the caller.
2015-07-13 08:39:51 +00:00
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
rc = smpp_try_deliver(gsms, msc_a);
if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) {
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_NO_RECEIVER));
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
} else if (rc < 0) {
LOG_TRANS(trans, LOGL_ERROR, "SMS delivery error: %d\n", rc);
rc = GSM411_RP_CAUSE_MO_TEMP_FAIL;
/* rc will be logged by gsm411_send_rp_error() */
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_DELIVER_UNKNOWN_ERROR));
Trivial: code simplification, return early 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
2020-01-13 05:30:27 +00:00
}
#else
rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_NO_RECEIVER));
sms: Move the routing of the sms to a separate function The "default-route" for SMPP will be used after a local subscriber look-up. Sometimes we want to route everything to SMPP. Make this possible by changing this routine.
2015-07-06 13:54:25 +00:00
#endif
return rc;
}
[misc] Remove whitespace from the end of the line.
2010-03-29 06:47:44 +00:00
/* process an incoming TPDU (called from RP-DATA)
* return value > 0: RP CAUSE for ERROR; < 0: silent error; 0 = success */
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
static int gsm340_rx_tpdu(struct gsm_trans *trans, struct msgb *msg,
libmsc: remove 'deferred' parameter in sms_route_mt_sms() No need to cache the sms object, just cache what we need into the smpp_cmd structure. This simplifies what that I introduced in 93ffbd0029d1 ("libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP"). Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
2017-08-07 13:01:10 +00:00
uint32_t gsm411_msg_ref)
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
{
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t *smsp = msgb_sms(msg);
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
struct gsm_sms *gsms;
gsm_04_11: use 'unsigned int sms_alphabet' to include 0xffffffff Detected by Smatch
2011-07-16 11:34:52 +00:00
unsigned int sms_alphabet;
gsm340_rx_tpdu: comment-out two unused vars Kills two compiler warnings.
2016-02-24 18:30:52 +00:00
uint8_t sms_mti, sms_vpf;
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t *sms_vp;
uint8_t da_len_bytes;
uint8_t address_lv[12]; /* according to 03.40 / 9.1.2.5 */
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
int rc = 0;
libmsc/gsm_04_11.c: fix NULL-pointer dereference in gsm340_rx_tpdu() Change-Id: I1e9b351e949efe596295d18f98c8a73c8e013763 Fixes: CID#198451
2019-05-10 20:35:45 +00:00
struct gsm_network *net;
struct vlr_subscr *vsub;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
libmsc/gsm_04_11.c: fix NULL-pointer dereference in gsm340_rx_tpdu() Change-Id: I1e9b351e949efe596295d18f98c8a73c8e013763 Fixes: CID#198451
2019-05-10 20:35:45 +00:00
if (!trans->msc_a) {
LOG_TRANS(trans, LOGL_ERROR, "Insufficient info to process TPDU: "
"MSC-A role is NULL?!?\n");
return GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
}
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
libmsc/gsm_04_11.c: fix NULL-pointer dereference in gsm340_rx_tpdu() Change-Id: I1e9b351e949efe596295d18f98c8a73c8e013763 Fixes: CID#198451
2019-05-10 20:35:45 +00:00
net = msc_a_net(trans->msc_a);
vsub = msc_a_vsub(trans->msc_a);
if (!net || !vsub) {
LOG_TRANS(trans, LOGL_ERROR, "Insufficient info to process TPDU: "
"gsm_network and/or vlr_subscr is NULL?!?\n");
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
return GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
libmsc/gsm_04_11.c: fix NULL-pointer dereference in gsm340_rx_tpdu() Change-Id: I1e9b351e949efe596295d18f98c8a73c8e013763 Fixes: CID#198451
2019-05-10 20:35:45 +00:00
}
/* FIXME: should we do this on success, after all checks? */
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_SUBMITTED));
keep some internal statistics inside OpenBSC the statistics will give us some idea about the network load and performance.
2009-12-21 23:41:05 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms = sms_alloc();
if (!gsms)
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
return GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
/* invert those fields where 0 means active/present */
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_mti = *smsp & 0x03;
sms_vpf = (*smsp & 0x18) >> 3;
libmsc: missing bit shift in status report flag when stored in sms object So we just store 0 or 1 depending on what the mobile phone requests. Change-Id: Idb7d5594219c0e458ccb561383a59604bc1a4201
2017-08-07 13:01:21 +00:00
gsms->status_rep_req = (*smsp & 0x20) >> 5;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms->ud_hdr_ind = (*smsp & 0x40);
gsm340_rx_tpdu: comment-out two unused vars Kills two compiler warnings.
2016-02-24 18:30:52 +00:00
/*
* Not evaluating MMS (More Messages to Send) because the
* lchan stays open anyway.
* Not evaluating RP (Reply Path) because we're not aware of its
* benefits.
*/
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
smsp++;
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms->msg_ref = *smsp++;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
gsms->gsm411.transaction_id = trans->transaction_id;
gsms->gsm411.msg_ref = gsm411_msg_ref;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
/* length in bytes of the destination address */
da_len_bytes = 2 + *smsp/2 + *smsp%2;
if (da_len_bytes > 12) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Destination Address > 12 bytes ?!?\n");
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
rc = GSM411_RP_CAUSE_SEMANT_INC_MSG;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
goto out;
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
} else if (da_len_bytes < 4) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Destination Address < 4 bytes ?!?\n");
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
rc = GSM411_RP_CAUSE_SEMANT_INC_MSG;
goto out;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
}
SMS: fix parsing of destination phone number
2009-06-11 18:42:11 +00:00
memset(address_lv, 0, sizeof(address_lv));
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
memcpy(address_lv, smsp, da_len_bytes);
/* mangle first byte to reflect length in bytes, not digits */
SMS: fix parsing of destination phone number
2009-06-11 18:42:11 +00:00
address_lv[0] = da_len_bytes - 1;
SMPP: Implement support for MO SMS Each ESME can have a number of prefix-matching routes, or it can be a 'default route' to whcih all otherwise unknown SMS destinations are routed.
2012-11-23 18:02:37 +00:00
SMPP: add small utility program 'smpp_mirror' This program binds as ESME transceiver to a SMSC and simply mirrors back all SMS that it receives.
2012-11-23 22:35:01 +00:00
gsms->dst.ton = (address_lv[1] >> 4) & 7;
gsms->dst.npi = address_lv[1] & 0xF;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
/* convert to real number */
gsm_04_11: use gsm48_decode_bcd_number2(), evaluate rc 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
2019-04-29 17:14:43 +00:00
if (gsm48_decode_bcd_number2(gsms->dst.addr,
sizeof(gsms->dst.addr), address_lv, da_len_bytes, 1)) {
LOG_TRANS(trans, LOGL_ERROR, "Failed to decode destination Address\n");
rc = GSM411_RP_CAUSE_SEMANT_INC_MSG;
goto out;
}
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
smsp += da_len_bytes;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms->protocol_id = *smsp++;
gsms->data_coding_scheme = *smsp++;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_alphabet = gsm338_get_sms_alphabet(gsms->data_coding_scheme);
gsm_04_11: Attempt to fix some possible memory leaks in the SMS code Sometimes we need to free the SMS, sometimes also the transaction.
2010-06-14 08:13:16 +00:00
if (sms_alphabet == 0xffffffff) {
sms: Possiqble meamleak fix gsm340_rx_tpdu() Slight clean up of the code in gsm340_rx_tpdu() and a fix for an unlikely, but possible memory leak there.
2013-10-04 00:42:27 +00:00
rc = GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
goto out;
gsm_04_11: Attempt to fix some possible memory leaks in the SMS code Sometimes we need to free the SMS, sometimes also the transaction.
2010-06-14 08:13:16 +00:00
}
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
switch (sms_vpf) {
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
case GSM340_TP_VPF_RELATIVE:
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_vp = smsp++;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
break;
case GSM340_TP_VPF_ABSOLUTE:
case GSM340_TP_VPF_ENHANCED:
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_vp = smsp;
[SMS] Implement TP-VPF-ENHANCED While doing so, we also restructure/reorganize the vailidity period parsing in general.
2009-11-26 11:28:41 +00:00
/* the additional functionality indicator... */
[sms] bugfix: additional functionality indicator only appears in TP_VPF_ENHANCED - not in TP_VPF_ABSOLUTE
2009-12-05 11:44:41 +00:00
if (sms_vpf == GSM340_TP_VPF_ENHANCED && *smsp & (1<<7))
smsp++;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
smsp += 7;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
break;
Support sms with a validity period format of none
2009-08-13 01:40:49 +00:00
case GSM340_TP_VPF_NONE:
sms_vp = 0;
break;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "SMS Validity period not implemented: 0x%02x\n", sms_vpf);
sms: Possiqble meamleak fix gsm340_rx_tpdu() Slight clean up of the code in gsm340_rx_tpdu() and a fix for an unlikely, but possible memory leak there.
2013-10-04 00:42:27 +00:00
rc = GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER;
goto out;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
}
libmsc/gsm_04_11.c: properly handle TP-User-Data-Length 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
2019-04-16 08:18:33 +00:00
/* As per 3GPP TS 03.40, section 9.2.3.16, TP-User-Data-Length (TP-UDL)
* may indicate either the number of septets, or the number of octets,
* depending on Data Coding Scheme. We store TP-UDL value as-is,
* so this should be kept in mind to avoid buffer overruns. */
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms->user_data_len = *smsp++;
libmsc/gsm_04_11.c: properly handle TP-User-Data-Length 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
2019-04-16 08:18:33 +00:00
if (gsms->user_data_len > 0) {
if (sms_alphabet == DCS_7BIT_DEFAULT) {
/* TP-UDL is indicated in septets (up to 160) */
if (gsms->user_data_len > GSM340_UDL_SPT_MAX) {
LOG_TRANS(trans, LOGL_NOTICE,
"TP-User-Data-Length %u (septets) "
"is too big, truncating to %u\n",
gsms->user_data_len, GSM340_UDL_SPT_MAX);
gsms->user_data_len = GSM340_UDL_SPT_MAX;
}
memcpy(gsms->user_data, smsp, gsm_get_octet_len(gsms->user_data_len));
gsm_7bit_decode_n(gsms->text, sizeof(gsms->text),
smsp, gsms->user_data_len);
} else {
/* TP-UDL is indicated in octets (up to 140) */
if (gsms->user_data_len > GSM340_UDL_OCT_MAX) {
LOG_TRANS(trans, LOGL_NOTICE,
"TP-User-Data-Length %u (octets) "
"is too big, truncating to %u\n",
gsms->user_data_len, GSM340_UDL_OCT_MAX);
gsms->user_data_len = GSM340_UDL_OCT_MAX;
}
memcpy(gsms->user_data, smsp, gsms->user_data_len);
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
}
}
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
OSMO_STRLCPY_ARRAY(gsms->src.addr, vsub->msisdn);
introduce multiple log levels (DEBUG/INFO/NOTICE/ERROR) to SMS code
2009-12-24 14:08:18 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_INFO,
"MO SMS -- MTI: 0x%02x, VPF: 0x%02x, "
"MR: 0x%02x PID: 0x%02x, DCS: 0x%02x, DA: %s, "
"UserDataLength: 0x%02x, UserData: \"%s\"\n",
sms_mti, sms_vpf, gsms->msg_ref,
gsms->protocol_id, gsms->data_coding_scheme, gsms->dst.addr,
gsms->user_data_len,
sms_alphabet == DCS_7BIT_DEFAULT ? gsms->text :
osmo_hexdump(gsms->user_data, gsms->user_data_len));
[sms] Send a notification on incoming SMS Further tests of the signal class. Send a notification on incoming SMS.
2009-02-16 19:07:18 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
gsms->validity_minutes = gsm340_validity_period(sms_vpf, sms_vp);
sms: Introduce VTY-configurable minimum SMS validity period 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
2022-05-17 17:01:43 +00:00
if (gsms->validity_minutes < net->sms_queue_cfg->minimum_validity_mins) {
LOG_TRANS(trans, LOGL_INFO, "Overriding user-provided validity period (%lu) "
"with minimum SMSC validity period (%u) minutes\n", gsms->validity_minutes,
net->sms_queue_cfg->minimum_validity_mins);
gsms->validity_minutes = net->sms_queue_cfg->minimum_validity_mins;
}
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
rc = sms_route_mt_sms(trans, gsms);
libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms() 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
2017-08-07 13:01:13 +00:00
libmsc: SMS, Avoid premature RP-ACK to MS 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
2020-01-15 09:00:24 +00:00
/* This SMS got routed through SMPP and we are waiting on the response. */
if (gsms->smpp.esme) {
libmsc: fix memory leak (struct gsm_sms) in gsm340_rx_tpdu() If a MO SMS gets successfully routed through SMPP, we return early in gsm340_rx_tpdu() and leak a chunk of type 'struct gsm_sms'. Change-Id: I8a745d747f06baa7109418ffe600b27b3c0a5228 Fixes: [1] Ic34d398e0a850856e20380ae35e5c2ae5e3c539b Fixes: OS#5334
2021-11-28 23:09:43 +00:00
rc = -EINPROGRESS;
goto out;
libmsc: SMS, Avoid premature RP-ACK to MS 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
2020-01-15 09:00:24 +00:00
}
Don't Store an SMS in the database when the ESME is not Bound 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
2020-09-01 14:41:32 +00:00
/* This SMS got routed through SMPP, but the configured ESME was
* unavailable at this time. This is an OOO condition.
* Don't store this SMS in the database as we may never be
* able to deliver it. (we would need to process the stored SMS and
* attempt re-submission to the ESME)
*/
if (rc == GSM411_RP_CAUSE_MO_NET_OUT_OF_ORDER)
libmsc: fix another memleak (struct gsm_sms) in gsm340_rx_tpdu() Change-Id: I42e819fb83096c1432df16f501b9d1f6a6160ae7 Fixes: I2c50904349dd4ed229b60b8468d776b817c0bd44
2021-11-29 12:45:25 +00:00
goto out; /* free() the message */
Don't Store an SMS in the database when the ESME is not Bound 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
2020-09-01 14:41:32 +00:00
Accept SMS for any receiver 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
2018-01-22 17:33:42 +00:00
/*
* This SMS got routed through SMPP or no receiver exists.
* In any case, we store it in the database for further processing.
*/
libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms() 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
2017-08-07 13:01:13 +00:00
switch (sms_mti) {
case GSM340_SMS_SUBMIT_MS2SC:
/* MS is submitting a SMS */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
rc = gsm340_rx_sms_submit(trans, gsms);
libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms() 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
2017-08-07 13:01:13 +00:00
break;
case GSM340_SMS_COMMAND_MS2SC:
case GSM340_SMS_DELIVER_REP_MS2SC:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti);
libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms() 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
2017-08-07 13:01:13 +00:00
rc = GSM411_RP_CAUSE_IE_NOTEXIST;
break;
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti);
libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms() 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
2017-08-07 13:01:13 +00:00
rc = GSM411_RP_CAUSE_IE_NOTEXIST;
break;
}
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
out:
libmsc: remove 'deferred' parameter in sms_route_mt_sms() No need to cache the sms object, just cache what we need into the smpp_cmd structure. This simplifies what that I introduced in 93ffbd0029d1 ("libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP"). Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
2017-08-07 13:01:10 +00:00
sms_free(gsms);
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
return rc;
Parse sms-submit messages
2008-12-29 00:44:41 +00:00
}
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
/* Prefix msg with a RP-DATA header and send as SMR DATA */
static int gsm411_rp_sendmsg(struct gsm411_smr_inst *inst, struct msgb *msg,
uint8_t rp_msg_type, uint8_t rp_msg_ref,
int rl_msg_type)
{
struct gsm411_rp_hdr *rp;
uint8_t len = msg->len;
/* GSM 04.11 RP-DATA header */
rp = (struct gsm411_rp_hdr *)msgb_push(msg, sizeof(*rp));
rp->len = len + 2;
rp->msg_type = rp_msg_type;
sms: Increment the RP Message Reference for each transaction Each RP-DATA should have a unique msg reference. Currently 42 is used for all of these. Remember the last reference we used and increment it on the next SMS. Do not track if the reference is still in use a clash is a lot less likely now. First unless SMPP is used only one SMS is delivered at a time, second the transaction space is a lot smaller than the one for the reference.
2014-02-08 14:20:48 +00:00
rp->msg_ref = rp_msg_ref;
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
return gsm411_smr_send(inst, rl_msg_type, msg);
}
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
int gsm411_send_rp_ack(struct gsm_trans *trans, uint8_t msg_ref)
ACK sms-submit
2008-12-29 01:54:02 +00:00
{
struct msgb *msg = gsm411_msgb_alloc();
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "TX: SMS RP ACK\n");
ACK sms-submit
2008-12-29 01:54:02 +00:00
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
return gsm411_rp_sendmsg(&trans->sms.smr_inst, msg, GSM411_MT_RP_ACK_MT,
msg_ref, GSM411_SM_RL_REPORT_REQ);
ACK sms-submit
2008-12-29 01:54:02 +00:00
}
libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-04 16:44:22 +00:00
int gsm411_send_rp_error(struct gsm_trans *trans, uint8_t msg_ref,
uint8_t cause)
ACK sms-submit
2008-12-29 01:54:02 +00:00
{
struct msgb *msg = gsm411_msgb_alloc();
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
msgb_tv_put(msg, 1, cause);
ACK sms-submit
2008-12-29 01:54:02 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "TX: SMS RP ERROR, cause %d (%s)\n", cause,
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
get_value_string(gsm411_rp_cause_strs, cause));
ACK sms-submit
2008-12-29 01:54:02 +00:00
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
return gsm411_rp_sendmsg(&trans->sms.smr_inst, msg,
GSM411_MT_RP_ERROR_MT, msg_ref, GSM411_SM_RL_REPORT_REQ);
ACK sms-submit
2008-12-29 01:54:02 +00:00
}
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
/* Receive a 04.11 TPDU inside RP-DATA / user data */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
static int gsm411_rx_rp_ud(struct msgb *msg, struct gsm_trans *trans,
libmsc/gsm_04_11.c: forward MO SMS messages over GSUP Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-11-06 22:08:18 +00:00
struct gsm411_rp_hdr *rph,
uint8_t *dst, uint8_t dst_len)
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
{
int rc = 0;
libmsc/gsm_04_11.c: forward MO SMS messages over GSUP Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-11-06 22:08:18 +00:00
if (trans->net->sms_over_gsup) {
/* RP-ACK or RP-ERROR is triggered as soon as we get the response */
rc = gsm411_gsup_mo_fwd_sm_req(trans, msg, rph->msg_ref, dst, dst_len);
if (rc) /* GSUP message sending error */
return gsm411_send_rp_error(trans, rph->msg_ref, rc);
return 0;
}
libmsc: remove 'deferred' parameter in sms_route_mt_sms() No need to cache the sms object, just cache what we need into the smpp_cmd structure. This simplifies what that I introduced in 93ffbd0029d1 ("libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP"). Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
2017-08-07 13:01:10 +00:00
rc = gsm340_rx_tpdu(trans, msg, rph->msg_ref);
if (rc == 0)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
return gsm411_send_rp_ack(trans, rph->msg_ref);
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
else if (rc > 0)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
return gsm411_send_rp_error(trans, rph->msg_ref, rc);
libmsc: SMS, Avoid premature RP-ACK to MS 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
2020-01-15 09:00:24 +00:00
else if (rc == -EINPROGRESS)
rc = 0;
return rc;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
}
/* Receive a 04.11 RP-DATA message in accordance with Section 7.3.1.2 */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
static int gsm411_rx_rp_data(struct msgb *msg, struct gsm_trans *trans,
struct gsm411_rp_hdr *rph)
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
{
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t src_len, dst_len, rpud_len;
uint8_t *src = NULL, *dst = NULL , *rp_ud = NULL;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
/* in the MO case, this should always be zero length */
src_len = rph->data[0];
if (src_len)
src = &rph->data[1];
dst_len = rph->data[1+src_len];
if (dst_len)
dst = &rph->data[1+src_len+1];
rpud_len = rph->data[1+src_len+1+dst_len];
if (rpud_len)
rp_ud = &rph->data[1+src_len+1+dst_len+1];
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "RX_RP-DATA: src_len=%u, dst_len=%u ud_len=%u\n",
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
src_len, dst_len, rpud_len);
libmsc/gsm_04_11.c: refactor RP-DATA header validation 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
2018-11-06 20:20:00 +00:00
if (src_len && src)
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "RP-DATA (MO) with SRC ?!?\n");
libmsc/gsm_04_11.c: refactor RP-DATA header validation 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
2018-11-06 20:20:00 +00:00
if (!dst_len || !dst || !rpud_len || !rp_ud) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR,
libmsc/gsm_04_11.c: refactor RP-DATA header validation 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
2018-11-06 20:20:00 +00:00
"RP-DATA (MO) without DST or TPDU ?!?\n");
gsm411_send_rp_error(trans, rph->msg_ref,
GSM411_RP_CAUSE_INV_MAND_INF);
return -EIO;
}
msg->l4h = rp_ud;
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "DST(%u,%s)\n", dst_len, osmo_hexdump(dst, dst_len));
libmsc/gsm_04_11.c: refactor RP-DATA header validation 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
2018-11-06 20:20:00 +00:00
libmsc/gsm_04_11.c: forward MO SMS messages over GSUP Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-11-06 22:08:18 +00:00
return gsm411_rx_rp_ud(msg, trans, rph, dst, dst_len);
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static struct gsm_sms *sms_report_alloc(struct gsm_sms *sms, struct gsm_trans *trans)
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
{
struct gsm_sms *sms_report;
int len;
sms_report = sms_alloc();
OSMO_ASSERT(sms_report);
sms_report->msg_ref = sms->msg_ref;
sms_report->protocol_id = sms->protocol_id;
sms_report->data_coding_scheme = GSM338_DCS_1111_8BIT_DATA;
/* Invert address to send status report back to origin. */
sms_report->src = sms->dst;
sms_report->dst = sms->src;
/* As specified by Appendix B. Delivery Receipt Format.
* TODO: Many fields in this string are just set with dummy values,
* revisit this.
*/
len = snprintf((char *)sms_report->user_data,
sizeof(sms_report->user_data),
"id:%.08llu sub:000 dlvrd:000 submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DELIVRD err:000 text:%.20s",
LIBMSC: Use sms->text, not sms->user_data to construct report body 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
2017-08-14 13:11:57 +00:00
sms->id, sms->text);
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
sms_report->user_data_len = len;
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "%s\n", sms_report->user_data);
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
/* This represents a sms report. */
sms_report->is_report = true;
return sms_report;
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
static void sms_status_report(struct gsm_sms *gsms, struct gsm_trans *trans)
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
{
struct gsm_sms *sms_report;
int rc;
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
sms_report = sms_report_alloc(gsms, trans);
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
rc = sms_route_mt_sms(trans, sms_report);
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
if (rc < 0) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Failed to send status report! err=%d\n", rc);
return;
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
}
libmsc: support GSM 03.40 status report for nitb This patch adds support for GSM 03.40 in nitb mode. MS GSM 03.40 SMSC | | | SMS-SUBMIT | |--------------------------->| | GSM 04.11 RP-ACK | |<---------------------------| | SMS-DELIVER | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | SMS-STATUS-REPORT | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | | Change-Id: I5cc7bb4ebadde0940f44d10c3df34707b0615160
2017-08-07 14:17:17 +00:00
/* No route via SMPP, send the GSM 03.40 status-report now. */
libmsc: Don't send SMS STATUS REPORT locally if the ESME accepted it. 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
2018-11-16 13:29:05 +00:00
if (sms_report->receiver)
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
gsm340_rx_sms_submit(trans, sms_report);
libmsc: support GSM 03.40 status report for nitb This patch adds support for GSM 03.40 in nitb mode. MS GSM 03.40 SMSC | | | SMS-SUBMIT | |--------------------------->| | GSM 04.11 RP-ACK | |<---------------------------| | SMS-DELIVER | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | SMS-STATUS-REPORT | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | | Change-Id: I5cc7bb4ebadde0940f44d10c3df34707b0615160
2017-08-07 14:17:17 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Status report has been sent\n");
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
sms_free(sms_report);
}
implement proper SAPI3 handling for SMS SM's need to be transferred over their own RLL connection on SAPI3, rather than the default SAPI0 connection that we're using for signalling like 04.08 RR/MM/CC. This is not that much of a problem in the case of SMS SUBMIT from the MS to the netwrok. In that case, the MS will start its primary RLL connection with SAPI3, and we can just respond with SAPI3. However, in the case of SMS DELIVER to a MS, we first page the MS, it then establishes SAPI0. We then need to explicitly request the establishment of a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER RPDU Now that we have the bsc_rll.c code, we can actually wait for a paging response, and from the paging response request the establishment of the SAPI3 connection. We will be called back once that connection is open and can successively start transmission of the SM.
2009-08-09 12:59:02 +00:00
/* Receive a 04.11 RP-ACK message (response to RP-DATA from us) */
libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error} 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
2018-11-22 09:54:36 +00:00
static int gsm411_rx_rp_ack(struct gsm_trans *trans,
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
struct gsm411_rp_hdr *rph)
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
{
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
struct gsm_sms *sms = trans->sms.sms;
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
/* Acnkowledgement to MT RP_DATA, i.e. the MS confirms it
* successfully received a SMS. We can now safely mark it as
* transmitted */
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
if (trans->net->sms_over_gsup) {
/* Forward towards SMSC via GSUP */
return gsm411_gsup_mt_fwd_sm_res(trans, rph->msg_ref);
}
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
if (!sms) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "RX RP-ACK but no sms in transaction?!?\n");
implement proper SAPI3 handling for SMS SM's need to be transferred over their own RLL connection on SAPI3, rather than the default SAPI0 connection that we're using for signalling like 04.08 RR/MM/CC. This is not that much of a problem in the case of SMS SUBMIT from the MS to the netwrok. In that case, the MS will start its primary RLL connection with SAPI3, and we can just respond with SAPI3. However, in the case of SMS DELIVER to a MS, we first page the MS, it then establishes SAPI0. We then need to explicitly request the establishment of a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER RPDU Now that we have the bsc_rll.c code, we can actually wait for a paging response, and from the paging response request the establishment of the SAPI3 connection. We will be called back once that connection is open and can successively start transmission of the SM.
2009-08-09 12:59:02 +00:00
return gsm411_send_rp_error(trans, rph->msg_ref,
GSM411_RP_CAUSE_PROTOCOL_ERR);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
}
/* mark this SMS as sent in database */
db,sms: Rename db_sms_mark_sent() to db_sms_mark_delivered() In MT-SMS the message is being delivered. Make the naming follow that. The schema still refers to "sent" while it should be "delivered" too.
2014-03-08 20:27:37 +00:00
db_sms_mark_delivered(sms);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_DELIVERED, trans, sms, 0);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
if (sms->status_rep_req)
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
sms_status_report(sms, trans);
libmsc: add support for SMPP delivery receipts 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
2017-08-07 13:01:30 +00:00
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_free(sms);
trans->sms.sms = NULL;
return 0;
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
}
libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error} 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
2018-11-22 09:54:36 +00:00
static int gsm411_rx_rp_error(struct gsm_trans *trans,
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
struct gsm411_rp_hdr *rph)
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
{
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
struct msc_a *msc_a = trans->msc_a;
struct gsm_network *net = msc_a_net(msc_a);
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
struct gsm_sms *sms = trans->sms.sms;
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t cause_len = rph->data[0];
uint8_t cause = rph->data[1];
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
/* Error in response to MT RP_DATA, i.e. the MS did not
* successfully receive the SMS. We need to investigate
* the cause and take action depending on it */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "RX SMS RP-ERROR, cause %d:%d (%s)\n",
cause_len, cause, get_value_string(gsm411_rp_cause_strs, cause));
some more comments
2009-07-09 21:52:59 +00:00
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
if (trans->net->sms_over_gsup) {
/* Forward towards SMSC via GSUP */
return gsm411_gsup_mt_fwd_sm_err(trans, rph->msg_ref, cause);
}
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
if (!sms) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "RX RP-ERR, but no sms in transaction?!?\n");
actual code running at end of har2009
2009-08-17 07:39:55 +00:00
return -EINVAL;
#if 0
implement proper SAPI3 handling for SMS SM's need to be transferred over their own RLL connection on SAPI3, rather than the default SAPI0 connection that we're using for signalling like 04.08 RR/MM/CC. This is not that much of a problem in the case of SMS SUBMIT from the MS to the netwrok. In that case, the MS will start its primary RLL connection with SAPI3, and we can just respond with SAPI3. However, in the case of SMS DELIVER to a MS, we first page the MS, it then establishes SAPI0. We then need to explicitly request the establishment of a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER RPDU Now that we have the bsc_rll.c code, we can actually wait for a paging response, and from the paging response request the establishment of the SAPI3 connection. We will be called back once that connection is open and can successively start transmission of the SM.
2009-08-09 12:59:02 +00:00
return gsm411_send_rp_error(trans, rph->msg_ref,
GSM411_RP_CAUSE_PROTOCOL_ERR);
actual code running at end of har2009
2009-08-17 07:39:55 +00:00
#endif
implement proper SAPI3 handling for SMS SM's need to be transferred over their own RLL connection on SAPI3, rather than the default SAPI0 connection that we're using for signalling like 04.08 RR/MM/CC. This is not that much of a problem in the case of SMS SUBMIT from the MS to the netwrok. In that case, the MS will start its primary RLL connection with SAPI3, and we can just respond with SAPI3. However, in the case of SMS DELIVER to a MS, we first page the MS, it then establishes SAPI0. We then need to explicitly request the establishment of a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER RPDU Now that we have the bsc_rll.c code, we can actually wait for a paging response, and from the paging response request the establishment of the SAPI3 connection. We will be called back once that connection is open and can successively start transmission of the SM.
2009-08-09 12:59:02 +00:00
}
if (cause == GSM411_RP_CAUSE_MT_MEM_EXCEEDED) {
/* MS has not enough memory to store the message. We need
sms: Fix a small typo.
2010-12-23 21:23:15 +00:00
* to store this in our database and wait for a SMMA message */
implement proper SAPI3 handling for SMS SM's need to be transferred over their own RLL connection on SAPI3, rather than the default SAPI0 connection that we're using for signalling like 04.08 RR/MM/CC. This is not that much of a problem in the case of SMS SUBMIT from the MS to the netwrok. In that case, the MS will start its primary RLL connection with SAPI3, and we can just respond with SAPI3. However, in the case of SMS DELIVER to a MS, we first page the MS, it then establishes SAPI0. We then need to explicitly request the establishment of a SAPI3 RLL connection, before we can send CP-DATA with our RP-DATA and DELIVER RPDU Now that we have the bsc_rll.c code, we can actually wait for a paging response, and from the paging response request the establishment of the SAPI3 connection. We will be called back once that connection is open and can successively start transmission of the SM.
2009-08-09 12:59:02 +00:00
/* FIXME */
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_MEM_EXCEEDED, trans, sms, 0);
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_RP_ERR_MEM));
sms: Dispatch a failed signal in many of the MT-sms points This attempts to dispatch a signal whenever a MT-sms is failing. In some cases, e.g. with freeing the transaction, this will also happen for MO-sms.
2010-12-24 08:47:04 +00:00
} else {
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0);
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_RP_ERR_OTHER));
sms: Dispatch a failed signal in many of the MT-sms points This attempts to dispatch a signal whenever a MT-sms is failing. In some cases, e.g. with freeing the transaction, this will also happen for MO-sms.
2010-12-24 08:47:04 +00:00
}
first 'working' SMS implementation we now have the full path from the MS into the database (SUBMIT), as well as back from the database to the MS (DELIVER). The database gets correctly updated once a SMS has been successfully delivered. What's still missing is the periodic scan over all undelivered messages, trying to deliver them to the respective MS. So far, you have to manually trigger this on the telnet interface with 'sms send pending 1'
2009-08-08 14:03:15 +00:00
sms_free(sms);
trans->sms.sms = NULL;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
return 0;
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
}
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
static int gsm411_rx_rp_smma(struct msgb *msg, struct gsm_trans *trans,
struct gsm411_rp_hdr *rph)
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
{
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
int rc;
libmsc/gsm_04_11.c: forward MO SMS messages over GSUP Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-11-06 22:08:18 +00:00
if (trans->net->sms_over_gsup) {
/* RP-ACK or RP-ERROR is triggered as soon as we get the response */
rc = gsm411_gsup_mo_ready_for_sm_req(trans, rph->msg_ref);
if (rc) /* GSUP message sending error */
return gsm411_send_rp_error(trans, rph->msg_ref, rc);
return 0;
}
SMS improvements * send more pending messages after RP-ACK of DELIVER has been received * send pending messages after RP-SMMA has been received * clear the transaction when sending CP-ACK in MT/DELIVER case * always use the same transaction ID (since my assumptions about SMS transactions were wrong) * try to deliver messages through existing lchan rather than starting paging * send pending SM's after LOCATION UPDATE ACCEPT has been sent
2009-08-09 17:07:41 +00:00
rc = gsm411_send_rp_ack(trans, rph->msg_ref);
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
/* MS tells us that it has memory for more SMS, we need
* to check if we have any pending messages for it and then
* transfer those */
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_SMMA, trans, NULL, 0);
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
return rc;
more SMS improvements * describe data structures in gsm_04_11.h * increae LCHAN RELEASE TIMEOUT for case of long SMS * convert header field in sql table from NUMERIC to BLOB * initial handling for validity period * send RP ERROR messages with meaningful RP CAUSE in case of error
2009-07-05 12:02:46 +00:00
}
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
/* receive RL DATA */
static int gsm411_rx_rl_data(struct msgb *msg, struct gsm48_hdr *gh,
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
struct gsm_trans *trans)
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
{
ACK sms-submit
2008-12-29 01:54:02 +00:00
struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data;
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t msg_type = rp_data->msg_type & 0x07;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
int rc = 0;
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
switch (msg_type) {
case GSM411_MT_RP_DATA_MO:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "RX SMS RP-DATA (MO)\n");
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
rc = gsm411_rx_rp_data(msg, trans, rp_data);
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
break;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
case GSM411_MT_RP_SMMA_MO:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "RX SMS RP-SMMA\n");
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
rc = gsm411_rx_rp_smma(msg, trans, rp_data);
break;
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Invalid RP type 0x%02x\n", msg_type);
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
rc = -EINVAL;
break;
}
return rc;
}
/* receive RL REPORT */
static int gsm411_rx_rl_report(struct msgb *msg, struct gsm48_hdr *gh,
struct gsm_trans *trans)
{
struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data;
uint8_t msg_type = rp_data->msg_type & 0x07;
int rc = 0;
switch (msg_type) {
case GSM411_MT_RP_ACK_MO:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "RX SMS RP-ACK (MO)\n");
libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error} 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
2018-11-22 09:54:36 +00:00
rc = gsm411_rx_rp_ack(trans, rp_data);
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
break;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
case GSM411_MT_RP_ERROR_MO:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "RX SMS RP-ERROR (MO)\n");
libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error} 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
2018-11-22 09:54:36 +00:00
rc = gsm411_rx_rp_error(trans, rp_data);
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
break;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Invalid RP type 0x%02x\n", msg_type);
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
rc = -EINVAL;
Store incoming SMS into SQL database * gsm_util now uses caller-allocated data (rather than callee-allocated) * correctly parse destination address * parse (but not transcode) non-default encodings of SMS * reject SMS to unknown destination number * resolve target subscriber id and store incoming SMS (without header) in 'sms' table What we're now missing is the sending part, i.e. a regular task iterating over all pending SMS and trying to deliver them. Also, check for pending SMS once we get a LOCATION UPDATE.
2009-03-30 20:56:32 +00:00
break;
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
}
return rc;
}
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
/* receive SM-RL sap message from SMR
* NOTE: Message is freed by sender
*/
int gsm411_rl_recv(struct gsm411_smr_inst *inst, int msg_type,
struct msgb *msg)
{
struct gsm_trans *trans =
container_of(inst, struct gsm_trans, sms.smr_inst);
struct gsm48_hdr *gh = msgb_l3(msg);
int rc = 0;
switch (msg_type) {
case GSM411_SM_RL_DATA_IND:
rc = gsm411_rx_rl_data(msg, gh, trans);
break;
case GSM411_SM_RL_REPORT_IND:
if (gh)
rc = gsm411_rx_rl_report(msg, gh, trans);
break;
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Unhandled SM-RL message 0x%x\n", msg_type);
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
rc = -EINVAL;
}
return rc;
}
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
/* receive MNCCSMS sap message from SMC
* NOTE: Message is freed by sender
*/
static int gsm411_mn_recv(struct gsm411_smc_inst *inst, int msg_type,
struct msgb *msg)
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
{
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
struct gsm_trans *trans =
container_of(inst, struct gsm_trans, sms.smc_inst);
struct gsm48_hdr *gh = msgb_l3(msg);
int rc = 0;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
switch (msg_type) {
case GSM411_MNSMS_EST_IND:
case GSM411_MNSMS_DATA_IND:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "MNSMS-DATA/EST-IND\n");
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
rc = gsm411_smr_recv(&trans->sms.smr_inst, msg_type, msg);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
break;
case GSM411_MNSMS_ERROR_IND:
if (gh)
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "MNSMS-ERROR-IND, cause %d (%s)\n",
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
gh->data[0],
get_value_string(gsm411_cp_cause_strs,
gh->data[0]));
else
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "MNSMS-ERROR-IND, no cause\n");
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
rc = gsm411_smr_recv(&trans->sms.smr_inst, msg_type, msg);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
break;
default:
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_NOTICE, "Unhandled MNCCSMS msg 0x%x\n", msg_type);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
rc = -EINVAL;
SMS improvements * send more pending messages after RP-ACK of DELIVER has been received * send pending messages after RP-SMMA has been received * clear the transaction when sending CP-ACK in MT/DELIVER case * always use the same transaction ID (since my assumptions about SMS transactions were wrong) * try to deliver messages through existing lchan rather than starting paging * send pending SM's after LOCATION UPDATE ACCEPT has been sent
2009-08-09 17:07:41 +00:00
}
misc: Fix warnings about returning with value... return rc in these cases.
2009-08-10 05:59:27 +00:00
return rc;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
static struct gsm_trans *gsm411_trans_init(struct gsm_network *net, struct vlr_subscr *vsub, struct msc_a *msc_a,
uint8_t tid, bool mo)
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
{
/* Allocate a new transaction */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
struct gsm_trans *trans = trans_alloc(net, vsub, TRANS_SMS, tid, new_callref++);
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
if (!trans) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "No memory for transaction\n");
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
return NULL;
}
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (msc_a) {
msc_a_get(msc_a, MSC_A_USE_SMS);
trans->msc_a = msc_a;
osmo_fsm_inst_dispatch(msc_a->c.fi, MSC_A_EV_TRANSACTION_ACCEPTED, trans);
if (mo) {
if (!osmo_use_count_by(&msc_a->use_count, MSC_A_USE_CM_SERVICE_SMS))
LOG_TRANS(trans, LOGL_ERROR, "MO SMS without prior CM Service Request\n");
else
msc_a_put(msc_a, MSC_A_USE_CM_SERVICE_SMS);
}
}
/* Init both SMC and SMR state machines */
gsm411_smc_init(&trans->sms.smc_inst, 0, 1,
gsm411_mn_recv, gsm411_mm_send);
gsm411_smr_init(&trans->sms.smr_inst, 0, 1,
gsm411_rl_recv, gsm411_mn_send);
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
return trans;
}
libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr() 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
2019-01-18 09:01:50 +00:00
/* Assigns an (unused) SM-RP-MR value to a given transaction */
static int gsm411_assign_sm_rp_mr(struct gsm_trans *trans)
{
uint8_t mr;
/* After allocation a given transaction has zero-initialized
* SM-RP-MR value, so trans_find_by_sm_rp_mr() may consider
* 0x00 as used. This is why we "poison" this transaction
* using the highest value. */
trans->sms.sm_rp_mr = 0xff;
/* According to 8.2.3, MR is in the range 0 through 255 */
for (mr = 0x00; mr < 0xff; mr++) {
if (trans_find_by_sm_rp_mr(trans->net, trans->vsub, mr))
continue; /* this MR is busy, find another one */
/* An unused value has been found, assign it */
trans->sms.sm_rp_mr = mr;
return 0;
}
/* All possible values are busy */
return -EBUSY;
}
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
static struct gsm_trans *gsm411_alloc_mt_trans(struct gsm_network *net,
struct vlr_subscr *vsub)
{
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
struct msc_a *msc_a;
libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans() 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
2019-06-19 13:10:38 +00:00
struct gsm_trans *trans;
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
int tid;
/* Generate a new transaction ID */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
tid = trans_assign_trans_id(net, vsub, TRANS_SMS);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
if (tid == -1) {
libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans() 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
2019-06-19 13:10:38 +00:00
LOGP(DLSMS, LOGL_ERROR, "No available transaction IDs\n");
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
return NULL;
}
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
/* Attempt to find an existing connection */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
msc_a = msc_a_for_vsub(vsub, true);
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
/* Allocate a new transaction */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
trans = gsm411_trans_init(net, vsub, msc_a, tid, false);
SMS: remove code duplication in transaction init 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
2019-01-16 11:05:30 +00:00
if (!trans)
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
return NULL;
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_INFO, "Going to send a MT SMS\n");
libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr() 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
2019-01-18 09:01:50 +00:00
/* Assign a unique SM-RP Message Reference */
if (gsm411_assign_sm_rp_mr(trans) != 0) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Failed to assign SM-RP-MR\n");
libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr() 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
2019-01-18 09:01:50 +00:00
trans_free(trans);
return NULL;
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
}
libmsc/gsm_04_11.c: fix: always use SAPI 3 for MT SMS 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
2018-11-30 12:10:37 +00:00
/* Use SAPI 3 (see GSM 04.11, section 2.3) */
trans->dlci = UM_SAPI_SMS;
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
return trans;
}
/* High-level function to send an SMS to a given subscriber */
int gsm411_send_sms(struct gsm_network *net,
struct vlr_subscr *vsub,
struct gsm_sms *sms)
{
uint8_t *data, *rp_ud_len;
struct gsm_trans *trans;
struct msgb *msg;
int rc;
/* Allocate a new transaction for MT SMS */
trans = gsm411_alloc_mt_trans(net, vsub);
if (!trans) {
send_signal(S_SMS_UNKNOWN_ERROR, NULL, sms, 0);
sms_free(sms);
return -ENOMEM;
}
/* Allocate a message buffer for to be encoded SMS */
msg = gsm411_msgb_alloc();
if (!msg) {
send_signal(S_SMS_UNKNOWN_ERROR, NULL, sms, 0);
trans_free(trans);
sms_free(sms);
return -ENOMEM;
}
/* Hardcode SMSC Originating Address for now */
data = (uint8_t *)msgb_put(msg, 8);
data[0] = 0x07; /* originator length == 7 */
data[1] = 0x91; /* type of number: international, ISDN */
data[2] = 0x44; /* 447785016005 */
data[3] = 0x77;
data[4] = 0x58;
data[5] = 0x10;
data[6] = 0x06;
data[7] = 0x50;
/* Hardcoded Destination Address */
data = (uint8_t *)msgb_put(msg, 1);
data[0] = 0; /* destination length == 0 */
/* obtain a pointer for the rp_ud_len, so we can fill it later */
rp_ud_len = (uint8_t *)msgb_put(msg, 1);
if (sms->is_report) {
/* generate the 03.40 SMS-STATUS-REPORT TPDU */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
rc = gsm340_gen_sms_status_report_tpdu(trans, msg, sms);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
} else {
/* generate the 03.40 SMS-DELIVER TPDU */
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
rc = gsm340_gen_sms_deliver_tpdu(trans, msg, sms);
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
}
if (rc < 0) {
send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0);
sms_free(sms);
trans_free(trans);
msgb_free(msg);
return rc;
}
*rp_ud_len = rc;
/* Store a pointer to abstract SMS representation */
trans->sms.sms = sms;
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_DELIVERED));
libmsc/gsm_04_11.c: refactor MT SMS message handling 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
2018-11-22 08:42:39 +00:00
db_sms_inc_deliver_attempts(trans->sms.sms);
return gsm411_rp_sendmsg(&trans->sms.smr_inst, msg,
GSM411_MT_RP_DATA_MT, trans->sms.sm_rp_mr,
GSM411_SM_RL_DATA_REQ);
}
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
/* Low-level function to send raw RP-DATA to a given subscriber */
int gsm411_send_rp_data(struct gsm_network *net, struct vlr_subscr *vsub,
size_t sm_rp_oa_len, const uint8_t *sm_rp_oa,
libmsc/gsm_04_11.c: properly handle MMTS indication 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
2019-05-11 22:38:41 +00:00
size_t sm_rp_ud_len, const uint8_t *sm_rp_ud,
bool sm_rp_mmts_ind)
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
{
struct gsm_trans *trans;
struct msgb *msg;
/* Allocate a new transaction for MT SMS */
trans = gsm411_alloc_mt_trans(net, vsub);
if (!trans)
return -ENOMEM;
libmsc/gsm_04_11.c: properly handle MMTS indication 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
2019-05-11 22:38:41 +00:00
/* Multi-part SMS: handle MMTS (More Messages to Send) indication */
trans->sms.sm_rp_mmts_ind = sm_rp_mmts_ind;
if (trans->msc_a != NULL)
gsm411_handle_mmts_ind(trans);
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
/* Allocate a message buffer for to be encoded SMS */
msg = gsm411_msgb_alloc();
if (!msg) {
trans_free(trans);
return -ENOMEM;
}
/* Encode SM-RP-OA (SMSC address) */
msgb_lv_put(msg, sm_rp_oa_len, sm_rp_oa);
/* Encode SM-RP-DA (shall be empty, len=0) */
msgb_v_put(msg, 0x00);
/* Encode RP-UD itself (SM TPDU) */
msgb_lv_put(msg, sm_rp_ud_len, sm_rp_ud);
Use new osmo stat items/ctr APIs Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-06-04 14:45:44 +00:00
rate_ctr_inc(rate_ctr_group_get_ctr(net->msc_ctrs, MSC_CTR_SMS_DELIVERED));
libmsc/gsm_04_11.c: accept MT SMS messages over GSUP Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-11-14 18:05:53 +00:00
return gsm411_rp_sendmsg(&trans->sms.smr_inst, msg,
GSM411_MT_RP_DATA_MT, trans->sms.sm_rp_mr,
GSM411_SM_RL_DATA_REQ);
}
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
/* Entry point for incoming GSM48_PDISC_SMS from abis_rsl.c */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
int gsm0411_rcv_sms(struct msc_a *msc_a, struct msgb *msg)
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
{
struct gsm48_hdr *gh = msgb_l3(msg);
misc: Move from u_int to uint types of stdint.h This was done with sed on the files.
2011-04-18 15:04:00 +00:00
uint8_t msg_type = gh->msg_type;
04.08: apply new transaction id inline functions libosmocore recently added inline functions to relieve callers from applying bitmasks and bit shifts to access the transaction id of a GSM 04.08 header. Apply these functions.
2016-03-14 15:13:25 +00:00
uint8_t transaction_id = gsm48_hdr_trans_id_flip_ti(gh);
libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactions 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
2019-01-23 16:34:31 +00:00
struct gsm411_rp_hdr *rph = (struct gsm411_rp_hdr *) gh->data;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
struct gsm_trans *trans;
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
int new_trans = 0;
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
int rc = 0;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
struct vlr_subscr *vsub = msc_a_vsub(msc_a);
struct gsm_network *net = msc_a_net(msc_a);
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
trans = trans_find_by_id(msc_a, TRANS_SMS, transaction_id);
sms: Avoid infinite CP-ERROR/CP-ACK loop with sms. The issue can be reproduced by typing the following 9 or more times. OpenBSC> subscriber id 2 sms sender id 2 send bla For some unknown reason the phone sends us a CP-ERROR for a transaction identifier we have allocated and used but don't remember. Due the way we use the SMC/SMR we 'establish' the machine and this results in a CP-ACK being sent out. But the CP-ERROR is not having the content we want for an establish so we send out a RP-ERROR. This will result in a CP-ERROR because the phone does not know the transaction... Avoid the issue by checking the direction of the transaction. If we do not know the transaction and it is supposed to be allocated by us then just ignore it and do not create a new transaction.
2013-01-13 15:23:36 +00:00
/*
* A transaction we created but don't know about?
*/
if (!trans && (transaction_id & 0x8) == 0) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "trans_id=%x allocated by us but known "
sms: Avoid infinite CP-ERROR/CP-ACK loop with sms. The issue can be reproduced by typing the following 9 or more times. OpenBSC> subscriber id 2 sms sender id 2 send bla For some unknown reason the phone sends us a CP-ERROR for a transaction identifier we have allocated and used but don't remember. Due the way we use the SMC/SMR we 'establish' the machine and this results in a CP-ACK being sent out. But the CP-ERROR is not having the content we want for an establish so we send out a RP-ERROR. This will result in a CP-ERROR because the phone does not know the transaction... Avoid the issue by checking the direction of the transaction. If we do not know the transaction and it is supposed to be allocated by us then just ignore it and do not create a new transaction.
2013-01-13 15:23:36 +00:00
"to us anymore. We are ignoring it, maybe a CP-ERROR "
"from a MS?\n",
transaction_id);
return -EINVAL;
}
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
if (!trans) {
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
new_trans = 1;
trans = gsm411_trans_init(net, vsub, msc_a, transaction_id, true);
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
if (!trans) {
/* FIXME: send some error message */
return -ENOMEM;
}
libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactions 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
2019-01-23 16:34:31 +00:00
trans->sms.sm_rp_mr = rph->msg_ref; /* SM-RP Message Reference */
DTAP: Ensure proper DLCI is used in MSC-originated DTAP 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
2018-04-09 14:35:01 +00:00
trans->dlci = OMSC_LINKID_CB(msg); /* DLCI as received from BSC */
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_DEBUG, "receiving SMS message %s\n",
gsm48_pdisc_msgtype_name(gsm48_hdr_pdisc(gh), gsm48_hdr_msg_type(gh)));
libmsc/gsm_04_11.c: clarify implicit CP-ACK handling Change-Id: I3c5327a5019590c65d0ccb33a52f07b3988ea952
2019-04-14 11:34:18 +00:00
/* According to section 5.3.4, due to structure of message flow on
* SAPI 0 and 3 it is possible that the CP-ACK of a short message
* transfer might not be received. In this case the reception of
* CP-DATA may be interpreted as the reception of the awaited
* CP-ACK (implicit) and CP-DATA message. */
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
if (trans->sms.smc_inst.cp_state == GSM411_CPS_IDLE
libmsc/gsm_04_11.c: clarify implicit CP-ACK handling Change-Id: I3c5327a5019590c65d0ccb33a52f07b3988ea952
2019-04-14 11:34:18 +00:00
&& msg_type == GSM411_MT_CP_DATA) {
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
int i;
struct gsm_trans *ptrans;
/* Scan through all remote initiated transactions */
for (i=8; i<15; i++) {
if (i == transaction_id)
continue;
gsm_04_11: Support for implicit CP-ACK in case of multi-SMS See GSM 04.11 Chapter 5.4 for details. The idea is that when multi-SMS are mobile originated, it's possible the CP-ACK of the previous transaction to be lost and the reception of a new CP-DATA for a new transaction should close previous transaction "as-if" we had received the CP-ACK ... Note that testing is hard since it's an exceptional condition that's hard to create. I tested by temporarly disabling CP-ACK processing and checked it worked as expected. Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2009-12-24 15:47:08 +00:00
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
ptrans = trans_find_by_id(msc_a, TRANS_SMS, i);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
if (!ptrans)
continue;
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(ptrans, LOGL_DEBUG, "Implicit CP-ACK for trans_id=%x\n", i);
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
/* Finish it for good */
trans_free(ptrans);
further steps towards better, transaction based SMS
2009-07-27 18:11:35 +00:00
}
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
}
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
gsm411_smc_recv(&trans->sms.smc_inst,
(new_trans) ? GSM411_MMSMS_EST_IND : GSM411_MMSMS_DATA_IND,
msg, msg_type);
Start implementing GSM 04.11 (short message service)
2008-12-28 00:31:09 +00:00
return rc;
}
fix sms layer timer leak/corruiption using trans_free() we only stopped the cp1* timer on reception of cp-ack, but not in error cases like rx of cp-error.
2009-08-14 12:52:17 +00:00
void _gsm411_sms_trans_free(struct gsm_trans *trans)
{
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
/* cleanup SMS instance */
sms: Replaced the SMR process by new implementation in libosmocore Rebased, tested and fixed by Holger Freyther. Release the transaction only once the SMC is asking for the release and set the cb's to NULL to catch a use after free early.
2011-10-28 09:11:13 +00:00
gsm411_smr_clear(&trans->sms.smr_inst);
trans->sms.smr_inst.rl_recv = NULL;
trans->sms.smr_inst.mn_send = NULL;
sms: Replaced the SMC process by new implementation in libosmocore This has been rebased and fixed by Holger Freyther. The change of the debug area was split out in a previous commit and the is_mt was put back into the transaction code. The transaction is now freed from the RELEASE_REQ sent by the SMC layer and not inside the error path. When clearing the SMC instance we also clear the callbacks.
2011-10-28 02:07:07 +00:00
gsm411_smc_clear(&trans->sms.smc_inst);
trans->sms.smc_inst.mn_recv = NULL;
trans->sms.smc_inst.mm_send = NULL;
gsm_04_11: Speculative leak fix for the SMS...
2010-06-15 04:29:37 +00:00
if (trans->sms.sms) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "Freeing transaction that still contains an SMS -- discarding\n");
sms: Create signal data for SMS with more information This is providing access to the paging result, the sms, the transaction. This will allow the SMS queue to do decisions based on the source of the failure.
2010-12-24 09:15:55 +00:00
send_signal(S_SMS_UNKNOWN_ERROR, trans, trans->sms.sms, 0);
gsm_04_11: Speculative leak fix for the SMS...
2010-06-15 04:29:37 +00:00
sms_free(trans->sms.sms);
trans->sms.sms = NULL;
}
fix sms layer timer leak/corruiption using trans_free() we only stopped the cp1* timer on reception of cp-ack, but not in error cases like rx of cp-error.
2009-08-14 12:52:17 +00:00
}
Use libvlr in libmsc (large refactoring) 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
2016-06-19 16:06:02 +00:00
/* Process incoming SAPI N-REJECT from BSC */
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
void gsm411_sapi_n_reject(struct msc_a *msc_a)
bsc_api: Do not use RLL inside the SMS code, handle SAPI n REJECT Directly send a SMS using the send method, in case of an error we will need to find the transaction and free the SMS and the transaction.
2010-06-15 04:03:10 +00:00
{
sms: Fix crash by saving the gsm_network The conn might be released during the loop and then conn->bts is a null pointer and we end up crashing. Store the gsm_network in a local variable and access this one.
2010-12-27 22:25:53 +00:00
struct gsm_network *net;
bsc_api: Do not use RLL inside the SMS code, handle SAPI n REJECT Directly send a SMS using the send method, in case of an error we will need to find the transaction and free the SMS and the transaction.
2010-06-15 04:03:10 +00:00
struct gsm_trans *trans, *tmp;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
net = msc_a_net(msc_a);
sms: Fix crash by saving the gsm_network The conn might be released during the loop and then conn->bts is a null pointer and we end up crashing. Store the gsm_network in a local variable and access this one.
2010-12-27 22:25:53 +00:00
sms: Fix crash on RLL Establish Request timeouts with active call Sylvain pointed out that in the current crash log the transaction we try to read the SMS from is actually a transaction for Call Control. On AMD64 the struct layout is different and that leads to a crash when the CC transaction is in front of the SMS transaction. Look at the trans->protocol to fix the crash. The issue got introduced in 6a3d765bf97349535602ed5b2b55d2093aa18d71 (2010) when I added the SAPI N Reject handling. #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 284 if (sms->source != SMS_SOURCE_SMPP) (gdb) bt #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 #1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4, signal_data=0x7fff33574ea0) at signal.c:105 #2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>, sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 #4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>) at bsc_api.c:733 #5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:755 #6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:736 #7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>) at bsc_rll.c:55 #8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243 #9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133 #10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346 (gdb) frame 3 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0); (gdb) p trans $1 = (struct gsm_trans *) 0xedba80 (gdb) p *trans .... data = 0x1}}, sms = 0x3439323400000003}}} (gdb) p trans->protocol $4 = 3 '\003'
2013-12-27 21:47:09 +00:00
llist_for_each_entry_safe(trans, tmp, &net->trans_list, entry) {
struct gsm_sms *sms;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (trans->msc_a != msc_a)
sms: Fix crash on RLL Establish Request timeouts with active call Sylvain pointed out that in the current crash log the transaction we try to read the SMS from is actually a transaction for Call Control. On AMD64 the struct layout is different and that leads to a crash when the CC transaction is in front of the SMS transaction. Look at the trans->protocol to fix the crash. The issue got introduced in 6a3d765bf97349535602ed5b2b55d2093aa18d71 (2010) when I added the SAPI N Reject handling. #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 284 if (sms->source != SMS_SOURCE_SMPP) (gdb) bt #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 #1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4, signal_data=0x7fff33574ea0) at signal.c:105 #2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>, sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 #4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>) at bsc_api.c:733 #5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:755 #6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:736 #7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>) at bsc_rll.c:55 #8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243 #9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133 #10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346 (gdb) frame 3 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0); (gdb) p trans $1 = (struct gsm_trans *) 0xedba80 (gdb) p *trans .... data = 0x1}}, sms = 0x3439323400000003}}} (gdb) p trans->protocol $4 = 3 '\003'
2013-12-27 21:47:09 +00:00
continue;
large refactoring: support inter-BSC and inter-MSC Handover 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
2018-12-07 13:47:34 +00:00
if (trans->type != TRANS_SMS)
sms: Fix crash on RLL Establish Request timeouts with active call Sylvain pointed out that in the current crash log the transaction we try to read the SMS from is actually a transaction for Call Control. On AMD64 the struct layout is different and that leads to a crash when the CC transaction is in front of the SMS transaction. Look at the trans->protocol to fix the crash. The issue got introduced in 6a3d765bf97349535602ed5b2b55d2093aa18d71 (2010) when I added the SAPI N Reject handling. #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 284 if (sms->source != SMS_SOURCE_SMPP) (gdb) bt #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 #1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4, signal_data=0x7fff33574ea0) at signal.c:105 #2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>, sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 #4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>) at bsc_api.c:733 #5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:755 #6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:736 #7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>) at bsc_rll.c:55 #8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243 #9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133 #10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346 (gdb) frame 3 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0); (gdb) p trans $1 = (struct gsm_trans *) 0xedba80 (gdb) p *trans .... data = 0x1}}, sms = 0x3439323400000003}}} (gdb) p trans->protocol $4 = 3 '\003'
2013-12-27 21:47:09 +00:00
continue;
sms = trans->sms.sms;
if (!sms) {
add LOG_TRANS, proper context for all transactions Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-02-28 04:50:06 +00:00
LOG_TRANS(trans, LOGL_ERROR, "SAPI Reject but no SMS.\n");
sms: Fix crash on RLL Establish Request timeouts with active call Sylvain pointed out that in the current crash log the transaction we try to read the SMS from is actually a transaction for Call Control. On AMD64 the struct layout is different and that leads to a crash when the CC transaction is in front of the SMS transaction. Look at the trans->protocol to fix the crash. The issue got introduced in 6a3d765bf97349535602ed5b2b55d2093aa18d71 (2010) when I added the SAPI N Reject handling. #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 284 if (sms->source != SMS_SOURCE_SMPP) (gdb) bt #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 #1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4, signal_data=0x7fff33574ea0) at signal.c:105 #2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>, sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 #4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>) at bsc_api.c:733 #5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:755 #6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:736 #7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>) at bsc_rll.c:55 #8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243 #9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133 #10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346 (gdb) frame 3 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0); (gdb) p trans $1 = (struct gsm_trans *) 0xedba80 (gdb) p *trans .... data = 0x1}}, sms = 0x3439323400000003}}} (gdb) p trans->protocol $4 = 3 '\003'
2013-12-27 21:47:09 +00:00
continue;
bsc_api: Do not use RLL inside the SMS code, handle SAPI n REJECT Directly send a SMS using the send method, in case of an error we will need to find the transaction and free the SMS and the transaction.
2010-06-15 04:03:10 +00:00
}
sms: Fix crash on RLL Establish Request timeouts with active call Sylvain pointed out that in the current crash log the transaction we try to read the SMS from is actually a transaction for Call Control. On AMD64 the struct layout is different and that leads to a crash when the CC transaction is in front of the SMS transaction. Look at the trans->protocol to fix the crash. The issue got introduced in 6a3d765bf97349535602ed5b2b55d2093aa18d71 (2010) when I added the SAPI N Reject handling. #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 284 if (sms->source != SMS_SOURCE_SMPP) (gdb) bt #0 smpp_sms_cb (subsys=1, signal=4, handler_data=0xbb8270, signal_data=0x7fff33574ea0) at smpp_openbsc.c:284 #1 0x00007f424e4a094c in osmo_signal_dispatch (subsys=1, signal=4, signal_data=0x7fff33574ea0) at signal.c:105 #2 0x000000000042b070 in send_signal (sig_no=<optimized out>, trans=<optimized out>, sms=<optimized out>, paging_result=<optimized out>) at gsm_04_11.c:125 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 #4 0x0000000000408983 in send_sapi_reject (link_id=<optimized out>, conn=<optimized out>) at bsc_api.c:733 #5 rll_ind_cb (_data=<optimized out>, lchan=<optimized out>, link_id=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:755 #6 rll_ind_cb (lchan=<optimized out>, link_id=<optimized out>, _data=<optimized out>, rllr_ind=<optimized out>) at bsc_api.c:736 #7 0x000000000041f8d2 in complete_rllr (rllr=<optimized out>, type=<optimized out>) at bsc_rll.c:55 #8 0x00007f424e4a03bc in osmo_timers_update () at timer.c:243 #9 0x00007f424e4a069b in osmo_select_main (polling=0) at select.c:133 #10 0x0000000000407394 in main (argc=<optimized out>, argv=0x7fff33575238) at bsc_hack.c:346 (gdb) frame 3 #3 0x000000000042ccd2 in gsm411_sapi_n_reject (conn=0xec6790) at gsm_04_11.c:1000 1000 send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0); (gdb) p trans $1 = (struct gsm_trans *) 0xedba80 (gdb) p *trans .... data = 0x1}}, sms = 0x3439323400000003}}} (gdb) p trans->protocol $4 = 3 '\003'
2013-12-27 21:47:09 +00:00
send_signal(S_SMS_UNKNOWN_ERROR, trans, sms, 0);
sms_free(sms);
trans->sms.sms = NULL;
trans_free(trans);
}
bsc_api: Do not use RLL inside the SMS code, handle SAPI n REJECT Directly send a SMS using the send method, in case of an error we will need to find the transaction and free the SMS and the transaction.
2010-06-15 04:03:10 +00:00
}