SIP Registration and INVITE Flow, Step by Step

Introduction¶

SIP is a text protocol that looks a lot like HTTP: request lines, headers, a blank line, an optional body (usually SDP describing the media). Two transactions do almost all the work — REGISTER (tell the server where you are) and INVITE (set up a call). If you can read those from a packet capture, you can debug most VoIP problems.

Registration¶

When a phone boots, it tells its SIP registrar which address to send calls to:

REGISTER sip:pbx.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-abc123
From: <sip:[email protected]>;tag=8f2a
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Content-Length: 0

The server challenges with 401 Unauthorized and a nonce; the phone resends REGISTER with an Authorization header (MD5 digest of the credentials + nonce). The server replies 200 OK and stores the binding 1001 → 192.168.1.50:5060 for 3600 seconds. The phone re-registers before expiry.

NAT wrinkle: the Contact says 192.168.1.50 (private). The registrar actually received the packet from a public IP:port. Most servers support "NAT-aware" registration (nat=force_rport in Asterisk / rewrite-contact in Kamailio) — they use the source address they saw, not what the phone claimed.

The INVITE flow¶

A basic call, 1001 calling 1002:

1001 ---- INVITE (SDP offer) ---->  PBX  ---- INVITE ---->  1002
1001 <---- 100 Trying ------------  PBX
1001 <---- 180 Ringing -----------  PBX  <--- 180 Ringing - 1002
1001 <---- 200 OK (SDP answer) ---  PBX  <--- 200 OK ------ 1002
1001 ---- ACK -------------------->  PBX  ---- ACK -------->  1002
         <=========== RTP media flows directly / via PBX ===========>
   ...
1001 ---- BYE -------------------->  PBX  ---- BYE -------->  1002
1001 <---- 200 OK ----------------  PBX  <--- 200 OK ------ 1002

Key points:

• INVITE / 200 / ACK is a three-way handshake, like TCP's SYN/SYN-ACK/ACK. The ACK confirms the caller got the answer. A call that "connects then drops after ~30s" is almost always a lost ACK — the callee retransmits 200 OK, gives up, and sends BYE.
• 100 Trying stops the sender retransmitting the INVITE. 180 Ringing is informational. 200 OK carries the SDP answer (codec, RTP IP:port).
• Everything after setup is identified by the dialog: Call-ID + both tags (From tag + To tag). BYE must carry all three or it's rejected.

The headers that route everything¶

• Via — the path the request took. Each proxy prepends its own Via. Responses walk the Via list back down. A wrong/unreachable Via address means responses vanish (one-way signalling).
• Contact — where to send subsequent requests in this dialog (the ACK, re-INVITEs, BYE), bypassing proxies. Wrong Contact behind NAT → mid-call requests fail.
• Record-Route — a proxy that wants to stay in the signalling path for the whole dialog adds this. The endpoints then Route every in-dialog request through it. Without it, a stateful proxy (billing, NAT help) gets bypassed after setup.
• Max-Forwards — hop counter, like IP TTL. Hits 0 → 483 Too Many Hops (usually a routing loop).

SDP and media¶

The INVITE body:

v=0
o=- 20000 20000 IN IP4 192.168.1.50
c=IN IP4 192.168.1.50
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv

c= + m= say "send my audio to 192.168.1.50:40000". The answer in the 200 OK does the same for the other direction. Codecs 0 (PCMU/G.711µ) and 8 (PCMA/G.711a) are the offer; the answer picks one. 101 is telephone-events (DTMF).

Verification and troubleshooting¶

# Live view of SIP transactions, ladder diagrams, on the PBX
sngrep

# Capture SIP only (port 5060) for later analysis in Wireshark
tcpdump -i any -s0 -w sip.pcap 'port 5060'

# Asterisk
asterisk -rx "pjsip show registrations"
asterisk -rx "pjsip set logger on"

• Phone shows "not registered" — wrong credentials (watch for 403 Forbidden vs 401), firewall dropping UDP 5060, or the registrar behind NAT itself. sngrep shows whether REGISTER even arrives.
• Call connects, no audio (or one-way) — RTP, not SIP. The SDP c=/m= address is private and NAT isn't being fixed, or a firewall blocks the RTP port range (often 10000–20000 UDP). One-way = only one side's RTP is getting through.
• Call drops after ~30 seconds — lost ACK (see above), or a session timer (Session-Expires) with no re-INVITE keepalive.
• 488 Not Acceptable Here — no common codec between the two sides, or an SRTP/RTP mismatch (one side demands encryption).
• 480 Temporarily Unavailable — the destination extension isn't registered. 503 Service Unavailable — trunk/gateway down.
• Retransmissions of INVITE (same branch, every 500ms) — no 100 Trying came back; the next hop isn't responding at all.

Related tools and reading¶

• On-site: Port Checker, Ping test, DNS SRV Lookup.
• Related posts: RTP and RTCP basics, SIP trunk basics for sysadmins.