aboutsummaryrefslogtreecommitdiffstats
path: root/tests/msc_vlr
AgeCommit message (Collapse)AuthorFilesLines
2020-01-08send the RAT type (GERAN-A / UTRAN-Iu) to HLR on LUNeels Hofmeyr12-69/+69
Use new OSMO_GSUP_RAT_TYPES_IE to transmit the subscriber's RAT type to the HLR. Depends: I3e399ca8a85421f77a9a15e608413d1507722955 (osmo-hlr) Change-Id: I1b0c43c5ab03bc4dd146fdb3f5479b131d4f3b67
2020-01-06add full SDP codec information to the MNCC socketNeels Hofmeyr4-186/+4019
This way osmo-msc can benefit from the complete codec information received via SIP, which was so far terminated at osmo-sip-connector. osmo-sip-connector could/should have translated the received SDP to MNCC bearer_cap, but this was never implemented properly. Since osmo-msc already handles SDP towards the MGW, it makes most sense to pass SDP to osmo-msc transparently. To be able to send a valid RTP IP:port in the SDP upon the first MNCC_SETUP_IND going out, move the CN side CRCX to the very start of establishing a voice call. As a result, first create MGW conns for both RAN and CN before starting. The voice_call_full.msc chart shows the change in message sequence for MO and MT voice calls. Implement cc_sdp.c, which accumulates codec information from various sources (MS, BSS, Assignment, remote call leg) and provides filtering to get the available set of codecs at any point in time. Implement codec_sdp_cc_t9n.c, to translate between SDP and the various libosmo-mgcp-client, CC and BSSMAP representations of codecs: - Speech Version, - Permitted Speech, - Speech Codec Type, - default Payload Type numbers, - enum mgcp_codecs, - FR/HR compatibility - SDP audio codec names, - various AMR configurations. A codec_map lists these relations in one large data record. Various functions provide conversions by traversing this map. Add trans->cc.mnccc_release_sent: so far, avoiding to send an MNCC release during trans_free() was done by setting the callref = 0. But that also skips CC Release. On codec mismatch, we send a specific MNCC error code but still want a normal CC Release: hence send the MNCC message, set mnccc_release_sent = true and do normal CC Release in trans_free(). (A better way to do this would be to adopt the mncc_call FSM from inter-MSC handover also for local voice calls, but that is out of scope for now. I want to try that soon, as time permits.) Change-Id: I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f
2019-12-12gsup: indicate CN-Domain in SendAuthInfo RequestsNeels Hofmeyr21-146/+147
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS, set CN-Domain = CS in all SendAuthInfo Requests. In Milenage auth, it is highly desirable that osmo-hlr guarantees use of distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same time use the same IND bucket to generate Milenage SQN, that collision would rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each CS/PS Complete-Layer3. So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo Request, which was neither required nor evaluated. The CN-Domain is only sent for the UpdateLocation Request that usually follows later. Related: OS#4318 Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
2019-11-28msc_vlr_test_call: rename lu_utran_tmsiNeels Hofmeyr2-16/+16
Change-Id: I46a41321e6d1be3672a56a6e3cc36f013fdcd396
2019-11-28msc_vlr_tests: log descriptions in color with -vNeels Hofmeyr1-1/+4
Change-Id: I2b28a94a5b27932e343952ba82e7e11c46f5e87d
2019-11-28msc_vlr_test_call.c: add MNCC loggingNeels Hofmeyr2-5/+41
Change-Id: I03b25c134553c620d3fa9d23a67ad39414546861
2019-11-28msc_vlr_tests: better err logging for dtap msgsNeels Hofmeyr1-1/+3
Change-Id: I3edd90be40555dd648e9f16db5b6040665a19a95
2019-11-19Fix some typosMartin Hauke2-4/+4
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-05fix msc_vlr_test_call.cNeels Hofmeyr4-22/+432
Substantial parts of the CC / MNCC call establishment were so far completely missing from the msc_vlr_test_call.c tests. With my new insights on CC and MNCC procedures, complete the tests. Root reason: since I am going to re-order the sequence of events to enable codec negotiation via SDP in MNCC, I want to have comprehensive tests of the CC procedures to see the effect as diffs in the test output. Change-Id: Ie995e264eb1e3dd9558a1753ff6f9b55c1d084e1
2019-10-29also log MNCC_SETUP_REQNeels Hofmeyr1-0/+2
If an incoming MNCC_SETUP_REQ ends up in Paging (as usually it does), the early return so far skipped logging of that MNCC message. Add this logging. Change-Id: I1495dd562a06cf6c1e9453a1fe111bdf8f4be081
2019-10-21log which DTAP messages are sent to RANNeels Hofmeyr9-0/+84
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP message, which is in fact a very interesting detail when reading osmo-msc logs. Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
2019-10-21LOG_TRANS for CC: always log CC stateNeels Hofmeyr1-145/+145
For all CC type transaction logging, log the current trans->cc.state string for all LOG_TRANS*() logging. Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-09-03msc_a fsm: ignore state chg to same stateNeels Hofmeyr4-11/+0
We sometimes see errors like libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted! i.e. changing state to the state msc_a is already in. Ignore re-entering the same state for most state changes. However, there is one state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary to start the timeout. Hence add msc_a_state_chg_always() and use that for re-entering MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes. This should silence all no-op state change error messages for msc_a. Related: OS#4169 Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
2019-09-02msc_vlr_tests: GSUP: don't care about extra IEsNeels Hofmeyr1-1/+9
To not break the msc_vlr tests by new GSUP IEs added to some of the GSUP messages, make msc_vlr_tests only match the start of the GSUP message and not care about extra IEs. The extra IEs are anyway seen in the expected logs. The reason to drop the msgb_eq_data_print() is because it is useless for mismatching lengths. It will always print only the length mismatch, instead we need to be able to compare with what was expected. Change-Id: I38d51eeafab04ece83e4bb87bfaa967506f97b11
2019-09-02log, cosmetic: add "RR" to "Ciphering Mode Complete"Neels Hofmeyr1-1/+1
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer BSSMAP Cipher Mode Complete message in the DEBUG log. Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
2019-08-29vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPDNeels Hofmeyr1-1/+0
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr4-48/+12
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-08-05add msc_vlr tests for UMTS without cipheringNeels Hofmeyr2-79/+966
Following I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7, have tests for UMTS authentication both for cases with and without encryption. - Rename test_umts_authen_utran to test_umts_auth_ciph_utran() (uses encryption). - Again add test_umts_authen_utran() not using encryption. - Likewise with test_umts_authen_resync_utran(). Some permutations are still missing, like UMTS AKA on GERAN with encryption enabled; not bothering at the moment. Related: OS#2783 Change-Id: I54227f1f08c38c0bf69b9c48924669c4829b04b9
2019-08-05do not force encryption on UTRANNeels Hofmeyr4-0/+36
Remove the conditions that always enable encryption on UTRAN. We so far lack an explicit configuration for UTRAN encryption, and this patch does not add any either. Instead, whether UTRAN encryption is enabled is simply triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though GERAN and UTRAN encryption are not technically related at all, this makes UTRAN behave like GERAN for now, until we implement a proper separate configuration for UTRAN encryption. Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask such that the expected output remains unchanged. A subsequent patch (I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly cases of UTRAN without encryption. Adjust manual and vty doc. Related: OS#2783 Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
2019-08-02Set coding in mncc_set_cause()Keith Whyte2-2/+2
GSM 04.08 10.5.4.11 The Release indication needs to have the Coding Standard set. For phones that would display a message on screen, such as "Number not in use", if the coding standard is not defined, the display may show "Error in Connection" Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
2019-07-24vlr_lu_fsm.c: don't send LU reject twiceOliver Smith1-2/+0
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting called in the parent "lu" FSM and is therefore redundant: _vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause) -> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0) -> vlr_lu_compl_fsm_dispatch_result() -> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone() -> lu_fsm_failure() -> lfp->vlr->ops.tx_lu_rej() I have noticed the bug with the TTCN3 tests. This patch fixes TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking in [1] and also TC_iu_mo_crcx_ran_reject. [1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks) Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
2019-07-18replace osmo_counter with stat_itemsAlexander Couzens13-118/+120
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-09Fix: add missing semicolons to OSMO_ASSERT statementsVadim Yanitskiy1-1/+1
Change-Id: I4fae5fbab5fdbcce35906601d4f1031d971f4931
2019-06-19tests/msc_vlr: fix: do not pass RAT type to expect_bssap_clear()Vadim Yanitskiy4-11/+11
The function name implies OSMO_RAT_GERAN_A, and it has nothing to do with other OSMO_RAT_* types. Found using clang: warning: too many arguments in call to 'expect_bssap_clear' expect_bssap_clear(OSMO_RAT_GERAN_A); ^^^^^^^^^^^^^^^^ Change-Id: Id3a3af33fcc5da4ca4c48a2f589a69f3568d2586
2019-06-17libmsc/gsm_09_11.c: fix broken reference counting for vsubVadim Yanitskiy1-21/+24
In gsm0911_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 PROC-SS message. Change-Id: I5540556b1c75f6873883e46b78656f31fc1ef186
2019-06-17libmsc/gsm_09_11.c: do not abuse LOG_TRANS() and early trans allocationVadim Yanitskiy1-2/+2
In case of network-originated SS/USSD session establishment, we need to verify the received GSUP PROC_SS_REQ message and make sure that all mandatory IEs are present. There is no sensible need to allocate a new transaction before doing all the checks, other than the ability to use LOG_TRANS(). This complicates the code, so let's avoid the early allocation. Change-Id: I4e027b19e8065a39324a1647957cef4066b82ce7
2019-06-15libmsc/gsm_09_11.c: fix: return trans from establish_nc_ss_trans()Vadim Yanitskiy1-1/+1
It is expected that establish_nc_ss_trans() returns an allocated transaction in successful case, or NULL in case of error. The function assumes two scenarios: - the subscriber already has an active RAN connection, - RAN connection needs to be established (Paging). In the first case, a pointer to the transaction is returned as expected, but in case of Paging, NULL has always been returned, even if there were no errors. Let's fix this. Change-Id: I9dcee64dd0b435ef29630c223132b81724701f93
2019-06-03tests: share stubs.h from msc_vlr_test as stubs.cVadim Yanitskiy14-53/+14
We also need stubs for the upcoming db_sms tests. Due to a known bug of automake [1], we cannot use 'subdir-objects', so as a side effect this change introduces some autoreconf warnings. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 Change-Id: I8846c940f2695fd33e1007fecac83e73f508bb34
2019-05-15vlr: optionally send IMEI early to HLROliver Smith13-164/+150
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to the HLR before doing the location update with the HLR. The OsmoHLR documentation referenced in the code will be added in osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9. Related: OS#2542 Change-Id: I88283cad23793b475445d814ff49db534cb41244
2019-05-15vlr: when setting IMEISV, also set IMEIOliver Smith2-0/+6
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will get cut off then. This is needed for the subscriber on demand use case, since we can get the IMEISV early (see [1]), but need to send the IMEI to the Check IMEI procedure. While adjusting the tests, I have noticed that there are code paths where we ask the MS for the IMEISV first, and later ask the MS for the IMEI, although we already have the IMEISV. This could be improved in a future patch. [1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f Related: OS#2542 Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
2019-05-15vlr: fix IMEI lengthOliver Smith6-50/+46
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-13tests/.../Makefile.am avoid redundant linkage with librtVadim Yanitskiy1-1/+0
The librt is required for old glibc < 2.17 to get clock_gettime(). Since we do check the availability of this function libosmocore and conditionally link it against librt, there is no need to do such unconditional and redundant linkage here. Change-Id: If587d16d2db677b97e3a0641027eb735af9c9c30
2019-05-12add DSS logging categoryNeels Hofmeyr2-9/+14
Change-Id: Id7e04c9f5088334cd5ec6cfdb6a9b3a2a7e7fda0
2019-05-12libmsc/gsm_04_11.c: fix double init of both SMR and SMC FSMsVadim Yanitskiy6-36/+0
Change-Id: I23700a2c575a96057ef22bc5d8ab6271104d619b
2019-05-10LOG_TRANS: store subsys in trans, unify USSD logging back to DMMNeels Hofmeyr1-8/+8
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-09fix regression: fix internal MNCC operationNeels Hofmeyr2-2/+2
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 Hofmeyr27-15485/+19609
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 Hofmeyr8-365/+385
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr23-2101/+2104
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-12enable osmo_fsm_term_safely(), apply logging changesNeels Hofmeyr13-1140/+625
Start using osmo_fsm_term_safely(true), the recently added feature of libosmocore's fsm.c. Deallocates in slightly changed order and with slightly modified logging. Adjust test expectations. Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore) Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
2019-02-18a_iface: Fix hexdumping of N-DATA.reqHarald Welte2-4/+4
For some reason the existing code was using msgb_hexdump_l2() while the L2 header is not used by the BSSAP transmit code. Let's fix this. Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
2019-02-18a_iface: Centralize/wrap BSSAP / N-DATA transmissionHarald Welte3-0/+12
We don't want multiple callers to osmo_sccp_tx_data_msg() each having to hex-dump a log message about the to-be-transmitted message, with half of the caller sitest missing that printing. Let's centralize all calls of osmo_sccp_tx_data_msg() in a wrapper function which takes care of the related OSMO_ASSERT() and the related printing. Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-05VLR tests: use msgb_eq_data_print() for comparisonMax1-11/+12
This simplifies tests refactoring by showing exact byte where mismatch happened. It also makes code more readable. No changes in expected test output are necessary because the additional logging will be triggered iff the test fails so the result will be visible only during debugging of unit test issues. Change-Id: If9771c973f2bc55580f4c146bdbeeb1609d56786
2019-02-04Add SGs InterfaceHarald Welte14-0/+53
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-01-16Enable SMS-related log in VLR testsMax7-1/+589
The likely reason why it was disabled is due to paging_cb_mmsms_est_req() logging pointers which results in unstable log output. Fixing this allows us to track SMS-related regressions properly. Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-16VLR: send CHECK-IMEI to EIR/HLROliver Smith6-56/+853
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-12msc_vlr_tests: tweak logging in verbose modeNeels Hofmeyr1-2/+7
Change-Id: Ia06245f3adc6cf4c483d9c12c387cd5169582353
2019-01-12mm_rx_id_resp(): use osmo_mi_name()Neels Hofmeyr4-14/+14
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr12-11351/+11648
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-12rx CM Service Req: reject double use soonerNeels Hofmeyr1-2/+1
When a CM Service Req is being rejected, we should do so before changing the state of the current conn. Concerning multiple CM Service Requests: in fact we should store multiple requests, but first fix the status quo of rejecting multiple requests. Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-23 16:31:21 +0000