The result of osmo_ss7_pointcode_parse() is currently not
checked. This means that -EINVAL could end up as value
in the pointcode configuration.
Check the return code of osmo_ss7_pointcode_parse() and
exit the VTY command with CMD_WARNING if the returned
pointcode is < 0
Change-Id: Iae6d92b1d135063dfd0a26bc23a89802cb3b1a78
SCCP addresses are defined through a number of compoinents, not
just an IP-Address, there is also point code, ssn and more. To
simplify and unify the handling of such objects, this patch
introduces an addressbook functionality. The user can set up
multiple addresses per ss7 instance and give them names. Later
that name can be used to reference the address at a later point
in the config. This means that the usage of sccp-addresses from
the programmers point of view boils down to a VTY function that
reads the string name of a previously defined address. The
programmer can then use the API to get a pointer to the SCCP
address struct and use it normally.
For this feature, two additional VTY nodes are necessary,
this commit depends libosmocore change:
Change-Id I42aa29c0cccc97f284b85801c5329b015b189640
Change-Id: I068ed7f7d113dab88424a9d47bab7fc703bb7942
As an IPA SCCPlite message arrives without any MTP routing label, we
simply construct one artificially for all inbound IPA/SCCPlite packets:
* we set the SPC to the point-code of the routing key of the AS
(as this is the PC we route to this IPA/SCCPlite client anyway)
* we set the DPC to a point-code from a new vty config command
"point-code override dpc"
Change-Id: Id556398e1ded3e613cfde7ea8b71aff7a414ff90
This tries as good as possible to fit the IPA/SCCPlite stacking into the
existing SIGTRAN/SS7 code architecture/model. To the user, the IPA
protocol looks like yet another protocol on the same level as the choice
between SUA and M3AU. On the inside, things are obviously quite
different.
We need to handle TCP with IPA framing instead of SCTP for both server
and client. We also implement an alternative "ASP FSM" for IPA, which
takes care of the CCM handshake (ID_REQ/ID_RESP/ID_ACK/ID_ACK2) for both
client and server mode.
In server mode, we use the 'unit name' as identifier to look up the AS,
similar to how we use a routing context to look up the AS in the xUA
case.
We also have to bypass activating the default layer manager in the
simple client to make sure we don't run into even more complexity.
What's missing right now is some way to manually override/set the point
codes. As IPA/SCCPlite is missing any routing label, we currently
simply generate one with SPC=0/DPC=0, which will obviously not work in
most configurations.
Change-Id: I9098574cddeba10fcf8f1b6c196a7069a6805c56
By moving this variable into the SS7 instance, we avoid one more global
variable, and we also fix a bug where the xua servers would be saved
multiple times (once per instance).
Change-Id: Icbab59d773f23cc8514cbeb6e21e25ca35dd337f
If we add more xUA variants/protocols, we want to avoid having to touch
too many parts of the code with copy+pasted strings.
Change-Id: I085b884d98fb4c45ac15910a8ebf82b91e861fd4
If RKM has dynamically generated some AS definitions on the fly, or if
we accepted auto-creation of ASPs on SCTP connect time, then we don't
wnat to save such objects during vty config file store.
Change-Id: I9d0b0b61737a30b9d6e76cecbe42ec071bcddeeb
Using this command one can specify if ASP connections should be refused
if there's no matching configuration, or whether ASPs should simply be
create on-demand.
Change-Id: Ic93b99047fb566cdb25a2f4139ebef54849dece9
This way it is systematic and doesn't clash with other optional
arguments we may introduce sooner or later at the end of the commands
Change-Id: I5c1050b0564791b5684619d3737d1cb6c4539d63
Now that the VTY has no static dependencies like a global ss7_instance
anymore, we can move it back to libosmo-sigtran and make use of it in
other programs outside osmo-stp.
This requires Change-Id I184a7e3187b48c15c71bf773f86e188fe1daad15 in
libosmocore
Change-Id: I2e549f1eadbfb28dde79f620b130cbf022312c42
osmo-stp is able to define multiple M3UA and/or SUA application servers
(AS) as well as application server processes (ASPs). Clients can then
connect via M3UA or SUA, perform the respective ASPSM / ASPTM state
changes and finally exchange MTP signaling such as ISUP or SCCP on top
of it. Routing is currently only based on point codes (PC). Routing table
is fully configurable with Destination PC and mask.
Shortcomings:
* xUA: only "override" traffic mode supported, no load-balance or broadcast
* xUA: no SNM supported, i.e. DAVA/DUNA/... messages are neither parsed
nor generated
* SCCP: no Global Title based Routing (GTR) yet
* SCCP: no Global Title Translation (GTT) yet
* no M2PA / M2UA sigtran dialects
* no classic CS7 based signaling links(E1/T1 TDM)
Change-Id: If32227b8d3127c6178e4ee45527ce65f69bc7b1e
This is what aims to be a rather complete/proper implementation of the
SIGTRAN + SS7 protocol suite. It has proper abstraction between the
layers with primitives, finite state machines for things like the AS and
ASP state machines, support for point code routing, etc.
What's not implemented at this point:
* re-integration of pre-existing SUA (pending)
* actual MTP2 and physical E1/T1 link support
* different trafic modes like broadcast/fail-over/load-balance
Change-Id: I375eb80f01acc013094851d91d1d3333ebc12bc7