ISUP Trunking
This document describes the ISUP (ISDN User Part) trunk interface implemented by OmniMSC, including trunk group management, circuit allocation, message encoding, timers, continuity check support, and integration with the route table and SIP-I.
For ISUP-SIP cause code mapping, see SIP Trunking. For SIP-I (SIP with encapsulated ISUP), see SIP-I Trunking. For routing configuration and the :isup route type, see Routing Configuration. For call flow diagrams showing ISUP signaling in context (IAM/ACM/ANM, ISUP-to-SIP transit), see Call Flow Diagrams.
ISUP Trunk Groups
OmniMSC organizes ISUP circuits into trunk groups. Each trunk group represents a bundle of voice circuits to a remote SS7 exchange, identified by a destination point code and a range of Circuit Identification Codes (CICs).
CIC Allocation
When a call is routed to an ISUP trunk group, the circuit manager allocates the first idle circuit found in the configured range. The allocated CIC is included in the outgoing IAM and reserved until the call is released.
| Parameter | Type | Description |
|---|---|---|
name | string | Unique trunk group identifier, referenced in route table entries |
dpc | integer | Destination point code (encoded integer, e.g. a*2048 + b*8 + c for ITU 3-8-3) |
cic_range | {start, end} | Inclusive range of CICs available for this trunk group |
Circuit State Management
Each circuit within a trunk group tracks an independent state. The circuit manager handles blocking, unblocking, and group reset operations.
| Circuit State | Description |
|---|---|
:idle | Available for seizure |
:outgoing_busy | Allocated for an outgoing call (IAM sent) |
:incoming_busy | Reserved for an incoming call (IAM received) |
:blocked | Blocked via BLO, unavailable for seizure |
:unblocked_pending | Unblock (UBL) sent, awaiting acknowledgement |
:reset_pending | Circuit reset in progress (RSC/GRS), awaiting acknowledgement |
Circuit blocking (BLO) and unblocking (UBL) are performed per-circuit only. Group reset (GRS/GRA) resets all circuits in a range to idle and clears any blocking state; a single circuit can also be reset with RSC.
ISUP Message Flow
The standard ISUP signaling sequence for a successful call follows the IAM-ACM-ANM-REL-RLC pattern.
For incoming calls, the directions are reversed: IAM arrives from the remote exchange, and OmniMSC sends ACM and ANM as the call progresses through alerting and answer.
ISUP Handler States
The ISUP handler maintains per-call state that tracks the signaling progress for each circuit.
Outgoing Call States
Incoming Call States
ISUP Timers
OmniMSC implements the standard ISUP timers defined in ITU-T Q.764. These timers guard against signaling failures and ensure circuits are not left in indeterminate states.
| Timer | Duration | Started After | Expires When | Action on Expiry |
|---|---|---|---|---|
| T1 | 20s | REL sent | RLC not received | Retransmit REL |
| T5 | 300s | T1 first expiry | RLC still not received | Send maintenance alert, reset circuit |
| T7 | 25s | IAM sent | ACM not received | Release call, send REL |
| T9 | 180s | ACM received | ANM not received | Release call, send REL |
When T7 expires without receiving an ACM, OmniMSC sends a REL with cause 16 (normal call clearing) and notifies Call Control with cause 31 (normal, unspecified). When T9 expires without an ANM, OmniMSC sends a REL with cause 19 (no answer from user).
ISUP Message Encoding
OmniMSC implements a codec for encoding and decoding the five core ISUP message types used in call setup and release. All messages follow the ITU-T Q.763 format with mandatory fixed, mandatory variable, and optional parameter sections.
| Message | Type Code | Direction | Key Parameters |
|---|---|---|---|
| IAM | 0x01 | Originating | Nature of Connection, Forward Call Indicators, Calling Party Category, Transmission Medium Requirement, Called Party Number, Calling Party Number |
| ACM | 0x06 | Terminating | Backward Call Indicators, Optional Backward Call Indicators, Cause Indicators |
| ANM | 0x09 | Terminating | Backward Call Indicators |
| REL | 0x0C | Either | Cause Indicators |
| RLC | 0x10 | Either | (none -- acknowledgement only) |
Additional messages supported for circuit maintenance:
| Message | Type Code | Purpose |
|---|---|---|
| BLO | 0x13 | Block a circuit (local maintenance) |
| UBL | 0x14 | Unblock a circuit |
| RSC | 0x12 | Reset a single circuit |
| GRS | 0x17 | Group reset of a circuit range |
| GRA | 0x29 | Group reset acknowledgement |
| COT | 0x05 | Continuity check result |
| CPG | 0x2C | Call Progress (mid-call event/progress indication) |
Continuity Check
OmniMSC supports the ISUP continuity check procedure for verifying the bearer path before connecting a call. When the Forward Call Indicators in an outgoing IAM request a continuity check, the following sequence occurs:
- OmniMSC seizes the circuit and sends IAM with the continuity check indicator set.
- A loopback is applied at the far end of the circuit.
- OmniMSC sends a test tone and verifies the return.
- On success, OmniMSC sends COT (continuity check successful) and the call proceeds.
- On failure, OmniMSC sends COT (check failed) and may re-attempt on an alternate circuit.
For incoming calls, when OmniMSC receives an IAM with the continuity check indicator, it applies a loopback on the specified circuit and waits for the COT message before proceeding with call setup.
Route Table Integration
Routes with type :isup in the route table direct calls to an ISUP trunk group. The route entry specifies the trunk group name, destination point code, and CIC range.
| Route Parameter | Description |
|---|---|
type | :isup |
trunk_group | Trunk group name matching a configured trunk group |
dpc | Destination point code (encoded integer) |
cic_range | CIC range as {start, end} |
When routing selects an ISUP destination, the trunk router requests a free circuit from the circuit manager. If no circuits are available in the primary trunk group, the system attempts overflow trunk groups to the same destination point code.
For route configuration examples, see Routing Configuration.
SIP-I Support
SIP-I (SIP with encapsulated ISUP) provides an IP-based transport for ISUP messages. Routes with type :sip_i carry the full ISUP message (IAM, ACM, ANM, REL) as an application/ISUP MIME body within SIP signaling per ITU-T Q.1912.5 and RFC 3204.
SIP-I peers are configured separately from pure SIP peers. The ISUP encoder/decoder used for native ISUP trunks is shared with SIP-I for encoding and decoding the encapsulated ISUP bodies.
For SIP-I configuration, call flows, and header mapping, see SIP-I Trunking.
SIP with ISUP Failover
Routes with type :sip_with_failover attempt the call via a SIP peer first. If the SIP route fails (peer unreachable, 5xx response, or timeout), the trunk router automatically retries via the configured ISUP trunk group.
| Failover Trigger | Description |
|---|---|
Peer status :down | SIP peer is unreachable (OPTIONS keepalive failed) |
| SIP 5xx response | Server error from the SIP peer |
| SIP timeout | No response within the SIP transaction timer |
max_channels exceeded | SIP peer has no available capacity |
On failover, the trunk router allocates a CIC from the ISUP trunk group and sends an IAM. The CC FSM remains in the same state throughout the failover -- the retry is transparent to the radio-side signaling.
For failover route configuration, see Routing Configuration.
References
| Reference | Title | Relevance |
|---|---|---|
| ITU-T Q.761 | Functional Description of the ISUP | ISUP overview and architecture |
| ITU-T Q.762 | General Function of Messages and Signals of the ISUP | Message definitions |
| ITU-T Q.763 | Formats and Codes of the ISUP | Message encoding and parameter formats |
| ITU-T Q.764 | Signaling Procedures of the ISUP | Call setup/release procedures, timer definitions |
| ITU-T Q.850 | Usage of Cause and Location in ISDN | Cause code definitions used in REL |
| RFC 3204 | MIME Media Type for ISUP and QSIG Objects | ISUP encapsulation in SIP-I |
| ITU-T Q.1912.5 | Interworking between SIP and BICC or ISUP | SIP-I protocol definition |