implement OsmoSTP notification of peers disconnecting, e.g. for OsmoBSC to detect that a specific MSC in the pool is disconnected
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).
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
- 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.
- 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
- 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.