SCCP Routing based on callingGT

[faizann]

Hi

Currently SCCP routing works by matching calledGT. We can have more control on routing if we can also specify routing matches based on callingGT. This can help a lot in load sharing and blocking of traffic for MO/HR SMS.

This would mean that system will have to match both calling/calledGT for each rule and fall through to the wildcard matches.

[vetss]

Hello @faizann

This functionality makes sense. Can you contribute with it ?

[faizann]

Yes I can contribute that and will do a PR in a few weeks.

[vetss]

Hello @faizann

I have checked you PR https://github.com/RestComm/jss7/pull/230

1) I generally agree with your approach. A rule matches if both called and calling party fits (and only called party if calling party is null). Usage for calling party digits pattern like we have for called party pattern (like "1111/") is also good for me. We have for called party pattern "1111/" with splitting by "/" to have opportunity for replacing of a part of called party digits between "/" and "/" for some digits from a new sccp address (primary / secondary). Example: =="1111/", =="R/K", new address digits=="222/" - and if an original called party address was 111133333 the a new address will be 22233333. For calling party pattern we do not have such replacing functionality. We have "newcgparty-addressid" parameter but it replaces the whole calling party address. WDYT - is it good enough for your tasks or we need to have the behaviour like for called party addresses ?

2) The issue is a rule sorting for which SCCP rule is checked first, second, etc. Current sorting is automated and a user can not specify custom sorting. Now we are introducing a second sorting parameter (calling party address). I see your algo and it looks good for me. But I think we need to think of manually rules sorting tool as a further task.

3) may be it is better to have CLI names with "pattern" suffix like: calling-ai-pattern, calling-digits-pattern for more clear meaning. For calling-*-pattern CLI paramaters functionality I expect that if we miss any of a parameter then it will fit to any calling address.

4) We need to add unit tests for:

• sorting of rules in case when we have / do not have calling party addresses and for same called party address and different set of calling party address parameters
• matching a rule to a pattern for different called / calling addresses / patterns. Please provide them.

5) We need updates for a CLI helpers, GUI and into a manual.

[faizann]

Hi

1-- I thought about making calling party address changing using the pattern/mask just like for called party but this would bring breaking changes to the existing configuration systems with older configuration. How do you recommend we handle this? Do we leave the user to fix their routing if they upgrade to new JSS7 stack? Use versioning of config file? Allow a new callingPartyAddress parameter in parallel to newCallingPartyAddressId?

2-- Indeed it is sometimes confusing as to which rule is handled first. I think the rule ID itself can be used to do the sorting and then SCCP rule find will go one by one in each rule until it finds the one that matches. In this case called/calling party address sorting will have no effect. If someone puts a * rule as on the top then rest of them won't match.

3-- I think for calling-*-pattern it only makes sense for calling-digits-pattern as the rest of the items are exact match. If we allow advanced callingAddress splitting/replace then we can add calling-mask-pattern as well.

4-- Ordering unit test with callingParty is here https://github.com/faizann/jss7/blob/a42366e126cea46c438decdea9de80517e2f03a4/sccp/sccp-impl/src/test/java/org/mobicents/protocols/ss7/sccp/impl/router/RouterTest.java#L433 but I can add more with NULL calling party and do the same for tests for calledParty route test. The same unit test has different calling address and matching. If you can think of some specific cases, I can add those too.

5-- Will update CLI helper. GUI and manual we can do once we are happy with the current changes.

Action plan: I think I can easily add callingAddres replace/split just like calledParty. We can reuse new-calling-address-id with callingAddressMask/Pattern. This means to use new-calling-address-id user will have to provide mask/pattern always. Keeps things consistent but it will break older configurations.

[vetss]

Hello @faizann

1) If we want to have "calling party" like "called party" with a pattern then I see the minimal parameter set usage by (when we replace a whole address): calling-digits-pattern - "" calling-mask - "R" newcgparty-addressid - Backward compatibility can be achieved by a following way: when we are loading a xml file with settings from a previous JSS7 version and we find only "newcgparty-addressid" parameter then we will add "calling-digits-pattern"=="" and "calling-mask"=="R" parameters and previous configuring functionality stays teh same. Please let me know if you think the solution will work from your point of view.

But to be honest I am still not 100% sure we need so an extra complicated solution (with "calling-mask"), may be current (simplier soultion is good enouph). What do you think - do you need the "calling-mask" solution for your side configuring. Another difficult thing is that for calling party a user may want have only a "calling-digits-pattern" for rule selection, only a "newcgparty-addressid" for adderess change and both in different use cases. So let's decide this. What is your opinion for the best way ?

2) "the rule ID itself can be used to do the sorting" - we can do so, a user will be responsible for sorting in this case. Let it be that rules sorting will be a separate task (if current sorting algo fits your demands now).

3) So I see following CLI parameters: sccp rule create backup-addressid loadsharing-algo origination-type networkid calling-mask calling-ai calling-pc calling-ssn calling-tt calling-np calling-nai calling-digits-pattern newcgparty-addressid stackname

(or may be without "calling-mask" if we decide so)

4) It is better to cover all possible cases (also with present / absent of calling-party several options, may be other interesting cases) for both sorting and rule matching cases to be sure that imlementation works in a proper way.

5) agree

Let's decide the solution for 1) and finish the implementation.

[faizann]

Hi @vetss

1-- I don't really need a calling address mask based address change. I only needed a way to match on calling address to control routing better. I think for now lets skip the mask thing and keep it simple as it is. If in future we see the need we can implement it.

2-- Got it. Lets create a separate issue for this and I can help out in implementation.

3-- Sure. I will change the name calling-digits to calling-digits-pattern.

4-- Will add more cases and update the PR.

[vetss]

Hello @faizann

I don't really need a calling address mask based address change

ok, so we can avoid of introducing of "calling address mask based address change". Let's finish this issue fixing.

[faizann]

Done. Please review.

[vetss]

Partly fixed by: https://github.com/RestComm/jss7/commit/6e987d52c86f06ec81c414a9f02ebaf9f740d836 https://github.com/RestComm/jss7/commit/c722956d4973edffb537e42be7bdb8bff855c7ac https://github.com/RestComm/jss7/commit/7830a5d0647c536b7e905d39eb8f3d998a66acd7 https://github.com/RestComm/jss7/commit/c97f1f2a2ca1f1da739629a913cac7dfb0cb7c79 https://github.com/RestComm/jss7/commit/e0a9cc52e1920cda45e02ac51c31c7f67693ed62

[vetss]

Hello @faizann

I have added your PR https://github.com/RestComm/jss7/pull/230 into a master branch. Thanks for your work. I added some fix to GUI continue work and some compilcation errors.

We still need to complete:

• GUI
• manual

We need to make GUI / CLI in the way that new calling party pattern parameters are optional (a possibility not to fill them). Updating of GUI will need that new parameters become present in a web form. We do not have there much free place. Let's check how will it looks like.

[faizann]

HI @vetss

Yeah GUI will get really complicated but I think we can just add the new fields below the older ones and move newcallingpartyaddress-id also down. It will become a big form but we have similar for MProc rules where there are a lot of fields.

Will work on manual now.

[vetss]

Hello @faizann

thanks for announsement

[vetss]

Hello @faizann

thanks for your greate work, I added your PR https://github.com/RestComm/jss7/pull/238 I added some fixes for manual and CLI / GUI accepting for empty parameters. https://github.com/RestComm/jss7/commit/e0a9cc52e1920cda45e02ac51c31c7f67693ed62

I am closing the issue because the implementation is finished.