A basic SIP call is an INVITE/200/ACK three-way handshake followed by media and a BYE. The caller sends INVITE (with an SDP offer); the callee replies 100 Trying, 180 Ringing, then 200 OK (with the SDP answer); the caller sends ACK; RTP media flows; and either party ends the call with BYE, answered by 200 OK.
Setting up the call
The call begins with the caller's UAC sending an INVITE toward the callee, carrying an SDP offer describing the media it wants. As the request traverses proxies, each may return 100 Trying to stop retransmissions. When the callee's phone starts alerting, a 180 Ringing flows back — this is what produces ringback. If early media is needed (network announcements, ringback from the far network), a 183 Session Progress with SDP can open the media path before answer.
Answer and the three-way handshake
When the callee answers, its UAS returns a 200 OK carrying the SDP answer that finalises media negotiation. The caller confirms with an ACK — the third leg of the INVITE handshake — and the dialog is now fully established, identified by Call-ID plus both tags. The three-way INVITE/200/ACK exchange, rather than a simple request/response, is what makes SIP call setup reliable even over lossy UDP.
Alice (UAC) Bob (UAS)
│ INVITE (SDP offer) ─────────▶ │
│ ◀───────── 100 Trying │
│ ◀───────── 180 Ringing │ (Bob's phone rings)
│ ◀───────── 200 OK (SDP answer) │ (Bob answers)
│ ACK ─────────▶ │
│ ◀═══════ RTP media (both ways) ═▶ │ (the conversation)
│ BYE ─────────▶ │ (Alice hangs up)
│ ◀───────── 200 OK │Media and mid-call changes
Once ACK completes setup, RTP media flows directly between the endpoints (or via a media relay) on the ports the SDP negotiated, independent of the signalling path. Mid-call changes are made with a re-INVITE or UPDATE carrying a new SDP — this is how hold (a=sendonly), resume (a=sendrecv), codec renegotiation and adding video are done, all within the existing dialog without dropping the call.
Ending the call — BYE
Either party ends an established call by sending BYE, which the other confirms with 200 OK; the dialog is then closed and the media stops. BYE is an in-dialog request, so it carries the established Call-ID, From-tag, To-tag and the next CSeq. Because it is a normal transaction, a lost BYE is retransmitted until acknowledged, so both sides converge on the call being over.
Aborting a call in progress — CANCEL
If the caller gives up before the callee answers — the call is still ringing — the UAC sends CANCEL, not BYE, because no final response has arrived yet. The callee stops alerting and returns 487 Request Terminated for the original INVITE, which the caller ACKs. CANCEL is only valid in this pre-answer window; once a 200 OK has been received, the call is established and BYE is the way to end it.
| Situation | Method | Result |
|---|---|---|
| Call answered, now hang up | BYE | 200 OK; dialog closed |
| Still ringing, caller gives up | CANCEL | 487 Request Terminated on the INVITE |
| Callee rejects while ringing | (response) 486/603 | Busy Here / Decline; caller ACKs |
Frequently asked
What is the basic SIP call flow?
INVITE (with SDP offer) → 100 Trying → 180 Ringing → 200 OK (with SDP answer) → ACK, then RTP media flows, and the call ends with BYE → 200 OK. The INVITE/200/ACK three-way handshake establishes the dialog; BYE tears it down.
Why does SIP use a three-way handshake for INVITE?
The ACK confirms the caller received the final 200 OK, making call setup reliable even over lossy UDP. Because a 200 OK to an INVITE is retransmitted until ACKed, the three-way exchange guarantees both sides agree the call is up before media is trusted.
How do I put a SIP call on hold?
Send a re-INVITE (or UPDATE) within the established dialog carrying new SDP that sets the media direction to a=sendonly (and a=sendrecv to resume). The dialog and call stay up; only the media direction changes, which is also how music-on-hold is delivered.
When do I send CANCEL instead of BYE?
Send CANCEL when the call is still ringing and no final response has arrived — it aborts the pending INVITE and yields a 487. Send BYE only after the call is established (a 200 OK was received). Using the wrong one leaves the two sides out of sync.
Does the media follow the same path as the SIP messages?
Usually not. SIP signalling may traverse several proxies, but RTP media flows on separately negotiated ports, typically directly between the endpoints or through a dedicated media relay or SBC — which is why signalling can succeed while media (audio) fails independently.
Source specifications
The published standards this page is grounded in. Opens in a new tab.