Commit Graph

57 Commits

Author SHA1 Message Date
Vadim Yanitskiy ffc7f39f01 VTY: add osmo_tdef introspection and configuration commands
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-25 10:24:14 +07:00
Vadim Yanitskiy b7ddbf377f VTY: mark 'subscriber create imsi' command as deprecated
Neither it should appear in the interactive VTY nor in documentation.

Change-Id: I208faab69a40948af5d081edbeaf75f586dfb2e4
2020-01-25 08:17:56 +07:00
Vadim Yanitskiy 95c46b11e9 manuals/vty: update the VTY reference to reflect recent changes
Change-Id: I14a5c9adff649406b4a079a75f86167ae6b95db4
2020-01-18 19:25:11 +07:00
Vadim Yanitskiy c6b088bf38 counters: polish documentation of cm_service_request / paging_resp
Change-Id: I273bc4165c70cd54ed94ff5f99377189f3306f51
2019-12-02 08:44:42 +00:00
Vadim Yanitskiy 1448052f37 counters: clarify documentation for MSC_CTR_CALL_* entries
Change-Id: Iad1ef917a229c3be51bd8fbe155f009f81e7d72a
2019-12-02 08:44:42 +00:00
Vadim Yanitskiy bc7dabd38d counters: clarify documentation for MSC_CTR_LOC_UPDATE_* entries
Change-Id: I4f4a0d644db0a2dd7c8eefd846ea6913c0b780ce
2019-12-02 08:44:42 +00:00
Vadim Yanitskiy 1ce842de39 counters: clarify documentation for MSC_CTR_SMS_* entries
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-02 08:44:42 +00:00
Harald Welte 22d0ba860d manual: Fix copy+paste error
Change-Id: I2c03d8424c218155dae9038dd7cc5660a290c5c8
2019-12-01 15:31:52 +01:00
Martin Hauke 3f07daceef Fix some typos
Fix typos and common misspellings in code comments and log messages.

Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-19 01:04:34 +00:00
Neels Hofmeyr 82f58fed6a charts: add full MO and MT voice call diagram
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-01 17:35:17 +01:00
Neels Hofmeyr 0f6664bb3d add msc_log_to_ladder.py
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-11-01 17:35:17 +01:00
Neels Hofmeyr 4dfb2babf2 add 'encryption uea 1 2' cfg / fix ttcn3 iu tests
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-13 23:52:31 +02:00
Neels Hofmeyr 7ea0db8f29 doc/sequence_charts: fix naming of mncc_fsm to mncc_call
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-05 23:25:17 +02:00
Neels Hofmeyr 62c0a2a4ab doc/sequence_charts/mncc_fsm.msc: add SIP messages, tweak
- 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-05 23:25:16 +02:00
Neels Hofmeyr a4d7a76816 do not force encryption on UTRAN
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-05 23:24:47 +02:00
Neels Hofmeyr 75bdbbf45d manual: adjust and fix auth and ciph docs
Change-Id: Iffe159d4c0e0e9439f8719e0ddd28f06d4c80d9f
2019-08-05 23:24:47 +02:00
Pau Espin 637fc0218b doc: Add Osmux documentation to User Manual
Depends: osmo-gsm-manuals.git f3a734e6777a902abfb03257277454c7a879aeb7
Change-Id: I70c488c3d9b05599b834a8608e6361c8aa43ef31
2019-07-25 10:39:07 +00:00
Thorsten Alteholz 3a357de631 fix spelling detected by lintian
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-07-16 20:12:03 +00:00
Daniel Willmann 7a2c9c91e9 manuals: Include overview chapter about counters
Change-Id: I8c3e8bcda27f35118ab0e3d75621a02eec86f15c
2019-06-18 18:07:43 +02:00
Daniel Willmann fb73e0c654 manuals: Update counter/vty documentation
Change-Id: I1ef0e8ae166d7fdc5e85716a961e8387d26bdd2c
Related: OS#1700
2019-06-18 12:51:07 +00:00
Daniel Willmann a794ff4f46 manuals: Add script to update vty/counter documentation from docker
Change-Id: I3f5573f81460b40d4606fbcf0febcfd078a7bdca
Related: OS#1700
2019-06-18 12:51:07 +00:00
Oliver Smith a2273f5f1d debian: create -doc subpackage with pdf manuals
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-29 12:14:16 +02:00
Alexander Couzens b10ec6a751 remove msc specific db counters
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-15 18:27:12 +00:00
Neels Hofmeyr c4628a3ad4 large refactoring: support inter-BSC and inter-MSC Handover
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-05-08 17:02:32 +02:00
Oliver Smith 39093768ca build manuals moved here from osmo-gsm-manuals.git
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-27 17:50:54 +01:00
Neels Hofmeyr d9fb15603e Merge history from osmo-gsm-manuals.git
Change-Id: I30ec6b3bc18fa36e7bad74ca445bc9949dcefe80
2018-11-27 17:44:56 +01:00
Neels Hofmeyr ab3ade70c4 msc: update vty reference
Change-Id: I31f1d388b5323af8ece8a71a82c1b91f80d404e1
2018-11-27 17:43:39 +01:00
Daniel Willmann 020a485287 OsmoBSC/HLR/MSC: Fix default config file name
Mention that the default is not openbsc.cfg, but osmo-*.cfg

