SS7 Interworking With SIP-I: Mapping and Gateway Scenarios
SS7 interworking with SIP-I connects legacy circuit-switched signaling to IP-based voice networks without discarding the call-control information operators depend on. The gateway must translate ISUP procedures into SIP messages while preserving call identity, cause codes, bearer characteristics, and timing behavior.
SIP-I is especially useful where an operator needs SIP transport but still wants ISUP encapsulated within the signaling session. This approach differs from a simple SIP-to-ISUP conversion because the ISUP payload remains available to the receiving network, supporting feature transparency and more consistent interconnection between telecom carriers.
A reliable design begins with the signaling route, trunk group, and message-mapping rules. It also requires careful treatment of provisional responses, release procedures, number formats, and failure recovery across SS7 and IP domains.
Why SIP-I Is Used In Hybrid Networks
Traditional SS7 networks use MTP, SCCP where applicable, and ISUP to establish, supervise, and release telephone calls. SIP networks use requests and responses such as INVITE, 100 Trying, 180 Ringing, 200 OK, and BYE. SIP-I provides a bridge by carrying an ISUP message inside SIP signaling, commonly through the ISUP body of an INVITE or response.
This preserves information that may be lost during a basic SIP translation. Transit carriers can therefore maintain access indicators, forward call indicators, charge-related data, continuity procedures, and national variants of ISUP. The gateway still needs a clear interworking policy because the two protocols use different transaction models and state machines.
Core Message Mapping Between ISUP And SIP
An IAM generally maps to a SIP INVITE. Called-party and calling-party numbers are represented through SIP URI and header fields, while selected ISUP parameters may remain in the encapsulated body. The gateway may also use P-Asserted-Identity, Diversion, History-Info, or privacy-related headers according to the trust relationship between networks.
ACM commonly corresponds to a 183 Session Progress or another provisional response, while an ANM maps to 200 OK. An address-complete condition does not always mean that the called party is ringing, so the gateway must distinguish ACM from an alerting indication when generating SIP progress messages. Detailed treatment of ISUP call progress helps prevent misleading ringback behavior.
REL usually becomes a SIP BYE or CANCEL, depending on whether the call has been answered. SIP response codes such as 404, 408, 480, 486, and 503 must be translated into suitable ISUP cause values. The reverse direction requires equal care: a busy, unavailable, or congested condition should produce a meaningful SIP response rather than a generic gateway failure.
Trunking Gateway Deployment Scenarios
In a basic tandem scenario, an SS7-to-SIP-I gateway terminates an ISUP trunk on one side and an IP trunk group on the other. The gateway receives IAM messages over MTP3 or SIGTRAN, selects a SIP destination using the dialed number and routing plan, and sends an INVITE containing the corresponding ISUP information.
A more complex arrangement places SIP-I gateways at the edge of an international or inter-operator network. Multiple signaling points may share the same IP backbone, while media remains on separate RTP paths. This design makes gateway redundancy, signaling point codes, global titles, IP security, and route diversity central engineering concerns.
Some networks use SIP-I for transit while retaining SIP or SIP-T toward application servers. In that case, the gateway may need two mappings: ISUP to SIP-I for the carrier trunk and SIP-I to ordinary SIP for service logic. Feature loss should be documented, particularly for continuity checks, backward call indicators, charging data, and national ISUP extensions.
Mapping Reference For Common Call States
The following reference shows typical mappings. Exact behavior depends on ITU-T or ANSI variants, operator profiles, and whether the SIP session has been answered.
| ISUP Event | Typical SIP-I Representation | Interworking Consideration |
|---|---|---|
| IAM | INVITE with ISUP body | Preserve called and calling numbers, nature of address, and bearer capability |
| ACM | 183 Session Progress or provisional response | Avoid treating address complete as confirmed alerting |
| CPG | 180 Ringing or 183 Session Progress | Use event indicators to select ringing, progress, or in-band information |
| ANM | 200 OK | Establish the SIP dialog and begin charging supervision |
| REL before answer | CANCEL or final SIP error response | Map the ISUP cause to an appropriate response code |
| REL after answer | BYE | End the active dialog and release media resources |
| RLC | 200 OK to BYE or completed transaction | Ensure both signaling sides reach an idle state |
The table is a practical baseline rather than a universal profile. For example, a gateway may send 183 when in-band tones are available, while another implementation may use 180 for alerting and keep the ISUP body unchanged.
Timers, Routing, And Failure Handling
SS7 and SIP use different timer families. ISUP supervision includes timers for address completion, answer, release, and continuity procedures, while SIP uses transaction timers for provisional responses, retransmissions, and final replies. A gateway must prevent one protocol from waiting indefinitely while the other has already abandoned the call.
Routing policy should consider point codes, circuit identification codes, SIP trunk availability, number portability, and alternate destinations. A signaling route with insufficient capacity can create congestion even when the voice network has spare bearer channels. Engineers reviewing signaling route capacity should evaluate link utilization, route-set diversity, and gateway processing limits together.
Failure handling should also cover malformed ISUP bodies, unsupported parameters, duplicate responses, unavailable media ports, and broken SIGTRAN associations. Clear alarms and packet captures are essential for distinguishing a remote release from a local translation error.
Security And Operational Controls
SIP-I gateways sit at a sensitive boundary between trusted signaling domains and IP transport. Signaling should use controlled peering, filtering, authenticated management access, and network segmentation. Where supported by the interconnection model, IPsec or TLS can protect signaling, although encapsulated ISUP and interoperability requirements must be tested carefully.
Operational monitoring should correlate point codes, circuit identification codes, SIP Call-ID values, RTP statistics, and release causes. This makes it possible to trace a call across both protocol stacks. Rate limits and anomaly detection can also reduce the impact of scanning, signaling floods, and abnormal call-release patterns.
Deployment Recommendations
A successful interworking project benefits from a documented mapping profile and repeatable test cases.
- Define ISUP and SIP-I variants, national options, and supported optional parameters before configuration.
- Test answered, unanswered, busy, no-route, timeout, continuity-check, and early-media scenarios.
- Verify number normalization, privacy indicators, charge information, and portability-related routing.
- Engineer diverse SIGTRAN associations, IP paths, gateway instances, and bearer trunk groups.
- Monitor timer expiry, cause-code translation, retransmissions, and one-way media after launch.
SIP-I is most effective when treated as a signaling architecture rather than a simple protocol converter. Map the complete call state, validate each trunking scenario in a controlled lab, and use trace-based monitoring during production rollout. Apply these principles to build an SS7-to-IP gateway design that preserves service behavior while gaining the scalability and operational flexibility of SIP transport.
