CAP: SCCP Relay feature implementation

[MarekPisarski]

SCCP Relay is applied for a CAP dialogue established between MSC and JSLEE. When and IDP is received, JSLEE application business logic determines that the call should be relayed on SCCP level to another IN system. In such case JSLEE shall send the IDP message to the target IN system preserving original sender information. Following requirements shall be implemented

1. Relay handling shall be applied to CAP IDP message.
2. The IDP message sent out (relayed) to external platform must have unchanged SCCP part, specifically; • Called and calling party addresses are the same as in original message (SSN and GT attributes)
3. The IDP message sent out (relayed) to external platform must have unchanged TCAP part.
4. The IDP message sent out (relayed) to external platform must have unchanged CAMEL part, with exception of Service Key (Application invoking SCCP Relay Module specifies the Service Key to be used in outgoing IDP.)

[MarekPisarski]

The implementation is ready for contribution. Please assign me to the case.

[deruelle]

@MarekPisarski assigned to you

[vetss]

Hello @MarekPisarski

1. "the call should be relayed on SCCP level to another IN system" - does it mean the same SLEE / same point code or it means sending to another SS7 node ?
2. can you please shortly describe which extra functionality at stack level are you going to provide (to solve this issue), for which stack(s) (for better understanding).

[MarekPisarski]

Hello, Ad.1 - it means another node Ad.2 - relayCapMessage signatures added to CAPProvider interface - implementation to be added on RA level.

[vetss]

Hello @MarekPisarski

I checked your PR (https://github.com/RestComm/jss7/pull/194).

I see you are going to process "relay" procedure when CAP stack has already created CAPDialog and is processing of IDP message. In this case the procedure must include killing of a local dialog (by "capDailog.release()" method). Other thing is - we may be do not need to create a regular CAP dialog but just encode CAP / TCAP message with needed data and send it into SCCP stack. Althow your approach for "createNewRelayedDialog()" will work I think.

I do not see you have omplemented CapProvider.relayCapMessage() methos. May be you can implement them so we can add a full solution ?

Also we discussed internally the following approach. Please check it - may be it is helpful for you.

A solution when we can add an event at the time when a message has just come to SCCP stack for routing. If a message then will be finally routed to a local SCCP user another event “SccpListener.onMessage(SccpDataMessage message)” will be invoked. This new event will be used when SCCP works as a transit node. We can use SCCP stack in this way (for message transit) now but SCCP rules work only based on SCCP dest message addresses. No possibility to make routing depending on a message context / addresses / other parameters. Steps to achieve it: Create a event “void SccpListener.onMessageReceive(SccpDataMessage message);”. We will invoke the event when a data SCCP message has come before routing. A user may change any (??? - let’s discover it) part of SccpDataMessage message. Current solution for SccpListener registering means that a SccpListener is reguistered for one SSN. SCCP transit means that we have to listen messages for any SSN. Let’s make along with “for one SSN listeners” also a general “master” listener that will listen for all SSNs. A new method (than may accept null to remove such listener). void SccpProvider.registerMasterSccpListener(SccpListener listener); Then we will create some application that will be deployed at the top of SCCP stack and listens onMessageReceive() event and change dest address (and may be other staff depending on needed routing results). In this event we need to have a possibility of parse TCAP (and may be MAP / CAP / ISUP) message content and get from there needed details like transactionId or may be even data from MAP / CAP parts. TCAP stack itself does not have now good functionality just for message parsing. We have now two modes: a) regular behaviour (for as per specification message processing) b) preview mode (that listens all messages and tries to connect relations between messages into dialogs). For FEP we just need to a parse one message and have a possibility to take parameter(s) from TCAP payload and (as an option) from MAP / CAP payload. And we can make routing decision depending on these parameter values. We can formalize parsing by adding a method: ParsedTcapMessage TCAPProvider.parseTcapMessage(SccpDataMessage message); ParsedTcapMessage - a new class that will contain a parsed message on board and also a message type (TC-BEGIN etc) and error if occurred in parsing. We need to parse in such way also MAP and CAP messages.

[vetss]

"Ad.2 - relayCapMessage signatures added to CAPProvider interface - implementation to be added on RA level." - why do we need it at RA level ? Sometimes stack is used as standalone without RA. It is moer reasonable to implement it at stack level...

[vetss]

Also please take into account that CAP stack instead of CircuitSwitchedCall covers also SMS and GPRS parts, I think we need to cover them too.

[vetss]

Hello @MarekPisarski

I have added your PR https://github.com/RestComm/jss7/pull/194 into non-netty branch. It will be included into JSS7 release 7.3. This is a commit: https://github.com/RestComm/jss7/commit/2186359f2007d2bc849f88443fe3d5b752b6fc5a

I have not added the PR into master branch. I still think we need to implement a more common solution for the next release that will cover all / most cases