Change-Id: I139e6004e28d6f918f31792e634214a6153edd0e
2018-11-27 17:43:39 +01:00
Harald Welte 732443c3b8 add SGs / CSFB related dot + msc files
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-27 17:43:39 +01:00
Harald Welte d89f1d18cb vty-ref: Update URI of docbook 5.0 schema
... to match the /etc/xml/catalog file on debian (no "www" in hostname)

Change-Id: Id9f3579c7f2bc3af13fe30b5268f249b6f59ed0d
2018-11-27 17:43:39 +01:00
Neels Hofmeyr df7d7ffc52 OsmoMSC: update VTY reference
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-27 17:43:39 +01:00
Harald Welte 593bbb5e5e share chapters/gsup.adoc from OsmoSGSN to OsmoMSC + OsmoHLR
Since the NITB split, GSUP is used in all three network elements, so
make the protocol a shared chapter

Change-Id: Id2d7c27ef16eb0ebe5f60d625a1fcf42f1603f4f
2018-11-27 17:43:39 +01:00
Alexander Couzens 7fd0e0fd64 OsmoMSC: add rate counter documentation
Change-Id: Idc105fd16511c6ea4f5069a57b217ea3319bdbec
2018-11-27 17:43:39 +01:00
Neels Hofmeyr adfbd3b8d6 refactor Makefile build rules, don't use the FORCE
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-27 17:43:39 +01:00
Neels Hofmeyr fee9dd7902 add OsmoHLR manual, OsmoHLR VTY reference
Change-Id: Ieb6a362a26a7e65199f68f5cd32d9b6b0e5d0fbf
2018-11-27 17:43:39 +01:00
Neels Hofmeyr 8c8ebb13b6 add OsmoMSC manual
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-11-27 17:43:39 +01:00
Pau Espin 5e91debe4e Install sample cfg file to /etc/osmocom
Change-Id: I19f3755f7637dfc017a89f503831f7df8098a919
2018-09-12 18:49:29 +02:00
Philipp Maier f896c690be doc: update mgw settings in example config file
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-08-09 11:52:53 +00:00
Harald Welte 098aa71e83 remove unused "auth policy" VTY command
This is yet another unsused bit from the OsmoNITB legacy.

Related: OS#2528
Change-Id: I825e659da529257e5edec94d9d59f0e10c1b4c63
2018-02-14 09:04:56 +01:00
Harald Welte 27b40c601c remove unused VTY command "location updating reject cause"
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
2018-02-14 08:29:24 +01:00
Neels Hofmeyr 48ba1be752 examples: apply mgcp_client vty rename from 'mgcpgw' to 'mgw'
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-11-08 03:24:13 +00:00
Neels Hofmeyr 97ce015f58 vty: make auth tuple reuse configurable
Change-Id: Iba6253d9bf8d4a9d9f6f26ba045e6c7f0dc7f8f2
2017-10-31 02:02:44 +01:00
Neels Hofmeyr ca4875f133 fix vty tests: long timeout due to unreachable STP address
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-10-04 11:14:15 +00:00
Neels Hofmeyr fb11041da9 doc/examples: add detailed cs7 config examples
Change-Id: I4da6724cd4348e92dfd06516f82af06c97277ef9
2017-09-07 03:10:36 +02:00
Neels Hofmeyr 47cd0d2687 drop files unrelated to osmo-msc
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-09-06 16:33:43 +02:00
Neels Hofmeyr bac227653a split off osmo-msc: remove files, apply build, rename
Change-Id: Icf025e5ea8d180613b3114282951c9afa67af9a7
2017-08-29 12:51:19 +00:00
Neels Hofmeyr 6d82bec2c8 MSC,SGSN: use OSMO_GSUP_PORT == 4222 instead of 2222
In SGSN, actually place the port in the SGSN config by default, so that the
gsup port may now be omitted in the VTY config (the IP address suffices).

Adjust the osmo-sgsn.cfg example.

Depends: I4222e21686c823985be8ff1f16b1182be8ad6175 (libosmocore)
Change-Id: I50f2040e2eb0baacb43849e93cfed10cbc2fc156
2017-08-29 12:51:18 +00:00
Philipp Maier fbf6610dc1 Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring)
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.

Implement AoIP in osmo-msc and osmo-bsc.

Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.

From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN

jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new
M3UA SIGTRAN.

Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-08-29 12:51:18 +00:00
Harald Welte 5d1fa89819 GSM timers: User reasonable defaults; don't save if equal default
A number of the GSM timers (including T3109) had no reasonable
default values if not specified in the VTY / config file.  Together
with unconditional writing to the config file, this created
config files with a persistent setting for important timers as '0'.

To make things worse, many of our example cofig files suffered from the
same problem.

Let's avoid this from happening by
* having reasonable defaults if nothing specified in the config file
* conditionally savingg timers only if they differ from default
* reject any timer values that state zero during start-up (see previous
  commit)

Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8
Closes: OS#2380
2017-08-27 02:33:48 +02:00
Daniel Willmann 8dc8ea435f examples/sgsn: Use osmo-hlr with auth-policy remote by default
For the vty tests, add osmo-sgsn-accept-all.cfg (that does not need an HLR) and
use in vty_test_runner.py, otherwise the 'show sgsn' command will reply that it
could not connect to the HLR, failing the vty test which expects empty.

Change-Id: Ie3b2013198d3e2b780a4e31c36b89b58129dcacd
2017-08-24 16:47:42 +02:00