Using the called party number for ISUP number translation
In an ISUP call, the Called Party Number (CdPN) is more than a destination digit string. It carries information that helps switches interpret, translate and route a call across the Public Switched Telephone Network (PSTN) or an IP-based signalling environment.
Number translation services use the CdPN to convert a dialled number into a routable destination. The process can support national numbering, carrier selection, toll-free services, local access codes, mobile routing and service numbers such as Australia’s 13, 1300 and 1800 ranges.
Translation normally occurs in a service switching point, softswitch, media gateway controller or intelligent network platform. The result may be a modified CdPN, a new routing decision, or a service instruction that causes the call to continue towards a different network element.
Correct interpretation depends on more than the digits. The switch must consider the Nature of Address Indicator (NAI), numbering plan indicator, address presentation restrictions and the point in the call path where the translation is applied.
How the called party number is carried
The CdPN is a variable-length parameter in the ISDN User Part Initial Address Message (IAM). It commonly includes the address signal digits, an odd/even indicator, the nature of address and a numbering plan value. Together, these fields tell the receiving exchange how to read the number.
A national number, international number and subscriber number may contain similar digits but require different handling. For example, an international NAI can direct a gateway to apply international routing, while a national NAI may be evaluated against the domestic numbering plan. A translation engine should preserve this distinction rather than treating every value as an unqualified string.
Translation logic in a signalling network
A translation service typically receives the CdPN, matches it against a prefix or service rule, and returns a destination or routing instruction. Rules may add, remove or replace digits, select a carrier, identify a trunk group, or map a service number to a geographic or mobile termination.
For an Australian 1300 service, the dialled number can be translated into a destination based on state, time of day, caller location or business policy. A 1800 number may require a different charging and routing treatment, while a 13 number can be mapped to a shorter national service identity before the call reaches the service provider.
Translation may happen in an SCP through INAP, in a SIP application server, or inside a softswitch. In mixed networks, the service may receive ISUP from a TDM exchange and produce SIP routing information for an IP core.
Digits, prefixes and routing context
A reliable implementation separates the original called number from the translated destination. Keeping the original value supports billing, fraud analysis and troubleshooting, while the translated value controls the next routing step. Overwriting data too early can make it difficult to explain why a call reached an unexpected endpoint.
The routing label in MTP3 and the CdPN serve different purposes. The routing label selects a signalling point, whereas the CdPN identifies the called service or subscriber. A message can therefore be delivered to the correct signalling node while still requiring further number translation before call setup is complete.
Australian carriers may translate numbers between metropolitan and regional service areas, including traffic entering networks around Sydney, Melbourne, Brisbane or Perth. The rule set must account for national numbering conventions rather than relying only on local dialling patterns.
Common translation patterns
Prefix translation is the simplest model. A switch identifies a leading digit sequence and replaces it with another prefix. More advanced services use database lookups, subscriber profiles, time conditions, network congestion data or portability records.
Number portability makes static prefix assumptions unsafe. A number originally allocated to one carrier may have moved to another, so the translation platform may need a portability database or an authoritative routing query. The final destination can be unrelated to the number’s original allocation block.
| Input condition | Typical translation action | Operational consideration |
|---|---|---|
| National geographic number | Add or normalise national routing digits | Preserve the correct Australian numbering plan |
| 13 or 1300 service | Map service number to an enterprise destination | Apply location, schedule or overflow rules |
| 1800 service | Select a free-call service route | Check charging and inter-carrier treatment |
| International NAI | Pass to an international gateway | Validate country code and permitted route |
| Ported mobile number | Query portability or routing data | Do not infer carrier solely from prefix |
Interaction with ISUP parameters
The CdPN works with other IAM information. The Calling Party Number may influence authentication, screening or service policy; the Bearer Capability indicates the requested bearer service; and the Transmission Medium Requirement can affect gateway selection. Translation logic should evaluate these parameters together where service rules require it.
A change to the CdPN should not accidentally alter unrelated call information. Screening indicators, presentation restrictions and numbering-plan values need deliberate treatment. Incorrect indicators can produce rejected calls, misapplied translations or misleading caller identity at the terminating network.
Timers also matter. A translation lookup that delays IAM processing can contribute to post-dial delay or trigger network supervision problems. Capacity planning should cover busy periods such as weekday traffic in the Australian Eastern time zone, when enterprise contact centres and mobile users generate substantial demand.
Translation across SIGTRAN and IP networks
When ISUP is transported over SIGTRAN, protocols such as M2PA or M3UA carry signalling between IP nodes, but the CdPN semantics remain ISUP semantics. The move from TDM links to SCTP-based transport does not remove the need to validate address indicators and digit encoding.
A gateway connecting LTE or VoLTE infrastructure may translate between legacy ISUP and SIP or Diameter-related service functions. Engineers working on this boundary can review an SS7 over LTE guide to understand how gateway and mobility components affect signalling interworking.
Redundancy is essential for translation databases and signalling nodes. An outage in a central lookup service can affect many apparently unrelated numbers, so cached rules, alternate SCPs and controlled failure behaviour should be designed into the network.
Security and operational controls
The called number is valuable to attackers because it can expose service logic, premium routes and enterprise destinations. Unauthorised manipulation may redirect calls, create toll fraud or bypass charging controls. Validation should reject malformed digits, unexpected numbering plans and disallowed prefixes before a translation is executed.
Operational teams should log the received CdPN, interpreted indicators, selected rule, translated destination and result code, subject to privacy and retention requirements. Correlating these records with IAM, SIP and billing traces makes faults easier to isolate across legacy and IP domains.
Emergency traffic requires special care. In Australia, calls to 000 must be routed according to regulatory and carrier obligations, with location and priority handling protected from ordinary business translation rules. The key principle is simple: interpret the Called Party Number with its indicators and network context, then translate it transparently, securely and consistently.
