Proxy CAP dialogs

[barbos...@gmail.com]

Hello to all,

Once I did forward CAP InitiaDP to new service, but didn't investigate response processing.. Now I have a task to create CAP Proxy and discover some problems.

The simpliest scenario is like this:

1. Sbb receives InitialDP (event InitialDPRequest) as part of origin capDialog (lets call it Dialog1).

2. We create new capDialog (lets call this dialog Dialog2) with new TCAP ID, and initiate InitialDP to another system.

3. We receive release command (event DialogRelease) as part of Dialog2, which we have to proxy back to Dialog1.

4. End of scenario.

So when we receive InitialDP, we create new dialog and via javax.slee.ActivityContextInterface#attach, attach Dialog2 to Dialog1 (sbbContext.sbbLocalObject).

But when we receive release command addressed to Dialog2, we can't get original Dialog1, because capProvider = sbbContext.getResourceAdaptorInterface(CAP_RA_TYPE_ID, CAP_RA_LINK) as CAPProvider is an instance of org.restcomm.slee.resource.cap.wrappers.CAPProviderWrapper, which has method org.restcomm.slee.resource.cap.wrappers.CAPProviderWrapper#getCAPDialog, which doesn't have access to pool of available dialogs.

So, our questions are:

- is it possible to get access to org.restcomm.protocols.ss7.cap.CAPProviderImpl?

- is there another right way to attach two dialogs and get access from events of Dialog2 to Dialog1?

- is it possible at all to realize such scenario?

Best regards,

Sergey Yashchenkov

[Vladimir Tzanev]

Hi Sergey,

 CAPProviderWrapper#getCAPDialog(TxId) returns a CAPDialogActivityHandle.
Now call getActivity()-> CAPDialogWrapper.
And on the CAPDialogWrapper you can invoke release or close(boolean) – I’m not sure, which was the correct method to send a release message, It's some years ago...

But, why so complicated (2 dialogs, TCAP, CAP stack, application)?

Is it not possible to implement it just with a simple M3UA + SCCP stack, which receive and forward messages, based on SCCP rules? Some years ago, I've implemented a simple SS7FrontEnd in such manner. It was based on the map load server, but without TCAP & MAP layer. 
https://github.com/RestComm/jss7/blob/master/map/load/src/main/java/org/restcomm/protocols/ss7/map/load/Server.java

BR, 
Vladimir

[barbos...@gmail.com]

Hello Vladimir,

Maybe we use different versions of RAs. In the version that we use 8.0.0-128,  CAPProviderWrapper#getCAPDialog(TxId)  return CAPDialog via call:

CAPDialogActivityHandle ah = new CAPDialogActivityHandle(dialogId);

return (CAPDialog)this.ra.getActivity(ah);

In turn, CAPDialogActivityHandle has field private transient CAPDialogWrapper activity, which is null. So as a result, this.ra.getActivity(ah) returns null.

As field transient, maybe we have to add an explicit call of setActivity(CAPDialogWrapper activity) somewhere? 

 

We need it in a such complicated way because we have to add some logic between proxy interrogation, and responses will not always be the same as Dialog2 returns.

Best regards,

Sergey Yashchenkov

пятница, 4 декабря 2020 г. в 19:34:59 UTC+3, Vladimir Tzanev:

[barbos...@gmail.com]

Images were not attached in the previous message.

Best regards,

Sergey Yashchenkov

пятница, 4 декабря 2020 г. в 19:34:59 UTC+3, Vladimir Tzanev:

[barbos...@gmail.com]

Can anyone point me what is the best way to proxy two CAP Dialogs?

It looks like we have to keep two Sbb alive and they should communicate.

Best regards,

Sergey Yashchenkov

понедельник, 7 декабря 2020 г. в 10:26:11 UTC+3, barbos...@gmail.com:

[Vladimir Tzanev]

Hello Sergey,

Sorry, we had a long weekend (bank holiday). You have right, maybe this is working only for the dialog of the incomming message. 

But in the CAPResourceAdaptor you have access to the unwrapped CAPProvider (protected CAPProvider realProvider) and the CAPProvider.getCAPDialog(Long dialogId) should give you the expected dialog.

@Override

public CAPDialog getCAPDialog(Long dialogId) {

synchronized (this.dialogs) {

return this.dialogs.get(dialogId);

}

}

Maybe this can help you.

BR,

Vladimir 

[barbos...@gmail.com]

Hi Vladimir,

Maybe I get it wrong, but in my case capProvider already CAPProviderWrapper..

