aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2019-01-05use mgcp-client configured endpoint domain nameneels/mgw_domainNeels Hofmeyr1-7/+6
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and osmo-msc address their MGW with differing domain names. Otherwise, both will have a '0@mgw' endpoint and it gets really confusing. After this, with according configuration, there can be a '0@bsc' and a '0@msc' endpoint. osmo-mgw-for-msc.cfg: mgcp domain msc osmo-msc.cfg: msc mgw endpoint-domain msc Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw) Change-Id: I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
2019-01-04use osmo_rat_type from libosmocoreNeels Hofmeyr10-42/+35
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-04vty cfg: move 'ipa-name' from 'msc' to 'hlr' sectionNeels Hofmeyr1-22/+21
during code review, I completely overlooked this: We've added the 'ipa-name', which identifies the MSC on the GSUP link to the HLR, under the 'msc' section, while all other GSUP/HLR related config is under the 'hlr' section. Before we roll that out in a release, move it over to 'hlr'. Related: OS#3355 Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
2019-01-04abort assignment on Assignment FailureNeels Hofmeyr2-1/+23
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-04fix: incoming call during ongoing callNeels Hofmeyr1-0/+31
If a call is already busy and another call is coming in, do not try to immediately assign an lchan (before this patch, it fails because there already is an mgcp_ctx for the conn). Leave the second CC transaction waiting. When a call is hung up, as soon as the old mgcp_ctx is discarded, look for other CC transactions that are waiting. If there is one, trigger assignment, so a new mgcp_ctx is set up for the new call. This fixes the following scenario: - from A, call B. - from C, call B; B rings during ongoing call. - in B, pick up the call, choose to drop the old call. After this patch, and with osmo-bsc patch with change-id I0c00ec2c120e5008281755adcd4944a3ce4d8355 we are now able to talk to the new caller. I currently haven't tested yet what happens if there is *three* peers trying to talk to the same number, running out of lab phones (not really, just not bothering now). Possibly we should be taking over the particular call indicated by the CC TI; instead, the current patch version takes on whichever waiting call it finds first. This is fine if *one* additional call comes in on an ongoing call, and this is already a huge improvement to what we had before. Related: OS#3735 Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
2019-01-04move trans->assignment_done to cc.assignment_startedNeels Hofmeyr1-3/+3
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 Hofmeyr2-23/+19
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-2/+13
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
2019-01-03release RTP stream only for matching CC transactionNeels Hofmeyr1-0/+6
Do not break the currently ongoing call when rejecting a second incoming caller. There may be multiple (up to seven) simultaneous CC transactions, and there is one mgcp_ctx for the currently active RTP stream. Release the MGCP context only when the active CC transaction is releasing. Before this patch, any CC transaction release would destroy the single MGCP context, possibly breaking the currently ongoing call (another CC trans). This also fixes a possible use-after-free if there were pending MGCP message responses for the MGCP context; they are canceled properly for a released transaction, but since one transaction would free the other transaction's MGCP state, the clean up did not take place and possibly caused an mgcp client response handling to access a freed mgcp_ctx. Related: OS#3735 Change-Id: I1f8746e7babfcd3028a4d2c0ba260c608c686c76
2019-01-03cosmetics in msc_mgcp_call_release()Neels Hofmeyr1-8/+8
Use local variables instead of writing trans->conn-> all the time. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Change-Id: I99717b3b72a9d7cbc95455ea25b2018ec1755308
2018-12-30libmsc/gsm_04_11.c: forward MO SMS messages over GSUPVadim Yanitskiy4-2/+233
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
2018-12-30libmsc/VTY: introduce kill-switch for routing SMS over GSUPVadim Yanitskiy1-0/+23
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS processing, storage (in SQLite DB), and routing (via SMPP). In real networks this is done by the external entity called SMSC (SMS Centre), while the MSC is doing re-encapsulation of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU) between SM-RL (Relay Layer) and MAP. Since OsmoMSC itself is not a 'Network in The Box' anymore, it makes sense to replicate the 'traditional' behaviour of MSC. The problem is that this behaviour cannot co-exist with the current implementation, so the key idea is to rip out the local SMS storage and routing from OsmoMSC, and (re)implement it in a separate process (OsmoSMSC?). As a temporary solution, this change introduces a 'kill-switch' VTY option that enables routing of SMS messages over GSUP towards ESME (through VLR and HLR), but breaks the local storage and routing. This is why it's disabled by default. As soon as we move the SMS processing and storage away from OsmoMSC, this behaviour would be enabled by default, and the VTY option would be hidden and deprecated. At the moment, this option basically does nothing, and will take an effect in the follow-up changes. Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b Related: OS#3587
2018-12-23MNCC: use log wrapper for call processingMax1-13/+12
Add log/debug wrappers to conveniently print local and remote call references. Change-Id: I5c44d7bb28f1ff895dd4f839d75840495503c916
2018-12-21use vty->type instead of local variableStefan Sperling1-1/+1
We can check if we're parsing the config file by checking whether vty->type equals VTY_FILE. This avoids the use of an extra local variable to track the parsing state. Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75 Fixes: 1051c4208834c22d344dd92d25addfd8e5d95993 Related: OS#3355
2018-12-19mgcp log tweak: say RAN, not BTS, like surrounding loggingNeels Hofmeyr1-1/+1
Change-Id: Ibb40155189a7f05ba2da4fcf9cf03fda5ffc3683
2018-12-19fix msc_mgcp_fsm_evt_names: two missing eventsNeels Hofmeyr1-0/+2
Change-Id: I66ebaf0a55de1a46bccbc86652ffa9b73c951ebf
2018-12-19msc_vty: also show IMEI and IMEISVPhilipp Maier1-0/+4
When the VLR subscriber information is shown on the VTY it shows IMSI and TMSI, but not IMEI and IMEISV. Since in some cases this information might be helpful, lets display it as well. Change-Id: Iedd75dbb9850388ec1fedb984ed0b8bf4c62e780
2018-12-19Remove redundancy in LAC processingMax4-6/+6
Always use LAC which is part of Cell Global ID otherwise we might end up in a situation where separately stored LAC differs. Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part of LAI which is part of CGI so there should be no case when those values differ for a given subscriber. Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
2018-12-19msc_vty: display current RAN typePhilipp Maier1-0/+2
When a subscriber is displayed the RAN type is not included in the overview. Meanwhile the MSC supports multiple different ran types it becomes important to see in which RAN the subscriber is currently active. Change-Id: I000cafd5e41b9951d51b6bd6672ee68a224b8212 Related: OS#3615
2018-12-19msc_vty: display subscriber flagsPhilipp Maier1-0/+19
When a VLR subscriber is displayed on the VTY we get a lot of meta information, but there are also some flags to handle the internal subscriber status e.g. conf_by_radio_contact_ind. Lets display those flags as well as this information can be very helpful when debugging problems in the VLR Change-Id: I59a9145a4daad50d68de3fd5c3291f027256917f
2018-12-18vty: show subscriber: put() before printing the use countNeels Hofmeyr1-2/+5
Do not show the VTY command's own use count during 'show subscriber <ID>'. When using 'show subscriber msisdn 2023', I was surprised to see a use count of 2 and suspected a use count leak. With 'show subscriber cache' however, the use count is 1. So I realized it is the vty command's own use count that makes it two, besides the lu_complete=true one. Change-Id: Id02b57b7ed299b010b9f8b9e809548eb1e6aa699
2018-12-18Use proper type for tch_rtp_connect() parameterMax1-2/+1
Change-Id: I6e2efcd2e25d6ec2ff35a4b8cfcda02abe97fa59
2018-12-17CC: log more details about unhandled message/stateMax1-1/+1
Change-Id: I8e0febd04f7338aed7222dcfcd9bfddc7b8fda59
2018-12-17cosmetic: drop unused variableMax1-2/+1
Change-Id: Iff358eb2328cdd052e66b572aeec1b767174949b
2018-12-17cosmetic: drop duplicated #includeMax1-1/+0
Change-Id: I216425ba5994a49981d51bce6cfa7c3fa5fe9e40
2018-12-13require 'ipa-name' option to be set via config fileStefan Sperling1-0/+6
The 'ipa-name' option can now only be set via the configuration file because changing the IPA name at run-time conflicts with active GSUP connections and routes configured in the HLR. The osmo-msc program must be restarted if its IPA name needs to change. Change-Id: I6cff91793e646e0396e8f1bc87d0f52709e5f12a Related: OS#3355
2018-12-11Revert "move ASS-COMPL MGCP handling out of a_iface_bssap.c"Neels Hofmeyr3-78/+86
Two reasons: - the caller of msc_mgcp_ass_complete() from Iu, iucs_rx_rab_assign(), failed to be adjusted, breaking IuCS, as an --enable-iu --enable-werror build shows. Unfortunately our gerrit verification doesn't --enable-werror for osmo-msc. - the condition of requiring ST_MDCX_RAN is faulty, breaking GSM CS. This reverts commit 212c0c9bdaf1166e3bcbab85f3ab31dc17162f5b. Change-Id: I8348675c2f7c8856ea1682d05ee54160d4cfeb96
2018-12-11provide software version information to gsup peerStefan Sperling1-0/+1
Provide software version information to the GSUP peer. The version now shows up in logs like this: Software_Version='osmo-msc-1.2.0.120-1263b' Change-Id: I2eba32569349facdbb1fda201067c62cc804ccf4 Depends: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006 Related: OS#3355
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling2-2/+24
Add a 'ipa-name' VTY command which overrides the default IPA name used by the MSC. This is a prerequisite for inter-MSC handover. Related: OS#3355 Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
2018-12-10drop gsm48 RR ciph mode compl from permitted initial messagesNeels Hofmeyr1-1/+2
It is a message that is initially permitted, but it is in fact not handled in the L3 code but already before, upon receiving BSS_MAP_MSG_CIPHER_MODE_COMPLETE. Change-Id: I0079f07271ca76bd457d0e700f3a736eb9066b47
2018-12-10move ASS-COMPL MGCP handling out of a_iface_bssap.cNeels Hofmeyr3-86/+78
BSSMAP Assignment Complete: sort MGCP handling upon Assignment Complete to the proper locations. a_iface_bssap.c is not the right place to invoke the MGCP related procedures. - in a_iface_bssap.c only decode the IEs. - call ran_conn_assign_compl() and pass decoded values. - drop msc_assign_compl(), it was dead code; instead: - add ran_conn_assign_compl() - pass on all MGCP related info to msc_mgcp_ass_complete() - move all MGCP ctx related handling from a_iface_bssap.c to msc_mgcp.c. I'm dropping some comments to save some time, because if I adjust them IMHO they would still anyway restate the obvious. ran_conn_assign_compl() is now quite a thin shim, but it makes sense to have it: - This is the place that should tear down the ran_conn in case assignment failed, left for a future patch. - In the light of upcoming inter-MSC handover, ran_conn_assign_compl() will be the place where the Assignment Complete message might be relayed to a remote MSC. Change-Id: I8137215c443239bddf3e69b5715839a365b73b6c
2018-12-07ASS-COMPL: do not fire Sec Mode Compl eventNeels Hofmeyr1-4/+0
BSSMAP Assignment Complete: Do not invoke ran_conn_rx_sec_mode_compl(), that's just weird. Instead this should call msc_assign_compl(), which is currently dead code and does nothing ... and there are some more strings attached, being resolved in a subsequent patch. Change-Id: I448fdb783364628005437b3d866d1a076a9767d7
2018-12-05add VTY commands: mncc internal / external (== -M)Neels Hofmeyr2-0/+30
So far the only way to use external MNCC is to pass the -M cmdline arg: osmo-msc -M /path/to/socket However, the osmo-msc.service file for systemd is installed by 'make install', and hence it is quite impractical to depend on such a config item to be required in the service file: - It defies any scheme an operator may have in place to compose the osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs separate action to add to the installed service file. - After a make install or package upgrades / re-installations, this option will be plain overwritten silently, or lead to the need for resolving file conflicts. The initial spark for this came from configuring the 35c3 GSM from cfg templates. Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
2018-12-05vty: mncc cfg: separate the 'mncc' from 'mncc-guard-timeout'Neels Hofmeyr1-4/+14
I want to add 'mncc internal' and 'mncc external' commands, and IMHO makes most sense to have a common 'mncc' keyword to start MNCC config commands with. To put it in terms of VTY online help: OsmoMSC(config-msc)# mncc ? internal Use internal MNCC handler external Use internal MNCC handler guard-timeout Set global guard timeout So far only the 'guard-timeout' exists, I want to add 'internal' and 'external' in a subsequent commit. Keep the old command 'mncc-guard-timeout' as deprecated alias. That means it still works from old config files, but online documentation will omit it. On 'write', write back the new format instead. Rationale: see I2ec59d5eba407f83295528b51b93678d446b9cee Change-Id: I52d69af48e1ddc87b3fb54bf66a01b1b8cbf5abe
2018-12-05gsm_subscriber: make function msc_paging_request() staticPhilipp Maier1-1/+1
The function msc_paging_request() is only called from within gsm_subscriber.c but never from outside. Lets make it static. Change-Id: I2efc8eac01a4dd8733118067eecf566c13062106
2018-11-30GSM_EXTENSION_LENGTH -> VLR_MSISDN_LENGTHNeels Hofmeyr1-1/+1
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH -> VLR_NAME_LENGTH. Adjust some sms_queue stuff that anyway includes vlr.h already. Drop gsm_subscriber.h from vlr.h. Add other (more concise) includes that thus become necessary, since the include chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place. Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr2-4/+4
Along goes GSM_KEYSEQ_INVAL as VLR_*. It's where it logically belongs, and is almost the only reason why vlr.h includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved by upcoming patch. Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
2018-11-30cosmetic: drop some unused opaque struct defsNeels Hofmeyr1-1/+0
Change-Id: I4d461dd39d0abdc4f2327445671459340ca1c946
2018-11-30combine several small .h in msc_common.hNeels Hofmeyr14-14/+1
For hysterical raisins, there are some header files that contain few declarations, and where the name doesn't reflect the content. Combine them to new msc_common.h: - common.h - common_cs.h - osmo_msc.h Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
2018-11-30move ran_conn declarations to new ran_conn.hNeels Hofmeyr2-1/+2
With the dawn of inter-BSC,MSC handover, adopting the MSC-A,-I,-T roles from 3GPP TS 49.008, the RAN connection shall soon be a neatly separated corner of osmo-msc, so gravitate ran_conn decarations to files of matching name. Also, the current chaos of API defined in files with mismatching/meaningless names drives me crazy. Change-Id: Ice31e6c43e46678538c65261f150c67e1d0845e5
2018-11-30move subscr_conn.c to ran_conn.cNeels Hofmeyr2-1/+1
subscr_conn.c exclusively defines ran_conn related things. Rename the file. Change-Id: I6aa6b335842116c717a554c981083a914724ee21
2018-11-30rename some RAN conn related stuff to ran_conn_*Neels Hofmeyr12-77/+74
Following previous rename of gsm_subscriber_connection: Some functions and #defines are still called like "msc_conn" or just "msc_", while they are clearly about a RAN conn. To avoid confusion with the future separate concepts of MSC roles and a RAN connection, rename all those to match the common "ran_conn" prefix. Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
2018-11-30rename gsm_subscriber_connection to ran_connNeels Hofmeyr21-450/+448
In preparation for inter-BSC and inter-MSC handover, we need to separate the subscriber management logic from the actual RAN connections. What better time to finally rename gsm_subscriber_connection. * Name choice: In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it "bss_conn": in 3G a BSS is called RNS, IIUC. The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network. * Rationale: A subscriber in the MSC so far has only one RAN connection, but e.g. for inter-BSC handover, a second one needs to be created to handover to. Most of the items in the former gsm_subscriber_connection are actually related to the RAN, with only a few MM and RTP related items. So, as a first step, just rename it to ran_conn, to cosmetically prepare for moving the not strictly RAN related items away later. Also: - Rename some functions from msc_subscr_conn_* to ran_conn_* - Rename "Subscr_Conn" FSM instance name to "RAN_conn" - Rename SUBSCR_CONN_* to RAN_CONN_* Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-30drop msc_compl_l3() return valueNeels Hofmeyr3-44/+9
msc_compl_l3() always returns MSC_CONN_ACCEPT, because the conn FSM handles (or should handle) all reject cases. The accept/reject return value is a legacy from libbsc internally passing a conn over to libmsc, in osmo-nitb. Drop enum msc_compl_l3_rc. Change msc_compl_l3_rc() to return void. Change all callers to always act like for acceptance, as they always did anyway. Drop some local variables now no longer needed. Adjust the comment to msc_compl_l3(). Drop a bunch of #if-0'd code from msc_compl_l3(). Change-Id: I759d15f4e820d5fc16397ed7210ce92308e52a09
2018-11-30rename gsm_encr to geran_encr, it is only applicable on GERANNeels Hofmeyr3-7/+7
On UTRAN, Security Mode is used instead of Ciphering Command, which does not feature an A5 algorithm id. Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
2018-11-30populate gsm_subscriber_connection->encr during CiphNeels Hofmeyr2-0/+9
The gsm_subscriber_connection->encr is never used. Use it. When sending the Ciphering Mode Command, populate the encryption key. When receivint the Ciphering Mode Complete, populate the chosen alg_id. Out of paranoia, store the enc key only if the size is large enough. Hence the vty_dump_one_conn() now reports the actually chosen A5 algorithm ID used. For 3G connections, though, this will still remain 0 in the VTY, since there is no explicit A5 algorithm negotiated on UTRAN. (Security Mode Command and Security Mode Complete instead of the GERAN Ciphering.) (Note, 'struct gsm_encr encr' will be renamed to 'struct geran_encr geran_encr' in Idc7ca9da1aa13ae16f5db2cb1024676cbc770820) Change-Id: Ice2c470c360612249f97301944c6fdf9443c7dce
2018-11-30adjust copyright in subscr_conn.cNeels Hofmeyr1-1/+1
Change-Id: Ia89e2d343a850234557e365457705a11d26fd925
2018-11-30cosmetic: subscr_conn_fsm_auth_ciph() should be staticNeels Hofmeyr1-1/+1
Only used in subscr_conn.c. Change-Id: Iaa2c63d2b06f59d34e0465c40a98741f56ec526a
2018-11-30drop unused SUBSCR_CONN_E_INVALIDNeels Hofmeyr1-1/+0
The idea to catch uninitialized vars was completely moot. We pass events by constants anyway. Change-Id: I6f3c964ee04fec9a96f385199fb3141ac8d672d4
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 14:24:31 +0000