SIP vs. SS7: Signaling in Modern Telecom
The North American telephone network is in a decades-long transition from SS7-based circuit switching to SIP-based packet switching. Today, both protocols coexist — often within the same call path. Understanding how they interwork is essential for anyone operating voice infrastructure or troubleshooting call quality issues at the boundary between legacy and modern networks.
Two Different Worlds
SS7 and SIP were designed for fundamentally different network architectures:
| SS7 | SIP | |
|---|---|---|
| Network type | Circuit-switched (TDM) | Packet-switched (IP) |
| Signaling path | Dedicated signaling network (out-of-band) | In-band with media (same IP network, different ports) |
| Message format | Binary, compact | Text-based (HTTP-like) |
| Transport | MTP (dedicated 56/64 kbps links) | UDP, TCP, or TLS over IP |
| Media | 64 kbps DS0 circuits (PCM) | RTP packets (variable codecs) |
| Call model | Circuit reservation (dedicated bandwidth) | Session-based (shared bandwidth) |
| Designed for | Carrier-grade reliability, closed network | Flexibility, open standards, internet scale |
| Security model | Trusted network (no authentication) | TLS, digest auth, STIR/SHAKEN |
Despite these differences, they accomplish the same fundamental task: setting up, managing, and tearing down telephone calls.
Where They Meet: The Gateway
Most calls today cross at least one SS7/SIP boundary. The device at this boundary is a signaling gateway (often integrated into an SBC or media gateway). It translates signaling messages between protocols and transcodes media if needed.
A typical cross-network call flow:
VoIP Phone → SBC → SIP trunk → [Gateway] → SS7/ISUP → TDM Switch → LandlineAt the gateway:
- The SIP INVITE is translated to an ISUP IAM
- SDP codec negotiation maps to TDM circuit allocation
- SIP response codes map to ISUP messages (180 Ringing → ACM, 200 OK → ANM)
- RTP media is converted to/from TDM PCM (G.711 passthrough is common, avoiding transcoding)
- On teardown, SIP BYE maps to ISUP REL/RLC
SIP-I and SIP-T
The IETF defined two methods for carrying ISUP information within SIP, preserving the rich metadata from SS7 across IP networks:
SIP-T (SIP for Telephones)
Defined in RFC 3372, SIP-T encapsulates the entire ISUP message as a MIME body within the SIP message. The SIP headers carry the basic call information, while the full ISUP message rides along as an attachment.
INVITE sip:+[email protected] SIP/2.0
Content-Type: multipart/mixed; boundary=boundary42
--boundary42
Content-Type: application/sdp
[SDP body]
--boundary42
Content-Type: application/isup; version=itu-t92+
[Binary ISUP IAM]
--boundary42--This preserves every field in the ISUP message — even parameters that have no direct SIP equivalent. The downstream gateway can extract the ISUP body and forward it natively if the next hop is also SS7.
SIP-I (SIP with Encapsulated ISUP)
Similar to SIP-T but defined by the ITU-T (Q.1912.5). SIP-I is the dominant method in international carrier networks. The key difference is that SIP-I treats the encapsulated ISUP as the authoritative call information, with SIP headers serving as a summary. SIP-T treats the SIP headers as authoritative with the ISUP body as supplementary.
In practice, both approaches solve the same problem: ensuring that no call metadata is lost when signaling traverses an IP network segment between two SS7 segments.
Message Mapping
The key signaling messages map between protocols:
| SS7 (ISUP) | SIP | Direction |
|---|---|---|
| IAM (Initial Address Message) | INVITE | Call setup |
| ACM (Address Complete) | 180 Ringing / 183 Session Progress | Alerting |
| ANM (Answer) | 200 OK | Answer |
| REL (Release) | BYE or error response (4xx/5xx) | Teardown |
| RLC (Release Complete) | 200 OK (to BYE) | Confirmation |
| CPG (Call Progress) | 183 Session Progress | In-progress indication |
Some ISUP parameters have no clean SIP equivalent and require proprietary headers or are carried in the encapsulated ISUP body:
- Charge indicators: ISUP carries detailed charging information; SIP has no native billing fields
- Continuity check indicators: ISUP can request continuity testing on a circuit; irrelevant in IP
- Echo control: ISUP signals echo canceller status; handled differently in IP networks
- ISUP cause codes: Map to SIP response codes, but the mapping is not always one-to-one (RFC 3398 defines the standard mapping)
Why SS7 Persists
Given that SIP is technically superior in many ways — more flexible, more extensible, runs on commodity IP infrastructure — why does SS7 continue to operate?
Legacy Infrastructure
Billions of dollars of installed TDM switching equipment remains in service. Replacing a Class 5 switch serving 100,000 subscribers is a major capital project. Many ILECs have migrated their core networks to IP but still have TDM at the edges serving rural or low-density areas.
Reliability and Proven Track Record
SS7 networks achieve “five nines” (99.999%) availability. The protocol was designed from the ground up for carrier-grade reliability with redundant STPs, automatic failover, and decades of operational hardening. SIP networks can achieve similar reliability, but require careful engineering — the protocol itself does not guarantee it.
Database Services
TCAP-based database services — number portability (LNP), toll-free routing (SMS/800), CNAM caller name — were built on SS7. While IP-based alternatives exist (ENUM, HTTP-based APIs), many carriers still use TCAP for these queries, especially at scale.
Wireless Networks
2G and 3G mobile networks use SS7 variants (MAP — Mobile Application Part) for core operations: location registration, handoff, SMS delivery, roaming authentication. As carriers sunset 2G/3G, this dependency diminishes, but it has not yet fully disappeared.
The All-IP Transition
The industry trajectory is clear: all-IP networks using SIP (and eventually newer protocols) will replace SS7 entirely. Key milestones:
- IMS (IP Multimedia Subsystem): The 4G/5G mobile architecture uses SIP natively for voice (VoLTE/VoNR), eliminating the need for SS7 in the wireless core
- FCC IP transition orders: US regulators have set frameworks for carriers to retire TDM infrastructure
- Carrier network modernization: AT&T, Verizon, and Lumen have all announced TDM retirement programs, replacing legacy switches with IP-based platforms
- STIR/SHAKEN: The caller ID authentication framework is SIP-native, creating regulatory pressure to move signaling to SIP
The transition is gradual. No hard cutoff date exists for SS7 retirement. Instead, SS7 networks shrink as endpoints migrate to IP and carrier-to-carrier interconnections convert from TDM to SIP.
Practical Implications
For telecom operators and engineers working with NPA/NXX routing data:
- Routing tables serve both worlds: Whether a carrier uses SS7 or SIP internally, they still route based on NPA/NXX data. The signaling protocol changes how the route is executed, not how the destination is determined.
- Interworking introduces failure modes: Call setup failures at SS7/SIP boundaries are a common troubleshooting scenario. Mismatched codec support, incorrect cause code mapping, and missing parameters are frequent culprits.
- LRN dips work across both: Number portability lookups return the same LRN regardless of whether the querying carrier uses TCAP over SS7 or an IP-based database interface.
- CDR reconciliation: Calls crossing protocol boundaries may generate CDRs in different formats on each side, complicating billing reconciliation.
Further Reading
- SIP: Session Initiation Protocol — the IP-based signaling protocol
- SS7: Signaling System 7 — the legacy signaling suite
- STIR/SHAKEN — SIP-native caller ID authentication driving the IP transition
- How a Phone Call Gets Routed — call flow showing both protocols in action