aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/gsm_04_11_gsup.c
AgeCommit message (Collapse)AuthorFilesLines
2020-04-26SMS-over-GSUP: notify sender in case of RPL delivery failureVadim Yanitskiy1-1/+1
Change-Id: I8436601c4314395e28829960dc753778c37b1125
2020-04-26SMS-over-GSUP: notify sender about malformed GSUP messagesVadim Yanitskiy1-4/+3
Change-Id: I27f00e69ff045cbf641ef21adf44fcd55cb8f889
2020-04-26SMS-over-GSUP: notify sender about unhandled GSUP messagesVadim Yanitskiy1-0/+1
Change-Id: I7970349bd9d5c56a64c409e619e8b581682fef0b
2020-04-26SMS-over-GSUP: respond with error if net->sms_over_gsup is falseVadim Yanitskiy1-1/+1
Change-Id: If14f8a394e691f86e0acbffb283c3862fe62ffd2
2020-04-26SMS-over-GSUP: move net->sms_over_gsup check to gsm411_gsup_rx()Vadim Yanitskiy1-16/+8
Change-Id: I89988b7148b164af304ecae1f53b74f322fdc7bd
2020-04-26SMS-over-GSUP: clarify error message about unexpected MO/MT SMSVadim Yanitskiy1-4/+4
Change-Id: I34b25764f9ce9b09ccd28cf23fea01028d0828e0
2019-12-19libmsc/gsm_04_11_gsup.c: fix SM-RP-OA encoding for MO SMS over GSUPVadim Yanitskiy1-6/+12
We shall not include additional BCD length octet into the value part of SM-RP-OA (Originating Address) IE. Instead, there should be ToA/NPI header (1 octet). Since we do not get ToN/NPI fields from the VLR/HLR, let's assume the following default values: 1... .... = Extension: No extension .001 .... = Type of number: International (1) .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1) Change-Id: I0f32e2af0ed2d2fea6addf45efbdfee120c2425d TTCN-3 test case: Ib467eeca6439bc6cce72293fbb5bb48f6d233db9 Related: OS#4324
2019-12-19libmsc/gsm_04_11_gsup.c: do not init a buffer in gsm411_gsup_mo_fwd_sm_req()Vadim Yanitskiy1-1/+1
Because there is no real need for that. Change-Id: I19d4d0de0d5a46bf1de194b966f18ea8a84ced94
2019-06-20gsm_04_11_gsup.c: fix broken reference counting for vsubVadim Yanitskiy1-4/+11
This change is similar to I5540556b1c75f6873883e46b78656f31fc1ef186. In gsm411_gsup_rx() we do call vlr_subscr_find_by_imsi(), which increases subscriber's reference count by one using the function name as the token. However, we never release this token, so the reference count grows on every received GSUP FORWARD-SM message. Change-Id: Ic729beb5f94cbbfbb251bc9ab66a5e7b799286c0
2019-06-17libmsc/msc_net_init.c: pass pointer to gsm_network directlyVadim Yanitskiy1-18/+8
Change-Id: I122d2880b356997c60df5f0cf4f5ecb3abb2e672
2019-06-15libmsc/gsm_0(4|9)_11_gsup.c: print error message if subscr is not knownVadim Yanitskiy1-0/+2
Change-Id: I0b9d4128c853866d7d834f381ad520f78f441afe Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-05-19libmsc/gsm_04_11.c: properly handle MMTS indicationVadim Yanitskiy1-1/+9
According to 3GPP TS 29.002, section 7.6.8.7, MMS (More Messages to Send) is an optional IE of MT-ForwardSM-Req message which is used by SMSC to indicate that there are more (multi-part) MT SMS messages to be sent. The MSC needs to use this indication in order to decide whether to keep the RAN connection with a given subscriber open. Related Change-Id: (TTCN) I6308586a70c4fb3254c519330a61a9667372149f Change-Id: Ic46b04913b2e8cc5d11a39426dcc1bfe11f1d31e Related: OS#3587
2019-05-12libmsc/gsm_04_11_gsup.c: cosmetic: drop useless variableVadim Yanitskiy1-3/+1
Change-Id: I102e1bd0f8365e77bbc9203158909aad8dcf214b
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr1-13/+46
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles: - MSC-A is responsible for managing subscribers, - MSC-I is the gateway to the RAN. - MSC-T is a second transitory gateway to another RAN during Handover. After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while the original MSC-A retains the responsibility of subscriber management. MSC-T exists in this patch but is not yet used, since Handover is only prepared for, not yet implemented. Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC roles. Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications: - all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc instance, - messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface (GSUP), - no call routing between MSC-A and -I via MNCC necessary. This is the largest code bomb I have submitted, ever. Out of principle, I apologize to everyone trying to read this as a whole. Unfortunately, I see no sense in trying to split this patch into smaller bits. It would be a huge amount of work to introduce these changes in separate chunks, especially if each should in turn be useful and pass all test suites. So, unfortunately, we are stuck with this code bomb. The following are some details and rationale for this rather huge refactoring: * separate MSC subscriber management from ran_conn struct ran_conn is reduced from the pivotal subscriber management entity it has been so far to a mere storage for an SCCP connection ID and an MSC subscriber reference. The new pivotal subscriber management entity is struct msc_a -- struct msub lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however use msc_a, since MSC-A is where all the interesting stuff happens. Before handover, msc_i is an FSM implementation that encodes to the local ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM implementation that instead forwards via/from GSUP. Same goes for the msc_a struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the msc_a->fi is an FSM implementation that merely forwards via/from GSUP. * New SCCP implementation for RAN access To be able to forward BSSAP and RANAP messages via the GSUP interface, the individual message layers need to be cleanly separated. The IuCS implementation used until now (iu_client from libosmo-ranap) did not provide this level of separation, and needed a complete rewrite. It was trivial to implement this in such a way that both BSSAP and RANAP can be handled by the same SCCP code, hence the new SCCP-RAN layer also replaces BSSAP handling. sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN connections. A set of callback functions provides implementation specific details. * RAN Abstraction (BSSAP vs. RANAP) The common SCCP implementation did set the theme for the remaining refactoring: make all other MSC code paths entirely RAN-implementation-agnostic. ran_infra.c provides data structures that list RAN implementation specifics, from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra pointer hence allows complete abstraction of RAN implementations: - managing connected RAN peers (BSC, RNC) in ran_peer.c, - classifying and de-/encoding RAN PDUs, - recording connected LACs and cell IDs and sending out Paging requests to matching RAN peers. * RAN RESET now also for RANAP ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide proper RESET handling, which it so far duly ignores. (TODO) * RAN de-/encoding abstraction The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP implementations transparently, but also to be able to optionally handle RAN on distinct levels. Before Handover, all RAN messages are handled by the MSC-A role. However, after an inter-MSC Handover, a standalone MSC-I will need to decode RAN PDUs, at least in order to manage Assignment of RTP streams between BSS/RNC and MNCC call forwarding. ran_msg.h provides a common API with abstraction for: - receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP or RANAP; - sending RAN events: ran_enc_msg is the counterpart to compose RAN messages that should be encoded to either BSSMAP or RANAP and passed down to the BSC/RNC and MS/UE. The RAN-specific implementations are completely contained by ran_msg_a.c and ran_msg_iu.c. In particular, Assignment and Ciphering have so far been distinct code paths for BSSAP and RANAP, with switch(via_ran){...} statements all over the place. Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified. Note that SGs does not qualify for RAN abstraction: the SGs interface always remains with the MSC-A role, and SGs messages follow quite distinct semantics from the fairly similar GERAN and UTRAN. * MGW and RTP stream management So far, managing MGW endpoints via MGCP was tightly glued in-between GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP streams between different RAN peers by moving to object-oriented implementations: implement struct call_leg and struct rtp_stream with distinct FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose. Instead of implementing a sequence of events with code duplication for the RAN and CN sides, the idea is to manage each RTP stream separately by firing and receiving events as soon as codecs and RTP ports are negotiated, and letting the individual FSMs take care of the MGW management "asynchronously". The caller provides event IDs and an FSM instance that should be notified of RTP stream setup progress. Hence it becomes possible to reconnect RTP streams from one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP peers (inter-MSC Handover) without duplicating the MGCP code for each transition. The number of FSM implementations used for MGCP handling may seem a bit of an overkill. But in fact, the number of perspectives on RTP forwarding are far from trivial: - an MGW endpoint is an entity with N connections, and MGCP "sessions" for configuring them by talking to the MGW; - an RTP stream is a remote peer connected to one of the endpoint's connections, which is asynchronously notified of codec and RTP port choices; - a call leg is the higher level view on either an MT or MO side of a voice call, a combination of two RTP streams to forward between two remote peers. BSC MGW PBX CI CI [MGW-endpoint] [--rtp_stream--] [--rtp_stream--] [----------------call_leg----------------] * Use counts Introduce using the new osmo_use_count API added to libosmocore for this purpose. Each use token has a distinct name in the logging, which can be a globally constant name or ad-hoc, like the local __func__ string constant. Use in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count API. * FSM Timeouts Introduce using the new osmo_tdef API, which provides a common VTY implementation for all timer numbers, and FSM state transitions with the correct timeout. Originated in osmo-bsc, recently moved to libosmocore. Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore) Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore) Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp) I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw) Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw) I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-04-12add LOG_TRANS, proper context for all transactionsNeels Hofmeyr1-8/+7
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-03-07gsm_04_11_gsup.c: drop unused conn lookupNeels Hofmeyr1-11/+0
An earlier code state used the conn to lookup the transaction, but this is now done by vsub. Hence the conn lookup is not used and not needed. conn is no longer used since 36c44b210059bd75059008913ad05976dfef7d7e, change-Id I093f36d63e671e50e54fc6236e97a777cc6da77b, "transaction: change arguments of trans_find_by_sm_rp_mr()" Change-Id: Ia878d70138c883cb1a1d983516aff83efa6488ce
2019-02-01transaction: change arguments of trans_find_by_sm_rp_mr()Vadim Yanitskiy1-1/+1
The need to pass a pointer to RAN connection in order to find a transaction limits possible use cases of trans_find_by_sm_rp_mr(), e.g. when we need to find a transaction, but RAN connection is not established yet. Moreover, the pointer to RAN connection was only used to obtain pointers to gsm_network and vlr_subscr, so we can just pass them directly. Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy1-0/+96
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-12-30libmsc/gsm_04_11.c: forward MO SMS messages over GSUPVadim Yanitskiy1-0/+203
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 11:05:03 +0000