osmocom
/
libosmocore
mirror of https://gerrit.osmocom.org/libosmocore
11
0
Fork 1
Code Issues Releases Wiki Activity
libosmocore/tests/gsup/gsup_test.err

202 lines
16 KiB
Plaintext
Raw Normal View History

GSUP: add Message Class IE 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
2019-04-01 20:24:33 +00:00
generated message: 08 01 08 21 43 65 87 09 21 43 f5 0a 01 01
original message: 08 01 08 21 43 65 87 09 21 43 f5 0a 01 01
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
IMSI: 123456789012345
generated message: 09 01 08 21 43 65 87 09 21 43 f5 02 01 07
original message: 09 01 08 21 43 65 87 09 21 43 f5 02 01 07
IMSI: 123456789012345
generated message: 0a 01 08 21 43 65 87 09 21 43 f5 03 22 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 21 04 21 22 23 24 22 08 31 32 33 34 35 36 37 38 03 22 20 10 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 21 04 a1 a2 a3 a4 22 08 b1 b2 b3 b4 b5 b6 b7 b8
original message: 0a 01 08 21 43 65 87 09 21 43 f5 03 22 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 21 04 21 22 23 24 22 08 31 32 33 34 35 36 37 38 03 22 20 10 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 21 04 a1 a2 a3 a4 22 08 b1 b2 b3 b4 b5 b6 b7 b8
IMSI: 123456789012345
generated message: 04 01 08 21 43 65 87 09 21 43 f5
original message: 04 01 08 21 43 65 87 09 21 43 f5
IMSI: 123456789012345
generated message: 05 01 08 21 43 65 87 09 21 43 f5 02 01 07
original message: 05 01 08 21 43 65 87 09 21 43 f5 02 01 07
IMSI: 123456789012345
gsup: Add encoding/decoding for the pdp charging characteristics 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
2017-07-07 14:53:30 +00:00
generated message: 06 01 08 21 43 65 87 09 21 43 f5 08 07 91 94 61 46 32 24 43 09 07 91 83 52 38 48 83 93 04 00 05 19 10 01 01 11 02 f1 21 12 09 04 74 65 73 74 03 61 70 6e 13 01 02 14 02 ff 23 05 11 10 01 02 11 02 f1 21 12 08 03 66 6f 6f 03 61 70 6e 14 02 ae ff
original message: 06 01 08 21 43 65 87 09 21 43 f5 08 07 91 94 61 46 32 24 43 09 07 91 83 52 38 48 83 93 04 00 05 19 10 01 01 11 02 f1 21 12 09 04 74 65 73 74 03 61 70 6e 13 01 02 14 02 ff 23 05 11 10 01 02 11 02 f1 21 12 08 03 66 6f 6f 03 61 70 6e 14 02 ae ff
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
IMSI: 123456789012345
generated message: 1c 01 08 21 43 65 87 09 21 43 f5 06 01 00
original message: 1c 01 08 21 43 65 87 09 21 43 f5 06 01 00
IMSI: 123456789012345
generated message: 1d 01 08 21 43 65 87 09 21 43 f5 02 01 03
original message: 1d 01 08 21 43 65 87 09 21 43 f5 02 01 03
IMSI: 123456789012345
generated message: 1e 01 08 21 43 65 87 09 21 43 f5
original message: 1e 01 08 21 43 65 87 09 21 43 f5
IMSI: 123456789012345
generated message: 0c 01 08 21 43 65 87 09 21 43 f5
original message: 0c 01 08 21 43 65 87 09 21 43 f5
IMSI: 123456789012345
generated message: 0d 01 08 21 43 65 87 09 21 43 f5 02 01 03
original message: 0d 01 08 21 43 65 87 09 21 43 f5 02 01 03
IMSI: 123456789012345
generated message: 0e 01 08 21 43 65 87 09 21 43 f5 07 00
original message: 0e 01 08 21 43 65 87 09 21 43 f5 07 00
IMSI: 123456789012345
generated message: 0a 01 08 21 43 65 87 09 21 43 f5 03 62 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 21 04 21 22 23 24 22 08 31 32 33 34 35 36 37 38 23 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 24 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 25 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 27 08 01 02 03 04 05 06 07 08 03 62 20 10 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af 10 21 04 b1 b2 b3 b4 22 08 c1 c2 c3 c4 c5 c6 c7 c8 23 10 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df d0 24 10 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef e0 25 10 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff f0 27 08 91 92 93 94 95 96 97 98
original message: 0a 01 08 21 43 65 87 09 21 43 f5 03 62 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 21 04 21 22 23 24 22 08 31 32 33 34 35 36 37 38 23 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 24 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 25 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 27 08 01 02 03 04 05 06 07 08 03 62 20 10 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af 10 21 04 b1 b2 b3 b4 22 08 c1 c2 c3 c4 c5 c6 c7 c8 23 10 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df d0 24 10 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef e0 25 10 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff f0 27 08 91 92 93 94 95 96 97 98
IMSI: 123456789012345
generated message: 08 01 08 21 43 65 87 09 21 43 f5 26 0e 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
original message: 08 01 08 21 43 65 87 09 21 43 f5 26 0e 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 20 10 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10
IMSI: 123456789012345
GSUP: implement TCAP-like session management 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
2018-04-06 19:34:55 +00:00
generated message: 2b 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01
original message: 2b 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01
IMSI: 123456789012345
GSUP: introduce new messages for SS/USSD payloads 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
2018-03-30 22:23:09 +00:00
generated message: 20 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 35 14 a1 12 02 01 01 02 01 3b 30 0a 04 01 0f 04 05 aa 18 0c 36 02
original message: 20 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 35 14 a1 12 02 01 01 02 01 3b 30 0a 04 01 0f 04 05 aa 18 0c 36 02
IMSI: 123456789012345
generated message: 22 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 35 08 a3 06 02 01 01 02 01 47
original message: 22 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 35 08 a3 06 02 01 01 02 01 47
IMSI: 123456789012345
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
generated message: 24 01 08 21 43 65 87 09 21 43 f5 40 01 fa 41 08 03 91 52 75 47 99 09 82 42 01 ff 43 04 de ad be ef
original message: 24 01 08 21 43 65 87 09 21 43 f5 40 01 fa 41 08 03 91 52 75 47 99 09 82 42 01 ff 43 04 de ad be ef
IMSI: 123456789012345
generated message: 28 01 08 21 43 65 87 09 21 43 f5 40 01 fa 41 09 01 21 43 65 87 09 21 43 f5 42 08 03 91 52 75 47 99 09 82 43 04 de ad be ef 45 01 01
original message: 28 01 08 21 43 65 87 09 21 43 f5 40 01 fa 41 09 01 21 43 65 87 09 21 43 f5 42 08 03 91 52 75 47 99 09 82 43 04 de ad be ef 45 01 01
IMSI: 123456789012345
generated message: 2a 01 08 21 43 65 87 09 21 43 f5 40 01 fa 43 04 de ad be ef
original message: 2a 01 08 21 43 65 87 09 21 43 f5 40 01 fa 43 04 de ad be ef
IMSI: 123456789012345
tests/gsup_test.c: drop session IEs from MO-ForwardSM Error Both session state and session ID IEs were left from the initial version of Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71. There is no need to use them (as we use SM-RP-MR), so let's clean up. Change-Id: I0d910b87f15ffbc0aeeca9cb4fcbef32bdf3ef88
2018-12-19 21:20:10 +00:00
generated message: 25 01 08 21 43 65 87 09 21 43 f5 40 01 fa 44 01 af
original message: 25 01 08 21 43 65 87 09 21 43 f5 40 01 fa 44 01 af
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
IMSI: 123456789012345
GSUP/SMS: introduce READY-FOR-SM message 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
2018-11-12 19:06:15 +00:00
generated message: 2c 01 08 21 43 65 87 09 21 43 f5 46 01 02
original message: 2c 01 08 21 43 65 87 09 21 43 f5 46 01 02
IMSI: 123456789012345
GSUP: add CHECK-IMEI message 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
2018-12-14 15:14:34 +00:00
generated message: 30 01 08 21 43 65 87 09 21 43 f5 50 09 42 42 42 42 42 42 42 42 42
original message: 30 01 08 21 43 65 87 09 21 43 f5 50 09 42 42 42 42 42 42 42 42 42
IMSI: 123456789012345
generated message: 31 01 08 21 43 65 87 09 21 43 f5 02 01 60
original message: 31 01 08 21 43 65 87 09 21 43 f5 02 01 60
IMSI: 123456789012345
generated message: 32 01 08 21 43 65 87 09 21 43 f5 51 01 00
original message: 32 01 08 21 43 65 87 09 21 43 f5 51 01 00
IMSI: 123456789012345
GSUP: add inter-MSC handover related msgs and IEs 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
2019-02-01 10:35:10 +00:00
generated message: 34 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 34 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 35 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
original message: 35 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
IMSI: 123456789012345
generated message: 36 01 08 21 43 65 87 09 21 43 f5 08 07 91 94 61 46 32 24 43 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 36 01 08 21 43 65 87 09 21 43 f5 08 07 91 94 61 46 32 24 43 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 38 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 38 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 01 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 39 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
original message: 39 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
IMSI: 123456789012345
generated message: 3a 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 3a 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 3c 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 3c 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 3d 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
original message: 3d 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 64 01 51
IMSI: 123456789012345
generated message: 3e 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 3e 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 40 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 40 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 44 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
original message: 44 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 02 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42 62 05 01 42 42 42 42
IMSI: 123456789012345
generated message: 47 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42
original message: 47 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42
IMSI: 123456789012345
generated message: 4b 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 64 01 51
original message: 4b 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 64 01 51
IMSI: 123456789012345
generated message: 4e 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42
original message: 4e 01 08 21 43 65 87 09 21 43 f5 30 04 de ad be ef 31 01 03 0a 01 04 60 05 4d 53 43 2d 41 61 05 4d 53 43 2d 42
IMSI: 123456789012345
gsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IE 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
2019-08-16 10:22:29 +00:00
generated message: 08 01 08 21 43 65 87 09 21 43 f5 52 01 0a 0a 01 01
original message: 08 01 08 21 43 65 87 09 21 43 f5 52 01 0a 0a 01 01
IMSI: 123456789012345
GSUP: add Message Class IE 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
2019-04-01 20:24:33 +00:00
message 0: tested 14 truncations, 13 parse failures
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
message 1: tested 14 truncations, 13 parse failures
message 2: tested 83 truncations, 81 parse failures
message 3: tested 11 truncations, 11 parse failures
message 4: tested 14 truncations, 13 parse failures
gsup: Add encoding/decoding for the pdp charging characteristics 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
2017-07-07 14:53:30 +00:00
message 5: tested 81 truncations, 75 parse failures
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
message 6: tested 14 truncations, 13 parse failures
message 7: tested 14 truncations, 13 parse failures
message 8: tested 11 truncations, 11 parse failures
message 9: tested 11 truncations, 11 parse failures
message 10: tested 14 truncations, 13 parse failures
message 11: tested 13 truncations, 12 parse failures
message 12: tested 211 truncations, 209 parse failures
message 13: tested 45 truncations, 43 parse failures
GSUP: implement TCAP-like session management 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
2018-04-06 19:34:55 +00:00
message 14: tested 20 truncations, 18 parse failures
GSUP: introduce new messages for SS/USSD payloads 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
2018-03-30 22:23:09 +00:00
message 15: tested 42 truncations, 39 parse failures
message 16: tested 30 truncations, 27 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 17: tested 33 truncations, 29 parse failures
message 18: tested 44 truncations, 39 parse failures
message 19: tested 20 truncations, 18 parse failures
tests/gsup_test.c: drop session IEs from MO-ForwardSM Error Both session state and session ID IEs were left from the initial version of Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71. There is no need to use them (as we use SM-RP-MR), so let's clean up. Change-Id: I0d910b87f15ffbc0aeeca9cb4fcbef32bdf3ef88
2018-12-19 21:20:10 +00:00
message 20: tested 17 truncations, 15 parse failures
GSUP/SMS: introduce READY-FOR-SM message 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
2018-11-12 19:06:15 +00:00
message 21: tested 14 truncations, 13 parse failures
GSUP: add CHECK-IMEI message 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
2018-12-14 15:14:34 +00:00
message 22: tested 22 truncations, 21 parse failures
message 23: tested 14 truncations, 13 parse failures
message 24: tested 14 truncations, 13 parse failures
GSUP: add inter-MSC handover related msgs and IEs 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
2019-02-01 10:35:10 +00:00
message 25: tested 44 truncations, 38 parse failures
message 26: tested 40 truncations, 34 parse failures
message 27: tested 53 truncations, 46 parse failures
message 28: tested 44 truncations, 38 parse failures
message 29: tested 40 truncations, 34 parse failures
message 30: tested 44 truncations, 38 parse failures
message 31: tested 44 truncations, 38 parse failures
message 32: tested 40 truncations, 34 parse failures
message 33: tested 44 truncations, 38 parse failures
message 34: tested 44 truncations, 38 parse failures
message 35: tested 44 truncations, 38 parse failures
message 36: tested 37 truncations, 32 parse failures
message 37: tested 26 truncations, 22 parse failures
message 38: tested 37 truncations, 32 parse failures
gsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IE 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
2019-08-16 10:22:29 +00:00
message 39: tested 17 truncations, 15 parse failures
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
DLGSUP Stopping DLGSUP logging
GSUP: add Message Class IE 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
2019-04-01 20:24:33 +00:00
message 0: tested 3584 modifications, 771 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 1: tested 3584 modifications, 770 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 2: tested 21248 modifications, 2577 parse failures
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
message 3: tested 2816 modifications, 510 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 4: tested 3584 modifications, 770 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 5: tested 20736 modifications, 4025 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 6: tested 3584 modifications, 771 parse failures
message 7: tested 3584 modifications, 770 parse failures
gsup_test: also check stderr Configure logging to be deterministic and add stderr checking to testuite.at. However, exclude the thousands of message modification log lines from the log to not have a huge test expectation file. Change-Id: I0dd7112967a64a168556b62e5ec15107b7608ffb
2017-02-21 19:17:35 +00:00
message 8: tested 2816 modifications, 510 parse failures
message 9: tested 2816 modifications, 510 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 10: tested 3584 modifications, 770 parse failures
GSUP: add inter-MSC handover related msgs and IEs 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
2019-02-01 10:35:10 +00:00
message 11: tested 3328 modifications, 770 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 12: tested 54016 modifications, 4628 parse failures
message 13: tested 11520 modifications, 1028 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 14: tested 5120 modifications, 1030 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 15: tested 10752 modifications, 1263 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 16: tested 7680 modifications, 1271 parse failures
message 17: tested 8448 modifications, 2053 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 18: tested 11264 modifications, 2308 parse failures
GSUP/SMS: introduce MO-/MT-FORWARD-SM messages 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
2018-09-25 16:03:13 +00:00
message 19: tested 5120 modifications, 1031 parse failures
tests/gsup_test.c: drop session IEs from MO-ForwardSM Error Both session state and session ID IEs were left from the initial version of Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71. There is no need to use them (as we use SM-RP-MR), so let's clean up. Change-Id: I0d910b87f15ffbc0aeeca9cb4fcbef32bdf3ef88
2018-12-19 21:20:10 +00:00
message 20: tested 4352 modifications, 1030 parse failures
GSUP/SMS: introduce READY-FOR-SM message 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
2018-11-12 19:06:15 +00:00
message 21: tested 3584 modifications, 771 parse failures
gsup: add OSMO_GSUP_SUPPORTED_RAT_TYPES_IE and OSMO_GSUP_CURRENT_RAT_TYPE_IE 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
2018-12-26 17:13:38 +00:00
message 22: tested 5632 modifications, 772 parse failures
GSUP: add CHECK-IMEI message 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
2018-12-14 15:14:34 +00:00
message 23: tested 3584 modifications, 770 parse failures
message 24: tested 3584 modifications, 771 parse failures
GSUP: add inter-MSC handover related msgs and IEs 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
2019-02-01 10:35:10 +00:00
message 25: tested 11264 modifications, 2058 parse failures
message 26: tested 10240 modifications, 2060 parse failures
message 27: tested 13568 modifications, 2313 parse failures
message 28: tested 11264 modifications, 2058 parse failures
message 29: tested 10240 modifications, 2060 parse failures
message 30: tested 11264 modifications, 2058 parse failures
message 31: tested 11264 modifications, 2057 parse failures
message 32: tested 10240 modifications, 2060 parse failures
message 33: tested 11264 modifications, 2057 parse failures
message 34: tested 11264 modifications, 2058 parse failures
message 35: tested 11264 modifications, 2058 parse failures
message 36: tested 9472 modifications, 1803 parse failures
message 37: tested 6656 modifications, 1546 parse failures
message 38: tested 9472 modifications, 1803 parse failures
gsup: Introduce OSMO_GSUP_NUM_VECTORS_REQ_IE 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
2019-08-16 10:22:29 +00:00
message 39: tested 4352 modifications, 1030 parse failures