SIP Fundamentals for Network Engineers — How VoIP Call Flow Actually Works

The call connects. Audio is fine for three seconds. Then one side goes silent.

You check the firewall — ports are open. You check the VLAN — voice traffic is segmented correctly. You check QoS — markings look right. Everything you know how to check looks fine, and the call is still broken.

The problem is in the SIP flow, and if you can’t read it, you’re troubleshooting blind. This article fixes that. By the end you’ll understand exactly what happens at the protocol level every time a VoIP call is set up, negotiated, and torn down — and you’ll be able to look at a SIP trace and know immediately where a call went wrong and why.

Everything else in the Networking pillar — firewall rules, one-way audio troubleshooting, SBC logs — makes significantly more sense once you have this foundation.

What SIP Actually Is

SIP (Session Initiation Protocol) is a signaling protocol. It sets up calls, modifies them, and tears them down. It does not carry voice.

This is the distinction most people miss. When you make a VoIP call, two completely separate things happen simultaneously:

SIP handles the negotiation — who’s calling, where to reach them, what codecs both sides support, where to send the audio. All of this is text-based, human-readable, and travels over TCP or UDP on port 5060 (or TLS on 5061 for encrypted signaling).

RTP carries the media — the actual audio stream, in real time, over UDP on dynamically negotiated ports. Once SIP has completed the call setup, it steps back and RTP takes over for the duration of the call.

Understanding this split is the foundation for everything else. A call that connects but has no audio is almost always an RTP problem — SIP did its job, but the media path is broken. A call that never connects is almost always a SIP problem — negotiation failed before RTP ever started.

The SIP Call Flow

A basic SIP call between two endpoints follows a predictable sequence. Every call — whether it’s Microsoft Teams, Webex Calling, or a traditional IP PBX — goes through this same fundamental flow.

Step 1 — INVITE

The calling party sends an INVITE message to the destination. This is the SIP equivalent of picking up the phone and dialing. The INVITE contains:

The destination address (SIP URI — looks like an email address: sip:user@domain.com)
The caller’s address
An SDP (Session Description Protocol) body describing what the caller can support — codecs, IP address, and the UDP port where it wants to receive audio

INVITE sip:bob@10.10.20.50 SIP/2.0
Via: SIP/2.0/UDP 10.10.20.10:5060
From: "Alice" <sip:alice@10.10.20.10>
To: <sip:bob@10.10.20.50>
Call-ID: a84b4c76e66710@10.10.20.10
CSeq: 314159 INVITE
Contact: <sip:alice@10.10.20.10>
Content-Type: application/sdp
Content-Length: 142

v=0
o=alice 2890844526 2890844526 IN IP4 10.10.20.10
c=IN IP4 10.10.20.10
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The SDP section at the bottom is where the codec negotiation lives. m=audio 49170 tells the destination to send audio to port 49170 on the caller’s IP. a=rtpmap:0 PCMU/8000 is offering G.711 μ-law at 8000Hz. This is the caller saying: here’s where I am, here’s what I speak, talk to me.

Step 2 — 100 Trying

The receiving SIP proxy or endpoint sends back a 100 Trying immediately. This is a provisional response — it means “I got your INVITE, I’m working on it.” It prevents the caller from retransmitting the INVITE while the destination is being located and alerted.

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.20.10:5060
From: "Alice" <sip:alice@10.10.20.10>
To: <sip:bob@10.10.20.50>
Call-ID: a84b4c76e66710@10.10.20.10
CSeq: 314159 INVITE

Step 3 — 180 Ringing

Once the destination endpoint has been located and is alerting the user, it sends 180 Ringing. This is what triggers the ringback tone on the caller’s end — the sound you hear while waiting for someone to pick up is generated locally by the caller’s device based on receiving this message, not transmitted across the network.

Step 4 — 200 OK

The called party answers. A 200 OK is sent back containing its own SDP — the destination’s codec selection and the port where it wants to receive audio. This completes the codec negotiation.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.20.10:5060
From: "Alice" <sip:alice@10.10.20.10>
To: "Bob" <sip:bob@10.10.20.50>
Call-ID: a84b4c76e66710@10.10.20.10
CSeq: 314159 INVITE
Contact: <sip:bob@10.10.20.50>
Content-Type: application/sdp
Content-Length: 131

v=0
o=bob 2890844527 2890844527 IN IP4 10.10.20.50
c=IN IP4 10.10.20.50
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Both sides have now exchanged IP addresses and ports for media. RTP streams start flowing in both directions — Alice sends audio to 10.10.20.50:3456, Bob sends audio to 10.10.20.10:49170.

Step 5 — ACK

The caller sends an ACK to confirm receipt of the 200 OK. This completes the three-way handshake that establishes the session. The call is now active and RTP is carrying the audio.

