Splitting CAP API for gsmSSF/gsmSCF parts

[raidan2]

It's quite confusing when you have single interface org.mobicents.protocols.ss7.cap.api.service.circuitSwitchedCall.CAPServiceCircuitSwitchedCallListener with all methods for both sides of CAP participation.

I believe in most cases you always know if you gsmSCF or gsmSSF.

I suggest splitting this interfaces into 2 parts: CAPServiceCircuitSwitchedCallSCFListener and CAPServiceCircuitSwitchedCallSSFListener.

For instance void onInitialDPRequest(InitialDPRequest ind); and such should be moved into SCF interface (because it must be handled on SCF side).

On the other hand void onApplyChargingRequest(ApplyChargingRequest ind); is a method of SSF.

Same story for other components.

Of course it will require additional refactoring of CAPServiceCircuitSwitchedCallImpl, CAPServiceBaseImpl and so on.

[vetss]

Hi @raidan2

your suggestion in theory make sense but we have many users that will have to refactor their applications after this upadate (it is a major one). And this update will not give a big profit in practice. I think if we start it it it useful but update of working system will not give a big profic, so let's leave it now as it is.

[deruelle]

We can plan it for a next major upgrade of jSS7 ie a 8.0.0 version where it is acceptable to break backward compatibility

[raidan2]

@vetss @deruelle I agree, it's a quite big change.

Two notes:

1. I just upgraded to version 8.0.39 — isn't a 8x release?
2. It's possible to reduce amount of migration for clients by keeping old interface as a combination of new ones

interface CAPServiceCircuitSwitchedCallSCFListener {
   void onInitialDPRequest(InitialDPRequest ind);
   ...
}

interface CAPServiceCircuitSwitchedCallSSFListener {
   void onApplyChargingRequest(ApplyChargingRequest ind);
   ...
}

interface CAPServiceCircuitSwitchedCallListener extends CAPServiceCircuitSwitchedCallSCFListener, CAPServiceCircuitSwitchedCallSSFListener { }

This couldn't even require any change from clients code.

[vetss]

Hello @raidan2

1. 7.0 release is already released. We are working now for next 8.0 release that code is present in master branch
2. Except of listeners we need to think of a sender part like CAPDialogCircuitSwitchedCallImpl and CAPDialogCircuitSwitchedCall that must implement a half of functionality. Also we need to implement reaction for case when a message is coming from a peer that is not allowed for SCF or SSF. I am not sure that just common listeners will solve all problems in migration. That is why we need to think strong will the advantage of interface splitting bigger then disadvangates of migrations.