Inbound GT translation

The SGC determines how GT translation occurs for inbound SCCP messages. Multiple incoming called addresses can be configured for the SGC.

For where the incoming called address for an SCCP message is a GT, it is:

  • matched against the configuration to determine whether it should be processed, and

  • may then determine which SSN should receive it.

Configuration

The configuration for the inbound GT translation matching rules are in the inbound section.

For matching inbound called addresses, you may configure:

  • ❏ A unique id for the address for the configuration. This value is only used by the declarative configuration and is not exposed externally.

  • ❏ The called party address information to match on the inbound SCCP message digits. This is defined in the addrinfo field.

  • ❏ For matching the incoming address, whether to allow the address information to match on the prefix or have to match the entire address. This is set in the is-prefix field.

  • ❏ The SCCP message’s nature of address (natofaddr) code required for a match. The code is defined in the RFC 3868 Global Title Section.

  • ❏ The SCCP message’s numbering plan code (numplan) required for a match. The code is defined in the RFC 3868 Global Title Section.

  • ❏ The SCCP message’s translation type code (trtype) required for a match. The code is defined in the RFC 3868 Global Title Section.

  • ❏ The local ssn to route matched messages towards.

Setting up inbound GT translation

I want to …​

Send all inbound SCCP CdPA which have addressed digits=123456, in an international number format, in an ISDN numbering plan, and an unknown translation type to SSN 146

In the global-title, inbound section, add the inbound matching rule with a unique identifier.

Ensure that the following are set for the inbound rule:

  • id.

  • addrinfo is set to digits 123456.

  • is-prefix is set to false as we are only accepting an exact match.

  • natofaddr corresponds to Nature of Address for international numbers.

  • numplan corresponds to the numbering plan code for the ISDN numbering plan.

  • trtype corresponds- to the unknown translation type.

  • ssn.

deployment-config:sgc:
  m3ua:
    global-title:
      inbound:
        - id: 'to-sentinel-volte-gsm'
          addrinfo: '123456'
          is-prefix: false
          natofaddr: 4
          numplan: 1
          trtype: 0
          ssn: 146
Send inbound SCCP CdPA addressed to digits prefixed with 123456 to SSN 146

In the global-title, inbound section, add the inbound matching rule with a unique identifier.

    global-title:
      inbound:
        - id: 'inbound-rule-example'
          addrinfo: '123456'
          is-prefix: true
          ssn: 146
Send two different inbound SCCP CdPA addressed messages to different local SSNs

In the global-title, inbound section, add each inbound matching rule with their own unique identifiers.

In this case we have two inbound translation rules. For all inbound SCCP CdPA addressed to:

  • digits=1234567890, the message is sent to the local SSN 8.

      inbound:
      # All inbound SCCP CdPA addressed to digits=1234567890 will be sent to local SSN 8
        - id: 'SSN_6'
          addrinfo: '1234567890'
          is-prefix: false
          ssn: 8

  • digits=2143658709, the message is sent to the local SSN 146.

      inbound:
      # All inbound SCCP CdPA addressed to digits=2143658709 will be sent to local SSN 146
        - id: 'B'
          addrinfo: '2143658709'
          is-prefix: false
          ssn: 146

Outbound GT translation

The SGC determines how GT translation occurs for outbound SCCP messages. Multiple outgoing called addresses can be configured for the SGC.

When the outgoing SCCP called party address (SCCP CdPA) is set to ri=GT, global title translation function is invoked. The function uses the SCCP called party address to determine which destination point code (DPC) the M3UA layer should route the message to.

The parameters of the SCCP message are compared against the matcher rules defined in the configuration. If a match occurs, the message will be routed towards the DPC defined in one of the translation rules associated with that matcher.

Optionally after outbound GT translation, the GT rewriter rule(s) may modify the parameters of the SCCP called party address.

Configuration

There are three different types of rules defined for outbound GT translation.

These are:

  1. The matching rule, which decides what SCCP addresses are to be translated. This invokes specified translation rules.

  2. The translation rule, which decides the DPC to route and routing priority. This invokes specified rewriter rules.

  3. The rewriter rule, which decides what is replaced and transformed in the SCCP address.

The configuration for the outbound GT translation matching rules are in the outbound section.

The scope of these rules overlap for parts of the SCCP message and interact with each other. The following table demonstrates how each configurable rule may interact with each other and the SCCP message.

Table 1. Outbound SCCP Message GT Configurable Rules
Scope of Rule on SCCP message Matching Rule matchers Translation Rule translations Rewrite/Replace Rule rewriters

Rule ID

Matching rule id

Configuration specific translation rule id invoked by a matching rule

Configuration specific rewrite rule id invoked by a translation rule

Address Information

Match to specific addrinfo digits

Replace with addrinfo digits

Treat digits to match as a prefix

is-prefix

GT Encoding

Replace gtencoding

GTI Global Title Indicator

Replace gti

Nature of Address (code defined in RFC 3868)

Match natofaddr - may set a default for all matching rules

Replace natofaddr

Numbering Plan (code defined in RFC 3868)

Match numplan - may set a default for all matching rules

Replace numplan

Translation Type (code defined in RFC 3868)

Match trtype - may set a default for all matching rules

Replace trtype

SSN

ssn

