aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2019-08-20make vlr_gmm_cause_to_mm_cause publicAlexander Couzens1-0/+3
To be used by vlr_auth_fsm Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
2019-08-20mncc: send payload type matching chosen codecNeels Hofmeyr1-0/+3
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr1-0/+5
Recently, the ability to run UTRAN without encryption was added, but the config for it was tied to the A5 GERAN encryption configuration. This affected osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3 test suite sets A5 to 0 (no encryption) but still expects Iu to enable air encryption. Fix this "regression". Add a separate vty config option for UEA encryption, even if it does not provide full granularity to select individual UEA algorithms yet. As a result, Iu default behavior remains to enable encryption regardless of the A5 config. UTRAN encryption can be disabled by the new cfg option "encryption uea 0" alone. Even though the new vty command already allows passing various combinations of the UEA algorithm numbers, only '0' and '1 2' are accepted as valid combinations, to reflect current osmo-msc capabilities. Revert most changes to the msc_vlr test suite in commit "do not force encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new net->iu_encryption instead of net->a5_encryption_mask. Adjust/add to test_nodes.vty transcript tests. Related: OS#4144 Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-07-18replace osmo_counter with stat_itemsAlexander Couzens1-2/+20
osmo_counter will be soon deprecated. Use the newer and more flexible osmo_stat_item instead. Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore) Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
2019-07-16fix spelling detected by lintianThorsten Alteholz2-2/+2
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-05-29Use GSM23003_MSISDN_MAX_DIGITS from libosmogsmVadim Yanitskiy1-2/+1
Change-Id: If9eb46b83b6ad45f210b86b46dd416352adcc3ff Depends on: Idc74f4d94ad44b9fc1b6d43178f5f33d551ebfb1
2019-05-27sgs_iface: detect and react to VLR/HLR failurePhilipp Maier1-0/+1
The HLR (which is connected via the GSUP interface) may fail and disconnect. On the next location update the VLR will try to talk to the HLR and fail. This failure event is not communicated towards the SGs related code and the SGs-association will remain in the LA-PRESENT state forever. Lets add code to report the problem to the SGs code and trigger a RESET an the SGs interface. - Add a flag to report an HLR problem back to the SGs code - Fix the FSM that controls the reset - Make sure the all SGs associations are reset when the failure occurs. Change-Id: Icc7df92879728bc98c85fc1d5d8b4c6246501b12 Related: OS#3859
2019-05-26transaction: accept trans_type enum in trans_log_subsys()Vadim Yanitskiy1-4/+2
Change-Id: I3c373d20ebd6e96ebd57f84b74dc15a6b69c03ac
2019-05-21Request Osmux CID and forward it in Assign Req and Assign ComplPau Espin Pedrol3-0/+16
Related: OS#2551 Depends: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de Change-Id: I5b14e34481e890669c9ee02dba81eba84293cebb
2019-05-19libmsc/gsm_04_11.c: properly handle MMTS indicationVadim Yanitskiy3-1/+5
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-19bssap: Detect BSC Osmux support on RESET (ACK) recvPau Espin Pedrol1-0/+3
Related: OS#2551 Depends: libosmocore.git I28f83e2e32b9533c99e65ccc1562900ac2aec74e Change-Id: If4f33da9b414ab194098755d2c5be85e1fce5d31
2019-05-19vty: Add option to enable osmux towards BSCsPau Espin Pedrol3-0/+16
Change-Id: I6de1be0322ddbdc115074ebb6be2598ebf6c95db
2019-05-15remove msc specific db countersAlexander Couzens1-6/+0
DB counters has been used to save osmo_counters & osmo_rate_ctr to a local sqlite databases every 60 seconds. This is quite slow e.g. 1000 subscriber might slow the msc down. Change-Id: Id64f1839a55b5326f74ec04b7a5dbed9d269b89c
2019-05-15vlr: fix IMEI lengthOliver Smith1-1/+1
Set the length of vlr_subscr->imei to GSM23003_IMEI_NUM_DIGITS_NO_CHK (14) instead of GSM23003_IMEISV_NUM_DIGITS (16). Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes an additional checksum digit. This digit is not intended for digital transmission, so we don't need to store it. Also by not storing it, we can simply copy the IMEI-part from the IMEISV to the IMEI without worrying about the checksum (will be done in a follow up patch). A good overview of the IMEI/IMEISV structure is here: https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version) Related: OS#2542 Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
2019-05-14make LOG_TRANS() NULL-safe againSylvain Munaut1-1/+1
Previous patch [1] removed NULL-safety from LOG_TRANS(). Fix that. In case a trans is NULL, it is fine to log in the DMSC category, since the context should still be general (erratic message or other initial problems). [1] 7f85acea9bb9f80e208820958f4cae63625f3689 / I6dfe5b98fb9e884c2dde61d603832dafceb12123 "LOG_TRANS: store subsys in trans, unify USSD logging back to DMM" Change-Id: I6e36c47bf828dd073b36c6301bbeabcc28e101e6
2019-05-12add DSS logging categoryNeels Hofmeyr2-4/+2
Change-Id: Id7e04c9f5088334cd5ec6cfdb6a9b3a2a7e7fda0
2019-05-10call_leg: document the parent_event_* itemsNeels Hofmeyr1-0/+1
Change-Id: Ib099178a0f6ab218646c67c0e7a3d360c81af684
2019-05-10call_leg: remove unused event MSC_EV_CALL_LEG_RTP_RELEASEDNeels Hofmeyr2-6/+2
The event is actually never dispatched and useless, because when an RTP stream releases, the call_leg terminates directly anyway (which wasn't apparent when starting to design the call_leg FSM yet). Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
2019-05-10LOG_TRANS: store subsys in trans, unify USSD logging back to DMMNeels Hofmeyr1-3/+9
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather store in trans->log_subsys once on trans_alloc() and use that. Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little sense and may cause logging to switch subsystems depending on the RAN state. In trans_log_subsys(), add missing switch cases: - Log silent call transactions also on CC. - Log USSD on DMM. About USSD: we currently have no dedicated USSD logging category. As a result, after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC, depending on whether a RAN was associated with the trans or not. Before that change, USSD always logged on DMM, so, until we have a separate logging category for USSD, consistenly use DMM again. [1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7b62025473d8f1a950905ac2cb2f31c Related: coverity CID 198453 Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
2019-05-09comment: apply function renames to message cycle explanationNeels Hofmeyr1-12/+12
The misnomed 'nas_decode' and 'nas_encode' APIs have been renamed to 'ran_decode' and 'ran_encode', which was forgotten in the large comment explaining the message path in sccp_ran.h. Apply the rename there. Change-Id: I742fb4844ac8a9ad76f59883ae9447eb8819b82d
2019-05-09fix regression: fix internal MNCC operationNeels Hofmeyr1-1/+1
While developing the inter-MSC handover refactoring, I was annoyed by the fact that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as well as a separate msg_type argument, which may deviate from each other. So, as a first step I wanted to make sure that all callers send identical values for both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going to remove the separate msg_type argument. I then forgot to - carry on to remove the argument and - to actually test with internal MNCC (it so happens that all of our ttcn3 tests also use external MNCC). As a result, the "large refactoring" patch for inter-MSC Handover breaks internal MNCC operation. Fix that: remove the separate msg_type argument and make sure that all callers of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence also remove the odd duality of arguments. Various functions in mncc_builtin.c also exhibit this separate msg_type argument, which are all unused and make absolutely no sense. Remove those as well. Related: OS#3989 Change-Id: I966ce764796982709ea3312e76988a95257acb8d
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr51-726/+2470
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-26vlr subscr get/put: also check against NULLNeels Hofmeyr1-2/+2
Change-Id: I36929a4ba4abb46909181068d1d0af967b1f5a94
2019-04-12add LOG_TRANS, proper context for all transactionsNeels Hofmeyr1-0/+30
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr5-16/+36
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-08msc/gsm_data.h: drop unused SMS_HDR_SIZE macroVadim Yanitskiy1-1/+0
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
2019-03-19libvlr: Allow 2G auth tuples to be re-used without going through AUTHSylvain Munaut1-0/+2
If the key_seq we get in the first messages matches the last_tuple, then both we and the MS already know the key to use and we don't need the AUTH REQUEST/RESPONSE cycle. Security wise ... not so good, and so IMHO the 'auth required' option in the MSC should always be set. But this allows to turn on ciphering on a channel without doing any MM transaction, and so the MS doesn't turn on the T3240 timer which allows to have a ciphered silent-call channel that won't timeout. Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-03-14libmsc: Allow different channel types to be requested as silent callsSylvain Munaut1-1/+4
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-02-20libmsc/gsm_09_11.c: implement guard timer for NCSS sessionsVadim Yanitskiy2-0/+4
It may happen that either the MS or an EUSE would become unresponsive during a call independent SS session, e.g. due to a bug, or a dropped message. In such cases, the corresponding transaction would remain unfreed forever. This change introduces a guard timer, that prevents keeping 'stalled' NCSS sessions forever. As soon as it expires, both sides (i.e. MS and EUSE) are getting notified, and the transaction is being released. By default, the timer expires after 30 seconds. As soon as either the MS, or an EUSE initiates any activity, the watchdog timer is rescheduled. The timeout value can be configured from the VTY: msc ... ! Use 0 to disable this timer ncss guard-timeout 30 Please note that changing the timeout value at run-time doesn't affect the existing NCSS sessions, excepting the case when the timer is disabled at run-time. This change makes TC_lu_and_ss_session_timeout pass. Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f Related: OS#3655
2019-02-18a_iface: use 'const' qualifier for ran_conn whenever possibleHarald Welte1-1/+1
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-15transaction.h: use #pragma once as include guardVadim Yanitskiy1-4/+1
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
2019-02-15transaction: clarify magic 0xff transaction IDMax1-0/+3
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
2019-02-15transaction: drop meaningless ti_flag of trans_assign_trans_id()Max1-1/+1
According to GSM 04.07, the TI flag takes one bit and can be either of the following: '0'B - transaction is allocated by sender of a message, '1'B - transaction is allocated by receiver of a message. Since we store transaction ID in gsm_trans structure, we also store TI flag (as a part of transaction ID), which in this context means: '0'B - transaction is allocated by us (OsmoMSC), '1'B - transaction is allocated by some MS. In 100% cases, trans_assign_trans_id() is used to assign transaction IDs to transactions allocated by us (i.e. OsmoMSC) for MT connections. And there is no need to use it for MO transactions, because they basically already do contain a valid transaction ID assigned by the MS. Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-13libmsc/gsm_04_80.c: add msc_send_ussd_release_complete_cause()Vadim Yanitskiy1-0/+3
According to GSM 04.80, section 2.5.1, Release complete message may have an optional Cause IE. Let's add a new function, that allows to specify cause location and value. This function will be used by the upcoming changes. Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203 Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13libmsc/gsm_04_80.c: use gsm0480_create_release_complete()Vadim Yanitskiy1-1/+2
The previous implementation of msc_send_ussd_release_complete() was based on gsm0480_create_ussd_release_complete(), that doesn't allow to specify GSM 04.07 transaction identifier. The ability to specify particular transaction identifier is required for handling multiple SS/USSD transactions. Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-04Add SGs InterfaceHarald Welte11-2/+294
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support SMS tunneling and Circuit Switched Fallback (CSFB) Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3615
2019-02-01libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()Vadim Yanitskiy1-2/+0
Initially, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... As soon as we establish RAN connection with subscriber, we already have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also remains 0x00 - it isn't being increased! It means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 again. Moreover, there might be already a MO SMS transaction, and using the conn->next_rp_ref counter wouldn't prevent us from having duplicate SM-RP-MR value. Let's get rid of this per-connection counter, and introduce a function instead, that would iterate over existing transactions and look for an unused SM-RP-MR value. This change makes the following test cases pass: - TC_gsup_mt_sms_rp_mr, - TC_gsup_mo_mt_sms_rp_mr. Discovered by: Neels Hofmeyr Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120 Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01transaction: change arguments of trans_find_by_sm_rp_mr()Vadim Yanitskiy1-1/+2
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-16MNCC: use explicit struct type in gsm_callMax1-1/+1
There's no need to use 'void *' because we have forward declaration for 'struct gsm_network' in the very same header. Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16VLR: send CHECK-IMEI to EIR/HLROliver Smith1-0/+2
When check-imei-req is enabled in the VTY config, do not accept IMEIs sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait for its ACK or NACK. OsmoHLR also accepts all IMEIs at this point, but this allows to optionally store the IMEI in the HLR DB. Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr) Related: OS#3733 Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr1-2/+4
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static buffer in ran_conn_get_conn_id(). So far this function had no callers. Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber is associated yet, update the FSM Id by the MI type seen in the L3 Complete message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update. Call vlr.ops->subscr_update when the TMSI is updated, so that log context includes the TMSI from then on. Enrich context for vlr_subscr_name and ran_conn fi name. Include all available information in vlr_subscr_name(); instead of either IMSI or MSISDN or TMSI, print all of them when present. Instead of a short log, rather have more valuable context. A context info would now look like: Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP) It does get quite long, but ensures easy correlation of any BSSAP / IuCS messages with log output, especially if multiple subscribers are busy at the same time. Print TMSI and TMSInew in uppercase hexadecimal, which is the typical representation in the telecom world. When showing the RAN conn id GERAN_A-00000017 becomes GERAN-A-23 - We usually write the conn_id in decimal. - Leading zeros are clutter and might suggest hexadecimal format. - 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name(). Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore) Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore) Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
2019-01-12add LOG_RAN_CONN() to use the conn->fi->id for contextNeels Hofmeyr2-8/+8
For each conn, set a default logging category, to distinguish categories for BSSMAP and RANAP based conns. LOG_RAN_CONN(): log with the conn's default category, LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping previous DMM logging on the same category). In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and remove the manual context info, now provided by the conn->fi->id. This is loosely related to inter-BSC and inter-MSC handover: to speed up refactoring, I want to avoid the need for manual logging context and just use this LOG_RAN_CONN(). Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy2-0/+10
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-09VLR: vlr_subscr_{,msisdn_or_}name: const vsub argOliver Smith1-2/+2
Make the vsub argument of both vlr_subscr_msisdn_or_name() and vlr_subscr_name() a const. The LOGVSUBP() macro uses vlr_subscr_name() and will not generate a warning anymore when used with a const vsub. Change-Id: If609269191f4df6186d823a2eee14012846328e2
2019-01-04use osmo_rat_type from libosmocoreNeels Hofmeyr2-13/+4
Replace locally defined enum ran_type with libosmocore's new enum osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names. The string representations change, which has cosmetic effects on the test suite expectations. Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore) Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
2019-01-04abort assignment on Assignment FailureNeels Hofmeyr1-0/+1
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx FSM instance, so that the call gets torn down immediately. Before this, the non-call would idle around without anything happening. Related: OS#3236 Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore) Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
2019-01-04move trans->assignment_done to cc.assignment_startedNeels Hofmeyr1-3/+1
The flag is set to true when an assignment has been started, and it is only relevant for a CC transaction. So fix naming and place in cc struct. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
2019-01-04remove code dup: add msc_mgcp_try_call_assignment()Neels Hofmeyr1-0/+1
Various places in the code check a flag whether assignment was started and launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic. To be able to do that only in one place, remove code dup. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL) Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
2019-01-04Constify transaction helpers parametersMax1-5/+5
Change-Id: If002a1ff6ba4218cc16592946798340fcb1852ae
2019-01-04fix vlr ops.subscr_assoc re-associationNeels Hofmeyr1-1/+1
In rare cases, a conn is already associated with a subscriber. So far, we abort()ed on that, bringing the entire osmo-msc down. Rather log an error and keep the service running. In vlr.ops.subscr_assoc, add success/failure return value, and abort the LU/PARQ on error. I haven't figured out in detail yet why/how a subscriber would re-launch a LU/PARQ on a conn that is already associated, so far it is merely clear that we do not want to crash the MSC if that happens. A log is in OS#3742. Related: OS#3742, OS#3743 Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 08:45:10 +0000