The SIP protocol call flow is the ordered sequence of signaling messages, from INVITE through 200 OK and ACK to BYE, that establishes, modifies, and tears down a voice or video session between two endpoints. SIP itself only handles signaling; the actual audio travels over RTP, with SDP negotiated inside the SIP messages describing the media. Understanding this flow is essential for anyone building VoIP systems, and platforms like VideoSDK bridge SIP signaling into modern WebRTC rooms so traditional telephony and web apps can interoperate.
Every VoIP engineer eventually stares at a packet capture full of SIP messages trying to figure out why a call has no audio, or why the INVITE never gets a response. The SIP protocol call flow is the mental model that turns that wall of text into a story you can read. Once you can trace a call from INVITE to BYE in your head, troubleshooting stops being guesswork and becomes pattern matching.
This guide walks through the complete SIP protocol call flow: the core components, the basic INVITE-to-BYE sequence, common variations like authentication challenges and call forking, the headers that hold a dialog together, and the failure modes you will hit in production. By the end, you will be able to read a SIP trace the way you read a stack trace.
What Is the SIP Protocol and How Does a Call Flow Work?
The Session Initiation Protocol is defined as a text-based application-layer signaling protocol, standardized by the IETF in RFC 3261, that creates, modifies, and terminates multimedia sessions between participants. A SIP protocol call flow works by exchanging requests and responses between endpoints, much like HTTP: a client sends a request such as INVITE or BYE, and the receiving side replies with a numeric status response such as 200 OK or 486 Busy Here.
SIP handles only the signaling layer. It negotiates what media will flow, using the Session Description Protocol embedded in the message body, but the actual voice or video packets travel over the Real-time Transport Protocol on a completely separate path. This separation of signaling and media is the single most important architectural fact about SIP, and it explains most of the classic failure modes, such as calls that connect but carry no audio.
Because SIP messages are plain text, they are human-readable in a packet capture, which makes SIP one of the most debuggable protocols in real-time communication. That readability is also why understanding the call flow matters more here than in binary protocols: the protocol's behavior is fully visible if you know what to look for.
Key SIP Components in a Call Flow
Four component roles appear in almost every SIP protocol call flow. The User Agent is the endpoint, acting as a User Agent Client when sending requests and a User Agent Server when receiving them. The Proxy routes requests toward their destination, making forwarding decisions based on the request URI. The Registrar accepts registration requests and maps a user's address-of-record to their current contact address. The Back-to-Back User Agent sits in the middle of a call, terminating each leg independently, which is how most commercial SIP servers and session border controllers operate.
The Basic SIP Protocol Call Flow: INVITE to BYE
The basic SIP protocol call flow follows a well-defined sequence: the caller sends an INVITE, provisional responses indicate progress, a final 200 OK confirms the session, an ACK completes the three-way handshake, RTP media flows, and a BYE ends the call. Each step exists for a specific reason, and skipping or misunderstanding any of them is a common source of bugs in VoIP implementations.
The flow begins when the caller's User Agent constructs an INVITE and sends it, usually through one or more proxies, toward the callee. The INVITE carries the SDP offer describing the codecs, ports, and addresses the caller wants to use for media. As the INVITE hops through proxies, each proxy adds its own Via header, creating a record of the path so responses can follow the same route back.
Once the callee answers, media flows directly between the endpoints (or through a media relay if NAT or firewall conditions require it), entirely independent of the SIP signaling path. When either party hangs up, a BYE request travels to the other side, receives a 200 OK, and the session is over.
INVITE Request: The Session Offer
The INVITE is the request that starts every SIP call. It carries the caller's identity in the From header, the callee's identity in the To header, and the routing target in the Request-URI. Its message body contains the SDP offer: the list of supported codecs, the IP address and port where the caller expects to receive RTP, and attributes like encryption requirements. The callee cannot send media until it knows these details, which is why the SDP offer must ride along with, or immediately follow, the INVITE.
100 Trying: Stop Retransmitting
The 100 Trying response is a provisional, hop-by-hop message that tells the upstream hop the request was received and is being processed. Its main job is to suppress retransmissions: SIP over UDP retransmits an INVITE if no response arrives within a timer window, and 100 Trying prevents that timer from firing while the callee's phone is still ringing. It is never forwarded end-to-end and carries no SDP.
180 Ringing and 183 Session Progress
The 180 Ringing response tells the caller the callee's endpoint has been alerted. A 183 Session Progress response is subtly different: it signals that early media is on its way, such as ringback tones generated by the network or an IVR prompt played before the call connects. The practical difference matters for audio behavior. If the caller plays local ringback on 180 but the network plays early media with 183, mishandling the two can produce double ringback tones or dead air during call setup.
200 OK and ACK: Completing the Handshake
When the callee answers, their User Agent sends a 200 OK containing the SDP answer: the selected codec, and the address and port where the callee will receive RTP. The caller then sends an ACK, which acknowledges the final response and completes SIP's three-way handshake for INVITE transactions. Only after this exchange is the dialog fully established. The ACK carries no SDP in the basic flow because the offer and answer have already been exchanged inside the INVITE and 200 OK.
BYE and Call Teardown
Either party can end the session by sending a BYE request within the established dialog. The receiving side confirms with a 200 OK, and the session is terminated. RTP stops immediately, and any resources reserved for the call, such as media relay ports or transcoder sessions, are released. A BYE is only valid inside an existing dialog; sending it outside one is a protocol error.
The full sequence looks like this:
SIP Protocol Call Flow Variations You Will Meet in Production
The textbook INVITE-to-BYE sequence is the skeleton, but real deployments add muscle: authentication, forking, mid-call modification, transfers, and gatewaying to the PSTN. Each variation inserts new messages into the basic SIP protocol call flow without changing its fundamental structure.
Authentication Challenge: 401 and 407
SIP servers authenticate users with a challenge-response mechanism. When a proxy or registrar receives a request from an unauthenticated user, it rejects the request with a 401 Unauthorized (from a registrar) or 407 Proxy Authentication Required (from a proxy) response, including a nonce value. The client then resends the request with a credentials header computed from the nonce, its username, and the request details. Because the nonce is tied to the specific request, the client must recompute credentials for each new request. This adds a full extra round trip to call setup, which is why some systems cache authentication state per dialog to reduce setup latency.
Call Forking and Redirection
A SIP protocol call flow does not have to be one-to-one. With parallel forking, a proxy sends the same INVITE to multiple registered contacts simultaneously, and the first 200 OK wins while the other legs receive CANCEL requests. With serial forking, the proxy tries contacts one at a time. Redirection is different: the callee's server responds with a 3xx class response, such as 302 Moved Temporarily, containing a new contact address, and the caller's own User Agent retries the INVITE toward that address. Forking explains the classic bug where two phones ring but only one call connects, and the other shows a missed call from yourself.
Re-INVITE for Mid-Call Changes
Once a dialog is established, either party can send a new INVITE within that dialog to modify the session. Common uses include putting a call on hold by changing the media direction attribute in SDP, switching codecs when network conditions degrade, or updating the media address after a phone roams to a different network. A re-INVITE follows the same transaction pattern as the original: offer, provisional or final response with the answer, and ACK. Mishandled re-INVITEs are a frequent cause of one-way audio after a hold and resume sequence.
Transfer and REFER
Call transfer uses the REFER request, which asks the recipient to establish a new session to a third party, referenced by a URI in the Refer-To header. The recipient reports progress through NOTIFY messages within the subscription that REFER creates. Blind transfer sends the REFER and hangs up; attended transfer first consults the target, then joins the parties. In practice, transfers between different vendors' equipment are one of the least interoperable corners of SIP, so test them early.
SIP Trunk to PSTN Gateway
When a SIP call crosses into the traditional phone network, a gateway translates between SIP signaling and ISUP, the PSTN's signaling protocol, while bridging RTP media into time-division channels. The SIP protocol call flow on the trunk side looks normal to your SIP endpoints, but the gateway maps SIP response codes to ISUP messages, and mismatches in that mapping can cause oddities like calls that connect but report failure. This is exactly the boundary that VideoSDK's telephony and SIP integration manages, bridging SIP trunks from providers like Twilio, Telnyx, or Plivo into WebRTC-based rooms.
The authenticated call setup sequence looks like this:
Understanding SIP Headers and Transaction IDs
SIP messages are stitched together into transactions and dialogs by a small set of headers, and reading them correctly is the core skill of trace analysis. The Via header records each proxy hop a request traverses, and responses follow the recorded route in reverse. Branch parameters in Via identify the transaction, so a response matches the request that created it.
The Call-ID header is a globally unique identifier for all messages in a dialog. The From and To tags complete the dialog identification: the caller's tag is set in the INVITE, the callee's tag appears in the 200 OK, and the combination of Call-ID, local tag, and remote tag uniquely identifies the dialog thereafter. The CSeq header sequences requests within a dialog, which is how a receiver distinguishes a re-INVITE from a retransmission of the original INVITE.
When troubleshooting, always check these identifiers first. A response with a mismatched branch parameter, a missing To tag in a 200 OK, or a CSeq number that does not line up tells you immediately where the flow broke. The IETF's RFC 3261 remains the authoritative reference for these semantics.
Common SIP Call-Flow Issues and Troubleshooting Tips
Most SIP failures fall into a handful of recognizable patterns. One-way audio almost always means the SDP addresses and the actual RTP path disagree, typically because of NAT. If a phone behind NAT advertises its private address in SDP, the remote side sends RTP to an unreachable destination, and you get audio in one direction only. The fix is STUN-derived addresses, media relays, or SIP ALG handling, and the diagnosis is comparing the connection address in the SDP against the packet source addresses in the RTP stream.
No response to an INVITE usually points to routing or transport problems: a firewall dropping UDP port 5060, a proxy unable to resolve the next hop, or a retransmission timer expiring before any provisional response. Mismatched SDP, where the offer contains no codec the answerer supports, produces a 488 Not Acceptable Here response and a call that never rings.
Reading a SIP trace effectively means filtering to one Call-ID and walking the messages in order. Check that each request has a matching response, that Via branches line up, and that the SDP offer and answer are coherent. Tools like Wireshark's VoIP call flow view render this visually, which is often faster than reading raw text.
Troubleshooting Checklist
- Filter the capture to a single Call-ID and verify every request has a final response.
- Confirm the SDP connection address matches the observed RTP source address to rule out NAT issues.
- Check Via branch parameters and CSeq values for transaction and dialog consistency.
- Verify the INVITE reached the intended User Agent and was not redirected by a 3xx.
- Look for 401 or 407 challenges followed by missing or malformed credentials.
- Confirm both sides sent RTP to the ports negotiated in the SDP answer.
- Check whether a re-INVITE during hold or resume changed the media path unexpectedly.
Best Practices for Designing Reliable SIP Call Flows
Designing SIP infrastructure that survives production means planning for the failure modes above rather than reacting to them. Place session border controllers or media relays at every network boundary where NAT or firewall traversal is likely, and let them handle topology hiding and fix-ups of SDP addresses. Keep proxy hops minimal, because every hop adds latency to call setup and another point of failure in the Via chain.
Tune timer settings deliberately: overly aggressive retransmission timers on lossy networks generate duplicate INVITEs and ghost ringing, while overly relaxed timers make failed calls feel slow to fail. Enforce TLS for signaling and SRTP for media wherever the endpoints support it, and authenticate every request at the network edge. Finally, design for scale by keeping the signaling path stateless where possible, using stateless proxies for simple forwarding and reserving Back-to-Back User Agent statefulness for features that genuinely need it, such as billing, transfer, or recording.
If you are building modern applications that need to talk to the phone network, consider bridging rather than rebuilding: VideoSDK's SIP telephony integration handles the gateway, routing rules, and DTMF translation so your WebRTC or AI voice agent participants can join calls carried over traditional SIP trunks.
Definitions Glossary
SIP (Session Initiation Protocol): A text-based signaling protocol, defined in RFC 3261, that establishes, modifies, and terminates multimedia sessions. SIP carries only signaling; media travels separately over RTP.
INVITE: The SIP request that initiates a session, carrying the caller's SDP offer with codecs and media addresses. Every SIP call flow begins with an INVITE transaction.
SDP (Session Description Protocol): The message body format that negotiates media details, including codecs, IP addresses, and RTP ports, exchanged as an offer inside the INVITE and an answer inside the 200 OK.
RTP (Real-time Transport Protocol): The transport protocol that carries the actual audio and video packets after SIP signaling completes, on a path independent of the signaling route.
Back-to-Back User Agent (B2BUA): A SIP entity that terminates both legs of a call and manages them independently, used by most commercial SIP servers and session border controllers for features like transfer and recording.
Dialog: The peer-to-peer relationship between two User Agents, identified by the Call-ID, From tag, and To tag, that persists from the 200 OK until the BYE completes call teardown.
Key Takeaways
- The SIP protocol call flow follows a fixed sequence: INVITE with SDP offer, provisional responses, 200 OK with SDP answer, ACK, RTP media, and BYE for teardown.
- SIP handles signaling only; RTP carries media on a separate path, and most one-way audio bugs come from that separation interacting with NAT.
- Authentication challenges, forking, re-INVITE, and REFER all extend the basic flow without changing its transaction structure.
- Via, Call-ID, CSeq, and From/To tags are the identifiers that hold transactions and dialogs together, and they are the first thing to check in any trace.
- Bridging SIP into modern apps does not require rebuilding the stack; VideoSDK's telephony integration connects SIP trunks directly into WebRTC rooms and AI voice agents.
Conclusion
Mastering the SIP protocol call flow means you can read any VoIP trace, from the cleanest INVITE-to-BYE sequence to the messiest authenticated, forked, and transferred call. The protocol rewards this knowledge generously, because its text-based messages hide nothing once you understand the transaction and dialog model. Start by capturing a few calls in a lab environment and walking each message against the flows diagrammed here, then move to the harder variations like re-INVITE and REFER. When you are ready to connect SIP telephony into a modern application, explore VideoSDK's telephony documentation or grab a free account at app.videosdk.live to try the bridge yourself. What are you building with SIP? Drop a comment, I'd love to hear what kind of call flow you're working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