Route on SSN, GT, or no change

Replace route-on

Message DPC

Add dpc to route messages to

Local Routing

prefer-local routing on SGC or not

Relative Rule Priority

Rule priority

Rules to Invoke

Invoke translations rule(s)

Invoke rewriter-id rule(s)

To configure outbound GT translation, you must:

  • ❏ Configure the matching rules to activate the translation rules on the outbound GTs.

  • ❏ Configure the translation rule(s).

In addition, to rewrite the outbound GT after translation, you must:

  • ❏ Ensure that the translation rule(s) activates the appropriate rewrite rule(s).

  • ❏ Configure the rewrite rule(s).

Note The declarative configuration supports several different matching, translation, and rewriter rules. This allows for different numbers to be routed to different DPCs and have their SSN rewritten.

Setting up outbound GT translation

I want to …​

Route all outbound SCCP messages to a specific DPC

In the global-title, outbound section:

  • Add an outbound matcher rule that matches with any outgoing message.

    • Add is-prefix = true to allow any dialled digits to be matched.

    • Add to the matcher rule’s list of translations the unique identifier for the translation rule to invoke it.

    global-title:
      outbound:
        matchers:
          rules:
            - id: '1'
              is-prefix: true
              translations:
                - 'all'

  • Add a translation rule that is invoked by the matcher rule to the intended DPC.

    • Add the dpc that the messages are routed to.

    • Add the priority for the translation rule.

Note The priority for a translation rule is relative to other translation rules defined in the declarative configuration. 
    global-title:
      outbound:
        translations:
          - id: 'all'
            dpc: "5963"
            priority: 5
Route all SCCP CdPA with digits starting with 44123456 to primary and backup DPCs

In the global-title, outbound section:

  • Add an outbound matcher rule that matches with any outgoing message.

    • The addrinfo is set to the digit string 44123456.

    • The is-prefix is set true so SCCP addressed digits starting with 44123456 are accepted.

    • The invoked translations rules list has the identifier for the primary DPC 'to_4' and the secondary DPC 'to_100' added.

      outbound:
        matchers:
          rules:
            # All outbound SCCP CdPA with ri=GT and digits starting with 44123456 will be sent to DPC 4 (primary) and DPC 100 (backup)
            - id: 'to_44123456*'
              addrinfo: '44123456'
              is-prefix: true
              translations:
                - 'to_4'
                - 'to_100'

  • Add a translation rule that is invoked by the matcher rule to route to the primary DPC.

    • The id is set to match the primary DPC in the matcher rule.

    • The dpc is filled with the primary DPC in the network.

    • The priority is set higher than the backup DPC’s priority.

      outbound:
        translations:
          - id: 'to_4'
            dpc: '4'
            priority: 10

  • Add a translation rule that is invoked by the matcher rule to route to the backup DPC.

    • The id is set to match the backup DPC in the matcher rule.

    • The dpc is filled with the backup DPC in the network.

    • The priority is set lower than the primary DPC’s priority.

      outbound:
        translations:
          - id: 'to_100'
            dpc: '100'
            priority: 5
Route all SCCP CdPA with digits starting with 44666 to a primary DPCs and set their SSN to 146

In the global-title, outbound section:

  • Add an outbound matcher rule that matches with any outgoing message.

    • The addrinfo is set to the digit string 44666.

    • The is-prefix is set true so SCCP addressed digits starting with 44666 are accepted.

    • The invoked translations rules list has the identifier for the translation rule 'rewrite' which will invoke the rewrite rule.

      outbound:
        matchers:
          rules:
                # All outbound SCCP CdPA with ri=GT and digits starting with 44666 will be sent to DPC 4 and have the SSN rewritten to 146
                - id: 'to_44666*'
                  addrinfo: '44666'
                  is-prefix: true
                  translations:
                    - 'rewrite'

  • Add a translation rule that is invoked by the matcher rule that will route to the primary DPC and invoke a rewrite rule.

    • The id is set to match the translation rule invoked by the matcher rule.

    • The dpc is filled with the primary DPC in the network.

    • The rewriter-id is set to invoke the rewrite_44666_to_have_ssn rewrite rule.

      outbound:
        translations:
          - id: 'rewrite'
                  dpc: '4'
                  rewriter-id: 'rewrite_44666_to_have_ssn'

  • Add a rewrite rule that is invoked by the translation rule that will make the messages route on SSN 146.

    • The id is set to match the rewriter rule invoked by the translation rule.

    • The route-on is to set SSN, replacing existing route indicator on the message.

    • The ssn is set to 146, making the message be routed towards the 146 SSN.

      outbound:
        rewriters:
          - id: 'rewrite_44666_to_have_ssn'
                  route-on: SSN
                  ssn: 146
By default, only translate outbound SCCP messages that have a telex numbering plan, and an unknown nature of address and translation type

In the matchers, defaults section:

These given number codes correspond to a telex numbering plan, and an unknown nature of address and translation type as per RFC 3868 Section 3.10.2.3.

      outbound:
        matchers:
          # All addresses we care about are natofaddr=0, numplan=4 and trtype=0 so we can save some typing
          defaults:
            natofaddr: 0
            numplan: 4
            trtype: 0
Previous page Next page
Rhino VoLTE TAS Version 4.2