Quoting 3GPP TS 23.003 8.2:
1111 1010 BSC (BSSAP-LE);
1111 1011 MSC (BSSAP-LE);
1111 1100 SMLC (BSSAP-LE);
Hence the SMLC one should also be named *_BSSAP_LE.
I'm certain no other osmocom code is using this SSN yet, but anyway keep a
backwards compat shim #define.
Change-Id: I3e0c1be0ebbd3883d024174d1e7e9167a8281cfb
To allow osmo-bsc to add more than one MSC peer on a single SCCP instance, it
must add a local SCCP user only once per SCCP instance. The first configured
MSC adds a local user, all subsequent MSC should use the same local SCCP user.
So, it is most convenient to provide a public function to return such user if
it exists.
Add as thin wrapper instead of renaming and moving the internal
sccp_user_find(): to keep the patch smaller, and to match the way
osmo_sccp_user_bind_pc() is a 1:1 wrapper for sccp_user_bind_pc().
Related: OS#3682
Change-Id: I9ecbab16b45268f626950303d6ff8296dd6acda0
Rationale: the script is a good way to avoid bugs from manually composing the
big endian parts (for example, it detected the missing endian.h include, fixed
in I5906d94e0e0a74674c3a14cf2ec81c681e696474). However, it becomes cumbersome
if it creates numerous edits in the source tree, which cause more time spent
for whoever wanted to rather save time with it. So let's keep the code tree
matching that script's output.
Change-Id: I04ad3795fbaf495cae168aed69124b1dc132a9bd
Wrong type was used when the function was introduced a few commits ago.
Fixes: 5a7eb34f735e0ae93a74da3bc8361454457e49cdi
Closes: CID#207712
Change-Id: Ie9b89483158dd6b988e4c34b497bf3b231c15cd3
The code managing addresses is decoupled from xua_server since they will
also be used to manage addresses for ASPs.
Change-Id: I4af2a6915ac57c7baa67343bd9414c65154d67f7
This is like osmo_ss7_asp_find_and_create(), i.e. it's doing a full
match for an ASP within the specified SS7 instance, of the specified
port numbers. It just doesn't create it if it is missing.
Change-Id: I1ed3cf2b69ee622d6f9d8b50487f392fe913ae90
Related: OS#4271
So far, we had a static role model:
* SCTP servers (listening, such as OsmoSTP) are role SGW
* SCTP clients (connecting, such as OsmoMSC) are role ASP
While this is customary, it is not actually required by the
specification. The SGW can establish the SCTP connection to an ASP
but still remain "SG" role.
Let's make things more flexible by having the role configurable.
Related: OS#2005
Change-Id: I2df9cd9747ad5c9a05d567d9a71bab6184c53674
If the AS is e.g. configured as broadcast, then individual ASPs cannot
be activated in loadshare or override. Everyone must agree.
Change-Id: Ic73410fbc88d50710202453f759fa132ce14db4c
RFC 4666 (SS7/MTP3/M3UA) states in isection 4.3.4.3 ASP Active Procedures:
"""
If the traffic handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
"""
In section 3.6.1 Registration Request (REG REQ), no related information
is provided on how to handle it, but still makes sense to apply same
behavior as in 4.3.4.3.
Related: OS#4220
Change-Id: Iaebe3a93ad8d2d84ae01e41b02674f8ece9dfc95
After this patch, Several "local-ip" and "remote-ip" lines are accepted
under "listen" and "asp" VTY nodes, allowing to configure an SCTP
connection with multiple connections, hence allowing control of SCTP
multi-homing features.
libosmo-sccp clients such as osmo-bsc and osmo-msc also gain support for
this feature with this commit.
Related: OS#3608
Depends: libosmocore.git Ic8681d9e093216c99c6bca4be81c31ef83688ed1
Depends: libosmo-netif.git I0fe62f518e195db4e34f3b0ad1762bb57ba9d92a
Change-Id: Ibd15de7a4e00dbec78ff2e2dd6a686b0f3af22de
Commit 10d4815bb1 already fixed the issue
where binding was done during L_CS7_XUA_NODE (listen) done, meaning
local-ip inside it had no effect. In that comment, binding was moved to
happen during "local-ip" VTY cmd. Furthermore, that commit added a new
osmo_ss7_bind_all_instances() and related APIs to allow osmo-stp to have
all xua servers bound if no "local-ip" was provided.
These APIs have only been used so far by osmo-stp (which lays in the
same git repo that libosmo-sccp) since it's the only program using the
xua server features.
In the present commit, let's drop the APIs added by commit described
above, and instead let libosmo-sccp code to internally bind the xua
server upon exit of the VTY node. As a result, the previously introduced
APIs can be dropped (not used by anyone anymore) and it will provide
ways to support multiple "local-ip" commands in the future, hence
supporting SCTP multi-home features.
It's recommended to require libosmocore.git Ia6d88c0e63d94ba99e950da6efbc4c1871070012
since it fixes a bug where go_parent_cb was not called for nodes at the
end of the file.
Related: OS#3608
Change-Id: I2cff17b5e2e2fbfd4591e23a416e510e94e173d6
When receiving SCCP messages from an IPA peer/ASP, osmo-stp so far
unconditionally inserted origin/destination point codes int the SCCP
called / calling party addresses.
This behaviro is now made optional with the introduction of the
following per-AS configuration:
"point-code override patch-sccp (disabled|both)"
The default behavior is switched from 'both' to 'disabled' at the same
time.
Change-Id: I535e2170adadfe755d2bcbf5bbf4556bebb77737
Closes: OS#4219
The cellmgr-ng unfortunately looks at the data being sent and can't
handle the presence of XUDT at all. Add the structure definition
and refactor extraction code to work on offsets. Add a unit test.
Change-Id: I45a7447cc1be432fff34849e0e35abc0410cf153
osmo-msc identifies its BSC and RNC peers by SCCP address, and compares those
by memcmp(), which is not really accurate. Rather provide a meaningful
osmo_sccp_addr_cmp() API to determine whether SCCP addresses are identical.
Go for a full cmp that would also allow sorting.
Change-Id: Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5
Add osmo_sccp_user_sap_down_nofree(), which is identical to
osmo_sccp_user_sap_down(), but doesn't imply a msgb_free().
To implement that, sccp_sclc_user_sap_down_nofree() with the same msgb
semantics is required.
Rationale:
Avoiding msgb leaks is easiest if the caller retains ownership of the msgb.
Take this hypothetical chain where leaks are obviously avoided:
void send()
{
msg = msgb_alloc();
dispatch(msg);
msgb_free(msg);
}
void dispatch(msg)
{
osmo_fsm_inst_dispatch(fi, msg);
}
void fi_on_event(fi, data)
{
if (socket_is_ok)
socket_write((struct msgb*)data);
}
void socket_write(msgb)
{
if (!ok1)
return;
if (ok2) {
if (!ok3)
return;
write(sock, msg->data);
}
}
However, if the caller passes ownership down to the msgb consumer, things
become nightmarishly complex:
void send()
{
msg = msgb_alloc();
rc = dispatch(msg);
/* dispatching event failed? */
if (rc)
msgb_free(msg);
}
int dispatch(msg)
{
if (osmo_fsm_inst_dispatch(fi, msg))
return -1;
if (something_else())
return -1; // <-- double free!
}
void fi_on_event(fi, data)
{
if (socket_is_ok) {
socket_write((struct msgb*)data);
else
/* socket didn't consume? */
msgb_free(data);
}
int socket_write(msgb)
{
if (!ok1)
return -1; // <-- leak!
if (ok2) {
if (!ok3)
goto out;
write(sock, msg->data);
}
out:
msgb_free(msg);
return -2;
}
If any link in this call chain fails to be aware of the importance to return a
failed RC or to free a msgb if the chain is broken, or to not return a failed
RC if the msgb is consumed, we have a hidden msgb leak or double free.
This is the case with osmo_sccp_user_sap_down(). In new osmo-msc, passing data
through various FSM instances, there is high potential for leak/double-free
bugs. A very large brain is required to track down every msgb path.
osmo_sccp_user_sap_down_nofree() makes this problem trivial to solve even for
humans.
Change-Id: Ic818efa78b90f727e1a94c18b60d9a306644f340
We were printing the mask of the route, but not the point code itself.
Best would probably be to print both?
Closes: OS#3835
Change-Id: Ifa4fdbad953d40f222beb470a082eed8c20991ef
That's useful for external programs veryfying pointcode validity. For
example if used as part of BSS-related identity in GCR construction by
LCLS code we should be able to double.check that no significant bits off
pointcode are lost/ignored.
Change-Id: I5a9981dd2c1d78966c61a3f6b50c7c0d9b542caf
When saving the current VTY config to a configuration file,
do not write out AS/ASP configuration items which are generated
as a fallback by osmo_sccp_simple_client_on_ss7_id().
Since the user did not explicitly configure these configuration
items they should not be saved to the user's configuration file.
Change-Id: Id8a3afc6dee29ae1ee9c862cbe404a61fe979dba
Related: OS#3616
Anywhere else in the Osmocom code base, we arrange headers in
include/osmocom/foo/ and pass -I ${root_srcdir}/include/.
This way including an osmocom header always has the format
#include <osmocom/foo/bar.h>
whether we are including from the local source tree or from $prefix.
For some reason not clear to me, the mtp and sccp folders, even though they are
being installed to $prefix/include/osmocom/, were kept *next* to the osmocom/
dir, instead of inside it. Fix that weird situation.
The motivation is that I wanted to use a definition from sccp_types.h in a
public-API header. That is impossible if it requires
#include <sccp/sccp_types.h>
in a local build, but
#include <osmocom/sccp/sccp_types.h>
for any other source tree using libosmo-sccp. After this patch, both are
identical and including works without quirks. (The other patch that needed this
has changed in the meantime on and no longer needs this, but this still makes
sense for future hacking.)
The installed result does not change, since both mtp/*.h and sccp/*.h have
always been installed to $prefix/include/osmocom/{mtp,sccp}/. This merely
changes their position in the source tree.
The most curious situation before this is that any patch #including
<osmocom/sccp/sccp_types.h> might not get a notice that the header didn't
exist, but might instead include an older system-installed file.
Change-Id: I1209a4ecf9f692a8030b5c93cd281fc9dd58d105
Instead of allocating ss7->sccp in various places, unify that in one common
function. We shouldn't spread the decision what to pass as priv pointer around
everywhere. There is no functional difference.
This is preparation for a patch where the sccp_instance gets allocated from the
telnet VTY: I would prefer to hide all allocation details from that code; which
also makes sense for the other callers of osmo_sccp_instance_create().
Change-Id: Ie912898c66d31ce4ac8eeeea5a6ddc3f821c06f7
So far the tall_xua ctx used to allocate from in xua_msg_alloc() was never
initialized, actually hiding memory leaks from the talloc report.
Add this API to allow branching the xua_msg ctx off a sane root ctx.
Explicitly initialize tall_xua to NULL, so that, if xua_msg_ctx_init() isn't
called, tall_xua is still guaranteed to not be a random pointer.
osmo-bsc will use this function to hook the tall_xua ctx to osmo-bsc's own root
ctx.
Change-Id: I618878680a096a7f7fc2d83098590f2e4cb08870
Applications may be interested in handling data for those SCTP PPID or
IPA StreamID which libosmo-sigtran doesn't implement
natively/internally.
Let's add osmo_ss7_register_rx_unknown_cb() using which applications
can register a call-back to implement whatever behaviour they'd want for
those PPID/StreamIDs.
Change-Id: I8616f914192000df0ec6547ff4ada80e0f9042a2
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ia0d15a2814b08bc3f052a1ed12dbb68bade55309
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ib7abf69cfcf4c56273223054b280458451e6c2f6
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
It can be cumbersome to derive the ss7 instance needed to pass to
sccp_addr_name(), because struct osmo_sccp_instance is opaque and only
available in sccp_internal.h, within libosmo-sccp.
Add osmo_sccp_inst_addr_name() which derives the ss7 instance from the internal
knowledge of the osmo_sccp_instance struct. This can save calls to
osmo_ss7_instance_find() just to do some logging of an sccp address.
Naming: first I thought to pick osmo_sccp_addr_name2(), but for some of the
string composing functions, adding a 2 already means that it is identical but
using a second static buffer (to be used twice within the same printf).
Change-Id: I70ec5c8b42682a23f11a5820431c7e34e225709b
Since the NI is in bits DC, not BA, it needs to be shifted by 6, not 4, to end
up in the two most significant bits. Also, NI is two bits wide, hence & 0x3.
(The m3ua.c side of this is already correct.)
See ITU-T Recommendation Q.704 (07/96), 14.2 "Service information octet".
Before this patch, NI was always sent as 00 == International regardless of the
VTY configuration.
This patch was verified to work by a wireshark trace of osmo-bsc connecting to
osmo-msc, showing the NI decoded as configured by an osmo-bsc.cfg file in the
BSSMAP Reset message MTP 3 / Protocol data.
Change-Id: I7bb4eb6518a1e0d74313bda776d2a6acd0b02e1b
* BSSAP is 254 on both MSC and BSC side: Add missing define
* BSSAP-LE (LCS Extension) has 250/251, adjust name to add -LE suffix
Change-Id: Iccec75cfc0cf16bd717a9bd4606d1e772c332ccc
osmo_sccp_get_ss7() has the risk of a nullpointer dereference, when
sccp is NULL.
Return NULL when the sccp instance is NULL.
Add doxygen comment
Change-Id: I84d484e4441fd37443fff8c67e17df8fb15d5b2e
It is currently impossible to find out which SCCP instance handles
a particular user.
Introduce function to lookup the SCCP instance from a given SCCP
user.
Change-Id: I9562c4f1d00e2ebb3252c5dea598b643aa393719
osmo_sccp_addr_name() is not listed in any header file.
Add osmo_sccp_addr_name() to sccp_helpers.h in order to make
it available.
Change-Id: I092dd55948faeeff78f28f7d50c5b84b9e69ef24
The simple client takes certain parameters (pc, ip and port
numbers) which serve as a fallback default in case the user
did not configure any suitable parameters via the VTY.
Prefix all default variables with default_ to make the
purpose clear to the API user
Change-Id: Id9e697e8b198e4f58a79e59aaf2e649e84a3eb63
osmo_sccp_addr_dump() just prints the raw values. In osmo_sccp_addr_name(), use
osmo_ss7_pointcode_print() and newly added RI, SSN and GT value_string[] to
print more human readable log output.
Change-Id: Ie1aedd7894acd69ddc887cd65a8a0df4b888838c
Allows to automatically set an RI in future change
I75c67d289693f1c2a049ac61cf2b2097d6e5687d
"sccp-addr vty: set RI to SSN_PC when setting a point-code"
Change-Id: I6e2f31b023b08cba2f2ee8234e6108efcaca41c0
Introduce OSMO_SS7_PC_INVALID to mark an unset point code.
Add static osmo_ss7_pc_is_valid() (name matches schema of
osmo_ss7_pc_is_local()).
In osmo_ss7_pointcode_print(), return "(no PC)" if !osmo_ss7_pc_is_valid(), for
convenient printing of any PC state.
Subsequent patches will use this for
osmo_ss7_instance (I7f0f0c89b7335d9da24161bfac8234be214ca00c)
as well as osmo_sccp_user (I8684c9b559712072c772012890bbf7efa7c8eb35).
Rationale:
Currently, in osmo_ss7_vty.c we had "if (inst->cfg.primary_pc)" suggesting 0 is
invalid, but in struct osmo_sccp_user we have flag pc_valid suggesting 0 is
indeed valid. All known point code formats are <= 24bit, so we can easily use
0xffffffff as indicator for an unset PC, which removes the need to remember to
set a second field for validity and keeps the structs nice and lean.
Change-Id: Ib5715bf03a4de7713a7a809dfd821c700255ba8c
In order to catch invalid CS7 configurations, It is necessary
to check if sccp addresses contain plausible address data.
Change-Id: Ic6245288b0171eae10aa708403c1ddb584c92f38
Drop the separate osmo_ss7_set_vty_alloc_ctx() because we are likely to forget
calling it. Instead, incorporate into osmo_ss7_vty_init_*() with a new ctx arg,
and set the static context var in vty_init_shared().
Change-Id: Id4e7f47979001f7856b0b3665c9e94982e75e490
The most important parts of an SCCP address are the routing
indicator and the pointcode. The latter one is always available
via the SS7 instance, so a basic local address can be derived
from there.
Add function osmo_sccp_local_addr_by_instance() to derive a basic
local SCCP address from a given SCCP instance
Change-Id: I371dc9132871aad3d8321ea13cf9fd69d76eff8f
The osmo_sccp_simple_client_on_ss7_id and osmo_sccp_simple_client
are not entirely configurable via VTY commands. The relation to
the VTY is implicit. The user may set up instance objects via
VTY (cs7/ss7, AS, ASP), which are then automatically created on
startup.
Each cs7 instance gets its own ID via the VTY configuration. When
osmo_sccp_simple_client_on_ss7_id() is called with the cs7 instance
id. (for osmo_sccp_simple_client() the ID will be hardcoded to 1),
the function automatically checks if the CS7 instance is present,
if not it will create one automatically using the caller supplied
parameters as a defult. If a CS7 instance is present, the function
checks for the presence of an AS and an ASP. These objects are
present, they will be used. If not, new objects will be created.
Both functions must not be called if an SCCP instance is already
present. Since there can only be one SCCP instance per CS7 instance,
this is an error condition.
Add additional logic that checks to detect an already existing, valid
configuration. If no or an insufficient configuration is detected,
use the caller supplied parameters as default configuration.
Change-Id: I293f3526ce6182dca74a169a23449dbc7af57c7c
The sccp-addressbook only allows defining addresses for a specific
ss7 instance. It is not possible to use an sscp-address, that is
defined in the one ss7 instance in another ss7 instance.
Add a second global list where all sscp-addresses are added,
regardless on which instance they are defined.
Fixup the search functions so that they always search the global
list.
Change the API, so that the address data is written to a
destination pointer. This protects the stored address from
unintentional changes. Also return the ss7 instance, where the
address is associated with.
Change-Id: I5acc1e5abc3b3081149a9f476038e4e53d23b763
osmo_sccp_simple_client() and osmo_sccp_simple_server() are binding
on the ss7 instance with the id 1 by default. If the instance does
not exist, it is created automatically.
Allow choosing the ss7 instance by supplying the id number as
function parameter. Add two new functions:
osmo_sccp_simple_client_on_ss7_id()
osmo_sccp_simple_server_on_ss7_id()
Change-Id: I62e608253212415bddbb4c7dcf5d3b5e79c8d28e
Add function osmo_ss7_point_code_print2() to be able to print two point codes
in the same log message.
Change signatures of two static functions to aid logging:
add invalid ref arg to sccp_scoc_rx_inval_src_ref(),
pass conn instead of inst to sccp_scoc_rx_inval_opc().
Change-Id: Ia3243606d6cad7721f7da7f6caba2caa90ae2bbd
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
Higher-layer code shouldn't have to worry between client and server
difference. It just wants to close the underlying connection for a
given ASP - which it now can by means of osmo_ss7_asp_disconnect().
Change-Id: I36b089abd281b8edac8830fda2d8e57cc06cd0a7
When we destroy a xua_server, we would like to close and destroy any
ASPs that were established via that xua_server. In order to do so, we
need to add a list of ASPs to the xua_server, which we can iterate.
Change-Id: Iff3ed099b817e54e563b70d9ab40f63af63cc2fb
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
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
This properly integrates the concept of multiple SS7 instances (each
with their own point code format, address indicator, ...) into the VTY.
At the same time, this also removes the stp-global "g_s7i" instance
that existed so far, moving the VTY code more into the direction of also
being able to be used outside the STP - which is underlined by splitting
the vty commands between those generally useful, and those useful only
for a STP or only for a simpla ASP (client).
Change-Id: I30966fbf2e143318cd9127eb8c17cccb24407106
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
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 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
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
as 'struct osmo_sccp_instance' is opaque to the user application, it is
useful to have an accessor function that resolves the ss7 instance used
by the SCCP instance.
Change-Id: I8057a6d69584239b9781c5cece42066293ea1dd6
As 'struct osmo_sccp_user' is private, we need this accessor functions
for the SCCP User so it can set and get the 'priv' data.
Change-Id: Ia68a36dc18a7d754d63ae29c86d68e495b5c4134
We don't really need those thre log messages, and we can thus do away
with the library-internal log-subsystem of DXUA. The rest of
libosmo-sigtran uses the new globa DL... subsystems anyway
Change-Id: Iea0d3db34a3674a9c6422b174a879bfdaa25786f
If we use the infrastructure provided by osmo_ss7 on the lower layer and
the SCCP SCRC, SCLC and SCOC code on the upper side, not much of the
original sua.c code remains. It looks much like the M3UA code now.
Change-Id: I193b74f58aa70c443ae17e78b5604246d6bc3f71
This is an implementation of SCCP as specified in ITO-T Q.71x,
particularly the SCRC (routing), SCLC (Connectionless) and SCOC
(Connection Oriented) portions. the elaborate state machines of
SCOC are implemented using osmo_fsm, with one state machine for each
connection.
Interfaces to the top (user application) are the SCCP-USER-SAP and on
the bottom (network) side the MTP-USER-SAP as provided by osmo_ss7.
Contrary to a straight-forward implementation, the code internally
always uses a SUA representation of all messages (in struct xua_msg).
This enables us to have one common implementation of all related state
machines and use them for both SUA and SCCP. If used with real SCCP
wire format, all messages are translated from SCCP to SUA on ingress and
translated from SUA to SCCP on egress. As SUA is a super-set of SCCP,
this can be done "lossless".
Change-Id: I916e895d9a4914b05483fe12ab5251f206d10dee
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
msg_event_maps facilitate the mapping from a xUA message (class + type)
to an integer event. This is useful when passing xUA messages to a
osmo_fsm.
Change-Id: Iee1c7fc2bf64219ebb71a0dbe6fd210749332413
libosmo-sigtran is GPLv2-or-later, there were some files that
accidentially had an AGPLv3 license header, which was a copy+paste
mistake at that time.
Change-Id: I67dfd0ae6157afafd3873a3baaa4c6107c04ddfd
Higher-layer protocols (particularly SCCP) require knowledge on the
MTP-level routing label of a message. Let's add this to the common
header of 'struct xua_msg' to communicate it across layer boundaries.
Change-Id: I31a6388ac999e02ad779619adb54bbf4040672c9
The ITU-T Q.70x series describe a MTP-USER SAP, which we define
here for use with osmocom primitives.
Change-Id: Id1f8892e5dee877e2ffbeb3925753ab3da5a9420
This is more natural to most application code, so simply go for ASCII
string with NUL-termination rather than an array with explicit length.
Change-Id: I6312208cdfa83184be41157a473c96e9120c63db
A xua_msg_class repreents one xUA message class (like M3UA XFER
or SUA CL). A dialect is then something like SUA or M3UA, each
consisting of as many as 256 message classes. Each class contains
value_strings of the individual messages, as well as constraint
information on mandatory IEs for each message.
Change-Id: Ib538aca295b7b50132bc814b2d7b56cbe5d65bfc
A lot of IEIs are identical between the different xUA dialects, so let's
base the SUA definitions on the m3ua definitions.
Change-Id: I64c7166cf0b5c8a927ab7e14955100f8d13fe16a
Sometimes one already has the xua_msg_part and thus can avoid the
lookup that's done by xua_msg_get_u32().
Change-Id: Ie11c35f9528313d0b35786a361d853addd17364f
Neels Hofmeyr
Pau Espin
Harald Welte
Philipp Maier
Neels Hofmeyr