summaryrefslogtreecommitdiffstats
path: root/include/osmocom/gsm/gsup.h
Commit message (Collapse)AuthorAgeFilesLines
* gsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IEHarald Welte2019-12-091-0/+1
| | | | | | | | | | | | | | This is a bit of a hack, as we want to maintain binary compatibility without breaking existing users of libosmocore. To do so, we use the 'num_auth_vectors' field in two ways now: * In the existing use case as part of SEND_AUTH_INFO_RESPONSE, it indicates the number of vectors stored in the 'auth_vectors' field * In the new use case as part of SEND_AUTH_INFO_REQUEST, it indicates the number of vectors actually requested by the MSC/SGSN/MME. Change-Id: Iaecc47280f8ce54f3e3a888c1cfc160735483d0f
* add all missing OSMO_GSUP_TO_MSGT_*() macrosNeels Hofmeyr2019-11-281-0/+3
| | | | | | | | OSMO_GSUP_TO_MSGT_RESULT() is needed by osmo-hlr for osmo_gsup_req. The others are added for completeness' sake. Related: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9 Change-Id: I6e38a3bb8447f8f212f8d6f5b10a5d0df59323d7
* GSUP: rename E_ROUTING_ERROR to ROUTING_ERRORNeels Hofmeyr2019-11-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | GSUP routing was introduced when adding the E interface. Hence that was the first realm where routing errors could occur. I did notice back then that this message type was special: it does not convey a response to a particular message kind -- it does not make sense, for example, to return an Updating Location Error cause, and do that for all conceivable message types. Instead, this tells the sender that a deeper error exists, i.e. that the desired peer is completely gone and unreachable. I did not foresee though that for D-GSM, there would also be arbitrary GSUP proxy routing, and that this error is not limited to E interface semantics. From today's point of view, adding the "_E_" in the name was a mistake. Remove that "_E_" to yield OSMO_GSUP_MSGT_ROUTING_ERROR (with unchanged message type discriminator), but provide a #define linking the old name OSMO_GSUP_MSGT_E_ROUTING_ERROR to the new one. The only visible change should be that osmo_gsup_message_type_names[] now returns the new name without "_E_". I am not aware of any regression test fallout from that. Change-Id: Ic8e8bd11522d6c51ac7aaf946516cbce26bc6e1e
* gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IENeels Hofmeyr2019-09-281-0/+7
| | | | | | | | | | | | | | OSMO_GSUP_SUPPORTED_RAT_TYPES_IE corresponds to the Supported RAT Types Indicator from 3GPP TS 29.002. See 8.1.2 MAP_UPDATE_LOCATION service, which indicates the capabilities of the MSC/VLR to the HLR. So far, have room for eight RAT types in the gsup_msg. That is an arbitrary random choice without any rationale. OSMO_GSUP_CURRENT_RAT_TYPE_IE is useful to communicate the currently used RAN / RAT type of the current subscriber during Location Updating Request. Change-Id: I93850710ab55a605bf61b95063a69682a2899bb1
* Cosmetic: GSUP: fix too long comment lineOliver Smith2019-05-191-2/+2
| | | | Change-Id: I60ba8fef8924e58bc73cff5c7ff77ebb76d8bfaa
* GSUP: add inter-MSC handover related msgs and IEsOliver Smith2019-04-261-0/+66
| | | | | | | | | | | | | | | | | | | | Based on a draft created by Neels, which is the result of reading a MAP trace of two MSCs negotiating inter-MSC handovers, and of reading the TS 29.002, TS 29.010 and related specs: https://lists.osmocom.org/pipermail/openbsc/2019-January/012653.html I figured out that the "Handover Number" mentioned in the specifications is the same as the MSISDN IE that we already have, so we can use that instead of creating a new IE (example usage in tests/gsup/gsup_test.c). Create a new OSMO_GSUP_MSGT_E_ROUTING_ERROR message type, which the GSUP server uses to tell a client that its message could not be forwarded to the destination (see [1]). MAP has no related message. [1]: Change-Id: Ia4f345abc877baaf0a8f73b8988e6514d9589bf5 (osmo-hlr.git) Related: OS#3774 Change-Id: Ic00b0601eacff6d72927cea51767801142ee75db
* GSUP: add Message Class IENeels Hofmeyr2019-04-131-0/+21
| | | | | | | | | | | | | | | | | | osmo-msc and osmo-hlr have distinct subsystems handling incoming GSUP messages. So far we decide entirely by message type which code path should handle a GSUP message. Thus no GSUP message type may be re-used across subsystems. If we add a GSUP message to indicate a routing error, it would have to be a distinct message type for subscriber management, another one for SMS, another one for USSD... To allow introducing common message types, introduce a GSUP Message Class IE. In the presence of this IE, GSUP handlers can trivially direct a received message to the right code path. If it is missing, handlers can fall back to the previous switch(message_type) method. Change-Id: Ic397a9f2c4a7224e47cab944c72e75ca5592efef
* add OSMO_IMSI_BUF_SIZENeels Hofmeyr2019-04-131-1/+1
| | | | | | | | | | | | Various places in our code base figure out how many chars they need to safely store an IMSI. An IMSI can have a checksum digit, which is not reflected by GSM23003_IMSI_MAX_DIGITS. And we usually need a terminating \0. Instead of having a magic +2 repeated every so often, rather define OSMO_IMSI_BUF_SIZE to contain both checksum digit and nul char, and have the explanatory comment with it here in libosmocore. Change-Id: Id11ada4c96b79f7f0ad58185ab7dbf24622fb770
* GSUP: deprecate osmo_gsup_get_err_msg_type()Oliver Smith2019-02-041-2/+14
| | | | | | | | | | | | | | Replace osmo_gsup_get_err_msg_type() with a wrapper to OSMO_GSUP_TO_MSGT_ERROR(). This macro assumes, that all error messages are (request message | 0x000001). Add a big comment header for osmo_gsup_message_type, describing this already implicitly followed rule and therefore making it explicit. With this change, we don't need to maintain the request -> error message mapping in osmo_gsup_get_err_msg_type() anymore. Related: Iec1b4ce4b7d8eb157406f006e1c4241e8fba2cd6 (osmo-gsm-manuals) Change-Id: I46d9f2327791978710e2f90b4d28a3761d723d8f
* Cosmetic: GSUP: note "on wire" for imei_resultOliver Smith2019-01-091-2/+2
| | | | | | | | | | | | | | Note that OSMO_GSUP_IMEI_RESULT_ACK is 0 on the wire, although the enum value is 1. Same with NACK (1 on wire, enum 2). I had implemented enum osmo_gsup_imei_result after enum osmo_gsup_cancel_type above, where this comment exists as well, and I incorrectly assumed that enum osmo_gsup_cn_domain in the middle was also implemented this way and therefore adding the comments to each enum would be redundant. But for cn_domain, the values on the wire are the same as the enum values. Change-Id: If97c34f117bfaab2232bbb625e9d118c8f390e58
* GSUP: add CHECK-IMEI messageOliver Smith2018-12-211-0/+16
| | | | | | | | | | | | | | Implement necessary messages for Procedure Check_IMEI_VLR (TS 23.018 Chapter 7.1.2.9). This lets the VLR ask the EIR to check if an IMEI is valid. In the Osmocom stack, we don't have an EIR and this request will be handled by the HLR. We will be able to store the IMEI in the HLR as side-effect (OS#2541). This is roughly based on TS 29.002 8.7.1 MAP_CHECK_IMEI service, but only implements the bare minimum required IEs (imei and imei_result). Related: OS#3733 Change-Id: I085819df0ea7f3bfeb0cabebb5fd1942a23c6155
* GSUP: add end marker to enum osmo_gsup_ieiOliver Smith2018-12-211-0/+2
| | | | | | | | | | | | | Simplify gsup_test.c by defining an end marker in gsup.h. No need to manually update the last element every time anymore. The C standard guarantees, that the end marker will have the last value plus one: "Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by adding 1 to the value of the previous enumeration constant." (From C99: 6.7.2.2 Enumeration specifiers) Change-Id: I2aab7245e209f0ebd2f33a83d4d181dd3339cb17
* GSUP/SMS: introduce READY-FOR-SM messageVadim Yanitskiy2018-12-181-0/+7
| | | | | | | | | | | | | | | According to 3GPP TS 29.002, section 12.4, MAP-READY-FOR-SM is used between the MSC and VLR as well as between the VLR and the HLR to indicate that a subscriber has memory available for SMS. This change replicates this service in GSUP as READY_FOR_SM_*. The only mandatory IE for this service (excluding Invoke ID) is 'Alert Reason' that is replicated by OSMO_GSUP_SM_ALERT_RSN_IE. Change-Id: Ic37f3b2114b8095cfce22977e67133b9103942e3 Related Change-Id: (docs) I549b6c8840a1e86caac09e77fb8bc5042d939e62 Related Change-Id: (TTCN) If2256607527ecfcb10285583332fb8b0515d7c78 Related: OS#3587
* GSUP/SMS: introduce MO-/MT-FORWARD-SM messagesVadim Yanitskiy2018-12-181-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to 3GPP TS 29.002, there are two services: - MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2), - MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9), which are used to forward MO/MT short messages. This change replicates both services as GSUP messages: - OSMO_GSUP_MSGT_MO_FORWARD_SM_*, - OSMO_GSUP_MSGT_MT_FORWARD_SM_*. Please note, that only the 'must-have' IEs are introduced by this change, in particular the following: - OSMO_GSUP_SM_RP_MR_IE (see note below), - OSMO_GSUP_SM_RP_DA_IE (see 7.6.8.1), - OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2), - OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4), - OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7), - OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4), where both SM_RP_DA and SM_RP_OA IEs basically contain a single nested TV of the following format: - T: identity type (see 'osmo_gsup_sms_sm_rp_oda_t'), - V: encoded identity itself (optional). According to GSM TS 04.11, every single message on the SM-RL has an unique message reference (see 8.2.3), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. In case of TCAP/MAP, this message reference is being mapped to the Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not required for other applications (other than SMS), this change introduces a special 'SM_RP_MR' IE that doesn't exist in MAP. Change-Id: Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Related Change-Id: (docs) Ie0150756c33c1352bc4eb49421824542c711175c Related Change-Id: (TTCN) Ibf49474a81235096c032ea21f217170f523bd94e Related: OS#3587
* gsm/gsup.h: cosmetic: use tab for comment alignmentVadim Yanitskiy2018-11-061-1/+1
| | | | Change-Id: Id71d4b45e2b9f42da5e23e709ad97d4d0abfc3d9
* gsup: Add value_string for Session State IEHarald Welte2018-06-161-0/+5
| | | | | | | | In Change-Id I1cee271fed0284a134ffed103c0d4bebbcfde2a8 we added support for a new session state IE, but we didn't add any value_string array for string conversion of it. Let's fix this. Change-Id: I3d9f087786dc37c42498fa9a2be07483ec93ba7b
* gsup: Add osmo_gsup_get_err_msg_type() functionHarald Welte2018-06-111-0/+1
| | | | | | | | This function can be used to resolve the error message type for a given message type. Can be used by generic error handlers that work for any incoming message type. Change-Id: Ic637bec53dd7fe3ec83da99b49b4eae34d5602b2
* GSUP: introduce new messages for SS/USSD payloadsVadim Yanitskiy2018-05-311-0/+11
| | | | | | | | | | | | | | | | | In order to be able to transfer SS/USSD messages via GSUP, this change introduces the following new message types: - OSMO_GSUP_MSGT_PROC_SS_*, and the following new IE: - OSMO_GSUP_SS_INFO_IE which represents an ASN.1 encoded MAP payload coming to/from the mobile station 'as is', without any transcoding. Change-Id: Ie17a78043a35fffbdd59e80fd2b2da39cce5e532 Related: OS#1597
* GSUP: implement TCAP-like session managementVadim Yanitskiy2018-05-311-0/+21
| | | | | | | | | | | | | | | | | | | | Unlike TCAP/MAP, GSUP is just a transport layer without the dialogue/context. This prevents us from having session based communication, required e.g. for USSD. But we can emulate TCAP dialogue by adding additional IEs, which would allow to relate each message to a particular session. This change introduces the following IEs: - OSMO_GSUP_SESSION_ID_IE, - OSMO_GSUP_SESSION_STATE_IE, which optionally can be used to indicate that the message is related to a session with given ID, and to manage session state, i.e. initiate, continue, and finish. Change-Id: I1cee271fed0284a134ffed103c0d4bebbcfde2a8 Related: OS#1597
* define a constant for the max length of called party BCD IEStefan Sperling2018-05-071-0/+1
| | | | | | | | | | | | According to TS 24.008 10.5.4.7 the called party BSC number IE has a maximum length of 43 octets. This length is assumed inside osmo-hlr with a magic number: uint8_t msisdn_enc[43]; /* TODO use constant; TS 24.008 10.5.4.7 */ This change makes libosmocore provide a constant which osmo-hlr can use. Change-Id: Ia0bf6ceadcac38a8c75d166402b54058e5c6c6d4
* GSUP: change osmo_gsup_encode() return typeMax2018-02-051-1/+1
| | | | | | | | | | * match return type of osmo_gsup_encode() with osmo_gsup_decode() to allow propagating error to caller * check return value of osmo_gsup_encode() in GSUP test * return errors instead of braking app with aseert Change-Id: Idaa1deecb6d9e15329bd51867b4f6a03357461f0 Related: OS#2864
* Fix/Update copyright notices; Add SPDX annotationHarald Welte2017-11-131-1/+3
| | | | | | | | Let's fix some erroneous/accidential references to wrong license, update copyright information where applicable and introduce a SPDX-License-Identifier to all files. Change-Id: I39af26c6aaaf5c926966391f6565fc5936be21af
* [doc] Define 'gsup' group with proper name, add intro textHarald Welte2017-10-171-2/+19
| | | | Change-Id: Ieee6213dc5aad082a2d439c7418b51f281b80b1a
* GSUP: define default GSUP port as 4222Neels Hofmeyr2017-07-221-0/+2
| | | | | | | | | | | See also: https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers https://gerrit.osmocom.org/#/c/3195/2/include/openbsc/osmo_msc.h@13 (change-id I639544a6cdda77a3aafc4e3446a55393f60e4050) Change-Id: I4222e21686c823985be8ff1f16b1182be8ad6175
* gsup: Add encoding/decoding for the pdp charging characteristicsHolger Hans Peter Freyther2017-07-071-0/+8
| | | | | | | | These fields can be in the ISD and the PDP Context inofmration. Store pointers to this IE in both cases. It needs to be used by the SGSN when opening a PDP context. Change-Id: Iedc7c02adcf77ca5c9545119e19c968dfbbb3e6b
* doxygen: unify use of \file across the boardNeels Hofmeyr2017-06-231-3/+4
| | | | | | | | | | | | | | | | | Considering the various styles and implications found in the sources, edit scores of files to follow the same API doc guidelines around the doxygen grouping and the \file tag. Many files now show a short description in the generated API doc that was so far only available as C comment. The guidelines and reasoning behind it is documented at https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation In some instances, remove file comments and add to the corresponding group instead, to be shared among several files (e.g. bitvec). Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
* gsup: add osmo_gsup_message_type_name()Neels Hofmeyr2017-02-151-0/+5
| | | | Change-Id: Ic29b588b72893821d73fe90ecc16c6bf78d5a360
* cosmetic: gsup comments: write 'Generic' for the G in GSUPNeels Hofmeyr2016-12-091-1/+1
| | | | | | | | The G used to mean GPRS, but the scope is larger now. To satisfy the curious reader, give the G a name in gsup files' header comments. BTW, logging.h and gsup_test.c already mentioned "Generic" before this. Change-Id: I6ac5cf94c215e156ceff6a58da3d9e520ca942d9
* license: gsup: libosmogsm requires GPL, not AGPL; say 'sysmocom'Neels Hofmeyr2016-12-091-1/+1
| | | | | | | | | The copyright in gsup.h differed from the one in gsup.c: gsup.c names the GNU Affero GPL, gsup.h only the GNU GPL. Change both to GPL-v2-or-later. In gsup.c/h's copyright notice, 'sysmocom' should be spelled lower case. Change-Id: Ia5748c275501889b9086aef7d20ccb5c9edb8031
* gsup: Add OSMO_GSUP_MSGT_AUTH_FAIL_REPORTHarald Welte2016-06-161-0/+2
| | | | | | | | | The VLR must be able to notify the HLR of authentication failures. Change-Id: I156cff76e092b3548b05534141b61887ee6be3f3 Reviewed-on: https://gerrit.osmocom.org/303 Reviewed-by: Harald Welte <laforge@gnumonks.org> Tested-by: Jenkins Builder
* GSUP: Add support for RAND in SendAuthInfo.reqHarald Welte2016-05-061-0/+1
| | | | | | In the autentication re-sync case, we need not only the AUTS from the MS/UE, but also the RAND that we sent as part of the failed authentication challenge.
* GSUP: Add OSMO_GSUP_CN_DOMAIN_IE to differentiate CS and PS planeHarald Welte2016-05-061-0/+7
| | | | | We're starting to use GSUP for circuit-switched (CS) plane, so we need to differentiate the two planes somehow from each other.
* import gprs_gsup_message.[ch] from openbsc as gsup.[ch]Harald Welte2016-05-061-0/+139
Move those routines from OpenBSC to libosmogsm, so they can be re-used from other programs. I think it was a mistake to add them only inside the openbsc repository in the first place. We need to pay more attention to this in the future.