Bug #5145
closedDon't require a NTFY(AS-INACTIVE) after ASP-UP procedure
100%
Description
When we're in the ASP role, the current behavior is as follows:
- perform the ASP-UP procedure (outbound)
- wait for incoming NTFY
- if that arrives before T_NOTIFY times out: proceed with outbound ASP-ACTIVE procedure
- if T_NOTIFY times out: attempt RKM routing key registration
While this is in-line with the various ladder diagrams in RFC4666, that same RFC states the SG should send the NTFY. It doesn't say must.
We currently encouter a presumed Ericsson peer that doesn't send said NOTIFY.
So we should tolerate such a scenario, and attempt the ASP-ACTIVE procedure
As RKM is apparently a relatively rarely implemented M3UA feature, it's probably best to make the behavior on T_NOTIFY timeout configurable, so the user can choose whether to- attempt a blind ASP-ACTIVE, or
- attempt RKM registration
Updated by laforge almost 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 80
https://gerrit.osmocom.org/c/libosmo-sccp/+/24213
TTCN3 test case still missing
Updated by laforge almost 3 years ago
After writing a TTCN3 test, I found out during testing that the intended behavior is actually already supported: If there is no asp->lm (layer manager) assigned, the xua_asp_fsm directly proceeds to ASP-ACTIVATE after athe ASP-UP procedure!
So the in this case undesired behavior is present in the xua_default_lm_fsm, our default layer manager. That is only ever used when osmo_sccp_simple_client_on_ss7_id() is used, and I'm starting to regret I ever wrote the notion of this "simple client" back then, wanting to make it easier for other developers to set up SIGTRAN in the various applications.
The related commit reads :
commit ed15c74a01a044afc087a02f0e947ae49533762a
Author: Harald Welte <laforge@gnumonks.org>
Date: Fri Apr 7 17:14:54 2017 +0200
Add a default layer manager using RKM to register PC with SG
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
So now we have the choice on whether to keep the quirk, or whether to make the default layer manager optional in the simple_client...
Updated by laforge almost 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
patch and test case merged
