summaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* add gsm0808_cell_id_from_cgi(), gsm0808_cell_id_to_cgi()Neels Hofmeyr2019-03-082-8/+169
| | | | | | | | | | | | | | | | CGI to Cell ID: for example, for Paging, osmo-msc has a CGI for a subscriber and needs to send out a Cell Identifier IE. Makes sense to add this conversion here. Cell ID to CGI: for a Layer 3 Complete, a subscriber sends the current cell in the form of a Cell Identifier, which we store as a CGI, if necessary enriched with the local PLMN. Add enum with bitmask values to identify parts of a CGI, for the return value of gsm0808_cell_id_to_cgi(). Can't use enum CELL_IDENT for that, because it doesn't have a value for just a PLMN (and is not a bitmask). Change-Id: Ib9af67b100c4583342a2103669732dab2e577b04
* fsm: add osmo_fsm_inst_state_chg_keep_or_start_timer()Neels Hofmeyr2019-03-072-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | During FSM design for osmo-msc, I noticed that the current behavior that keep_timer=true doesn't guarantee a running timer can make FSM design a bit complex, especially when using osmo_tdef for timeout definitions. A desirable keep_timer=true behavior is one that keeps the previous timer running, but starts a timer if no timer is running yet. The simplest example is: a given state repeatedly transitions back to itself, but wants to set a timeout only on first entering, avoiding to restart the timeout on re-entering. Another example is a repeated transition between two or more states, where the first time we enter this group a timeout should start, but it should not restart from scratch on every transition. When using osmo_tdef timeout definitions for this, so far separate meaningless states have to be introduced that merely set a fixed timeout. To simplify, add osmo_fsm_inst_state_chg_keep_or_start_timer(), and use this in osmo_tdef_fsm_inst_state_chg() when both keep_timer == true *and* T != 0. In tdef_test.ok, the changes show that on first entering state L, the previous T=1 is now kept with a large remaining timeout. When entering state L from O, where no timer was running, this time L's T123 is started. Change-Id: Id647511a4b18e0c4de0e66fb1f35dc9adb9177db
* fix tdef_test.c: do call the function-to-test in all casesNeels Hofmeyr2019-03-063-19/+19
| | | | | | | | | | | | Always call osmo_tdef_fsm_inst_state_chg(), also when no timeout is defined. When there is no timeout defined for a state, tdef_test.c tries to be smart and print different output. In that mess, I missed the fact that osmo_tdef_fsm_inst_state_chg() isn't always called as it should. In the same mess, the resulting state was never printed until the preceding patch, which helped to hide this bug. Change-Id: I1d953d99854422bff8eb32f051e9c6147bc836b6
* tdef_test: tweak output to prepare for a fixNeels Hofmeyr2019-03-063-21/+24
| | | | | | | | | | | | | | - Always print the state after a state transition. This shows that actually state transitions are missing for states that have no timer defined. This is a bug in tdef_test.c, to be fixed subsequently. - Instead of total time passed since start, print the individual fake time intervals. Omit initial useless zero fake time advance. - Add two more state transitions, back out from and into a state that has no timeout set. Change-Id: Icb31af96d37741e256ff07868f3d4f5c48cdda74
* represent negative T-timers as Osmocom-specific X-timersNeels Hofmeyr2019-03-062-30/+60
| | | | | | | | | | | | | | | | | | | | fi->T values are int, i.e. can be negative. Do not log them as unsigned, but define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1, print "Timeout of X1" instead of "Timeout of T4294967295". The negative T timer number space is useful to distinguish freely invented timers from proper 3GPP defined T numbers. So far I was using numbers like T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way we can make sure to not accidentally define an invented timer number that actually collides with a proper 3GPP specified timer number that the author was not aware of at the time of writing. Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly. Mention the two timer classes in various API docs and VTY online-docs. Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
* coding: check gsm0503_rach_*() resultsMax2019-03-051-8/+10
| | | | | | | | Check return value of RACH encode/decode functions and fail test on unexpected results. Change-Id: I41bfa808e3c064a11152e7ce8ee77a01d38a0744 Related: OS#1854
* log: fsm: allow logging the timeout on state changeNeels Hofmeyr2019-02-262-10/+13
| | | | | | | | | | | | | | | | Add a flag that adds timeout info to osmo_fsm_inst state change logging. To not affect unit testing, make this an opt-in feature that is disabled by default -- mostly because osmo_fsm_inst_state_chg_keep_timer() will produce non-deterministic logging depending on timing (logs remaining time). Unit tests that don't verify log output and those that use fake time may also enable this feature. Do so in fsm_test.c. The idea is that in due course we will add osmo_fsm_log_timeouts(true) calls to all of our production applications' main() initialization. Change-Id: I089b81021a1a4ada1205261470da032b82d57872
* NS: Factor out gprs_nsvc_start_test() and use itHarald Welte2019-02-261-10/+10
| | | | | | | | | | | | This function performs sending a NS-ALIVE PDU and starting Tns-Test, let's use it in all places where we used to do that. As part of this, also fix a bug where the sendto() return value (number of bytes sent) would actually propagate up all the way to gprs_ns_rx_reset() return value, which in turn affects the test results on stdout. Change-Id: I4d303117f77fabb74bbb91887b9914a81c2a084a
* LCLS: add string dump helpersMax2019-02-262-3/+6
| | | | | | | | | Add functions to dump LCLS (without GCR) and GCR. Dumping entire struct results in inconveniently long string hence the separate functions. Both use talloc functions so they expect caller to take care of providing proper allocation context and freeing memory. Change-Id: Ic3609224c8f3282d667e75f68bc20327e36eb9e6
* gsm0808: Add unit tests for test_create_clear_command2()Harald Welte2019-02-182-0/+26
| | | | | Change-Id: Ie3f34b78edc91a013152742bebbd839586a787fe Related: OS#3805
* add OSMO_STRBUF_PRINTF()Neels Hofmeyr2019-02-172-0/+103
| | | | | | | | | | We are using macros like this or different workarounds in libmsc. In the course of implementing inter-MSC handover, I am encountering yet another such situation of appending multiple strings to a limited char buffer. Standardize. Add a unit test to utils_test.c. Change-Id: I2497514e26c5e7a5d88985fc7e58343be1a027b2
* Enable remote SIM protocol log levelMax2019-02-141-1/+1
| | | | | | | It's defined in logging.h for quite some time but is not actually enabled alongside with other internal logging categories. Change-Id: I0e7a2add6293a072752900608c8ba34cc3850f31
* platform independence fix: tdef range testsNeels Hofmeyr2019-02-068-133/+490
| | | | | | | | | | | | | Run INT_MAX and ULONG_MAX related tests only manually, remove from automatic testing. This will hopefully fix recent build failures on various platforms. Add a 64 bit output example for expected results when invoking `./tdef_test range'. This is not checked automatically and merely serves for manual reference. For vty tests, use 32bit max values instead of INT_MAX and ULONG_MAX. Change-Id: I6242243bde1d7ddebb858512a1f0b07f4ec3e5c2
* bitvec: Add bitvec_tailroom_bits() functionHarald Welte2019-02-051-0/+19
| | | | | | | | | This is similar to msgb_tailroom(): It returns the amount of space left at the end of the bit vector (compared to the current cursor). The function returns the number of bits left in the bitvec. Change-Id: I8980a6b6d1973b67a2d9ad411c878d956fb428d1
* bitvec: Add bitvec_bytes_used() functionHarald Welte2019-02-052-0/+28
| | | | | | | This new bitvec API function returns the number of bytes used in a given bit-vector. Change-Id: Id4bd7f7543f5b0f4f6f876e283bd065039c37646
* add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr2019-02-0410-0/+2095
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
* vty: enable optional-multi-choice syntax: [(one|two)]Neels Hofmeyr2019-02-042-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Since very recently we sensibly handle commands like cmd ([one]|[two]|[three]) as optional multi-choice arguments. In addition, support the more obvious syntax of cmd [(one|two|three)] Internally, the tokens are mangled to [one] [two] and [three], which is how the rest of the code detects optional args, and makes sense in terms of UI: > cmd ? [one] [two] [three] (i.e. optional arguments are always shown in braces in '?' listings) Before this patch, commands defined with a syntax like [(one|two)], would lead to an assertion (shows as "multiple") during program startup. Change-Id: I952b3c00f97e2447f2308b0ec6f5f1714692b5b2
* vty: enable optional-multi-choice syntax: ([one]|[two])Neels Hofmeyr2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic optional multi-choice argument support. The VTY detects optional arguments by square braces. > cmd ? [optional-arg] > cmd optional-arg ok > cmd ok However, within multi-choice args, these braces were so far not treated as optional: > list cmd2 ([one]|[two]|[three]) > cmd2 % Command incomplete In preparation for I952b3c00f97e2447f2308b0ec6f5f1714692b5b2 which will enable the more obvious syntax of cmd [(one|two)] for reasons of internal implementation, first support a syntax of cmd ([one]|[two]) The internal vty implementation always needs square braces around each option. There is currently no good way to prevent developers from defining braces inside multi-arguments, so it is easiest to allow and handle them: > list cmd2 ([one]|[two]|[three]) > cmd2 ok The VTY doesn't guard against a mix like cmd (one|[two]) With this patch, a multi-choice command is treated as optional iff the first element is in square brackets. The remaining elements' square brackets have no effect besides confusing the user. This is not explicitly checked against. In general, I would prefer to check all of these details, but the current VTY code with its endless code duplication and obscure string mangling just doesn't provide that luxury. There are numerous worse errors hidden in there. Change-Id: I9a8474bd89ddc2155c58bfca7bd038d586aaa60a
* add generic vty_transcript_test.c, vty_transcript_test.vtyNeels Hofmeyr2019-02-043-2/+301
| | | | | | | | I want to tweak general VTY features and need to cover with a transcript test to show the differences. Start by showing the current situation of optional and multi-choice arguments. Change-Id: I5a79c83fabd02aba6406b6e0d620969c4bd0cc1d
* osmo_fsm_inst_state_chg(): set T also for zero timeoutNeels Hofmeyr2019-01-293-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, if timeout_secs == 0 was passed to osmo_fsm_inst_state_chg(), the previous T value remained set in the osmo_fsm_inst->T. For example: osmo_fsm_inst_state_chg(fi, ST_X, 23, 42); // timer == 23 seconds; fi->T == 42 osmo_fsm_inst_state_chg(fi, ST_Y, 0, 0); // no timer; fi->T == 42! Instead, always set to the T value passed to osmo_fsm_inst_state_chg(). Adjust osmo_fsm_inst_state_chg() API doc; need to rephrase to accurately describe the otherwise unchanged behaviour independently from T. Verify in fsm_test.c. Rationale: it is confusing to have a T number remaining from some past state, especially since the user explicitly passed a T number to osmo_fsm_inst_state_chg(). (Usually we are passing timeout_secs=0, T=0). I first thought this behavior was introduced with osmo_fsm_inst_state_chg_keep_timer(), but in fact osmo_fsm_inst_state_chg() behaved this way from the start. This shows up in the C test for the upcoming tdef API, where the test result printout was showing some past T value sticking around after FSM state transitions. After this patch, there will be no such confusion. Change-Id: I65c7c262674a1bc5f37faeca6aa0320ab0174f3c
* build: add missing logging_vty_test.vty to EXTRA_DISTNeels Hofmeyr2019-01-291-0/+1
| | | | | | | | | | It was introduced and forgotten to add to EXTRA_DIST in: "logging vty: add VTY transcript test" commit 3a9ff11e574fa7ee19b1062b2c90151dbf7f0e27 change-Id I948e832a33131f8eab98651d6010ceb0ccbc9a9c Change-Id: I1bcedf3097f02b2adc679560d1cbceb27dbc345e
* add osmo_hexdump_buf() and testNeels Hofmeyr2019-01-282-0/+122
| | | | | | | | | | | | | | | | | | Add osmo_hexdump_buf() as an all-purpose hexdump function, which all other osmo_hexdump_*() implementations now call. It absorbs the static _osmo_hexdump(). Add tests for osmo_hexdump_buf(). Rationale: recently during patch review, a situation came up where two hexdumps in a single printf would have been useful. Now I've faced a similar situation again, in ongoing development. So I decided it is time to provide this API. The traditional osmo_hexdump() API returns a non-const char*, which should probably have been a const instead. Particularly this new function may return a string constant "" if the buf is NULL or empty, so return const char*. That is why the older implementations calling osmo_hexdump_buf() separately return the buffer instead of the const return value directly. Change-Id: I590595567b218b24e53c9eb1fd8736c0324d371d
* gsm0808: add BSSMAP Cell Identifier matching APINeels Hofmeyr2019-01-282-0/+459
| | | | | | | | | | | | | | | | | | | | | | | | | Add * osmo_lai_cmp() (to use in gsm0808_cell_id_u_matches()) * osmo_cgi_cmp() (to use in gsm0808_cell_id_u_matches()) * gsm0808_cell_id_u_match() (to re-use for single IDs and lists) * gsm0808_cell_ids_match() * gsm0808_cell_id_matches_list() * Unit tests in gsm0808_test.c Rationale: For inter-BSC handover, it is interesting to find matches between *differing* Cell Identity kinds. For example, if a cell as CGI 23-42-3-5, and a HO for LAC-CI 3-5 should be handled, we need to see the match. This is most interesting for osmo-msc, i.e. to direct the BSSMAP Handover Request towards the correct BSC or MSC. It is also interesting for osmo-bsc's VTY interface, to be able to manage cells' neighbors and to trigger manual handovers by various Cell Identity handles, as the user would expect them. Change-Id: I5535f0d149c2173294538df75764dd181b023312
* gsm0408_test: Fix IMEI-SV related tests to use no more than 16 digitsHarald Welte2019-01-222-16/+16
| | | | | | | | The IMEI-SV is speified as a 16 digit number: 14 digits of IMEI plus two digits of software version. Let's not try to feed 18 digit long numbers into our functions, as the resulting behavior is unspecified. Change-Id: I6fb85a0516dc387902ad9de4fe8c1ba82d68cae6
* LCLS: make GCR into static member of osmo_lclsMax2019-01-191-18/+22
| | | | | | | | | Most of the time we'll have GCR filled anyway so it make sense to have it as static parameter instead of a pointer to separately allocated structure. Update tests to cover both static and dynamic osmo_lcls allocation variants. Change-Id: I905c36d8455911c68c30bc429379b7313dd46aea
* LCLS: add status parameter to Assignment Completed messageMax2019-01-191-4/+5
| | | | | | | | | | * add gsm0808_create_ass_compl2() with additional gsm0808_lcls_status parameter and make gsm0808_create_ass_compl() into trivial wrapper around it * update tests accordingly Change-Id: I547c6b8707123aa8c1ef636db88908df112d90a4 Related: OS#2487
* LCLS: add GCR comparison helperMax2019-01-141-19/+4
| | | | Change-Id: I9e3b5560a058b976638d03cb819415d237ae9984
* LCLS: expand enc/dec testsMax2019-01-141-0/+12
| | | | Change-Id: I8ed87f26216104d34c7bd11c1527b203843760a2
* gsm23003: add osmo_imei_str_valid()Oliver Smith2019-01-142-0/+54
| | | | | | | | | | | Verify 14 digit and 15 digit IMEI strings. OsmoHLR will use the 14 digit version to check IMEIs before writing them to the DB. Place the Luhn checksum code in a dedicated osmo_luhn() function, so it can be used elsewhere. Related: OS#2541 Change-Id: Id2d2a3a93b033bafc74c62e15297034bf4aafe61
* port arfcn range encode support from osmo-bscStefan Sperling2019-01-122-0/+402
| | | | | | | | | | | | | | As part of fixing issue OS#3075, we want to migrate support for encoding system information from osmo-bsc to libosmocore. This change ports one of the prerequisites for doing so: osmo-bsc code for range-encoding ARFCNs, including tests. An osmo_gsm48_ prefix has been prepended to public symbols in order to avoid clashes with existing symbols in osmo-bsc code. Change-Id: Ia220764fba451be5e975ae7c5eefb1a25ac2bf2c Related: OS#3075
* add osmo_mi_name(), for MI-to-string like "IMSI-123456"Neels Hofmeyr2019-01-082-0/+44
| | | | | | | | We have gsm48_mi_to_string() and osmo_bcd2str(), but still lack a function that conveniently prints both MI type and value in one function call. Related: http://people.osmocom.org/neels/mi_mi_mi.jpg Change-Id: I7798c3ef983c2e333b2b9cbffef6f366f370bd81
* tests/gsup_test.c: drop session IEs from MO-ForwardSM ErrorVadim Yanitskiy2019-01-052-10/+4
| | | | | | | | 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
* LCLS: enc/dec entire parameter set instead of GCRMax2018-12-231-13/+20
| | | | | | | | | | | | | In 3GPP TS 48.008 the Global Call Reference IE is only used in HANDOVER REQUEST (§3.2.1.8) and ASSIGNMENT REQUEST (§3.2.1.1) messages which also include LCLS Config and CSC parameters. Hence, there's no point in using GCR encode/decode functions alone. Introduce gsm0808_dec_lcls() and gsm0808_enc_lcls() as trivial wrappers on top of GCR enc/dec routines which are made static. Adjust tests accordingly. Test output intentionally left unchanged. Change-Id: Icfbb2404e1a1d500243e2071173299b557369335
* tests/gsm0808: use new msgb comparison APIVadim Yanitskiy2018-12-211-12/+4
| | | | | | | | Since I3bc95f2f5ab6e3f4b502647fb3e0aaaf1f7c4cf5, we have some helpers to compare certain msgb layer to a given buffer. Let's change 'VERIFY' macro to use msgb_eq_l3_data_print(). Change-Id: Ib6be778236eff8f2153f3113f9379ecfbec9052b
* GSUP: add CHECK-IMEI messageOliver Smith2018-12-213-0/+54
| | | | | | | | | | | | | | 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-5/+1
| | | | | | | | | | | | | 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
* Use define for key buffersMax2018-12-201-1/+4
| | | | | | Add corresponding spec. references and comments where appropriate. Change-Id: If5e2aad86eaecd8eada667b3488ba415d81c6312
* add/clean big-endian packed structs (struct_endianess.py)Neels Hofmeyr2018-12-191-0/+1
| | | | | | | | | | | | | | This is 1:1 the result of doing cd libosmocore ./contrib/struct_endianess.py git commit -a Running struct_endianess.py again should result in no changes. That means we could include such a check in the gerrit verification job now. Change-Id: Ia0b99d76932aeb03e93bd0c62d3bf025dec5f9d2
* GSUP/SMS: introduce READY-FOR-SM messageVadim Yanitskiy2018-12-183-1/+19
| | | | | | | | | | | | | | | 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-183-13/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
*