VoIP and SIP Deep Dive — SIP Messages, SDP, RTP, Codecs, NAT Traversal, and PBX Architecture

In this tutorial, you'll learn about VoIP and SIP Deep Dive. We cover key concepts, practical examples, and best practices.

SIP (Session Initiation Protocol) is the foundation of modern VoIP communications, enabling session establishment, media negotiation, and call control through a text-based request-response model that mirrors HTTP.

What You'll Learn

You will master the complete SIP call flow, SDP media negotiation syntax, RTP/RTCP transport mechanics, audio codec characteristics, NAT traversal strategies, and Asterisk PBX architecture for production VoIP deployments.

Why It Matters

Understanding SIP at the protocol level is essential for telecom engineers who deploy, troubleshoot, or interconnect VoIP systems. Mistranslated headers, misconfigured codecs, or missing NAT traversal cause silent call failures that are invisible to monitoring tools that only check server uptime.

Real-World Use

A global enterprise with 10,000 users reports one-way audio on calls between its European and Asian offices. The network team blamed the firewall. The VoIP team found the cause: SDP in the INVITE contained private IP addresses from the LAN, but the media was expected to traverse a WAN link with no TURN relay configured.

Main Content

SIP Message Structure

Every SIP message consists of a start line, headers, and an optional body. Requests have a Request-Line, responses have a Status-Line.

SIP Request Format:

INVITE sip:bob@company.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK1234
Max-Forwards: 70
From: Alice <sip:alice@company.com>;tag=abc123
To: Bob <sip:bob@company.com>
Call-ID: cdef1234@10.0.0.1
CSeq: 1 INVITE
Contact: <sip:alice@10.0.0.1:5060>
Content-Type: application/sdp
Content-Length: 158

[SDP Body]

SIP Response Format:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK1234
From: Alice <sip:alice@company.com>;tag=abc123
To: Bob <sip:bob@company.com>;tag=def456
Call-ID: cdef1234@10.0.0.1
CSeq: 1 INVITE
Contact: <sip:bob@10.0.0.2:5060>
Content-Type: application/sdp
Content-Length: 152

[SDP Body]

Expected behavior: The branch parameter in the Via header must be globally unique and start with z9hG4bK. The tag parameter in From and To uniquely identifies each participant in the dialog. These tags are used to match responses and subsequent requests to the correct dialog.

SIP Response Codes

SDP Media Negotiation

SDP (Session Description Protocol) is carried in the body of SIP messages. It describes media capabilities so endpoints can agree on codecs, transport addresses, and session parameters.

SDP from INVITE (Alice offering):

v=0
o=alice 2890844526 2890844526 IN IP4 10.0.0.1
s=-
c=IN IP4 10.0.0.1
t=0 0
m=audio 49170 RTP/AVP 0 8 9
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=sendrecv

SDP from 200 OK (Bob answering):

v=0
o=bob 2890844527 2890844527 IN IP4 10.0.0.2
s=-
c=IN IP4 10.0.0.2
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv

Expected behavior: Alice offers three codecs: PCMU (0), PCMA (8), and G.722 (9). Bob answers with PCMU (0) only — he selects the preferred codec from the offered list. The c= line carries the IP address where Bob expects to receive RTP. Port 49172 is the RTP destination port on Bob's side.

RTP and RTCP

RTP carries the actual media payload. RTCP provides out-of-band statistics about the call quality.

RTP Packet Structure:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          payload ...                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Expected behavior: Each RTP packet carries a sequence number for loss detection and reordering, a timestamp for jitter calculation and playback timing, and an SSRC identifier that uniquely identifies the media stream within a session.

Audio Codec Deep Dive

NAT Traversal

NAT (Network Address Translation) breaks SIP because IP addresses embedded in headers and SDP differ from the translated addresses seen on the public internet.

flowchart TD
    A[SIP Phone behind NAT] -->|Private IP in SDP: 192.168.1.10:49170| B[NAT Router]
    B -->|Public IP in packet: 203.0.113.5:12345| C[SIP Server on Internet]
    C -->|Sends RTP to 192.168.1.10:49170 - FAILS| D[Internet]
    D -->|RTP packets dropped| A

Solutions:

Asterisk PBX Architecture

Asterisk is an open-source PBX platform that connects SIP phones, PSTN gateways, and VoIP providers through a modular architecture.

Asterisk Core Components:

        +-------------------------+
        |    Asterisk Core        |
        | (Channel, Bridge, PBX)  |
        +-----------+-------------+
                    |
     +--------------+--------------+
     |              |              |
+----v----+   +----v----+   +-----v-----+
| SIP     |   | DAHDI   |   | IAX2      |
| Channel |   | Channel |   | Channel   |
+---------+   +---------+   +-----------+

Sample Asterisk SIP configuration (pjsip.conf):

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[1001]
type=endpoint
context=internal
disallow=all
allow=ulaw
allow=alaw
allow=g722
auth=1001-auth
aors=1001-aor

[1001-auth]
type=auth
auth_type=userpass
password=securepass123
username=1001

[1001-aor]
type=aor
max_contacts=1

Expected behavior: The transport section binds Asterisk to UDP port 5060. Endpoint 1001 is configured to accept ulaw, alaw, and g722 codecs. Authentication requires the password securepass123. The AOR (Address of Record) limits registration to one device.

