osmo-msc/src/libmsc/gsm_09_11.c

160 lines
5.1 KiB
C
Raw Normal View History

/* (C) 2008-2009 by Harald Welte <laforge@gnumonks.org>
* (C) 2008, 2009 by Holger Hans Peter Freyther <zecke@selfish.org>
* (C) 2009 by Mike Haben <michael.haben@btinternet.com>
*
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
* 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
* (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
* GNU Affero General Public License for more details.
*
* 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/>.
*
*/
/**
* MSC-specific handling of call independent Supplementary
* Services messages (NC_SS) according to GSM TS 09.11
* "Signalling interworking for supplementary services".
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <osmocom/msc/gsm_04_80.h>
#include <osmocom/msc/gsm_subscriber.h>
#include <osmocom/msc/debug.h>
#include <osmocom/msc/osmo_msc.h>
#include <osmocom/msc/vlr.h>
#include <osmocom/msc/gsm_04_08.h>
#include <osmocom/msc/transaction.h>
/* FIXME: choose a proper range */
static uint32_t new_callref = 0x20000001;
/* Declarations of USSD strings to be recognised */
const char USSD_TEXT_OWN_NUMBER[] = "*#100#";
/* A network-specific handler function */
static int send_own_number(struct gsm_subscriber_connection *conn,
const struct ss_request *req)
{
char *own_number = conn->vsub->msisdn;
char response_string[GSM_EXTENSION_LENGTH + 20];
DEBUGP(DMM, "%s: MSISDN = %s\n", vlr_subscr_name(conn->vsub),
own_number);
/* Need trailing CR as EOT character */
snprintf(response_string, sizeof(response_string), "Your extension is %s\r", own_number);
return gsm0480_send_ussd_response(conn, response_string, req);
}
/* Entry point for call independent MO SS messages */
int gsm0911_rcv_nc_ss(struct gsm_subscriber_connection *conn, struct msgb *msg)
{
struct gsm48_hdr *gh = msgb_l3(msg);
struct gsm_trans *trans;
struct ss_request req;
uint8_t pdisc, tid;
uint8_t msg_type;
int rc;
pdisc = gsm48_hdr_pdisc(gh);
msg_type = gsm48_hdr_msg_type(gh);
tid = gsm48_hdr_trans_id_flip_ti(gh);
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
/* Associate logging messages with this subscriber */
log_set_context(LOG_CTX_VLR_SUBSCR, conn->vsub);
DEBUGP(DMM, "Received SS/USSD data (trans_id=%x, msg_type=%s)\n",
tid, gsm48_pdisc_msgtype_name(pdisc, msg_type));
/* Reuse existing transaction, or create a new one */
trans = trans_find_by_id(conn, pdisc, tid);
if (!trans) {
/**
* According to GSM TS 04.80, section 2.4.2 "Register
* (mobile station to network direction)", the REGISTER
* message is sent by the mobile station to the network
* to assign a new transaction identifier for call independent
* supplementary service control and to request or acknowledge
* a supplementary service.
*/
if (msg_type != GSM0480_MTYPE_REGISTER) {
LOGP(DMM, LOGL_ERROR, "Unexpected message (msg_type=%s), "
"transaction is not allocated yet\n",
gsm48_pdisc_msgtype_name(pdisc, msg_type));
gsm0480_send_ussd_reject(conn, &req,
GSM_0480_PROBLEM_CODE_TAG_GENERAL,
GSM_0480_GEN_PROB_CODE_UNRECOGNISED);
return -EINVAL;
}
DEBUGP(DMM, " -> (new transaction)\n");
trans = trans_alloc(conn->network, conn->vsub,
pdisc, tid, new_callref++);
if (!trans) {
DEBUGP(DMM, " -> No memory for trans\n");
gsm0480_send_ussd_return_error(conn, &req,
GSM0480_ERR_CODE_SYSTEM_FAILURE);
return -ENOMEM;
}
trans->conn = msc_subscr_conn_get(conn, MSC_CONN_USE_TRANS_NC_SS);
trans->dlci = OMSC_LINKID_CB(msg);
cm_service_request_concludes(conn, msg);
}
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
memset(&req, 0, sizeof(req));
rc = gsm0480_decode_ss_request(gh, msgb_l3len(msg), &req);
if (!rc) {
LOGP(DMM, LOGL_ERROR, "SS/USSD message parsing error, "
"rejecting request...\n");
libmsc/ussd.c: FIX: properly indicate errors There are error and problem codes defined by GSM TS 04.80: - Error codes are used when a message is structured correctly, but something is wrong in context of the current operation. Usually they are carried by 'Return Error' component. - Problem codes are used when something is wrong with the message structure, or with carried values. They are carried by 'Reject' component. There are three groups of them (see table 3.13): - General Problem Codes (table 3.14), - Invoke Problem Codes (table 3.15), - Return Result Problem Codes (table 3.16), - Return Error Problem Codes (table 3.17). The first group is general purpose, and can be sent in response to any kind of message, excluding 'Reject' itself. Other ones are bound to specific component types, such as 'Invoke', 'Return Result' and 'Return Error'. For some reason, a 'Reject' component with the general problem code 'GSM_0480_GEN_PROB_CODE_UNRECOGNISED' was always used in OsmoMSC. Even when the message structure is correct. Let's properly indicate errors in the following way: - 'Reject' with GSM_0480_GEN_PROB_CODE_UNRECOGNISED when the gsm0480_decode_ss_request() fails to decode a message. It can only return 0 or 1, so it's hard to guess which exact part of message caused the error. - 'Return Error' with GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION when the operation code is not related to USSD. - 'Return Error' with GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE when the requested USSD code is unhandled (not supported). There is a TTCN-3 testcase for this: https://gerrit.osmocom.org/9470/ Change-Id: I800e7ec98dc9d0bca2d45a8b8255d60253d63e14
2018-06-08 10:13:44 +00:00
gsm0480_send_ussd_reject(conn, &req, GSM_0480_PROBLEM_CODE_TAG_GENERAL,
GSM_0480_GEN_PROB_CODE_UNRECOGNISED);
/* The GSM 04.80 API uses inverted codes (0 means error) */
return -EPROTO;
}
/* Interrogation or releaseComplete? */
if (req.ussd_text[0] == '\0' || req.ussd_text[0] == 0xFF) {
if (req.ss_code > 0) {
/* Assume interrogateSS or modification of it and reject */
libmsc/ussd.c: FIX: properly indicate errors There are error and problem codes defined by GSM TS 04.80: - Error codes are used when a message is structured correctly, but something is wrong in context of the current operation. Usually they are carried by 'Return Error' component. - Problem codes are used when something is wrong with the message structure, or with carried values. They are carried by 'Reject' component. There are three groups of them (see table 3.13): - General Problem Codes (table 3.14), - Invoke Problem Codes (table 3.15), - Return Result Problem Codes (table 3.16), - Return Error Problem Codes (table 3.17). The first group is general purpose, and can be sent in response to any kind of message, excluding 'Reject' itself. Other ones are bound to specific component types, such as 'Invoke', 'Return Result' and 'Return Error'. For some reason, a 'Reject' component with the general problem code 'GSM_0480_GEN_PROB_CODE_UNRECOGNISED' was always used in OsmoMSC. Even when the message structure is correct. Let's properly indicate errors in the following way: - 'Reject' with GSM_0480_GEN_PROB_CODE_UNRECOGNISED when the gsm0480_decode_ss_request() fails to decode a message. It can only return 0 or 1, so it's hard to guess which exact part of message caused the error. - 'Return Error' with GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION when the operation code is not related to USSD. - 'Return Error' with GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE when the requested USSD code is unhandled (not supported). There is a TTCN-3 testcase for this: https://gerrit.osmocom.org/9470/ Change-Id: I800e7ec98dc9d0bca2d45a8b8255d60253d63e14
2018-06-08 10:13:44 +00:00
return gsm0480_send_ussd_return_error(conn, &req,
GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION);
}
/* Still assuming a Release-Complete and returning */
return 0;
}
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
msc_subscr_conn_communicating(conn);
if (!strcmp(USSD_TEXT_OWN_NUMBER, (const char *)req.ussd_text)) {
DEBUGP(DMM, "USSD: Own number requested\n");
rc = send_own_number(conn, &req);
} else {
DEBUGP(DMM, "Unhandled USSD %s\n", req.ussd_text);
libmsc/ussd.c: FIX: properly indicate errors There are error and problem codes defined by GSM TS 04.80: - Error codes are used when a message is structured correctly, but something is wrong in context of the current operation. Usually they are carried by 'Return Error' component. - Problem codes are used when something is wrong with the message structure, or with carried values. They are carried by 'Reject' component. There are three groups of them (see table 3.13): - General Problem Codes (table 3.14), - Invoke Problem Codes (table 3.15), - Return Result Problem Codes (table 3.16), - Return Error Problem Codes (table 3.17). The first group is general purpose, and can be sent in response to any kind of message, excluding 'Reject' itself. Other ones are bound to specific component types, such as 'Invoke', 'Return Result' and 'Return Error'. For some reason, a 'Reject' component with the general problem code 'GSM_0480_GEN_PROB_CODE_UNRECOGNISED' was always used in OsmoMSC. Even when the message structure is correct. Let's properly indicate errors in the following way: - 'Reject' with GSM_0480_GEN_PROB_CODE_UNRECOGNISED when the gsm0480_decode_ss_request() fails to decode a message. It can only return 0 or 1, so it's hard to guess which exact part of message caused the error. - 'Return Error' with GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION when the operation code is not related to USSD. - 'Return Error' with GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE when the requested USSD code is unhandled (not supported). There is a TTCN-3 testcase for this: https://gerrit.osmocom.org/9470/ Change-Id: I800e7ec98dc9d0bca2d45a8b8255d60253d63e14
2018-06-08 10:13:44 +00:00
rc = gsm0480_send_ussd_return_error(conn, &req,
GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE);
}
/**
* TODO: as we only handle *#100# for now, and always
* respond with RELEASE COMPLETE, let's manually free
* the transaction here, until the external interface
* is implemented.
*/
trans_free(trans);
return rc;
}