path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2 daysipa: VTY config option to explicitly enable/disable SCCP patchingHarald Welte1-0/+6
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
3 daysMove definition of LOGSS7() to header file; add LOGPAS() like LOGPASP()Harald Welte1-1/+7
Change-Id: Ic85fc460cc1f31d0fb407095afe417ceaa60e7bd
2019-05-01xudt: Implement address and data extractionHolger Hans Peter Freyther1-0/+54
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
2019-04-12add osmo_sccp_addr_cmp(), osmo_sccp_addr_ri_cmp()Neels Hofmeyr1-0/+3
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
2019-04-12add caller-owns-msgb variant osmo_sccp_user_sap_down_nofree()Neels Hofmeyr1-0/+1
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
2019-03-15Fix output of route destination in 'show ss7 instance <0-15> route'Harald Welte1-0/+1
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
2018-11-19Make pointcode width function publicMax1-0/+2
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
2018-10-29skip simple-client default as/asp when saving VTY configStefan Sperling1-0/+6
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
2018-10-21build: move include/{mtp,sccp} to include/osmocom/Neels Hofmeyr8-2/+2
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
2018-09-27cosmetic: allocate ss7->sccp in one common functionNeels Hofmeyr1-0/+2
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
2018-07-12add osmo_xua_msg_tall_ctx_init()Neels Hofmeyr1-0/+2
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
2018-06-08Introduce osmo_ss7_register_rx_unknown_cb() for unknown PPID/StreamIDHarald Welte1-0/+11
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
2018-01-17sccp_types.h: Fix value for SCCP_REFUSAL_UNEQUIPPED_USERHarald Welte1-1/+3
It seems we have been sending the wrong numeric value in SCCP connection refusal due to an unqeuipped user. It turns out our list of refusal causes was missing one entry, causing an off-by-one for this refusal cause. While at it, add a comment which section of which spec is relevant for this enum. Change-Id: I113645bd6df1ec9ae5137977028df38560fc4789
2017-12-24add osmo_ss7_route_name()Neels Hofmeyr1-0/+1
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
2017-12-24add osmo_sccp_user_name()Neels Hofmeyr1-0/+2
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
2017-12-20ss7: Re-bind xUA server socket after setting new IPPau Espin Pedrol1-0/+5
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 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
2017-11-08add osmo_sccp_inst_addr_name(), a variant of osmo_sccp_addr_name()Neels Hofmeyr1-0/+1
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
2017-10-26sccp_scrc: fix Network Indicator in SIO compositionNeels Hofmeyr1-1/+1
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
2017-09-03sccp_sap.h: Fix SSN for BSSAP and BSSAP-LEHarald Welte1-2/+3
* 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
2017-08-11sccp: fixup for osmo_sccp_get_ss7()Philipp Maier1-1/+1
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
2017-08-11sccp: function to get sccp instance from sccp userPhilipp Maier1-0/+1
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
2017-08-11sccp: make osmo_sccp_addr_name() availablePhilipp Maier1-0/+1
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
2017-08-10sccp: prefix default parameters of osmo_sccp_simple_client()Philipp Maier1-7/+10
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
2017-08-09add osmo_sccp_addr_name() and three value_string[]sNeels Hofmeyr1-0/+13
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
2017-08-09introduce OSMO_SCCP_RI_NONE to indicate unset RINeels Hofmeyr1-0/+1
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
2017-08-09constify ss7_instance arg of osmo_ss7_pointcode_print()Neels Hofmeyr1-2/+2
Change-Id: I8c6b7188d004033e75e9c41f4a65c418d13a79c5
2017-08-09add OSMO_SS7_PC_INVALID, add osmo_ss7_pc_is_valid()Neels Hofmeyr1-0/+8
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
2017-08-09sccp: add function to check sccp addressesPhilipp Maier1-0/+2
In order to catch invalid CS7 configurations, It is necessary to check if sccp addresses contain plausible address data. Change-Id: Ic6245288b0171eae10aa708403c1ddb584c92f38
2017-08-07osmo_ss7_vty_init: ensure a talloc ctx is set by userNeels Hofmeyr1-3/+2
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
2017-08-07add osmo_sccp_addr_set_ssn()Neels Hofmeyr1-0/+2
Will be used by e.g. osmo-hnbgw to add an SSN to addresses obtained from the sccp address book. Change-Id: I85b46269dbe7909e52873ace3f720f6292a4516c
2017-08-01sccp: derive local address from given sccp instancePhilipp Maier1-0/+4
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
2017-07-22sccp: make simple client configurable via VTYPhilipp Maier1-0/+5
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
2017-07-20sccp: global addressbook search + api fixPhilipp Maier1-4/+4
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
2017-07-05simple-client/server: be able to decide on which ss7 instance to bindPhilipp Maier1-0/+11
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
2017-06-29sccp_helpers.h: remove duplicate declaration of osmo_sccp_make_addr_pc_ssn()Neels Hofmeyr1-2/+0
Change-Id: Ifbb03de3df3b9bac86fb97dfc8e81e99fc172292
2017-06-25add/tweak various logging to help figure out complex routingNeels Hofmeyr1-0/+1
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
2017-06-23cosmetic: drop second ';;'Neels Hofmeyr1-1/+1
Change-Id: I861b87e485d94f17e4b4a800c8da865f98633c92
2017-06-22sccp: Fix a classic typo of mineHolger Hans Peter Freyther1-7/+7
Change-Id: Ie1194406d9d9c62a513fac35ffa458957809a0e3
2017-06-21sccp: add addressbook functionality for sccp addressesPhilipp Maier2-0/+7
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
2017-06-18cosmetic: Fix typo in sccp_types.hPhilipp Maier1-1/+1
2017-04-18IPA: Override/Set point codesHarald Welte1-0/+3
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
2017-04-18Add IPA/SCCPlite support as SIGTRAN alternativeHarald Welte1-0/+4
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
2017-04-15introduce new osmo_ss7_asp_disconnect() functionHarald Welte1-0/+1
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
2017-04-15osmo_ss7: Clean up all ASPs established via xua_server upon destroyHarald Welte1-0/+4
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
2017-04-14get rid of global osmo_ss7_xua_servers variableHarald Welte1-1/+2
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
2017-04-14SCCP: Add VTY interface for SCCPHarald Welte1-0/+2
Change-Id: I100daaa947dbab6a4528c4e9fbd0d30790288f63
2017-04-14move osmo_ss7_vty.c [back] into libosmo-sigtranHarald Welte1-0/+8
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
2017-04-14STP: re-structure VTY interface; introduce 'cs7 instance' nodeHarald Welte1-0/+1
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
2017-04-13xua_rkm: Make dynamic registration of Routing Keys workHarald Welte1-0/+4
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
2017-04-13Add a default layer manager using RKM to register PC with SGHarald Welte2-1/+14
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