Complete SIP Call Flow with All Messages

sequenceDiagram
    participant A as SIP Phone A
    participant P as SIP Proxy
    participant B as SIP Phone B

    A->>P: INVITE
    P->>A: 100 Trying
    P->>B: INVITE
    B->>P: 180 Ringing
    P->>A: 180 Ringing
    B->>P: 200 OK (with SDP)
    P->>A: 200 OK (with SDP)
    A->>P: ACK
    P->>B: ACK
    Note over A,B: RTP Media Flow
    A->>P: BYE
    P->>B: BYE
    B->>P: 200 OK (BYE)
    P->>A: 200 OK (BYE)

Expected behavior: The proxy forwards requests and responses between the two endpoints. In a direct media scenario, the proxy learns the IP addresses from SDP exchange and instructs endpoints to send RTP directly to each other in the ACK.

Common Errors

1. Wrong SDP Origin or Connection Address

Putting the wrong IP address in the o= or c= line of SDP is the most common cause of one-way audio. Always verify these addresses match the interface that will actually send and receive RTP.

2. Via Branch Parameter without z9hG4bK Prefix

RFC 3261 mandates that Via branch parameters begin with z9hG4bK for compatibility. Non-compliant branch values cause proxies and endpoints to reject messages.

3. Missing RTP Port Ranges in Firewalls

SIP signaling on port 5060 may succeed, but if the firewall blocks the dynamic RTP port range (typically 16384-32767), no audio flows. Open the full RTP range or configure a specific port range in the PBX.

4. Confusing Asterisk Dialplan Contexts

An endpoint placed in the wrong dialplan context cannot make or receive calls. Contexts control call routing, permissions, and features. Verify the context= setting in pjsip.conf matches an existing context in extensions.conf.

5. STUN Failing on Symmetric NAT

STUN works with cone NAT but fails with symmetric NAT (where each destination IP/port pair gets a different public port). ICE with TURN fallback is the only reliable solution for symmetric NAT environments.

6. RTCP Not Enabled

RTCP provides packet loss, jitter, and round-trip time statistics. Without RTCP, administrators have no visibility into call quality issues. Enable RTCP with rtcp-mux or a separate RTCP port range.

7. Incorrect SDP Codec Preference Ordering

The first codec in the SDP m= line is the preferred codec. If G.711 is listed first but both sides support Opus with better quality, callers get G.711 anyway. Reorder the allow= directives in Asterisk to match desired preference.

Practice Questions

Question 1

What SIP message carries the SDP body that describes media capabilities?

Answer: The INVITE request carries the offer SDP. The 200 OK response carries the answer SDP. Each side advertises its media capabilities and chosen parameters.

Question 2

How does ICE solve the NAT traversal problem for VoIP?

Answer: ICE gathers candidate transport addresses from the local interface (host), from a STUN server (server reflexive), and from a TURN relay (relay). It prioritizes candidates by type and tests connectivity between each pair until a working path is found, then reports the selected pair through SDP.

Question 3

What is the difference between RTP and RTCP?

Answer: RTP carries the actual media payload (audio/video). RTCP carries out-of-band statistics including packet loss, jitter, round-trip time, and sender/receiver reports. RTCP typically uses 5% of the RTP session bandwidth.

Question 4

Explain what happens when the called party does not support any codec offered by the calling party.

Answer: The called party responds with a 488 Not Acceptable Here response. The calling party may retry with a different codec list, or the call fails. Proper SIP implementations should include a fallback plan such as a transcoding gateway.

Challenge Question

Trace the complete SIP and SDP message exchange for a call between two phones behind different symmetric NATs, using ICE with TURN relay. Identify at which point each candidate is gathered, how connectivity checks work, and when the media relay path is selected.

Mini Project

Deploy a SIP PBX with Asterisk and Configure Two Extensions

Set up a functional Asterisk PBX on a Linux virtual machine with two SIP extensions and an outbound trunk.

Requirements:

• Ubuntu 22.04 or Debian 12 VM (any hypervisor)
• Asterisk 20+ installed from official packages
• Two SIP softphones (Linphone or Zoiper) on the same network
• Wireshark for verification

Steps:

1. Install Asterisk: sudo apt install asterisk
2. Configure pjsip.conf with two endpoints (1001, 1002) as shown in the sample above
3. Configure extensions.conf:

[internal]
exten => 1001,1,Dial(PJSIP/1001,30)
exten => 1002,1,Dial(PJSIP/1002,30)
exten => _X.,1,Dial(PJSIP/${EXTEN}@trunk-provider)

4. Register softphones as extensions 1001 and 1002
5. Place a call from 1001 to 1002 — verify audio flows both ways
6. Capture SIP signaling with Wireshark and confirm the INVITE/200 OK/ACK/BYE sequence
7. Examine the SDP in the INVITE — note the codecs offered and the connection IP

Expected output: Both extensions register and authenticate with Asterisk. Calls between extensions complete with two-way audio. Wireshark shows the complete SIP dialog including INVITE, 180 Ringing, 200 OK, ACK, BYE. The SDP contains the correct IP addresses and negotiated codecs.

This deployment mirrors the architecture used by VoIP PBX systems in small-to-medium businesses and demonstrates the core protocol interactions of SIP communications.

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