App Config (Normalisation)

Overview

Some applications allow for number normalisation based on generic configuration. These may have normalisation and denormalisation specifications within their config configuration block, e.g.:

 <application ...>
     ...
     <config>
         ...
         <normalisation>
             <common>
                 <rule .../>
             </common>
             <xxx>
                 <rule .../>
             </xxx>
         </normalisation>
         <denormalisation>
             <common>
                 <rule .../>
             </common>
             <xxx>
                 <rule .../>
             </xxx>
         </denormalisation>
     </config>
 </application>

Each application will define what configuration blocks are available for which input and output fields, i.e. replacing the xxx shown above.

Configuration may also be placed within a common block in order to apply after any other specific rules.

Normalisation rules are applied to fields that are received from the network. In such rules, the number nature is removed and only the normalised form of the number is used within processing.

Denormalisation rules are applied to fields that are sent to the network, and supply the denormalised number as well as the number nature to use.

In all cases, rules are checked in order of definition, with rules in the common block applied last. Once a rule is matched, no further rules are checked.

Configuration Details

The rule elements within both the normalisation and denormalisation blocks and all sub-blocks share similar configuration elements.

A rule is matched successfully when:

• The leading attribute matches the candidate string.
• The nature definitions match the candidate nature. Note that integer definitions are specific for each number type.
• The candidate string length is inclusively between the min_len and max_len attributes.

Match Inversion

When matching on the leading parameter in a normalisation or denormalisation rule, the match may be made inverted by prefixing the match to be made with !.

If the string to be matched starts with an exclamation mark, add an additional !, i.e. !! for a normal match and !!! for an inverted match.

Some examples of using and not using inversion:

• rule specifies abc (match only abc):
  • against actual value abc: match
  • against actual value abd: no match
  • against actual value !abc: no match
  • against actual value !abd: no match
• rule specifies !abc (match anything that is not abc):
  • against actual value abc: no match
  • against actual value abd: match
  • against actual value !abc: match
  • against actual value !abd: match
• rule specifies !!abc (match only !abc):
  • against actual value abc: no match
  • against actual value abd: no match
  • against actual value !abc: match
  • against actual value !abd: no match
• rule specifies !!!abc (match anything that is not !abc):
  • against actual value abc: match
  • against actual value abd: match
  • against actual value !abc: no match
  • against actual value !abd: match

Number Natures

When specifying a nature in a normalisation or denormalisation rule, generic natures may be specified as text. These generic natures are translated to the appropriate number for each number type.

The following generic natures are available:

• unknown
• international
• national
• network
• subscriber
• alphanumeric
• abbreviated
• dedicated

Sentinel Replacement

Some applications may allow for specification of sentinel strings within the prepend definition that are replaced with dynamic data at runtime. In such cases, any occurrences of these strings will result in the dynamic data being inserted, replacing the sentinel.

If the specified dynamic data is not available for replacement, the rule will fail to match.

Sentinel strings are always surrounded by % (e.g. %vlr%) and are not case-sensitive. To have a literal % in a prepend string, prefix it with a ! (e.g. !%vlr!% will become %vlr% and will not be treated as a sentinel).

Applications have these sentinel characters and their associated dynamic data internally set and are not changeable. Refer to the specific application documentation for sentinel definition and behaviour.

Number Types

Different number types are available, depending on the protocol used by the application and the field to which normalisation rules are applied.

Applications have these number type assignations internally set and they are not changeable.

Map Address Strings

MAP address strings are used for all CAMEL, INAP, and MAP ASN.1 types derived from AddressString, including but not limited to:

• AddressString
• ISDN-AddressString
• SMS-AddressString

This includes, but is not limited to, the following information elements:

• InitialDPSMSArg
  • callingPartyNumber
  • calledPartyNumber
  • mscAddress
  • sMSCAddress
• ConnectSMSArg
  • callingPartysNumber
  • sMSCAddress
• InitialDPArg –> mscAddress
• InitialDPArgExtension –> gmscAddress

MAP address strings have their number natures taken as the Nature of Address from MAP (3GPP 29.002 / ETSI TS 129 002).

MAP address strings are limited to the following characters:

 0 1 2 3 4 5 6 7 8 9 a b c * #

GSM Called Party BCD Numbers

GSM called party BCD numbers are used for all CAMEL and INAP CalledPartyBCDNumber information elements, including but not limited to:

• InitialDPArg -> calledPartyBCDNumber
• InitialDPSMSArg -> destinationSubscriberNumber
• ConnectSMSArg -> destinationSubscriberNumber

GSM called party BCD numbers have their number natures taken as the Type of Number from 3GPP TS 24.008 / ETSI TS 124 008.

GSM called party BCD numbers are limited to the following characters:

 0 1 2 3 4 5 6 7 8 9 a b c * #

ISUP Numbers

ISUP numbers are generally used for all CAMEL and INAP ASN.1 types defined in ISUP (ITU-T REC Q.763 / ETSI EN 300 356-1), including but not limited to:

• Called Party Number
• Calling Party Number
• Connected Number
• Generic Number
• Location Number
• Original Called Number
• Redirecting Number
• Redirection Number
• Call Transfer Number
• Terminating Network Routing Number
• Called Directory Number
• HTR Information

This includes (but is not limited to) the following ASN.1 types and the corresponding information elements:

• CalledPartyNumber
• CallingPartyNumber
• DestinationRoutingAddress
• GenericNumber
• IPRoutingAddress
• LocationNumber
• OriginalCalledPartyID
• RedirectingPartyID

ISUP numbers have their number natures taken as the Nature of Address from 3GPP TS 24.008 / ETSI TS 124 008.

ISUP numbers are limited to the following characters:

 0 1 2 3 4 5 6 7 8 9 a b c d e f

SMPP Address

SMPP addresses have their number natures taken as the Type of number from SMPP Protocol Specification v3.4/v5.0.

SMPP addresses have no character restrictions.