InvokeTimeouts configuring for MAP and CAP stacks

[vetss]

Now TCAP layer InvokeTimeout is overritten at MAP and CAP stacks:

org.mobicents.protocols.ss7.map.api.MAPDialog:
int _Timer_s = 10000;
int _Timer_m = 30000;
int _Timer_ml = 600000;
int _Timer_l = 136800000;

org.mobicents.protocols.ss7.cap.api.CAPDialog
int _Timer_CircuitSwitchedCallControl_Short = 6000; // 1 - 10 sec
int _Timer_CircuitSwitchedCallControl_Medium = 30000; // 1 - 60 sec
int _Timer_CircuitSwitchedCallControl_Long = 300000; // 1 s - 30 minutes
int _Timer_Sms_Short = 10000; // 1 - 20 sec
int _Timer_Gprs_Short = 10000; // 1 - 20 sec

let's make them configurable at Stack level by getters and setters (we do not have CLI / GUI parameters for MAP / CAP stacks so far).

[abhayani]

Regarding Invoke Timeout, since TCAP DialogImpl#sendComponent() sets invoke timeout at TCAP level, I believe we should remove setting this at MAP/CAP Dialog level.

Below is code in DialogImpl
if (invoke.getTimeout() == TCAPStackImpl._EMPTY_INVOKE_TIMEOUT)
invoke.setTimeout(this.provider.getStack().getInvokeTimeout());

[vetss]

MAP and CAP levels use several type of Invoke timeouts (like small, medium, large etc) which has different values (from 10 seconds to many minutes) and must be different. TCAP stack has only one value and this can not be reused for MAP / CAP stacks.

I have not found a protocol that is used on the top of TCAP where we can use original TCAP value. May be the removing of TCAP Invoke Timeout from CLI / GUI makes sense to avoide of user confusing. At least as for now...

[deruelle]

@javad272 I just assigned this issue to you. If you have any questions feel free to reach out to @vetss

[javad272]

Hi Jean

How can I send my question to vetss?
I need to know about the process that I must obey

On Wed, Jul 27, 2016 at 2:16 PM, Jean Deruelle notifications@github.com
wrote:

@javad272 https://github.com/javad272 I just assigned this issue to
you. If you have any questions feel free to reach out to @vetss
https://github.com/vetss

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#66 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATASjI2qvitV8OQDS2Nm7KIi6mw9IfLrks5qZyjsgaJpZM4IJJDS
.

[deruelle]

just use @vetss in your comments.

On Fri, Jul 29, 2016 at 1:48 PM, javad notifications@github.com wrote:

Hi Jean

How can I send my question to vetss?
I need to know about the process that I must obey

On Wed, Jul 27, 2016 at 2:16 PM, Jean Deruelle notifications@github.com
wrote:

@javad272 https://github.com/javad272 I just assigned this issue to
you. If you have any questions feel free to reach out to @vetss
https://github.com/vetss

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#66 (comment), or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/ATASjI2qvitV8OQDS2Nm7KIi6mw9IfLrks5qZyjsgaJpZM4IJJDS

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#66 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADUB2k06dWDlD-UKaJETMrt6fGO7cfBks5qaeicgaJpZM4IJJDS
.

[javad272]

hi @vetss
would you tell me how to import this project to my eclipse?
should I import as a maven or as a WAR?

[vetss]

Hi @javad272

1. you need to download source code by git locally (master branch)
2. you need to run "mvn mobicents:eclipse" from root folder to create an eclipse project and then load an existing project from Eclipse.

I also strongly recommend to fork your own copy of a github repo where you can save

[faizann]

Hi Guys

I am picking up this one. I can finish it quite fast.
Is it OK or is @javad272 working on it?

[faizann]

By the way SMSC still uses SS7 stack from 7.xxx series. Do we make this change in SS7 8.xxx series or 7.xxxx? I can use the latest 7.4.1404 tag.

[vetss]

Hello @faizann

I think nobody is working on this issue, please take it. Thanks for your work.

Yes, SMSC GW still reuses 7.* jss7 stack and we have not still moved to 8.* (and 8.0 is not stll released). Because of it we are updating now two jss7 github branches "non-netty" (for 7.*) and "master". Hope we will switch SMSC GW to 8.0 finally.

[vetss]

We need to implement it for master (8.x).
We can partly reuse of a PR #86 but (for uniform) avoid of usage of CAPTimerDefault and put parameters directly to MAP/CAP stacks as we have for TCAPStackImpl.dialogTimeout with getters / setters.

MAP.CAPDialog instead of _Timer_CircuitSwitchedCallControl_Short will have something like getTimer_CircuitSwitchedCallControl_Short() that will refers in CAP/MAPDialogImpl to CAP/MAPStack.

MAP / CAP do not have CLI / GUI so far and no need to update CLI / GUI because of it.
We need to update Stacks_Parameters.ods file.

[yevgenys]

@vetss hi, i started to work on this task, and i have questions:

1. how this timeouts expected to be configured ? should i store this timeouts in xmls Map/Cap_management.xml ?
2. should i create new management class's for managing this xml settings?

[vetss]

Hello @yevgenys

how this timeouts expected to be configured ? should i store this timeouts in xmls Map/Cap_management.xml ?

No needed this step. Let's make only getters / setters that can be updated when stack is / is not started

[knosach]

hi @yevgenys will you be able to close this issue till 28.05? If not I will close it by myself in next week

[yevgenys]

@knosach yes, code is ready, i'm testing it, i will create PR today, or tomorrow

[yevgenys]

PR ready, related PRs for smsc and camel:
RestComm/camelgateway#15
RestComm/smscgateway#291

for this PRs just added init persist dir in xml config for JBOSS 5