aboutsummaryrefslogtreecommitdiffstats
path: root/doc
AgeCommit message (Collapse)AuthorFilesLines
2020-04-14doc: do not use random ip-address for MGWPhilipp Maier3-3/+3
The example configs suggest to use a random ip-address as MGW address. Lets use a loopback address here. This will suit the usual case where MGW and MSC run together on the same machine. Change-Id: Ie2b2094fdcfed45353d9ba22cb07eed626fd143c
2020-03-18manual: add missing mention of MGCP in "Multiple instances"Neels Hofmeyr1-0/+1
Change-Id: I91d06921e4dca08428bf45fc1a3fd6e124599371
2020-01-25libmsc: move subscriber expiration timer T3212 to libvlrVadim Yanitskiy1-16/+0
Since the split of OsmoNiTB, OsmoMSC does not deal with the radio access network directly. Therefore the only purpose of T3212 is to control subscriber expiration in the local VLR. The timeout value indicated in System Information Type 3 needs to be configured separately in the BSC/RNC. This means that we don't need to store it in deci-hours anymore. Let's move T3212 to the group of VLR specific timers, so it can be configured and introspected using the generic 'timer' command, and deprecate the old '[no] periodic location update' command. It should be also noted that in the old code subscriber expiration timeout was actually set to twice the T3212 value plus one minute. After this change, we apply the configured value 'as-is', but keep the old behaviour for 'periodic location update' command. Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
2020-01-25libvlr: use generic osmo_tdef API for T3250, T3260, and T3270Vadim Yanitskiy1-3/+6
These timers so far were implemented as a list of unsigned integers, which has never been initialized to any reasonable defaults. Since they are used as state timeouts in several FSMs, we might end up staying in some state forever. Let's migrate to generic osmo_tdef API and use default values from table 11.2 of 3GPP TS 24.008. This way the user can introspect and change their values from the VTY / configuration file. Change-Id: Ia8cf98da0aea0e626c5ff088a833d7359c43847f Related: OS#4368
2020-01-25VTY: add osmo_tdef introspection and configuration commandsVadim Yanitskiy1-0/+40
This change introduces several new VTY commands letting the user a possibility to introspect and reconfigure some of the existing timers implemented using libosmocore's osmo_tdef API. At the moment this covers the following timers: - MGW specific timers: - X1 - MGCP response timeout, - X2 - RTP stream establishing timeout, - RAN specific timers (same names for GERAN and UTRAN): - X1 - Authentication and Ciphering timeout, - X2 - RAN connection release sanity timeout, - X3 - Handover procedure timeout. The following commands are introduced: - 'enable' node: - show timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] - 'config-msc' node: - timer [(mgw|mncc|sccp|geran|utran|sgs)] [TNNNN] [(<0-2147483647>|default)] Both MNCC and SCCP related timer definitions are empty at the moment. Achieved by using osmo_tdef_group API of libosmovty. Change-Id: I6024c104b6101666c8aa1108a043910eb75db9a5 Related: OS#4368
2020-01-25VTY: mark 'subscriber create imsi' command as deprecatedVadim Yanitskiy1-16/+0
Neither it should appear in the interactive VTY nor in documentation. Change-Id: I208faab69a40948af5d081edbeaf75f586dfb2e4
2020-01-18manuals/vty: update the VTY reference to reflect recent changesVadim Yanitskiy1-37/+439
Change-Id: I14a5c9adff649406b4a079a75f86167ae6b95db4
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-6/+6
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-12-01manual: Fix copy+paste errorHarald Welte1-1/+1
Change-Id: I2c03d8424c218155dae9038dd7cc5660a290c5c8
2019-11-19Fix some typosMartin Hauke3-3/+3
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-01charts: add full MO and MT voice call diagramNeels Hofmeyr2-1/+126
Add voice_call_full.msc, generated from a real 2G<->3G voice call log fed to msc_log_to_ladder.py. The idea is to document how the voice call sequence of events changes in upcoming patches. Change-Id: I8a907d6a4ece1f3ad78da75a8c3e3e76afd5418d
2019-11-01add msc_log_to_ladder.pyNeels Hofmeyr1-0/+724
Add script that reads in an osmo-msc log output and extracts the interesting information for displaying a sequence chart of voice call log, in mscgen format. I want to visualize how the sequence of messages changes across patches. It is error prone to do it manually, and re-doing the sequence chart for every patch (and patch rework) would be prohibitively time consuming. Change-Id: I2e4d8778f7b83dee558517a9b23450b817ee325d
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr1-6/+17
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-05doc/sequence_charts: fix naming of mncc_fsm to mncc_callNeels Hofmeyr2-14/+14
mncc_fsm.[hc] were renamed to mncc_call.[hc] during patch review, which failed to carry through to this sequence chart. Also fix the MNCC_ST_* to MNCC_CALL_ST_* and MNCC_EV_* to MNCC_CALL_EV_*. Change-Id: I03ee1b43ab95dca3c43fdb9e92dc158aad5a4203
2019-08-05doc/sequence_charts/mncc_fsm.msc: add SIP messages, tweakNeels Hofmeyr1-35/+55
- add SIP messages, taken from OS#1683 - change some wording and clarify some message ordering - have a separate sipcon1 and sipcon2 for the MO and MT sides Change-Id: I6782e416dbd8ee88d093cbef722b0c5084f3865c
2019-08-05do not force encryption on UTRANNeels Hofmeyr1-1/+5
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-05manual: adjust and fix auth and ciph docsNeels Hofmeyr1-14/+54
Change-Id: Iffe159d4c0e0e9439f8719e0ddd28f06d4c80d9f
2019-07-25doc: Add Osmux documentation to User ManualPau Espin Pedrol2-1/+67
Depends: osmo-gsm-manuals.git f3a734e6777a902abfb03257277454c7a879aeb7 Change-Id: I70c488c3d9b05599b834a8608e6361c8aa43ef31
2019-07-16fix spelling detected by lintianThorsten Alteholz1-1/+1
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-06-18manuals: Include overview chapter about countersDaniel Willmann1-0/+2
Change-Id: I8c3e8bcda27f35118ab0e3d75621a02eec86f15c
2019-06-18manuals: Update counter/vty documentationDaniel Willmann2-28/+199
Change-Id: I1ef0e8ae166d7fdc5e85716a961e8387d26bdd2c Related: OS#1700
2019-06-18manuals: Add script to update vty/counter documentation from dockerDaniel Willmann2-0/+18
Change-Id: I3f5573f81460b40d4606fbcf0febcfd078a7bdca Related: OS#1700
2019-05-29debian: create -doc subpackage with pdf manualsOliver Smith1-0/+1
I have verified, that the resulting debian packages build in my own OBS namespace (see the -doc packages): https://download.opensuse.org/repositories/home:/osmith42/Debian_9.0/all/ https://build.opensuse.org/project/show/home:osmith42 Depends: Ib7251cca9116151e473798879375cd5eb48ff3ad (osmo-ci) Related: OS#3899 Change-Id: Iafa9fba60b3ad4478ec24d6ba8538ec80ce99f52
2019-05-15remove msc specific db countersAlexander Couzens1-2/+2
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-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr5-0/+238
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
2018-11-27build manuals moved here from osmo-gsm-manuals.gitOliver Smith5-27/+35
Moved to doc/manuals/, with full commit history, in preceding merge commit. Now incorporate in the build system. Build with: $ autoreconf -fi $ ./configure --enable-manuals $ make Shared files from osmo-gsm-manuals.git are found automatically if - the repository is checked out in ../osmo-gsm-manuals; or - if it osmo-gsm-manuals was installed with "make install"; or - OSMO_GSM_MANUALS_DIR is set. Related: OS#3385 Change-Id: Ic3c5add3c87f0aadb1ffab668ce16be6d0805d33
2018-11-27Merge history from osmo-gsm-manuals.gitNeels Hofmeyr17-0/+3439
Change-Id: I30ec6b3bc18fa36e7bad74ca445bc9949dcefe80
2018-11-27msc: update vty referenceNeels Hofmeyr1-157/+311
Change-Id: I31f1d388b5323af8ece8a71a82c1b91f80d404e1
2018-11-27OsmoBSC/HLR/MSC: Fix default config file nameDaniel Willmann1-1/+1
Mention that the default is not openbsc.cfg, but osmo-*.cfg Change-Id: I139e6004e28d6f918f31792e634214a6153edd0e
2018-11-27add SGs / CSFB related dot + msc filesHarald Welte5-0/+93
Those graphs + message sequence charts are not yet used by any of our manuals, but they should become used by the OsmoMSC user manual once SGs interface support is added. Related: OS#2583 Change-Id: Idfd3a66c18131b5458d183b8e66f62eaaab65991
2018-11-27vty-ref: Update URI of docbook 5.0 schemaHarald Welte1-2/+2
... to match the /etc/xml/catalog file on debian (no "www" in hostname) Change-Id: Id9f3579c7f2bc3af13fe30b5268f249b6f59ed0d
2018-11-27OsmoMSC: update VTY referenceNeels Hofmeyr2-3025/+2535
This is the first update since the libosmocore changes to the 'show online-help' generated output. Hence the produced document now benefits from the structural improvements: - not repeating common commands for every node; - using section names that match the VTY prompt. Update msc_vty_additions.xml to match the new node ID scheme. Change-Id: I6f1698dbc205334cf69234f88b124abfce54cc9a
2018-11-27share chapters/gsup.adoc from OsmoSGSN to OsmoMSC + OsmoHLRHarald Welte1-0/+2
Since the NITB split, GSUP is used in all three network elements, so make the protocol a shared chapter Change-Id: Id2d7c27ef16eb0ebe5f60d625a1fcf42f1603f4f
2018-11-27OsmoMSC: add rate counter documentationAlexander Couzens3-0/+46
Change-Id: Idc105fd16511c6ea4f5069a57b217ea3319bdbec
2018-11-27refactor Makefile build rules, don't use the FORCENeels Hofmeyr1-38/+6
The initial goal was to make sure we don't have overall FORCE rules causing unnecessary rebuilds -- annoying while writing documentation. As I looked through possible dependencies, I finally understood what's going on here. Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In each, describe in a top comment how to use it, and also unify how they are used: - Rename Makefile.inc to Makefile.docbook.inc and refactor - Add Makefile.vty-reference.inc - Add Makefile.common.inc Make sure that we accurately pick up all dependencies. Drop use of the macro called 'command', that silenced the actual command lines invoked and replaced them with short strings: it obscures what is actually going on and makes the Makefiles hard to read and understand. Each manual's makefile is greatly reduced to few definitions and a Makefile include, e.g. one for asciidoc, one for VTY reference. Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link from OsmoNITB. It applies only to OsmoBSC and OsmoNITB. Add a script that combines a VTY reference file with *all* additions files found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc. Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
2018-11-27add OsmoHLR manual, OsmoHLR VTY referenceNeels Hofmeyr1-5/+5
Change-Id: Ieb6a362a26a7e65199f68f5cd32d9b6b0e5d0fbf
2018-11-27add OsmoMSC manualNeels Hofmeyr10-0/+3666
Add OsmoMSC and OsmoHLR to bibliography (even though the OsmoHLR manual does not yet exist, a reference to it has been added in OsmoMSC's manual). Change-Id: I9ecff2837fbf5fdc19675a726f6d70c21eb178ee
2018-09-12Install sample cfg file to /etc/osmocompespin/systemdPau Espin Pedrol1-0/+8
Change-Id: I19f3755f7637dfc017a89f503831f7df8098a919
2018-08-09doc: update mgw settings in example config filePhilipp Maier3-0/+6
This example configuration files lack port settings for the mgcp client. Lets explicitly assign a port for the MGW and a local port. For the local port lets use the IETF port number + 1. The reason for this is that the default config for osmo-bsc already uses the IETF port and in osmo-bsc and osmo-msc run on the same machine in many setups. Change-Id: I17453e0d30eec757aba9530b63eb5d1539cbdffc
2018-02-14remove unused "auth policy" VTY commandHarald Welte3-3/+0
This is yet another unsused bit from the OsmoNITB legacy. Related: OS#2528 Change-Id: I825e659da529257e5edec94d9d59f0e10c1b4c63
2018-02-14remove unused VTY command "location updating reject cause"Harald Welte3-3/+0
OsmoMSC is using whatever reject cause is apropriate in the given situation. This user-configurable reject cause only had relevance in OsmoNITB, and hence it is an unused parameter that can be removed in OsmoMSC. Related: OS#2528 Change-Id: Ie1f39e706477aaf42051877b52d4b3ae1c5f138e
2017-11-08examples: apply mgcp_client vty rename from 'mgcpgw' to 'mgw'Neels Hofmeyr3-3/+3
osmo-mgw.git is changing the mgcp_client_vty API to use 'mgw' instead of 'mgcpgw'. Fix example configs after that patch is merged. Depends: I1d43d42929dc9162e57640499526fb7cadbcfbe6 Change-Id: Ib4c5ec1046a3c7a916ecfb7e5aa83dfe2f5ea8bf
2017-10-31vty: make auth tuple reuse configurableNeels Hofmeyr1-0/+2
Change-Id: Iba6253d9bf8d4a9d9f6f26ba045e6c7f0dc7f8f2
2017-10-04fix vty tests: long timeout due to unreachable STP addressNeels Hofmeyr2-3/+3
The doc/examples/osmo-msc SCCP config examples with 10.23.42.1 as asp ip-remote cause >5 minutes timeout for each VTY config test being run before the VTY becomes available. This hugely elongates the config tests, we didn't spot it before because it does succeed after that timeout. Rather use link-local addresses in order to immediately note the lack of connection and carry on with the VTY config tests. Related: OS#2333 Change-Id: I5ea4ef8a7e181bd3a38edf9c3b5d098f6ba65ee5
2017-09-07doc/examples: add detailed cs7 config examplesNeels Hofmeyr2-0/+56
Change-Id: I4da6724cd4348e92dfd06516f82af06c97277ef9
2017-09-06drop files unrelated to osmo-mscNeels Hofmeyr9-555/+0
These either remain from openbsc.git or slipped in while applying recent patches from openbsc.git and do not belong in osmo-msc. Empty out contrib: remove things that are either obviously unrelated to osmo-msc, or seem old and/or esoteric. Change-Id: I49957769e09eed6d723bf7c3777024b62b3480fd
2017-08-29split off osmo-msc: remove files, apply build, renameNeels Hofmeyr13-573/+0
Change-Id: Icf025e5ea8d180613b3114282951c9afa67af9a7
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-09 08:14:10 +0000