Telecom Network Protocols — Beginner's Guide to SS7, SIP and VoIP

In this tutorial, you'll learn about Telecom Network Protocols. We cover key concepts, practical examples, and best practices.

Telecom network protocols are standardized rules that govern how signaling and media data is exchanged between switches, gateways, and endpoints across telephone and mobile networks worldwide.

What You'll Learn

You will learn how SS7, SIP, and related protocols carry signaling information across telecom networks to establish, manage, and tear down calls between subscribers on different carriers.

Why It Matters

Without signaling protocols, phone networks cannot route calls, verify billing, or support features like call forwarding and conference calling. These protocols are the hidden intelligence behind every connection. Network engineers who understand them can diagnose interoperability issues and design more reliable systems.

Real-World Use

When a prepaid mobile user roams onto a foreign network, SS7 messages travel between the visited network and the home network to authenticate the subscriber, check balance, and route the call — all within seconds, without the user ever knowing which protocol handled the transaction.

Main Content

The OSI Model and Telecom Protocols

Telecom protocols map to specific layers of the OSI (Open Systems Interconnection) model:

Signaling System No. 7 (SS7)

SS7 is the backbone signaling protocol used by the PSTN since the 1980s. It operates out-of-band — meaning signaling messages travel on a separate network from the voice paths themselves.

flowchart LR
    A[SSP - Service Switching Point] --> B[STP - Signal Transfer Point]
    B --> C[SCP - Service Control Point]
    B --> D[Other SSP]
    C --> E[Database - HLR, VLR, SCP Apps]
    A --> D

Expected behavior: When a call is placed, the SSP sends an ISUP IAM (Initial Address Message) to the next switch via STPs. The STP routes the message to the correct destination SSP or SCP based on the called number and point codes.

SS7 Protocol Stack

SS7 has its own layered protocol stack distinct from the OSI model:

• MTP Level 1 (Message Transfer Part) — physical layer, handles E1/T1 framing
• MTP Level 2 — ensures reliable transfer of signaling units between two directly connected points
• MTP Level 3 — routes messages between signaling points using Point Codes
• SCCP (Signaling Connection Control Part) — provides connectionless and connection-oriented services on top of MTP
• TCAP (Transaction Capabilities Application Part) — supports database queries (800 number lookup, prepaid balance)
• ISUP (ISDN User Part) — controls call setup, management, and teardown between exchanges

SS7 Message Example (ISUP IAM)

ISUP IAM (Initial Address Message)

Routing Label:
  DPC (Destination Point Code): 2-045-3
  OPC (Originating Point Code): 3-112-7
  SLS (Signaling Link Selection): 13

Circuit Identification Code: 145

Called Party Number: 1-212-555-0142
Calling Party Number: 1-415-555-0198
Nature of Connection Indicator: Digital, 64 kbps
Transmission Medium Requirement: Speech

Expected behavior: This message is sent from the originating switch to reserve a circuit between exchanges and begin call setup. The receiving switch checks the called number, determines the route, and sends a subsequent ACM (Address Complete Message) if the destination is available.

SIP (Session Initiation Protocol)

SIP is the application-layer protocol that establishes, modifies, and terminates multimedia sessions — including voice, video, and messaging — over IP networks. It is text-based and modeled after HTTP, making it easier to debug than binary SS7 messages.

SIP Message Example

INVITE sip:+12125550142@provider.net SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK74b43
Max-Forwards: 70
From: "Alice" <sip:+14155550198@provider.net>;tag=1928301774
To: "Bob" <sip:+12125550142@provider.net>
Call-ID: a84b4c76e66710@192.168.1.100
CSeq: 314159 INVITE
Contact: <sip:alice@192.168.1.100>
Content-Type: application/sdp
Content-Length: 142

[SDP body describing media capabilities]

Expected behavior: This INVITE is sent by Alice's phone to the SIP proxy server. The proxy resolves the domain, routes the request to Bob's phone, and Bob's phone responds with 180 Ringing and later 200 OK. Alice's phone then sends an ACK to confirm media parameters, and the RTP media stream begins.

SIP Methods Summary

VoIP Protocols Compared

Why SS7 and SIP Both Exist

SS7 was designed for circuit-switched networks where a dedicated path exists for the call duration. SIP was designed for packet-switched IP networks. The two worlds connect through signaling gateways that translate between SS7 ISUP and SIP messages at carrier interconnection points.

Protocol Interworking Scenario

PSTN Phone --SS7 ISUP--> Gateway --SIP--> VoIP Provider --SIP--> SIP Phone

The gateway:
1. Receives ISUP IAM from PSTN
2. Maps the called number to a SIP URI
3. Generates a SIP INVITE with equivalent call parameters
4. Forwards DTMF digits using SIP INFO or RFC 2833
5. Translates ISUP REL (Release) to SIP BYE when call ends

