New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAP: SCCP Relay feature implementation #192

Open
MarekPisarski opened this Issue Jan 11, 2017 · 8 comments

Comments

Projects
None yet
3 participants
@MarekPisarski

MarekPisarski commented Jan 11, 2017

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

This comment has been minimized.

MarekPisarski commented Jan 11, 2017

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

@deruelle

This comment has been minimized.

Member

deruelle commented Jan 11, 2017

@MarekPisarski assigned to you

@vetss

This comment has been minimized.

Collaborator

vetss commented Jan 11, 2017

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).

@vetss vetss added the enhancement label Jan 12, 2017

@vetss vetss added this to the 8.0.0 milestone Jan 12, 2017

@MarekPisarski

This comment has been minimized.

MarekPisarski commented Jan 12, 2017

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

@vetss

This comment has been minimized.

Collaborator

vetss commented Jan 12, 2017

Hello @MarekPisarski

I checked your PR (#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

This comment has been minimized.

Collaborator

vetss commented Jan 12, 2017

"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

This comment has been minimized.

Collaborator

vetss commented Jan 12, 2017

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 vetss modified the milestones: 8.1.0, 8.0.0 Feb 21, 2017

vetss added a commit to vetss/jss7 that referenced this issue May 10, 2017

fix for issue RestComm#192 @github SCCP Relay feature implementation
Conflicts:
	cap/cap-api/src/main/java/org/mobicents/protocols/ss7/cap/api/CAPProvider.java
	cap/cap-impl/src/main/java/org/mobicents/protocols/ss7/cap/CAPProviderImpl.java
@vetss

This comment has been minimized.

Collaborator

vetss commented May 10, 2017

Hello @MarekPisarski

I have added your PR #194 into non-netty branch. It will be included into JSS7 release 7.3.
This is a commit: 2186359

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment