Your First Call Flow: INVITE to BYE

SIP Signaling From the Wire Up: Part 3 of 12

You can now read individual SIP messages and understand what the major headers do. The next step is seeing how those messages fit together in sequence. A phone call isn't a single message. It's a conversation between SIP entities, a series of requests and responses that follow a specific pattern. Understanding this pattern is what lets you look at a packet capture and say "this is where the call went wrong."

This post walks through a complete basic call, from the moment someone dials a number to the moment someone hangs up. We'll show every SIP message in the sequence, explain why each one exists, and point out the things you should pay attention to when you see these in a trace.

The players

For this example, we have three entities:

• Alice's phone (10.0.0.50), the caller
• Proxy server (10.0.0.1), the PBX or SIP proxy handling call routing
• Bob's phone (192.168.1.100), the callee

In a real deployment, there might be more hops (an SBC, a SIP trunk provider, another proxy on the far side), but the fundamental message pattern is the same regardless of how many intermediaries are involved.

The call flow

Here's the complete sequence. We'll go through each step.

Alice                    Proxy                    Bob
  |                        |                        |
  |------- INVITE -------->|                        |
  |<----- 100 Trying ------|                        |
  |                        |------- INVITE -------->|
  |                        |<----- 180 Ringing -----|
  |<----- 180 Ringing -----|                        |
  |                        |<------ 200 OK ---------|
  |<------ 200 OK ---------|                        |
  |-------- ACK ---------> (directly to Bob or via proxy)
  |                        |                        |
  |<== RTP audio flows directly between Alice and Bob ==>|
  |                        |                        |
  |--------- BYE -------->|                        |
  |                        |--------- BYE -------->|
  |                        |<------ 200 OK ---------|
  |<------ 200 OK ---------|                        |
  |                        |                        |

Step 1: Alice sends INVITE

Alice picks up her phone and dials Bob's number. Her phone constructs an INVITE message and sends it to the proxy:

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 281

v=0
o=alice 2890844526 2890844526 IN IP4 10.0.0.50
s=Call
c=IN IP4 10.0.0.50
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 opus/48000/2
a=sendrecv

The Request-URI is sip:[email protected], which is a logical address. Alice's phone doesn't know Bob's IP address. That's the proxy's job to figure out. The SDP body at the bottom contains Alice's media proposal: she can do G.711 mu-law (PCMU), G.711 A-law (PCMA), or Opus, and she wants to receive audio on port 49170 at her IP address 10.0.0.50.

Step 2: Proxy sends 100 Trying

The proxy receives the INVITE, and the first thing it does is send back a 100 Trying:

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0

The 100 Trying says "I got your INVITE and I'm working on it." This is a hop by hop response. It stops Alice's phone from retransmitting the INVITE (since SIP over UDP has no built in delivery confirmation, the sender will keep resending until it gets a response). The 100 Trying does not mean the call is going to succeed. It just means the proxy acknowledged receipt.

Step 3: Proxy forwards INVITE to Bob

The proxy looks up Bob's registration (to find out where Bob's phone currently is) and forwards the INVITE:

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
Max-Forwards: 69
To: <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 281

[same SDP body as before]

Notice two changes. First, the Request-URI has been rewritten to sip:[email protected]:5060, which is Bob's actual network address from his registration. This is the proxy doing its job: translating a logical address into a physical one. Second, a new Via header has been added at the top for the proxy. The original Via from Alice is still there underneath. Max-Forwards has been decremented by one.

Step 4: Bob's phone rings, sends 180 Ringing

Bob's phone receives the INVITE, determines that it can accept the call, and starts ringing. It sends back a 180 Ringing:

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:[email protected]>;tag=a6c85cf
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Length: 0

The 180 Ringing tells Alice's phone to play a ringback tone (the sound you hear while waiting for someone to pick up). Note that Bob's phone has added a tag to the To header (tag=a6c85cf). Now we have both tags and the complete dialog identifier exists.

The proxy receives this response, peels off the top Via header (its own), and forwards the 180 to Alice's phone using the remaining Via.

Step 5: Bob answers, sends 200 OK

Bob picks up the phone. His phone sends a 200 OK with an SDP body containing Bob's media answer:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK2d4790
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:[email protected]>;tag=a6c85cf
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 203

v=0
o=bob 2808844564 2808844564 IN IP4 192.168.1.100
s=Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv

Bob's SDP answer selects PCMU (G.711 mu-law) from Alice's list of offered codecs and provides his own IP address and port for receiving audio (192.168.1.100 port 3456). Both sides now have all the information they need to start sending RTP audio to each other.

The proxy forwards the 200 OK to Alice, again stripping its own Via header in the process.

Step 6: Alice sends ACK

Alice's phone receives the 200 OK and sends an ACK to confirm:

ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf10
Max-Forwards: 70
To: <sip:[email protected]>;tag=a6c85cf
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0

The ACK is the third part of a three way handshake that's unique to INVITE. No other SIP method uses this pattern. The reason it exists is reliability. SIP often runs over UDP, which provides no delivery guarantee. The 200 OK to an INVITE is critically important (it commits both sides to the call and triggers resource allocation), so there needs to be a positive confirmation that the caller received it. If Bob's phone sends a 200 OK and never gets an ACK, it knows the 200 didn't arrive and can retransmit.

Step 7: Audio flows (RTP, not SIP)

At this point, SIP's job is done for now. Alice and Bob are talking. The audio travels as RTP packets directly between Alice's phone (10.0.0.50 port 49170) and Bob's phone (192.168.1.100 port 3456). SIP is not involved in this phase at all. There are no SIP messages during the conversation unless something changes, like a hold or transfer.

Step 8: Alice hangs up, sends BYE

Alice ends the call. Her phone sends a BYE:

BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf11
Max-Forwards: 70
To: <sip:[email protected]>;tag=a6c85cf
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 2 BYE
Contact: <sip:[email protected]:5060>
Content-Length: 0

Notice that CSeq has incremented to 2, and the method is now BYE. Same Call-ID, same tags. This is still the same dialog.

Step 9: Bob responds with 200 OK

Bob's phone acknowledges the BYE:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf11
To: <sip:[email protected]>;tag=a6c85cf
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0

The call is now complete. Both sides stop sending RTP. The dialog is terminated. Notice that BYE uses a simple two message exchange (BYE, 200 OK), not the three way handshake that INVITE uses. The ACK is only for INVITE.

What about CANCEL?

There's one more scenario worth covering. What happens if Alice hangs up while Bob's phone is still ringing, before he answers? Alice can't send BYE because the dialog isn't fully established yet (no 200 OK was received). Instead, she sends CANCEL:

CANCEL sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK74bf9
To: <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=9fxced76sl
Call-ID: [email protected]
CSeq: 1 CANCEL
Content-Length: 0

The CANCEL uses the same branch value as the original INVITE because it's cancelling that specific transaction. Bob's phone responds with a 200 OK to the CANCEL (acknowledging it received the cancellation) and then sends a 487 Request Terminated for the original INVITE (indicating that the INVITE was cancelled before it could be answered).

Why this matters for troubleshooting

When you're looking at a SIP trace of a failed call, the first thing to do is find the call flow and see where it deviates from this normal pattern. A call that never gets past the INVITE (no 100 Trying, no 180 Ringing) has a routing problem or the INVITE is being dropped by a firewall. A call that rings but never connects (180 Ringing comes back, but no 200 OK and no error response) might have a problem on the callee's end. If the trace ends with an unfamiliar response code, the SIP response code reference can help you narrow down the cause. A call that connects (200 OK received) but then drops immediately might have an ACK delivery problem.

Knowing what the normal flow looks like is the foundation for recognizing when something is abnormal. For a symptom-based reference of what deviations from this pattern mean in practice, see Common SIP Problems and What They Look Like.

Next up: SIP Registration: How Your Phone Tells the World Where It Is, covering what happens when a phone boots up and announces itself to the network.