When RKM dynamically allocates ASs on the SGP based on RKM registration
requests, we must make sure to properly destroy those at the time the
related ASP disconnects. Also, make sure to send
XUA_ASP_E_SCTP_COMM_DOWN_IND to the layer manager (if any).
Change-Id: Ie6505680bb6890814ae36858c54a2a6d2850f5cf
The existign xua_rkm code was merged a bit pre-maturely as it was not
properly tested. This adds a lot of fixes to make it work at all in the
first place, as well as the configurable option for fully dynamic
routing key management, where ASs and routing keys must not be
configured statically by administrative means, but clients (ASPs) can
simply come and register for whatever point code they want.
Change-Id: I79a070fa7b271b44995511f7b3ff7cc6beec8278
This "default layer manager" can optionally be used by a xUA ASP. It
will handle the xUA Layer Manager (xlm) primitives and use them to
behave as follows:
* bring the ASP into state "INACTIVE"
* see if the SG can match our connection (based on IP address + port
information) to a statically configured ASP configuration with
associated AS(s). If yes, it will send us a NOTIFY message with
AS-INACTIVE.
* if the above doesn't work, try to dynamically register a routing key
using RKM for the point code that was locally confiured on the
ASP/client. If that works, the SG will now have created ASP and AS
objects as well as a routing key and be able to serve us, sending the
NOTIFY with the AS-INACTIVE state.
* After either of the two above, we will attempt to transition into
ASP-ACTIVE. The SG should send us an AS-ACTIVE notification in return
* if anything fails, abort and disconnect the SCTP connection, restart
related FSMs and start from scratch
Change-Id: I78d4623dd213b5c59007a026a6cc3cfe5c04af50
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
The SCCP spec clearly defines which optional information element each of
the messages supports. We must make sure to not include any other
options when converting from SUA. SUA has more relaxed rules about
this, and e.g. supports SRC and DEST ADDR in the COAK, while the SCCP CC
only permits a CalledParty, but not CallingParty.
This was found when interoperating against the Ericsson TTCN-3 SCCP
implementation for Eclipse Titan.
Change-Id: I7d9e23dec1d3e786d291abd270a261704593befc
the '0' confuses the Ericsson SCCP code for Eclipse Titan, even though
the spec considers it permitted.
Change-Id: I21269a7d610a4bf52555ffcef4f8acc55824515e
In 17df5953ff we fixed endianness issues
with the Stream ID field, but at the same time mistook the PPID field
for 16bits. In reality it is 32bits, and hence our 'htons' is rendering
wrong PPID values.
Change-Id: Ief04486e752e6b7e0a853b1fa9ca525ad47800f6
In M3UA RKM we need a "Local Routing Key ID" which uniquely identifies a
given routing key locally at the node. Allocate this value and store it
in each osmo_ss7_as, as well as add a lookup function for it.
Change-Id: I89a0abcf66228ce092126a497cc7971df3a6af71
When we are on the ASP (client) side, we must initialize the routing key
of the AS with the proper primary point code of the system. Only this
way, the correct point code will be used during dynamic routing key
registration via RKM.
Change-Id: If586ac9f3449254973a19654dd13dce5793f285f
When we accept SCTP connections from clients for whose IP/port we have
no matching local configurations, and it is permitted by local
configuration, we dynamically allocate osmo_ss7_asp's in this case.
Make sure to properly destroy them at the time the SCTP connection is
lost.
Change-Id: I07d69a0cd52a049a7a4bb0d996e95d39fee9a106
When we destroy a linkset, it make sense to remove all associated routes
pointing to the linkset, as they would point to nowhere anyway.
Change-Id: I393400bc758c28997e16bc78e3142719b6a61be8
We cannot use osmo_talloc_replace_string() together with
osmo_sock_get_name(), as the latter already creates a dynamically
allocated string, and the former will then make a copy of that
allocation.
Change-Id: I6798221ccb3c70186c1c51dd34b7823fefd6df58
The M3UA RFC defines this primitive to the layer manager, but we so far
didn't generate it. Let's inform the Layer Manager about such events,
in case it wants to take appropriate action.
Change-Id: I4e4e86f9b9d8ef4639c835878749ce8d8cc76f7c
If we don't do this, we get some nasty packet delays, which are
sufficient enough to trigger re-transmissions of an M3UA ASP-UP packet
even over loopback/localhost on an otherwise unloaded system.
Change-Id: I6aa4eb421ecb483d3da1b0ce3aa6511d161c3750
In case there is no user data in a CONNECT.conf primitive (or other CO
primitives), we must make sure that msgb->l2h = msgb->tail so that the
SCCP User can use msgb_l2len(msg) == 0 as indicator to verify if user
data is present or not.
Change-Id: Ie512fe063391e3a634097f555b9b0089d2981de9
When sending messages like CC (or SUA COAK) without user data, we must
make sure to not include the optional data part - as opposed to
including one with zero length.
Change-Id: If91edb526cbcd792ec5ebcb4518cf848feb69391
In their infinite wisdom, the inventors of SCTP designed an API (the
sockets API described in RFC6458), where some members are in host byte
order (like the stream identifier), while other members are in network
byte order (like the PPID).
Let's handle this properly (we assumed both are network byte order), and
also use 16-bit htons/ntohs fo the PPID, rather than htonl/ntohl.
Change-Id: I51c87314ef9ba6415e7e89980699ab07e787ed5d
This was discovered (and fix validated) using m3ua-sgp-mtr-i-003 of
Michael Tuexen's m3ua-testtol.
Change-Id: I7498f606b031f5a6dfb538d9900c744da6aed36f
According to the RFC, Stream ID 0 MUST not be used for XFER/DATA
messages.
This was discovered (and fix validated) using m3ua-sgp-mtr-v-003-alternate
of Michale Tuexen's m3ua-testtool.
Change-Id: I80b941426b5106e091bd1becff0ae97958aff97c
This was discovered (and fix validated) using m3ua-sgp-asptm-i-005 of
Michael Tuexne's m3ua-testtool.
Change-Id: I217ae287e22371e36dda0f87a7737b62fb1bf2d6
This was discovered (and fix validated) using m3ua-sgp-asptm-o-003
of Michale Tuexen's m3ua-testtool.
Change-Id: If231072655170fe52dae738882dd63b1d0a60cf9
This was discovered (and fix validated) using m3ua-sgp-asptm-o-001 of
Michael Tuexen's m3ua-testtool.
Change-Id: I6d254f7a33856e036329aa717a9c03efb1f1289d
This was discovered (and fix validated) using m3ua-sgp-asptm-i-004 of
Michael Tuexen's m3ua-testtool.
Change-Id: I76c01189b75ff3084cd4d3944314ec9b9f811dbf
This was discovered (and fix validated) using m3ua-sgp-aspsm-i-003
of Michale Tuexen's m3ua-testtool.
Change-Id: I8b63e7b5e39a7ef8dd66bf014110a04f5f3dc2a2
When we crate a sccp address with PC+SSN, we should also set the routing
indicator accordingly (OSMO_SCCP_RI_SSN_PC).
Change-Id: Ie179df7158624520e90093da063c57f1e3efa0bd
After verifying the routing context of an incoming M3UA message, remove
the routing context before passing into MTP routing. In the forwarding
case, we might want to set a new routing context on the outbound link,
and we don't want the routing context IE to show up twice.
Change-Id: I7a534cb1da275369c70766c059aaae8157ce6833
osmo_ss7_pointcode_print() osmo_ss7_pointcode_parse() etc. now support
passing a NULL ss7-instance which will lead to application of the
default ITU 3.8.3 point code format.
Change-Id: Ifb739e92e31eaaa0343dc57c9af8c9164d00175f
if osmo_xua_server.cfg.accept_dyn_reg is set, then ASPs are permitted
to connect without having a pre-configured matching ASP definition in
the vty. This helps particularly in cases where RKM is used for
dynamica registration of a RC (and hence AS).
Change-Id: Ie48898202acbdbfe144fdd5851dfedbb554b11aa
Harald Welte