SCCP routing/translation logic

[Igor Vukomanovic]

Hi,

I'm playing around with jSS7 and I'm quite puzzled about SCCP routing/translation logic in one case.

I'm looking at the translationFunction() and RuleImpl code and cannot see that SSN provided in the rule pattern is used anywhere in the logic. Only GT is used in the matching logic in RuleImpl (only pattern.getGlobalTitle() is invoked, and pattern.getSubsystemNumber() is never invoked).

So I don't quite understand the purpose of the SSN value in the the rule pattern?

For example, I thought I could use this value to have two different rules (different by SSN, same by GT)...but in this example 2nd rule is never matched, although the SCCP address passed into the matching logic does have the SSN value included. So in this example I was expecting I could have a match by SSN+GT:

<id value="1"/>

<value ruleType="Solitary" loadSharingAlgo="Undefined" originatingType="LocalOriginated" mask="K" paddress="2" saddress="-1">

<patternSccpAddress pc="0" ssn="8">

<ai value="18"/>

<gt type="GT0100" tt="0" es="2" np="1" nai="4" digits="*"/>

</patternSccpAddress>

</value>

<id value="2"/>

<value ruleType="Solitary" loadSharingAlgo="Undefined" originatingType="LocalOriginated" mask="K" paddress="3" saddress="-1">

<patternSccpAddress pc="0" ssn="6">

<ai value="18"/>

<gt type="GT0100" tt="0" es="2" np="1" nai="4" digits="*"/>

</patternSccpAddress>

</value>

Is my thinking/knowledge of SCCP translation not correct or is this missing from the rule matching logic? Using jSS7 2.0.0.FINAL.

Thanks,

Igor

[Oliver Jowett]

In traditional GT analysis, translation rules do not match on SSN. See Q.714 Figure 2 and section 2.4.5:

1)

Step 1: the GTI and the three optional parameters TT, NP and NAI should be

unambiguously associated to a translator which defines a set of translation rules. If this

translator cannot be determined, the GTT function shall be aborted with the cause "no

translation for an address of such nature".

2)

Step 2: the set of translation rules determined by Step 1 is used to analyse the GTAI possibly

accompanied by the encoding scheme. If no output exists for this GTAI, then the GTT

function shall be aborted with the cause "no translation for this specific address". Otherwise

the output of this Step 2 is at least the Routing Indicator (RI) and an SCCP Entity Set. In

addition, if the routing indicator is set to "Route on GT", then a GT information is a

mandatory output otherwise the GT information as an output is optional.

3)

Step 3: if an SSN is available as a GTT function input, then the Step 3 consists of using this

input SSN as a default value if some SSN are missing in the SCCP Entity Set. It may happen

that the value zero appears as an SSN value in the SCCP Entity Set: this is a correct value

which overwrites the SSN given as input of the GTT function.

I am not familiar with the jSS7 implementation but In your case I guess that the PC/SSN provided in the rule is defining the output SCCP Entity Set, not part of the matching criteria.

Oliver

--
You received this message because you are subscribed to the Google Groups "mobicents-public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobicents-publ...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Amit Bhayani]

Hi Igor,

As Oliver mentioned, SSN will not be used for GTT if routing indicator mentions that route based on GT. However once GTT is done and its confirmed that MSU is for this node, stack will check if Application Part is registered for given SSN.

Hence, your rule declared above doesn't make much sense as once GTT is done all messages will be consumed by stack and depending on SSN will call respective User Part. You can just define one rule and still everything will work.

Amit.