SCCP: adding UpdateL4() to force of SCCP be informed of states of DPC link

[vetss]

Tran reported the bug in SCCP stack. We have loadsharing at SCCP level to two m3ua (and SCTP) links. One of the links is constantly down because of some IP issues operator's and another one comes up. Then SCCP routes messages to both links althow it should route to the active link only.

I think that the reason is because:

• SCCP stack uses RemoteSignalingPointCodeImpl class to check if the link (DPC code) up or down.
• by default remoteSccpProhibited parameter is false so this means "not prohibited"
• if m3ua link never was up then SCCP has never received MTP-PAUSE message and RemoteSignalingPointCodeImpl thinks that the link is "not prohibited"

So we make proper loadsharing only if both links were up for some time after stack start.

I tested at with SMSC GW (just one link without loadsharing to SS7 Simulator): before the first SCTP connection the error message is:

2016-04-13 18:51:46,719 ERROR org.mobicents.protocols.ss7.m3ua.impl.M3UAManagementImpl Tx : No AS found for routing message TransferMessage: {528=Protocol opc=2 dpc=1 si=3 ni=2 sls=1}

(SCCP passes SCCP level and failes at m3ua - sccp does not know that the link is down)

and after I have connected / disconnected SCTP link and I see this:

2016-04-13 18:54:30,712 WARN org.mobicents.protocols.ss7.sccp.impl.SccpRoutingControl Received SccpMessage=Sccp Msg [Type=-1 networkId=0 sls=4 incomingOpc=-1 incomingDpc=-1 outgoingDpc=-1 CallingAddress(pc=0,ssn=8,AI=18,gt=GlobalTitle0100Impl [digits=22220, natureOfAddress=INTERNATIONAL, numberingPlan=ISDN_TELEPHONY, translationType=0, encodingScheme=BCDOddEncodingScheme[type=BCD_ODD, code=1]]) CalledParty(pc=0,ssn=8,AI=18,gt=GlobalTitle0100Impl [digits=777777777000, natureOfAddress=INTERNATIONAL, numberingPlan=ISDN_TELEPHONY, translationType=0, encodingScheme=BCDEvenEncodingScheme[type=BCD_ODD, code=2]]) DataLen=66] for Translation but primary Remote Signaling Pointcode = 1 is prohibited

so error at SCCP level

[vetss]

I made some revision how we can fix the issue (SCCP stack does not know at the start of a DPC link a status - is it up / down / congested). This affects m3ua, Dialogic and Dahdi cases in the case when

• sccp stack becomes up after m3ua links have connectd
• sccp application becomes up / runs after a dialogic / dahdi card has been already initiated and links are up

I have found in dialogic API ("Dialogic® SS7 Protocols. MTP3 Programmer’s Manual" - chapter "3.5.12 MTP_MSG_UPDATE_L4 – Update Level 4 Request" :

Description This message is sent to the MTP3 module to request that all user parts are notified of the current route status for the given destination using the normal MTP PAUSE, MTP RESUME and MTP STATUS primitives. The message is intended for use after new routes have been configured or following additional user part configuration on a live system (for example, the addition of a new ISUP circuit group). It allows the user to ensure that the user part is updated with the current accessibility of the destination. The confirmation message indicates success or failure in the status field of the header (success = 0). Parameters • dpc The destination point code for which a status broadcast is requested.

So I guess we can force a Dialogic board (via GctLib API) to update us for a state of a specified DPC. Amit, do you have any experiense / ideas for it ? I guess for our m3ua stack we can provide the same functionality.

If we agree with this we can do following:

1. SCCP: remoteSccpProhibited / remoteSpcProhibited leave false by default (to keep current behavoir for parts that we can not update)

2. interface Mtp3UserPart - add a method: void UpdateL4(int dpc);

3. DialogicMtp3UserPart: implement UpdateL4(int dpc); method.

4. m3ua stack implement UpdateL4(int dpc); method. I have not check how. Possibly for MTP-PAUSE / MTP-RESUME we can check routing tables and find the active AS / ASP. Amit, may be you can advise here. For MTP-STATUS - we have now implemented a congestion state for links - so we need to reuse it.

5. Dahdi: do not update now. May be community help us

6. SCCP invoke UpdateL4() :

• at the stack start for existing RemoteSignalingPointCode resources
• at the moment when a RemoteSignalingPointCode resource has been added
• optionally: periodiaclly or by CLI / GUI command (possibly later)

7. ISUP stack : I do not have any info how to update it. We will have new updates in MTP part that is not covered for ISUP

• congestion control
• UpdateL4() I think we need to create issues for it for future.

I suggest to do it only in netty-2 branch. This is a major interface update, like we have for congestion control.

[vetss]

For dialogic board case I have created a separate issue: https://github.com/RestComm/jss7/issues/87 See also https://github.com/RestComm/jss7/issues/54 (same case)