aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2020-01-08Fix duplicate SMS when SMPP returns to same MSCNeels Hofmeyr1-0/+1
Change-Id: I8c9b61dc05bda6f2b09cbc1890de1f2702f7abc8
2020-01-06add full SDP codec information to the MNCC socketNeels Hofmeyr10-8/+135
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
2020-01-05libmsc/gsm_04_08.c: fix: verify MI before calling vlr_subscr_rx_id_resp()Vadim Yanitskiy1-0/+3
During the last congress, we have noticed that OsmoMSC crashes on receipt of malformed MM Identity Response messages: BSSAP Message Type: Direct Transfer (0x01) Data Link Connection Identifier 00.. .... = Control Channel: not further specified (0x0) ..00 0... = Spare: 0x0 .... .000 = SAPI: RR/MM/CC (0x0) Length: 11 GSM A-I/F DTAP - Identity Response Protocol Discriminator: Mobility Management messages (5) .... 0101 = Protocol discriminator: Mobility Management messages (0x5) 0000 .... = Skip Indicator: No indication of selected PLMN (0) 01.. .... = Sequence number: 1 ..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19) Mobile Identity - Format Unknown Length: 8 .... 1... = Odd/even indication: Odd number of identity digits .... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash [Expert Info (Warning/Protocol): Unknown format 7] [Unknown format 7] [Severity level: Warning] [Group: Protocol] The value '111'B is not a valid Mobile Identity type, and shall be considered as reserved according to 3GPP TS 24.008, section 10.5.1.4. Later on it was discovered that '000'B also crashes OsmoMSC in the same way. The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp(). Let's keep that assert in there, and make sure that: - on receipt of MM Identity Response, Mobile Identity type matches the one in MM Identity Request; - on receipt of RR Ciphering Mode Complete, Mobile Identity contains IMEI(SV) if present. Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825 TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743 Fixes: OS#4340
2019-12-02counters: polish documentation of cm_service_request / paging_respVadim Yanitskiy1-4/+4
Change-Id: I273bc4165c70cd54ed94ff5f99377189f3306f51
2019-12-02counters: clarify documentation for MSC_CTR_CALL_* entriesVadim Yanitskiy1-7/+7
Change-Id: Iad1ef917a229c3be51bd8fbe155f009f81e7d72a
2019-12-02counters: clarify documentation for MSC_CTR_LOC_UPDATE_* entriesVadim Yanitskiy1-6/+6
Change-Id: I4f4a0d644db0a2dd7c8eefd846ea6913c0b780ce
2019-12-02counters: clarify documentation for MSC_CTR_SMS_* entriesVadim Yanitskiy1-7/+8
Please note that counter "sms:delivered" assumes "Delivered MT SMS", but actually counts total number MT SMS delivery attempts. This change describes its _actual_ (erroneous) behaviour. Change-Id: I081cf962ce2658ceab02699f3cdee19658d00939 Related: OS#4273
2019-11-28MNCC v6: add optional SDP to the socket protocolNeels Hofmeyr1-1/+6
Add a char buffer of 1024 characters length as space for SDP to pass to / receive from MNCC. Actually support receiving MNCC without such an SDP tail. The main reason for this is to avoid the need to adjust the ttcn3 implementation of MNCC: it would stop working for older osmo-msc. Older or non-SIP MNCC peers could operate the previous MNCC protocol unchanged (save the protocol number bump) without having to implement SDP. The SDP part in the MNCC protocol will be used in upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f. This patch must be merged at the same time as osmo-sip-connector patch Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925, so that both sides have a matching MNCC protocol version number. Change-Id: Ie16f0804c4d99760cd4a0c544d0889b6313eebb7
2019-11-28add sdp_msg API: SDP parsing/compositionNeels Hofmeyr2-0/+69
Rationale: in order to add full SDP to the MNCC protocol (upcoming patch I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f), we need to parse and compose SDP messages. Obviously, libosmo-mgcp-client already contains similar code, but that is unfortunately heavily glued to the actual MGCP implementation. The simplest solution is to create this separate implementation, copy-pasting from the existing libosmo-mgcp-client code as is convenient. This API is added here to probe whether it works well. When it does, the intention is to "move it up" to osmo-mgw and overhaul the SDP parsing in our MGCP client and MGCP server APIs using this same API. Change-Id: If3ce23cd5bab15e2ab4c52ef3e4c75979dffe931
2019-11-19Fix some typosMartin Hauke5-8/+8
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-05BSSMAP: decode Codec List (BSS Supported)Neels Hofmeyr1-0/+2
Actually decode the Codec List (BSS Supported) in BSSMAP, in both the Complete Layer 3 Information and the Assignment Complete messages. An upcoming patch improves codec negotiation and requires the BSS supported codecs, which are so far ignored (which is/was a pity as osmo-bsc goes at great lengths to compose those IEs). Change-Id: I66c735c79e982388f06b5de783aa584c9d13569e
2019-11-05cc trans: remove unused tch_rtp_createNeels Hofmeyr1-4/+0
Use of this flag was dropped when adding inter-BSC and inter-MSC Handover support, I forgot to remove it. Change-Id: I5ec78e30eb36fbe78a3f7c46bfa44af5a4eb7bf2
2019-10-29send MNCC REL only if MNCC has actually startedNeels Hofmeyr1-0/+1
Change-Id: I07b2b6c0ee33f5d3e0a060c10cf36d5c7c9f0d9b
2019-10-21LOG_TRANS for CC: always log CC stateNeels Hofmeyr1-1/+3
For all CC type transaction logging, log the current trans->cc.state string for all LOG_TRANS*() logging. Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
2019-10-17make vlr_gmm_cause_to_mm_cause publicAlexander Couzens1-0/+3
To be used by vlr_auth_fsm Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
2019-09-26paging: Send SGsAP-SERVICE-ABORT-REQUEST on paging timeoutPhilipp Maier1-0/+1
When pagig for a CS-Call via SGs times out, the MME expects to be informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this message is sent, but only for CS-Fallback calls. Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877 Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a Related: OS#3614
2019-09-18fix error on BSSMAP Cipher Mode Complete L3 msg IENeels Hofmeyr1-0/+1
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second time, but instead point to it from the ran_msg.cipher_mode_complete struct. When the MSC-A decodes the Ciphering Mode Complete message, it always wants to also decode the enclosed DTAP from the Layer 3 Message Contents IE. However, when the MSC-I preliminarily decodes messages, it often just wants to identify specific messages without fully acting on them, let alone dispatching RAN_UP_L2 events more than once. So leave it up to the supplied decode_cb passed to ran_dec_l2() implementations to decide whether to decode the DTAP. In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher Mode Complete's Layer 3 Message Contents IE. Particularly, the previous choice of calling the decode_cb a second time for the enclosed DTAP caused a header/length parsing error: the second decode_cb call tried to mimick DTAP by overwriting the l3h pointer and truncating the length of the msgb, but subsequently ran_a_decode_l2() would again derive the l3h from the l2h, obliterating the intended re-interpretation as DTAP, and hence the previous truncation caused error messages on each and every Cipher Mode Complete message, like: DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message This error was seen a lot at CCCamp2019. Modifying the msgb was a bad idea to begin with, the approach taken in this patch is much cleaner. Note that apparently many phones include the IMEISV in the Cipher Mode Complete message even though the BSSMAP Cipher Mode Command did not include the Cipher Response Mode IE. So, even though we did not specifically ask for the Cipher Mode Complete to include any identity, many MS default to including the IMEISV of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using a Samsung Galaxy S4mini. Related: OS#4168 Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
2019-09-03Implement a global switch on the network to disable call waiting.Keith Whyte1-0/+3
Add a network -> callwaiting VTY command as boolean. When this is enabled (default) there is no change to operation previous to this commit. When this switch is disabled with "no call-waiting" in vty then when a call arrives, we will check if we have an active call transaction for this subscriber, no matter if it is establishing, established, or alerting, in any of these cases we will return USER BUSY to the calling party. Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-09-02cosmetic: fix call_leg_ensure_ci() decl. arg name to match impl.Neels Hofmeyr1-1/+1
Change-Id: I576bc5c1fd63fe8048a7a6a2d06763fc3221fa49
2019-08-28mncc: 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 11:48:14 +0000