Feature #4701
implement OsmoSTP notification of peers disconnecting, e.g. for OsmoBSC to detect that a specific MSC in the pool is disconnected
100%
Description
This is a spin-off from the discussion in #4619 (where the MSC-pooling tests leave osmo-bsc in a state of assuming presence of MSCs that have disconnected)
and also related to #2623 (which is actually more about sending RESET upon re-connect)
The aim is to be able to immediately notify of disconnected peers across the STP (e.g. BSC <-> MSC).
laforge wrote:
On Fri, Aug 07, 2020 at 01:44:00PM +0000, neels [REDMINE] wrote:
Now I need to pinpoint what exactly the right mechanism would be for osmo-bsc to realize that an MSC is no longer connected.
Without any active calls (SCCP connections) you don't really know.
The only situations are:
- SCCP connection timers timing out (if there are any active SCCP connections)
- SCCP network informing the user about unavailability of a given point code
- we don't imlpement this in Osmocom so far, but there are messages like
M3UA DUNA/DAVA that can be used by an STP to notify M3UA ASPs like the BSC about
availability/unavailability of a given point code.- libosmo-sigtan would have to parse such messages and send N-NOTICE.indication
from the SCCP provider to the SCCP user (local SCCP user like MSC, BSC, ...),
as well as N-INFO.indication for active SCCP connections
Related issues
Associated revisions
History
#1 Updated by neels 7 months ago
- Related to Feature #2623: SCCP/M3UA: detect restart of osmo-msc and osmo-sgsn added
#4 Updated by laforge 22 days ago
- Assignee set to neels
I've implemented notification of SCCP users via the SCCP-User SAP in https://gerrit.osmocom.org/c/libosmo-sccp/+/22778
This means that every time a [remote] point code becomes available or unavailable, the SCCP user application (MSC, BSC, SGSN, SMLC, ...) should now receive a N-PCSTATE.ind stating the "affected point code". and either
sp_status OSMO_SCCP_SP_S_INACCESSIBLE or OSMO_SCCP_SP_S_ACCESSIBLE.
This indication should then be used by the applications to trigger whatever internal logic that needs to happen if a remote point-code disappears or re-appears. I'll leave that part to @neels. I'll just implement some tests to ensure we get those notifications as expected now.
#5 Updated by laforge 18 days ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
- We have MTP-level notifications by means of M3UA DUNA/DAVA in place now, as shown by the below three test cases
- TC_ssnm_aspac_dava_aspia_duna
- TC_ssnm_distribution_dava_duna
- TC_ssnm_distribution_dava_duna_multipc
- those are now reported via N-PCSTATE primitives on the SCCP user SAP
There's some additional work in the pipeline to also provide separate notifications of SSN availability, etc. but none of that would strictly fall within the scope of this specific issue. Marking it resolved.
ctrl: Fix CTRL TRAP for {msc.X,msc_)connection_status not sent
The tx TRAP callback is triggered through a signal which is never sent in
osmo-bsc code, and never was as far as I can tell going quite far in the
logs.
In the meanwhile, the msc_connection_status was left in favour of
multi-msc msc.X.connection_status CTRL variable, so let's prepre the cb
function to work for that onei too, dropping global variables which may lead
to wrong output in multi-msc environments, and simply use msc->nr==0 for
the old variable "msc_connection_status".
The signal is now triggered in a_reset when the A conn becomes connected
or disconnected. As a result, a user waiting for the disconnect event
may notice that the status may be changed with a noticeable delay, since
the A conn may be reset only due to high layer timeouts after several
repeated failures (T4, BAD_CONNECTION_THRESOLD).
Related: OS#2623
Related: OS#4701
Related: SYS#5046
Change-Id: I645d198e8e1acd0aba09d05cb3ae90443946acf8