SCCP: matching rules with SSN present

[gfigiel]

Currently SCCP router rules ignores SSN value while matching rules over received CalledPartyNumber.
Thus there is a problem with GTT when single GT supports several SSN and receives messages with RI= Route on GT (like SCP supporting CAP & MAP simulanously on the same GT).

SCCP rule matching should check if pattern SSN matches the received CdPa address SSN.

[vetss]

Hello @gfigiel,

I have checked your pull request (#74). I have following remarks:

1. this update means a major behavour update. Now a rule matches in case of any SSN that is in a rule pattern. This means that if a user specify a wrong SSN value then just after this update sccp will stop work. We need at least the behaviour for when a pattern's SSN==0 or <0 or >255 this means that this rule applies to any SSN of a dest address.
2. We can nto add so many debug level logging for any rule checking. This will lead very heavy logs in big traffic case.

Can you provide an update that takes into account "1)" and does not add any extra logging.

[gfigiel]

Hello @vetss
Sorry for delay - I analysed again the code and here are my doubts:

1. this update means a major behavour update. Now a rule matches in case of any SSN that is in a rule pattern. This means that if a user specify a wrong SSN value then just after this update sccp will stop work. We need at least the behaviour for when a pattern's SSN==0 or <0 or >255 this means that this rule applies to any SSN of a dest address.

If user configures stack in a wrong way it should not work - I think this is correct behaviour - user must ensure the correct configuration values are set. Regarding required behaviour you described - I mentioned in pull request:

Otherwise if pattern AI has SSN present bit unset - received SSN always matches (it means wildcard pattern SSN setting).

So this setting appropriate AI value in pattern will result in rule matching as you specified - no SSN bit set in AI => any SSN in received dest address matches. Does it cover you requirement or please clarify more regarding matching algorithm you described. Anyway current rule maching impelemntation does not allow support for different SSN with the same DPC for final GTT.

2. We can nto add so many debug level logging for any rule checking. This will lead very heavy logs in big traffic case.

I used conditions if(logger.isDebugEnabled()) when logging so I think the performance impact on INFO logging levels (production one) should not be heavy - what do you think?. Anyway my intention was to know which rule matched the incoming request in case integration debugging is needed... As least I would leave additional debug message for RouterImpl class when rule is matched as to know which rule was indeed matched.

Br,
Greg

[vetss]

Hello @gfigiel,

I fully share your point of a user must properly configure routing rules and "wrong SSN / AI value" must follow a bug in routing. But the problem is that before we did not have such restrictions (AI must contain or not SSN referense in order to SSN value will affect or not and SSN must be properly configured). This means that many users that followed our old manual will just face that rules will stop working. We need to follow backward compatibility as much as possible to simplify the life of users. We have (as for my experiense) may installations that SSn==0 but AI may say that SSN is included.

1. Therefor I need to ask you make the best behavior that covers your needs and let some old installations work with a min number of problem with behaviour:

• SSN value from Rule pattern will be taken into account if both is true:
  • AI bit 0x01 says "ssnPresent" and
  • SSN value of a rule pattern >1 and <256 (so SSN==0 will not taken into account even when AI has "ssnPresent").
    SSN==0 means management messages. Do you really want that management messages' SSN must be also affected by such rules ? If yes, please let me know a use case for it.

2. we use warn / info and debug log levels also in production. Debug level is used when we have a bug / error that we can not find easily. For Debug level for your case we can add ONE message for all matching rule process for a message. AFAIR we have now a WARN message is no rule passes. We can add one DEBUG level messages like "for message ... the rule ... is matched. SCCP address before translation ... after translation". If you really need for debugging results like rule #x matched or not please use TRACE level.

Please let me know if the requirenmensf fit your needs and you can finish the update.

[vetss]

I have not managed to extract a cherry pick update after your pull request. I have created a cumulative update and commited it into master and netty-2 branches:
da42dcf

Thanks for your work.