Expected behavior: The calling party experiences no difference — the call quality depends on the weakest link in the chain. Translation delays at the gateway add 5–15 milliseconds of latency.

Common Errors

1. Point Code Misconfiguration

SS7 Point Codes must match across all interconnected nodes. A single-digit error in a Destination Point Code causes calls to fail silently or route to the wrong carrier, often with no obvious alarm.

2. SIP Dialog Mismatches

A SIP BYE that does not match the Call-ID, From tag, and To tag of the original INVITE is rejected by the receiving endpoint. This happens frequently when proxies rewrite headers without preserving dialog identifiers.

3. Confusing MTP and SCCP Routing

MTP Level 3 routes based on Point Codes alone. SCCP adds Global Title Translation (GTT) for number-based routing. Engineers who bypass SCCP configuration cause database queries for 800 numbers and prepaid roaming to fail.

4. UDP vs. TCP for SIP

SIP over UDP has no delivery guarantee. Bursty networks may drop INVITE messages silently. Using TCP ensures delivery but increases firewall complexity. Choosing the wrong transport causes intermittent call setup failures.

5. Overlooking SDP Negotiation Failures

SDP contains media codec lists, IP addresses, and port numbers. If Alice's phone offers G.711 and G.729 but Bob's phone supports only Opus, negotiation fails silently unless both endpoints handle codec mismatch gracefully.

6. SS7 Security Assumptions

SS7 was designed for trusted carrier networks with no authentication. Modern SS7 access from untrusted networks enables location tracking, intercepting calls, and draining prepaid balances — a well-documented attack vector.

7. RTP Port Exhaustion

Each call requires an RTP port pair (one for audio, one for RTCP). NAT gateways and firewalls that do not dynamically open RTP ports cause one-way audio or no audio after the first few calls.

Practice Questions

Question 1

What is the primary difference between SS7 and SIP signaling?

Answer: SS7 is a binary, out-of-band protocol designed for circuit-switched PSTN networks using dedicated signaling links. SIP is a text-based, in-band protocol for packet-switched IP networks, modeled after HTTP.

Question 2

Which SS7 message is used to initiate a call, and what information does it contain?

Answer: The ISUP IAM (Initial Address Message) initiates a call. It contains the destination point code, originating point code, circuit identification code, called and calling party numbers, and transmission medium requirements.

Question 3

A SIP INVITE receives no response. What are three possible causes?

Answer: (1) The INVITE was sent over UDP and was lost — SIP retransmission timers may not have triggered. (2) The SIP proxy or endpoint is behind a firewall blocking UDP port 5060. (3) The SIP domain in the Request-URI is not served by the receiving proxy.

Question 4

How does a signaling gateway translate between SS7 and SIP?

Answer: The gateway receives ISUP IAM, extracts the called number, maps it to a SIP URI based on routing tables, generates a SIP INVITE with equivalent parameters, and maintains a mapping between the circuit identifier and SIP dialog for media translation.

Challenge Question

Design a call flow diagram for a call that originates on a traditional PSTN phone in Chicago and terminates on a SIP softphone in Berlin. Identify each protocol used at each hop and list the translation points where interworking occurs.

Mini Project

Capture and Analyze SIP Call Signaling

Set up a SIP call between two softphones and capture the signaling with Wireshark.

Requirements:

• Two SIP softphone clients (Zoiper, Linphone, or MicroSIP)
• A SIP server or PBX (Asterisk or FreePBX in a local VM)
• Wireshark installed on the same network segment

Steps:

1. Install and configure the SIP server with two extensions (1001 and 1002)
2. Register both softphones as extensions 1001 and 1002
3. Start a Wireshark capture on the interface the SIP server uses (filter: sip or udp.port==5060)
4. Place a call from extension 1001 to 1002
5. Speak for a few seconds, then hang up
6. Stop the capture and analyze the SIP messages

Expected SIP message sequence:

1001 -> Server: INVITE sip:1002@pbx.local SIP/2.0
Server -> 1002: INVITE sip:1002@192.168.1.50 SIP/2.0
1002 -> Server: 180 Ringing
Server -> 1001: 180 Ringing
1002 -> Server: 200 OK (with SDP)
Server -> 1001: 200 OK (with SDP)
1001 -> Server: ACK
Server -> 1002: ACK
    [RTP media flow]
1001 -> Server: BYE
Server -> 1002: BYE
1002 -> Server: 200 OK (BYE)
Server -> 1001: 200 OK (BYE)

Expected output: Wireshark displays the full SIP dialog. You can observe the Via, To, From, Call-ID, and CSeq headers in each message, along with the SDP body in INVITE and 200 OK responses. The RTP stream appears as a separate protocol after call setup.

This exercise mirrors the troubleshooting workflow used by telecom engineers and VoIP specialists in production environments.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.