aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2018-12-13require 'ipa-name' option to be set via config fileStefan Sperling1-0/+2
The 'ipa-name' option can now only be set via the configuration file because changing the IPA name at run-time conflicts with active GSUP connections and routes configured in the HLR. The osmo-msc program must be restarted if its IPA name needs to change. Change-Id: I6cff91793e646e0396e8f1bc87d0f52709e5f12a Related: OS#3355
2018-12-11Revert "move ASS-COMPL MGCP handling out of a_iface_bssap.c"Neels Hofmeyr2-9/+1
Two reasons: - the caller of msc_mgcp_ass_complete() from Iu, iucs_rx_rab_assign(), failed to be adjusted, breaking IuCS, as an --enable-iu --enable-werror build shows. Unfortunately our gerrit verification doesn't --enable-werror for osmo-msc. - the condition of requiring ST_MDCX_RAN is faulty, breaking GSM CS. This reverts commit 212c0c9bdaf1166e3bcbab85f3ab31dc17162f5b. Change-Id: I8348675c2f7c8856ea1682d05ee54160d4cfeb96
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling2-1/+8
Add a 'ipa-name' VTY command which overrides the default IPA name used by the MSC. This is a prerequisite for inter-MSC handover. Related: OS#3355 Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
2018-12-10move ASS-COMPL MGCP handling out of a_iface_bssap.cNeels Hofmeyr2-1/+9
BSSMAP Assignment Complete: sort MGCP handling upon Assignment Complete to the proper locations. a_iface_bssap.c is not the right place to invoke the MGCP related procedures. - in a_iface_bssap.c only decode the IEs. - call ran_conn_assign_compl() and pass decoded values. - drop msc_assign_compl(), it was dead code; instead: - add ran_conn_assign_compl() - pass on all MGCP related info to msc_mgcp_ass_complete() - move all MGCP ctx related handling from a_iface_bssap.c to msc_mgcp.c. I'm dropping some comments to save some time, because if I adjust them IMHO they would still anyway restate the obvious. ran_conn_assign_compl() is now quite a thin shim, but it makes sense to have it: - This is the place that should tear down the ran_conn in case assignment failed, left for a future patch. - In the light of upcoming inter-MSC handover, ran_conn_assign_compl() will be the place where the Assignment Complete message might be relayed to a remote MSC. Change-Id: I8137215c443239bddf3e69b5715839a365b73b6c
2018-12-05add VTY commands: mncc internal / external (== -M)Neels Hofmeyr2-0/+2
So far the only way to use external MNCC is to pass the -M cmdline arg: osmo-msc -M /path/to/socket However, the osmo-msc.service file for systemd is installed by 'make install', and hence it is quite impractical to depend on such a config item to be required in the service file: - It defies any scheme an operator may have in place to compose the osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs separate action to add to the installed service file. - After a make install or package upgrades / re-installations, this option will be plain overwritten silently, or lead to the need for resolving file conflicts. The initial spark for this came from configuring the 35c3 GSM from cfg templates. Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
2018-11-30move gsm_cbfn to gsm_subscriber.h, the only userNeels Hofmeyr2-6/+4
(with two less line feeds) Change-Id: I375e5b021e643f6b1986ea35ebaf3a6d60e189f5
2018-11-30drop cruft from gsm_subscriber.hNeels Hofmeyr1-23/+0
Change-Id: If6e2252486fe8d932f229a70ce5a4b6f22f6fc52
2018-11-30GSM_EXTENSION_LENGTH -> VLR_MSISDN_LENGTHNeels Hofmeyr2-7/+6
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH -> VLR_NAME_LENGTH. Adjust some sms_queue stuff that anyway includes vlr.h already. Drop gsm_subscriber.h from vlr.h. Add other (more concise) includes that thus become necessary, since the include chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place. Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr2-10/+11
Along goes GSM_KEYSEQ_INVAL as VLR_*. It's where it logically belongs, and is almost the only reason why vlr.h includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved by upcoming patch. Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
2018-11-30cosmetic: drop some unused opaque struct defsNeels Hofmeyr2-4/+0
Change-Id: I4d461dd39d0abdc4f2327445671459340ca1c946
2018-11-30combine several small .h in msc_common.hNeels Hofmeyr6-25/+13
For hysterical raisins, there are some header files that contain few declarations, and where the name doesn't reflect the content. Combine them to new msc_common.h: - common.h - common_cs.h - osmo_msc.h Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
2018-11-30move ran_conn declarations to new ran_conn.hNeels Hofmeyr9-243/+250
With the dawn of inter-BSC,MSC handover, adopting the MSC-A,-I,-T roles from 3GPP TS 49.008, the RAN connection shall soon be a neatly separated corner of osmo-msc, so gravitate ran_conn decarations to files of matching name. Also, the current chaos of API defined in files with mismatching/meaningless names drives me crazy. Change-Id: Ice31e6c43e46678538c65261f150c67e1d0845e5
2018-11-30rename some RAN conn related stuff to ran_conn_*Neels Hofmeyr1-26/+24
Following previous rename of gsm_subscriber_connection: Some functions and #defines are still called like "msc_conn" or just "msc_", while they are clearly about a RAN conn. To avoid confusion with the future separate concepts of MSC roles and a RAN connection, rename all those to match the common "ran_conn" prefix. Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
2018-11-30rename gsm_subscriber_connection to ran_connNeels Hofmeyr16-123/+116
In preparation for inter-BSC and inter-MSC handover, we need to separate the subscriber management logic from the actual RAN connections. What better time to finally rename gsm_subscriber_connection. * Name choice: In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it "bss_conn": in 3G a BSS is called RNS, IIUC. The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network. * Rationale: A subscriber in the MSC so far has only one RAN connection, but e.g. for inter-BSC handover, a second one needs to be created to handover to. Most of the items in the former gsm_subscriber_connection are actually related to the RAN, with only a few MM and RTP related items. So, as a first step, just rename it to ran_conn, to cosmetically prepare for moving the not strictly RAN related items away later. Also: - Rename some functions from msc_subscr_conn_* to ran_conn_* - Rename "Subscr_Conn" FSM instance name to "RAN_conn" - Rename SUBSCR_CONN_* to RAN_CONN_* Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-30drop msc_compl_l3() return valueNeels Hofmeyr1-7/+2
msc_compl_l3() always returns MSC_CONN_ACCEPT, because the conn FSM handles (or should handle) all reject cases. The accept/reject return value is a legacy from libbsc internally passing a conn over to libmsc, in osmo-nitb. Drop enum msc_compl_l3_rc. Change msc_compl_l3_rc() to return void. Change all callers to always act like for acceptance, as they always did anyway. Drop some local variables now no longer needed. Adjust the comment to msc_compl_l3(). Drop a bunch of #if-0'd code from msc_compl_l3(). Change-Id: I759d15f4e820d5fc16397ed7210ce92308e52a09
2018-11-30rename gsm_encr to geran_encr, it is only applicable on GERANNeels Hofmeyr2-2/+2
On UTRAN, Security Mode is used instead of Ciphering Command, which does not feature an A5 algorithm id. Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
2018-11-30drop unused gsm0408_allow_everyone() declarationNeels Hofmeyr1-1/+0
Change-Id: Id56ea492594edc38d1f9d31d94a1679c0cb61fa0
2018-11-30drop unused SUBSCR_CONN_E_INVALIDNeels Hofmeyr1-2/+0
The idea to catch uninitialized vars was completely moot. We pass events by constants anyway. Change-Id: I6f3c964ee04fec9a96f385199fb3141ac8d672d4
2018-11-30drop unused openbscdefines.hNeels Hofmeyr2-35/+0
Change-Id: If35cd49baa4d0a3b38f31736e1696f481babba9c
2018-11-30drop unused gsm_network->handover.activeNeels Hofmeyr1-3/+0
gsm_network contains an int handover.active which is always zero. Drop it. There is real handover code coming up soon, one part of this is to avoid confusion. The internal MNCC code queried it to decide whether to MNCC_BRIDGE or proxy RTP (MNCC_FRAME_RECV). Since RTP is being handled by osmo-mgw since forever, drop that entire condition from mncc_builtin. Change-Id: Ie16e718266882588b38297121364ca0b7fdfe948
2018-11-30drop unused gsm_subscr_conn->mncc_rtp_bridgeNeels Hofmeyr1-3/+0
Change-Id: I322dc18cfe2cc573744261df837e719b5cf224ba
2018-11-29libmsc/gsm_04_11.c: refactor MT SMS message handlingVadim Yanitskiy1-3/+3
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-29libmsc/transaction: introduce trans_find_by_sm_rp_mr()Ivan Kluchnikov1-0/+5
According to GSM TS 04.11, section 8.2.3, the RP Message Reference is a mandatory field for all messages on the SM-RL (SM Relay Layer), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. This change extends the transaction state structure with SM-RP-MR, and introduces a new function for matching transactions within a given connection by this reference. Change-Id: Ice47c37ecef4416e65ecee8931d946c915316791
2018-11-23osmo_msc: remove unused parameter from msc_dtap()Philipp Maier1-2/+1
The parameter link_id in the function msc_dtap() is unused. Lets remove it. Change-Id: I7ba67b0cb514c91bc87a7b396ed3962b7a68e7da
2018-11-21msc/gsm_04_11.h: use forward-declaration for _gsm411_sms_trans_free()Vadim Yanitskiy1-1/+0
Change-Id: I87f96abd2b2d446751d8f95c9164c5eb6a58e66c
2018-11-21msc/gsm_04_11.h: drop unused sms_next_rp_msg_ref()Vadim Yanitskiy1-2/+0
Change-Id: I53b27629177b3342c4f5b34c80d52cbb6dc8476b
2018-11-02Add counters for BSSMAP cipher mode messagesMax1-0/+4
Count COMPLETE and REJECT messages. Besides general troubleshooting that's also useful for TTCN-3 tests to check that OsmoMSC processed those messages as expected. Change-Id: I5822b2b38b64f1a691b26c926a8e2bece21dc624 Related: OS#3187
2018-10-24gsm_04_08_cc: Add global guard timer for MNCCPhilipp Maier2-0/+4
The external MNCC handler may hang indefinitely in cases where the remote end of the MNCC ceases to work properly. Add a global guard timer to make sure the call reaches ACTIVE state. Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d Related: OS#3599
2018-09-18fix Classmark Update without VLR subscriberNeels Hofmeyr1-0/+4
This recent patch moves Classmark storage to the VLR subscriber, and introduced a segfault when a Classmark Update is received during IMSI detach: commit 986fe7ed18580775bed91399a1f02eae60bda251 change-id I27081bf6e9e017923b2d02607f7ea06beddad82a Mon Sep 17 01:12:13 2018 +0200 "store classmark in vlr_subscr, not conn" It assumed that we would never accept any Classmark Update messages unless we also have a valid subscriber for it. Well, that is proven wrong by the ttcn3-msc-test TC_imsi_detach_by_imsi(), which brings osmo-msc to its knees. Fix: in case of no valid vlr_subscr being present, store Classmark in the conn temporarily, and copy any received Classmark to VLR subscriber as soon as it gets associated with the conn (if at all). Change-Id: Ib2a2ae6bf86e8f29fc6751a8b5cdb7187cd70290
2018-09-17A5/n Ciph: request Classmark Update if missingNeels Hofmeyr3-0/+15
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we need a ciph algo flag from a Classmark information that is not yet known (usually CM 2 during LU), send a BSSMAP Classmark Request to get it. To manage the intermission of the Classmark Request, add - msc_classmark_request_then_cipher_mode_cmd(), - state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE, - event SUBSCR_CONN_E_CLASSMARK_UPDATE. From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and re-initiate Ciphering Mode. To be able to re-enter the Ciphering Mode algo decision, factor it out into msc_geran_set_cipher_mode(). Rationale: In the following commit, essentially we stopped supporting A5/3 ciphering: commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670 "MSC: Intersect configured A5 algorithms with MS-supported ones" Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3 A5/3 was no longer supported because from that commit on, we strictly checked the MS-supported ciphers, but we did not have Classmark 2 available during Location Updating. This patch changes that: when Classmark 2 is missing, actively request it by a BSSMAP Classmark Request; continue Ciphering only after the Response. Always request missing Classmark, even if a lesser cipher were configured available. If the Classmark Update response fails to come in, cause an attach failure. Instead, we could attempt to use a lesser cipher that is also enabled. That is left as a future feature, should that become relevant. I think it's unlikely. Technically, we could now end up requesting a Classmark Updating both during LU (vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the only time we lack a Classmark is: during Location Updating with A5/3 enabled. A5/1 support is indicated in CM1 which is always available, and A5/3 support is indicated in CM2, which is always available during CM Service Request as well as Paging Response. So this patch has practical relevance only for Location Updating. For networks that permit only A5/3, this patch fixes Location Updating. For networks that support A5/3 and A5/1, so far we always used A5/1 during LU, and after this patch we request CM2 and likely use A5/3 instead. In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works during LU. Also verify that the lack of a Classmark Response results in attach failure. In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is missing during proc_arq_fsm and proves that that code path works, even though the practical relevance is currently zero. It would only become interesting if ciphering algorithms A5/4 and higher became relevant, because support of those would be indicated in Classmark 3, which would always require a Classmark Request. Related: OS#3043 Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore) Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-17store classmark in vlr_subscr, not connNeels Hofmeyr2-2/+2
Store all Classmark information in the VLR. So, we now always know the Classmark 1 (mandatory IE for LU). This is visible in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported" because classmark 1 is missing, because we now know the Classmark 1. Rationale: During Location Updating, we receive Classmark 1; during CM Service Request and Paging Response, we receive Classmark 2. So far we stored these only for the duration of the conn, so as soon as a LU is complete, we would forget CM1. In other words, for anything else than a LU Request, we had no Classmark 1 available at all. During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1 is supported. That is moot if we don't even have a Classmark 1 for any CM Service Request or Paging Response initiated connections. The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1 is missing. To add to the confusion, if a phone indicated that it did *not* support A5/1 in the Classmark 1, according to spec we're supposed to not service it at all. A code comment however says that we instead want to heed the flag -- which so far was only present in a Location Updating initiated connection. Now we can make this decision without assuming things. This got my attention while hacking on sending a BSSMAP Classmark Request from the MSC if it finds missing Classmark information, and was surprised to see it it lacking CM1 to decide about A5/1. Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-08-20use __FILE__, not __BASE_FILE__Neels Hofmeyr2-9/+9
The intention was to use the file's basename, but __BASE_FILE__ means "the root file that is being parsed and contains #include statements". If we had a function using __BASE_FILE__ and that was defined in an #included file, __BASE_FILE__ would indicate the first file where the #include is, and not the file where the function is defined. __BASE_FILE__ works for us because we don't ever include function definitions that log something, so __BASE_FILE__ always coincides with __FILE__ for our logging; but still __BASE_FILE__ is semantically the wrong constant. Related: OS#2740 Change-Id: I1c8122c909938daaf782468c1c5b0262d555c3ce
2018-08-07mgcp: use codec information returned with ASSIGNMENT COMPL.Philipp Maier1-0/+3
When the assignment completes a choosen codec is returned. At the moment we do not use this information. - add struct members for codec info (both, RAN and CN) - parse codec info in BSSMAP ASSIGNMENT COMPLETE - use codec info on mgcp Since the MNCC API is not complete yet, we currently only use the codec info only on the internal MNCC yet. Change-Id: I9d5b1cd016d9a058b22a367d0e5e9f2ef447931a Related: OS#2728
2018-08-05RRLP: migrate and share mode definitions from msc_vty.cVadim Yanitskiy1-0/+5
Change-Id: I9560e6eab0ad1b5d57ca732741fc0b6f61f1a4a2
2018-08-05RRLP: properly name the init functionVadim Yanitskiy1-1/+1
We don't actually deal with DSO loading here... Change-Id: I24d0c9ad52f07f08176ad129878b48a591a3af6c
2018-08-05Remove local libgsupclient; Use libosmo-gsup-client from osmo-hlrHarald Welte3-69/+2
osmo-hlr has recently (as of Change-Id Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library implementation of libosmo-gsup-client. We can remove the local implementation in osmo-msc and use the system-installed shared library instead. Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
2018-08-05libmsc/gsm_09_11.c: clean up the local GSM 04.80 APIVadim Yanitskiy1-10/+2
Since we don't process SS/USSD requests in OsmoMSC anymore, there are some useless GSM 04.80 functions remained from the past. In particular, this change does the following: - removes both gsm0480_send_{ussd_response|return_error} functions because they are not used anymore; - changes symbol prefix from 'gsm0480_' to 'msc_', in order to avoid possible conflicts with the libosmogsm's GSM 04.80 API; - cleans up useless includes; Change-Id: I2990d8627bce0ce6afb1dcf6b11bb194292380d3
2018-08-04msc/rrlp.h: use #pragma once include guardVadim Yanitskiy1-5/+1
Change-Id: Ie68b2092a0a9ceae3519ab9059ac2c1e3d8d7450
2018-08-04msc/signal.h: use #pragma once include guardVadim Yanitskiy1-4/+1
Change-Id: I114026808abeff72a3f4f3cb1b84680c116409d4
2018-07-31migrate to oap_client in libosmogsmHarald Welte3-86/+3
libosmogsm in libosmocore.git from Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950 onwards contains oap_client.c, so we don't need our local copy here in this repo anymore. Change-Id: Ib6496c35d0ce6eb531e97129dc45a9f68e503b34 Requires: libosmocore.git Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950
2018-07-30libmsc/gsm_09_11.c: introduce counter for active sessionsVadim Yanitskiy1-0/+1
Change-Id: Ia17e7c747fffb5267d3ca5bc4193c1be4a57ef3a
2018-07-30libmsc/gsm_09_11.c: introduce rate counters for NC_SS sessionsVadim Yanitskiy1-0/+8
This change introduces some new rate counters for call-independent SS/USSD connections. As OsmoMSC doesn't handle the messages itself, and only responsible for dispatching messages between both A and GSUP interfaces, the following is taken into account: - MS-initiated and network-initiated requests to establish a NC SS/USSD session (transaction) - "nc_ss:m{o|t}_requests"; - successfully established MS-initiated and network-initiated SS/USSD sessions (transactions) - "nc_ss:m{o|t}_established". Change-Id: I23c9475abc9951d82f3342fdc5aaa367836f7741
2018-07-30libmsc/gsm_09_11.c: implement network-initiated sessionsVadim Yanitskiy1-0/+7
This change introduces a possibility to establish network-initiated SS/USSD transactions with a subscriber in either IDLE, or DEDICATED state. In the first case, a new transaction is established using Paging procedure. If a subscriber already has an active connection, a separate new transaction is established. TTCN-3 test case: I073893c6e11be27e9e36f98f11c1491d0c173985 Change-Id: Ief14f8914ef013bd6efd7be842f81fbf053f02e2
2018-07-30libmsc/gsm_09_11.c: forward SS/USSD messages to HLR over GSUPVadim Yanitskiy1-0/+2
In order to be able to support external SS/USSD gateway, we should not terminate the GSM 04.80 messages at OsmoMSC. Instead, we need to follow the GSM TS 09.11 specification, and forward all messages unhandled by OsmoMSC to OsmoHLR over GSUP protocol. This change implements forwarding of MO SS/USSD messages. The forwarding assumes transcoding between GSM 04.80 messages and GSUP messages. The payload of Facility IE is carried 'as is'. As a side-effect, this will disable the osmo-msc internal handler implementing the "*#100#" for obtaining the subscribers own phone number. In order to re-gain this functionality, you will need a modern osmo-hlr (Change-Id I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9) and the following line in your osmo-hlr.cfg: hlr ussd route prefix *#100# internal own-msisdn TTCN-3 test case: I01de73aced6057328a121577a5a83bc2615fb2d4 Change-Id: Ide5f7e350b537db80cd8326fc59c8bf2e01cb68c
2018-07-29libvlr/vlr.c: forward unhandled GSUP messages towards MSCVadim Yanitskiy1-0/+4
Some internal sub-systems, such as SS/USSD or SMS implementation, may also need to use GSUP connection with HLR. Previously, it was only available within the libvlr code, and nowhere else. Let's introduce the generic GSUP message router, which will receive messages unhandled by VLR itself, and route them to a handler depending on the message type. Change-Id: Ib8146ce5788c8f249dcaa39d61bd0388574bf892
2018-07-25libmsc: move L3 call-control to separate C file (gsm_04_08_cc.c)Harald Welte1-0/+1
The CC sub-layer is fairly self-contained, so let's move it to a separate C source file. The old gsm_04_08.c file now only contains the 04.07 / DTAP core and MM sub-layer handling. I did this initially as an experiment to see how self-contained our CC implementation really is. Given this rather straight-forward patch builds fine, CC really is self-contained (yay!). Change-Id: Idb8dd7a8d9d8b4a28c492f12da3cc3305b695cca
2018-06-12libmsc/gsm_04_80.c: make the API abstract from ss_request structVadim Yanitskiy1-5/+5
There is no need to pass a pointer to a ss_request struct when calling the gsm0480_send_ussd_* functions, because they only use both transaction ID and InvokeID from there, which may be passed directly. This change allows one to use this API without parsing the whole GSM 04.80 message, or when parsing is failed. Moreover, if InvokeID is not available, one can pass any incorrect, (e.g. negative) value, so the universal NULL tag will be used. Finally, setting a TI flag is also up to the caller. Change-Id: I13d5abbfdcf8238ebaf0566c420f09cd9255b648
2018-06-12libmsc/gsm_04_08.c: expose gsm48_tx_simple()Vadim Yanitskiy1-0/+2
This function could be also used by other parts of code, e.g. by gsm_04_11.c or by gsm_09_11.c, during initialization of a new transaction. No need to hide it. Change-Id: I9a9d17fca4901163dae10d76455aa4cf54497156
2018-06-12Use proper naming for GSM TS 09.11 implementationVadim Yanitskiy3-6/+6
During a long time, we had both file and symbol names, actually related to Supplementary Services, with the 'ussd' abbreviation. This is not absolutely wrong, but isn't correct at the same time. USSD is a kind of Supplementary Services, this is only a part of them. There are also 'structured' Supplementary Services, which can be call related or call independent. The "Signalling interworking for supplementary services" is defined by GSM TS 09.11, and this is exactly what MSC should implement. Let's use the specification number for naming, as we do e.g. in the GSM 04.11 (SMS) implementation. Change-Id: Ic1eaceddb58132318e4e941be542da34b8ebefe1
2018-06-10libmsc: properly name the MSC_CONN_USE token for SSVadim Yanitskiy1-1/+1
Previously the MSC_CONN_USE token for Supplementary Services was called 'MSC_CONN_USE_TRANS_USSD'. Non-call related Supplementary Services is not only about USSD, so let's rename it. Change-Id: I5b3517c87a32fa64dea6b0c912f2b76c5c25a112
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 01:36:03 +0000