ACK sip:bob@10.10.20.50 SIP/2.0
Via: SIP/2.0/UDP 10.10.20.10:5060
From: "Alice" <sip:alice@10.10.20.10>
To: "Bob" <sip:bob@10.10.20.50>
Call-ID: a84b4c76e66710@10.10.20.10
CSeq: 314159 ACK

Step 6 — BYE / 200 OK

When either party hangs up, a BYE message is sent. The other side responds with a 200 OK confirming the session is terminated. RTP streams stop. The call is over.

SIP Response Codes — What They Mean

SIP uses a response code system similar to HTTP. Once you know the categories, reading a SIP trace becomes significantly faster.

Code Range	Category	Examples
1xx	Provisional — request received, processing	100 Trying, 180 Ringing
2xx	Success	200 OK
3xx	Redirection — try elsewhere	302 Moved Temporarily
4xx	Client error — bad request or auth failure	401 Unauthorized, 404 Not Found, 486 Busy Here
5xx	Server error — the server failed	500 Internal Server Error, 503 Service Unavailable
6xx	Global failure — call cannot be completed anywhere	603 Decline

The codes you’ll see most in production:

401 Unauthorized / 407 Proxy Auth Required — authentication challenge. Normal in the call flow — the endpoint responds with credentials and the INVITE is retried. If you see a 401 with no subsequent retry, authentication is failing.

404 Not Found — the destination SIP URI doesn’t exist. Dial plan problem — the number isn’t resolving to a valid endpoint.

486 Busy Here — destination is busy. Normal call flow.

487 Request Terminated — the caller hung up before the call was answered. Normal if a user cancels a call, worth investigating if it’s happening systematically.

480 Temporarily Unavailable — the endpoint exists but isn’t reachable right now. Registration expired, endpoint offline, or network path broken.

503 Service Unavailable — the SIP server is down or overloaded. Seen during SBC outages or when a carrier SIP trunk goes down.

488 Not Acceptable Here — codec negotiation failed. The INVITE offered codecs the destination doesn’t support. Common in mixed environments where endpoints have restricted codec lists.

Where Things Go Wrong — Reading the Flow

Now that you know the flow, the failure modes become readable.

Call never connects, no ringback: INVITE sent, no response or immediate 4xx/5xx. Check network connectivity to the SIP destination, verify the SIP trunk is registered, check firewall rules for TCP/UDP 5060.

Call connects but drops immediately: INVITE → 200 OK → ACK exchange completes, then almost immediately a BYE. SIP negotiation succeeded but RTP failed to establish. The most common cause is NAT — the SDP contains a private IP address that the remote end can’t reach. The 200 OK has the media destination, the remote end tries to send RTP there, nothing arrives, the call tears down. Check the IP addresses in the SDP bodies — they should be routable from both sides.

One-way audio: RTP is flowing in one direction only. The SDP negotiation completed, both sides think they know where to send audio, but one side’s packets aren’t arriving. Firewall blocking the return UDP path, asymmetric NAT, or a routing problem on one side. Check that the UDP ports in both SDP bodies are reachable from both endpoints.

Authentication loop: INVITE → 401 → INVITE with credentials → 401 again, repeating. The credentials are wrong or the authentication realm doesn’t match what the endpoint is configured to use.

488 on every call: Codec mismatch. Check what codecs are in the INVITE SDP versus what the destination supports. Common when connecting to a carrier that only accepts G.711 and the endpoint is offering Opus or G.722 first.

SIP and Cloud UCaaS Platforms

Microsoft Teams and Cisco Webex Calling use SIP as their underlying signaling protocol, but you won’t see raw SIP flows in the Teams Admin Center or Webex Control Hub under normal conditions — the platforms abstract it away for standard deployments.

Where SIP becomes directly visible is at the edge:

Teams Direct Routing — your SBC speaks SIP to Microsoft’s infrastructure. SIP traces from the SBC are your primary troubleshooting tool for call failures. Understanding the flow in this article is what makes those traces readable.

Webex Calling PSTN — SIP trunks to PSTN providers go through the Webex infrastructure. SBC logs and carrier SIP traces follow the same flow.

SIP Header Breakdown Tool — if you’re staring at a raw SIP message from an SBC log or a packet capture and need to know what every header field means, the SIP Header Breakdown Tool parses it line by line and explains each field in plain English. Paste the message, get the breakdown. It covers 30+ headers including Teams-specific fields like X-MS-Diagnostics.

What Comes Next

SIP is signaling. RTP is where the audio actually lives — and where the most frustrating call quality problems originate. Troubleshooting One-Way Audio in VoIP — Root Cause and Fix takes everything in this article and applies it directly to the most common RTP failure mode in production deployments.

For the network requirements that support SIP and RTP traffic, Firewall Rules for Teams and Webex covers the ports and protocols that need to be open for both signaling and media to flow correctly.

For the full pre-deployment validation checklist that puts everything in this pillar together, see Network Readiness Assessment for UCaaS.