Looks like I have to investigate another way of proxy realization. Add two Sbb, which should communicate with each other and at the same time be responsible for unique TCAP dialog.

Best regards,

Sergey Yashchenkov

среда, 9 декабря 2020 г. в 16:35:24 UTC+3, Vladimir Tzanev:

[Vladimir Tzanev]

Hi,

But in the CAPProviderWrapper you have access to the RA (getRa()). 

You must just extend CAPResourceAdaptor with access to realProvider (or at least to the method getCAPDialog)

BR

[barbos...@gmail.com]

Hello Vladimir,

Thank you for the suggestion, but it looks like I have to change the conception of service.

There are should be two Sbb, each should handle particular Dialog1 and Dialog2 (so we don't have to switch between dialogs), and they should communicate with each other to send commands and notify about the current state.

I'm ashamed to admit that I just started to learn jain slee specification deeper and hope I will find the solution soon.

Do you know, what is the best way to accomplish service this way? Via fire and handle custom events or communicate via Sbb local objects and extension of SbbLocalInterface?

Best regards,

Sergey Yashchenkov

среда, 9 декабря 2020 г. в 17:15:45 UTC+3, Vladimir Tzanev:

[Vladimir Tzanev]

Hi Sergey,

 Via fire and handle custom events . We have such a framework with 1 Sbb for session control and 1 Sbb for call control - and they communicate via custom events.

BR,

Vladimir

[barbos...@gmail.com]

Hello Vladimir,

If I understand correctly, they communicate via ActivityContextInterface?
Could you please point to some open-source examples with approximately the same implementation?

Best regards,

Sergey Yashchenkov

четверг, 10 декабря 2020 г. в 14:51:02 UTC+3, Vladimir Tzanev:

[Vladimir Tzanev]

Hi Sergey,

You can check https://github.com/RestComm/jain-slee.media - in examples / mgcp-demo the conference-sbb uses custom events (ConferenceInitiate & ConferenceTerminate)

BR,

Vladimir

[barbos...@gmail.com]

Hello Vladimir,

Thank you so much for your help!

Best regards,

Sergey Yashchenkov

пятница, 11 декабря 2020 г. в 15:34:03 UTC+3, Vladimir Tzanev:

[barbos...@gmail.com]

Hello Vladimir,

After study Jain Slee specification I've tried to implement some custom events but got stack with two main issues:

1. How can I get a correct generic Activity Context Interface to pass it to fire event method? In documentation there is 

Right now call fire event method from event handler method, so I tried just to pass Activity Context Interface which I got there, and looks like it's incorrect.

2. How to respond back to the initiator?

I have FirstSbb which fire event InitiateInitialDP. SecondSbb has an event handler method to process this event, so while processing this event it creates new capDialog, send InitialDP event, attach itself to new ActivityContextInterface and waiting for responses.

When SecondSbb receives RequestReportBCSMEventRequest it should send it back to FirstSbb.. Just fire a new event from SecondSbb is incorrect, as it doesn't call the same Sbb Entity which did fire the initial event. So my question here is how to send a response back to origin SbbEntity? I may make an assumption that I have to assign FirstSbb to the new ActivityContextInterface created in FirstSbb, so than the RequestReportBCSMEventRequest event (and all others related to this activity) will be handled by FirstSbb.

Looks like I miss some main concept here..

Could you please point my how this could be done?

Best regards,

Sergey Yashchenkov

[barbos...@gmail.com]

Just for history and new developers who will try to solve the same task. I spent almost 2-3 days in common, trying to implement via custom events and then to find the correct way via  SBB Local Interfaces  .

This is also written in Jain Slee documentation, that communication between Sbb Components possible via SBB Local Interfaces.

If you need to process capDialog in FirstSbb, initiate a second capDialog via SecondSbb, and proxy all responses related to this dialog to FirstSbb - then you have to use Parent-Child architecture and parent's callbacks.

More details I've found here: 

1. Some description of callbacks in Jain Slee: https://docs.jboss.org/mobicents/jain-slee/2.5.0.FINAL/enablers/rest-client/user-guide/en-US/html/integrating.html

2. Example project: https://github.com/RestComm/jain-slee.sip.git

Check out SIPRegistrarSbb and DataSourceChildSbb relations as examples.

Best regards,

Sergey Yashchenkov

вторник, 22 декабря 2020 г. в 16:56:56 UTC+3, barbos...@gmail.com:

[yulian_o]

Hi
I think your requirements are incorrect. In case you would like to proxy Dialog why would you need to go to CAP layer? I mean you can use TCAP RA , and proxy TCAP messages from one leg to another... 
BR
Yulian Oifa