ISUP interworking with ISDN: Q.931 mapping and cause codes

Interworking between ISDN and SS7 depends on translating signalling semantics rather than simply copying message names. Q.931 operates at the subscriber access interface, while ISUP carries call-control information between exchanges. A gateway must therefore preserve the meaning of call states, numbering, bearer requirements and release conditions as traffic crosses the network boundary.

This remains useful in Australia, where older ISDN services, carrier interconnects and legacy PSTN components can coexist with SIP and other IP-based platforms. Engineers working on a Telstra exchange migration, a business service in Sydney or a regional deployment near Newcastle may still need to interpret Q.931 traces alongside MTP3, SCCP or SIGTRAN captures.

Call function Q.931 message ISUP message Main interworking consideration
Initiate call SETUP IAM Map called and calling numbers, bearer capability and channel information
Indicate routing progress CALL PROCEEDING ACM Preserve call state and network progress indicators
Alert subscriber ALERTING CPG or ACM Translate ringing and in-band progress correctly
Answer call CONNECT ANM Start charging and speech-path expectations
Clear call DISCONNECT REL Convert cause value, location and diagnostics
Complete release RELEASE COMPLETE RLC Ensure resources and circuits are freed

How the two signalling models align

Q.931 is used between a terminal and an ISDN exchange, commonly across a Basic Rate Interface or Primary Rate Interface. Its SETUP message contains the information needed to request a service, including the called party number, bearer capability, channel identification and, where applicable, a calling party number.

ISUP’s Initial Address Message performs a similar call-establishment role between network switches. The gateway normally maps SETUP to IAM, but the conversion requires policy decisions. Q.931 channel identification may correspond to an ISUP circuit identification code, while bearer capability and compatibility information must be represented in suitable ISUP parameters. Numbering-plan and type-of-number fields also need consistent treatment.

The reverse direction follows the same principle. An ISUP Address Complete Message generally becomes CALL PROCEEDING or an equivalent Q.931 progress indication, while an Answer Message maps to CONNECT. An ISUP Release Complete message is commonly represented by RELEASE COMPLETE after the access-side terminal has been informed that the call has ended.

Mapping call progress and supplementary information

The basic message sequence is rarely the whole story. ISUP may use ACM, CPG and ANM to distinguish routing progress, alerting and answer. Q.931 has separate messages and information elements for these states, so a gateway must avoid presenting an answered call as mere ringing or sending an early alert when the far end has not yet reached that state.

The Progress Indicator is particularly important when tones or announcements are supplied by a remote network. If the gateway strips it, a caller may hear silence instead of a busy tone, recorded announcement or interworking indication. Calling Line Identification, redirecting numbers, subaddresses and transit network selection can also be lost if the translation profile supports only the minimum call setup fields.

Australian numbering adds practical detail. National numbers commonly use the 0 prefix, while emergency calls use 000, and carrier systems may apply different presentation rules for geographic, mobile and special-service numbers. A translation rule that works in Melbourne may expose formatting or screening errors when a regional carrier hands over a call from Queensland.

Understanding Q.850 and ISUP cause values

Q.931 cause information is based on the Q.850 framework. A cause includes a numerical value and may also include coding standard, location and diagnostic information. Common examples include cause 1, “unallocated number”; cause 16, “normal call clearing”; cause 17, “user busy”; cause 18, “no user responding”; and cause 34, “no circuit/channel available.”

ISUP uses a Cause Indicators parameter with broadly compatible meanings, but the fields are not always interchangeable without adjustment. The gateway may need to change the location field, remove a diagnostic octet, or select a national-network equivalent. A remote exchange reporting congestion should not be translated into an apparently ordinary user-busy condition, because that affects rerouting, customer announcements and fault analysis.

Cause conversion should be documented in both directions. For example, Q.931 cause 44, “requested circuit/channel not available,” may be mapped to an ISUP congestion or circuit-unavailable condition, depending on the carrier profile. Operators should also define how unknown, incompatible or protocol-error causes are handled rather than allowing vendor defaults to decide silently.

Interworking across Australian carrier networks

Australian fixed-line services have been moving towards IP-based access and voice platforms, yet operational teams still encounter ISDN PBXs, private circuits and inter-exchange signalling during staged migrations. A gateway at a Brisbane business site may translate Q.931 from a PBX to SIP locally while the carrier core continues to expose ISUP through SIGTRAN. Each boundary can introduce a different cause-code policy.

Testing should cover ordinary calls, busy destinations, no answer, number changes, congestion, rejected bearer capability and early media. Capture both sides of the gateway and compare message timing, especially T303, T310, T313 and release supervision. A trace from an arvo outage review is much easier to interpret when the engineer can correlate each timer expiry with the cause delivered to the subscriber.

Training material should also be evaluated for technical relevance and source consistency. The wider domain includes a Kerst bonus casino aanbieding, showing why engineers should distinguish legacy or unrelated pages from signalling documentation before using it as a reference.

Building a reliable translation profile

A useful profile begins with a field-by-field matrix: message, information element, mandatory status, permitted values, default action and reverse mapping. Include bearer capability, channel identification, called and calling party numbers, progress indicators, connected number, cause indicators and user-to-user information. Record whether a value is passed, converted, discarded or generated locally.

Validation should use controlled test calls and negative cases, with results checked against switch logs and protocol captures. The SS7 training library can provide supporting material on ISUP, MTP3, timers and call routing, while carrier specifications remain the authority for national variants and interconnect requirements.

The practical rule is simple: treat Q.931-to-ISUP interworking as a semantic translation exercise. Preserve the call state, translate cause values deliberately, retain useful diagnostics, and verify the result with traces from both network sides before placing the gateway into service.