Attention is currently required from: fixeria, laforge, osmith.

Hello Jenkins Builder, fixeria, laforge, osmith,

I'd like you to reexamine a change. Please visit

https://gerrit.osmocom.org/c/libosmo-sigtran/+/40501?usp=email

to look at the new patch set (#6).

The following approvals got outdated and were removed: Code-Review+1 by fixeria, Verified+1 by Jenkins Builder

Change subject: asp: Support Tx DAUD when ASP becomes activated ......................................................................

asp: Support Tx DAUD when ASP becomes activated

Otherwise the local Signalling Point has no way to know whether the remote Signalling Points it wants to talk to are actually already connected to the STP when it becomes active after the process starts up, unless it attempts to transmit a message to it. This pocedure is documented both for M3UA and SUA: * RFC4666 4.6, RFC3868 4.6 * RFC4666 4.5.3, RFC3868 4.5.3 "ASP Auditing" * RFC4666 5.5.1.1.3 "Support for ASP Querying of SS7 Destination States"

The M3UA specs (RFC4666 5.5.1.1.3) explicitly state that the point codes to audit are not to be provided by uppers layers, so picking the ones from the locally configured address book for now: """ Note: there is no primitive for the MTP3-User to request this audit from the M3UA layer, as this is initiated by an internal M3UA management function. """

This is not enabled by default since it's optional according to specs, and some SGs may actually return errors (it's possible according to RFC4666 to deny access to auditing by the SG).

Related: OS#5917 Related: SYS#7501 Change-Id: I7c8c5099d4d00ea6f4a8db59ed6b833fb0ffa43d --- M src/ss7_asp.h M src/ss7_asp_vty.c M src/xua_asp_fsm.c M tests/vty/osmo_stp_test.vty 4 files changed, 120 insertions(+), 17 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/libosmo-sigtran refs/changes/01/40501/6