SIP shows up the moment you wire a phone number to anything: a PBX, a contact centre, a voice AI agent. And the first time a call fails, you're staring at a trace full of INVITEs, 1xx and 4xx codes. This post gives you the mental model to read that trace: what a session, dialog and transaction are, what the handshake protects, and how to tell which stage broke.
SIP (Session Initiation Protocol) is the IETF signalling standard that sets up, changes, and ends real-time calls over IP. It finds the other party, agrees on codecs and addresses using SDP, then steps aside while RTP carries the audio. SIP itself never carries a caller's voice.
This guide separates three terms that most explainers blur: session, dialog, and transaction. It then shows what the handshake protects, what SIP does when a message goes missing, and how to read a failed call by the stage where it stopped.
Note: Key takeaways
- SIP controls calls, and RTP carries them. A call can connect perfectly and still be silent, because the two protocols can take different network paths.
- A session is not a dialog. The session is the media exchange, the dialog is the signalling relationship, and a transaction is one request with its responses.
- The handshake is INVITE, 200 OK, ACK. SIP needs the third step because a person can take many seconds to answer.
- 32 seconds is a useful clue. With default timers, a 200 OK that never gets its ACK ends in a BYE at that point.
- In India, what you signal matters. TRAI's rules on number series and automated calls apply to the calls your trunk sets up.
What is SIP?
RFC 3261 defines SIP as an application-layer control protocol for creating, modifying, and terminating sessions. Published in June 2002, it replaced the original RFC 2543 of March 1999. It remains the base SIP standard, with extensions added by later RFCs.
SIP messages are readable text, and their request and response model resembles HTTP. A request names a method, such as INVITE, and a response returns a numeric status, such as 200 OK. The IANA SIP registry lists 14 methods as of its October 2026 update, though a basic call needs only a few.
SIP reaches well beyond desk phones. GetVoIP's overview lists uses including VoLTE, SIP trunking, and video conferencing. Each use relies on the same division of labour:
| Protocol | Job on a call | Defined in |
|---|---|---|
| SIP | Finds the party, rings, accepts, changes, and ends the call | RFC 3261 |
| SDP | Describes the media: codecs, address, port, and direction | RFC 8866 |
| Offer/answer | Sets how two sides use SDP to reach agreement | RFC 3264 |
| RTP | Carries the audio packets | RFC 3550 |
| SRTP | Encrypts and authenticates those packets | RFC 3711 |
Who takes part in SIP signalling?
A user agent is anything that starts or answers calls, such as a softphone, PBX, or voice AI service. A proxy routes requests onward. A registrar accepts REGISTER requests and records where a user can be reached. A session border controller sits at a network edge, and RFC 5853 catalogues its usual jobs, including topology hiding and NAT traversal.
The diagram follows the classic example from section 4 of RFC 3261. Notice that the audio never touches the proxies in this layout.
What is a SIP session?
In SIP, the session is the media exchange that signalling sets up. RFC 3261 puts it plainly: a session is a collection of participants and the media streams between them. The word gets used loosely, so check which of these two meanings you're reading.
- In the protocol, a session is one live media exchange, created when the offer and answer complete.
- In a sales quote, a "SIP session" can mean one concurrent call, the same unit as a channel. TelNet Worldwide's 2022 explainer uses the word this way.
Protocol engineers then split the signalling into two more layers. VideoSDK's session guide draws a similar three-part split, and these definitions follow the RFC:
| Layer | What it is | How long it lasts | How SIP identifies it |
|---|---|---|---|
| Transaction | One request and the responses to it | Usually seconds, or longer while a phone rings | The branch value in the top Via header |
| Dialog | The signalling relationship between two user agents | From the first tagged response until BYE | Call-ID, a local tag, and a remote tag |
| Session | The media those user agents exchange | From completed offer/answer until BYE | The origin line in SDP |
Why do the layers matter?
The separation lets you describe a problem precisely.
- A dialog can exist before a session does. A tagged 180 Ringing creates an early dialog, even though nobody has answered.
- One INVITE can create several dialogs. A forking proxy can ring several devices, and each 2xx from a different device forms its own dialog.
- A session can change while the dialog stays. A hold or codec change gives the session a new description under the same Call-ID.
- Your logs can join them. Call-ID is the value to search for when you compare traces from two systems.
Sizing uses the sales meaning, where one call in progress holds one channel. TRAI's February 2025 numbering recommendations note that a 2 Mbps PRI has 30 channels, and they put a SIP call at about 87 kbps with G.711 or 32 kbps with G.729. To turn call volume into channels, use the worked Erlang B example in What is SIP trunking?.
What is the SIP handshake?
The SIP handshake is the three-message exchange that establishes a call: INVITE, 200 OK, and ACK. RFC 3261 calls it the INVITE/200/ACK three-way handshake. Responses such as 100 Trying and 180 Ringing report progress, but they don't complete it.
- INVITE. The caller asks for a session and usually includes an SDP offer listing the media it can handle.
- 200 OK. The callee accepts and returns an SDP answer with its chosen codec and media address.
- ACK. The caller confirms that it received the acceptance, and the call is established.
Why does SIP need a third message?
Requests other than INVITE finish with a two-way exchange, but an INVITE usually waits on a person. The RFC gives that long, human-driven delay as the reason for the extra step. By the time someone answers, the caller may have gone or its network may have changed, so the callee needs proof that the caller is still there.
The name invites a comparison with TCP's three-way handshake, but the two do different jobs. TCP synchronises a connection between two hosts. SIP's exchange runs at the application layer, over UDP as well as TCP. It records a person's decision to answer and completes an agreement about media.
Two details surprise people when they read traces:
- The ACK for a 200 OK stands apart. It's a separate transaction and goes end to end, often straight to the address in the callee's Contact header. The ACK for a failure response stays within the INVITE transaction and is handled hop by hop.
- The offer can come later. If an INVITE has no SDP, the 200 OK carries the offer and the ACK carries the answer. This is often called delayed offer.
Most developers never send the ACK by hand, because SIP stacks normally generate it. Dialogic's 2010 SIP manual, for example, describes it as automatic with an option for manual control.
What happens when a handshake message is lost?
SIP was built to survive packet loss on UDP, so each side resends on a timer. The chart plots what RFC 3261's default timers produce.
The lower line produces a recognisable symptom. Both people talk normally for about half a minute, and then the call drops. The callee kept resending its 200 OK for 64 × T1 seconds, got no ACK, and ended the session with BYE. One likely cause is a Contact address that the ACK can't reach, such as a private address that a NAT device left in place.
The upper line can't produce audio at all. No reply within 64 × T1 ends the attempt, and the timing itself tells you that something on the signalling route never answered.
Other exchanges people call a SIP handshake
People use the word for four different exchanges, and each one fails in its own way:
| Exchange | Messages | What it settles | Typical failure |
|---|---|---|---|
| Call handshake | INVITE, 200 OK, ACK | Call accepted and media agreed | Drop at about 32 seconds |
| Digest challenge | Request, 401 or 407, then a retry with credentials | Who is calling | Same challenge repeats |
| Registration | REGISTER, often challenged, then 200 OK | Where a user can be reached | Binding expires, calls stop arriving |
| TLS handshake | TLS negotiation before any SIP message | Encryption and server identity on that hop | Certificate or version mismatch, with no SIP in the trace |
How does a SIP session change and end?
The session stays open to change after the handshake. These methods cover the rest of a call's life:
| Method | When you see it | What it does |
|---|---|---|
| REGISTER | Before any call | Records a user's current address |
| PRACK | During setup | Makes a provisional response reliable, which matters for PSTN interworking |
| CANCEL | Before answer | Abandons a ringing attempt, which draws a 487 |
| UPDATE | During setup or the call | Changes session details, even before the answer |
| re-INVITE | During the call | Offers a full new session description in the same dialog |
| REFER | During the call | Asks the other side to contact a third party, the basis of transfer |
| BYE | To end the call | Ends the session, usually the dialog as well |
Hold is a useful worked example. One side sends a new offer that marks the stream sendonly. The answer agrees, and the other side stops sending audio. The Call-ID doesn't change, because only the session changed.
If both sides send a re-INVITE at once, each side answers the other with 491 Request Pending. Each one then retries after a random wait. This collision is sometimes called glare.
What is a SIP session timer?
Base SIP has no keepalive for sessions. If a BYE is lost, a server tracking the call can't tell that it ended. RFC 4028 solves this with periodic re-INVITE or UPDATE requests, negotiated through the Session-Expires and Min-SE headers.
It recommends 30 minutes for Session-Expires, sets a floor of 90 seconds, and recommends refreshing at the halfway point. A value that is too low draws a 422 response. When calls drop at a regular interval, check whether a refresh was sent and answered.
How do you read a failed SIP call?
Start with the stage where the call stopped. The map below gives each stage a first check, and it's our own troubleshooting order rather than part of any standard.
The first digit of a response code tells you who needs to act:
| Class | Meaning | Codes you'll meet |
|---|---|---|
| 1xx | Still working | 100 Trying, 180 Ringing, 183 Session Progress |
| 2xx | Accepted | 200 OK |
| 3xx | Try elsewhere | 302 Moved Temporarily |
| 4xx | This request can't succeed as sent | 401, 404, 407, 408, 480, 486, 487, 488 |
| 5xx | The server failed | 500, 503 |
| 6xx | Nobody can accept this | 600 Busy Everywhere, 603 Decline |
When a firewall rewrites SIP
A firewall can change your SIP messages as well as filter them. Fortinet's FortiGate guide, for example, says its SIP session helper opens SIP and RTP pinholes and translates addresses inside SIP messages, and that SIP ALG mode adds further checks. If an SDP address or Contact header looks wrong, compare traces from both sides of the firewall. Change these settings only after that comparison shows the firewall is altering the messages.
Which SIP transport should you use?
RFC 3261 requires every SIP element to implement UDP and TCP. Its default ports are 5060 for UDP and TCP, and 5061 for TLS.
| Choose | When | Watch for |
|---|---|---|
| TLS | Signalling crosses the public internet | Certificates and renewals |
| TCP | You stay on a private network and messages grow large | Long-lived connections through NAT |
| UDP | You stay on a controlled network and need the simplest setup | Fragmentation. RFC 3261 moves requests above about 1,300 bytes to a congestion-controlled transport when the path MTU is unknown |
| WebSocket | The client is a browser, under RFC 7118 | Client and server must both support it |
What secures a SIP call?
SIP security comes in separate layers, and each one protects a different thing:
- TLS protects signalling one hop at a time. RFC 3261 warns that using TLS to a proxy gives no assurance of TLS end to end.
- SRTP protects the audio. TLS doesn't encrypt RTP, so you must enable SRTP separately. A mismatch can leave a connected call silent.
- Digest authentication proves identity. It avoids sending the password itself, and RFC 8760 adds SHA-256 options to the original algorithm.
- Source controls and destination limits contain damage. The SIP trunking guide has a full hardening checklist.
Do you need to handle SIP yourself?
Often you don't. Use this map to choose how much of the protocol you take on, then compare SIP with WebSocket streaming if you're building for voice AI.
Two neighbouring terms cause confusion here. VoIP is the wider category, and SIP is one protocol used within it, as SIP vs VoIP explains. WebRTC is a browser media stack, and it doesn't define which signalling you use.
What should you know about SIP in India?
SIP itself works the same in India, but the rules on what you signal are specific and active. The table connects each part of a call to its rule. Rules change often, so confirm the current text and take legal advice for your own case.
| Part of the call | Rule | Source and date |
|---|---|---|
| Calling number, promotional | Use the 140xx series after registering with your telecom provider | TRAI press release 91/2026, July 2026 |
| Calling number, service or transactional | Entities regulated by RBI, SEBI, IRDAI, and PFRDA, plus government bodies, use the 1600xx series | TRAI press release 91/2026, July 2026 |
| Calls started by software | Declare A2P calls and their CLI ranges to your originating provider in advance. Undeclared calls count as unsolicited | TRAI Third Amendment, September 2026 |
| The trunk itself | First unsolicited-call violation by a sender: outgoing services on all its telecom resources, including SIP trunks, barred for 15 days. Later violations: those resources disconnected for one year | TCCCPR Second Amendment, February 2025, and restated in the Third Amendment |
| Each number on the trunk | For the restoration provisions, each DID on a PRI or SIP trunk counts as a separate resource | TCCCPR Second Amendment, February 2025, and restated in the Third Amendment |
Three points deserve attention if you build on SIP.
Voice agents appear to fit the A2P definition. The Third Amendment covers calls started by an application, software system, or automated platform without direct human dialling, including artificial voice. An outbound voice agent seems to match that wording, so raise it with your provider before launch. Regulation 4 on declaration starts 60 days after Gazette publication. We could not confirm the publication date, so check whether it applies on your launch date.
The name on the call is changing. Inc42 reports that DoT directed operators to roll out calling name presentation (CNAP) from November 1, 2026, on 4G and newer networks. It adds that business and bulk-connection users can display a preferred name backed by a registered trademark or GST trade name. We read this in a news report rather than the DoT order. The report doesn't mention SIP.
CLI checks may tighten. TRAI has recommended CNAP for SIP and PRI calls reaching mobile networks, and a CLI authentication framework when providers extend SIP or PRI trunks to enterprises. These are recommendations, and we could not confirm how far each has been implemented.
For toll bypass and more enforcement detail, see the India section of What is SIP trunking?.
How Vobiz handles SIP
Vobiz SIP trunking exposes the protocol where you need it and handles it where you don't..
- Trunks. The console has separate pages for outbound and inbound trunks. The Trunks API sets each trunk's direction.
- The handshake's identity step. Attach an IP access control list or a SIP credential. Credential trunks are challenged with 407 Proxy Authentication Required.
- Transport and encryption. The trunk settings choose UDP, TCP, or TLS for signalling, and a separate setting controls SRTP for media.
- Paths. Signalling and media use different addresses, and media flows directly rather than through the signalling SBCs. Open the ranges on that page, because allowing only the SIP ports gives you a connected call with no audio.
- Endpoints. SIP endpoints register their own addresses. The API reports whether each endpoint is registered, its contact address, and when the registration expires, so you can check a binding directly.
- Transfers. SIP trunking supports blind and warm transfer through REFER, and the Transfer API works on a live call from your own code.
- No SIP at all. With VobizXML, your server returns call logic through webhooks (callbacks), and Vobiz handles the signalling. Audio Streams then fork live audio to your WebSocket server.
Tracing a session on Vobiz
The SIP call logs include a SIP Trace view of the raw messages with timing, the hangup cause code, and the authentication method used. Open a call and select the More tab to find them.
The CDR API can filter by SIP Call-ID, which lets you match a Vobiz record to your own PBX trace. Each record also reports the negotiated codec, plus call-quality scores, jitter, and packet loss. The hangup causes reference explains each code and its next step.
India on Vobiz
Vobiz's India calling regulations cover KYC, caller ID, and media anchoring. Both legs of an Indian call must stay in India. A breach ends the call with hangup cause 2070, and a caller ID that isn't a Vobiz number ends it with 3030. See 140 and 160 series acquisition for commercial numbers and UCC management for complaints.
Test calls are billed to your account. Run them with your own Auth ID and Auth Token, and confirm the numbers first. Current rates are on the Vobiz pricing page.
Frequently asked questions
FAQ
What is a SIP session?
In the protocol, a SIP session is the live media exchange between participants, created when the SDP offer and answer complete. In carrier quotes, the phrase can mean one concurrent call, the same capacity unit as a channel. Check which meaning applies before you compare plans.
What is the SIP three-way handshake?
It is the INVITE, 200 OK, and ACK exchange that establishes a call. The caller asks, the callee accepts, and the caller confirms that it received the acceptance. The third message exists because a person may take a long time to answer.
How does a SIP session differ from a SIP dialog?
The dialog is the signalling relationship, identified by the Call-ID and two tags. The session is the media that relationship controls. A dialog can exist while a phone rings, before any session starts, and a hold changes the session without creating a new dialog.
What is a SIP session timer?
It is a keepalive defined in RFC 4028. The two sides negotiate an interval with the Session-Expires header, then send a re-INVITE or UPDATE at about the halfway point. If no refresh arrives in time, each side treats the session as ended and should send BYE.
What port does SIP use?
The defaults are port 5060 for SIP over UDP or TCP, and port 5061 for SIP over TLS. Those ports carry signalling only. RTP audio uses separate ports chosen for each call and named in the SDP, so your firewall has to allow both.
Is SIP the same as VoIP?
No. VoIP is the broad category of carrying voice over IP networks. SIP is one signalling protocol used within it, and it handles call setup, changes, and teardown. A VoIP call that uses SIP still relies on RTP or SRTP to carry the audio.
Further reading on Vobiz
- What is SIP trunking? · SIP vs VoIP · What is WebRTC?
- SIP trunking concept guide · SIP vs WebSockets · Streaming over WebSockets
- Hangup causes · SIP call logs · IP whitelisting
- Concurrency capacity · Origination URI · 3CX integration · LiveKit integration
Sources
Standards and registries
- IETF, RFC 2543: SIP: Session Initiation Protocol, March 1999 (obsoleted).
- IETF, RFC 3261: SIP: Session Initiation Protocol, June 2002.
- IETF, RFC 3262: Reliability of Provisional Responses in SIP, June 2002.
- IETF, RFC 3264: An Offer/Answer Model with SDP, June 2002.
- IETF, RFC 3311: The SIP UPDATE Method, September 2002.
- IETF, RFC 3515: The SIP Refer Method, April 2003.
- IETF, RFC 3550: RTP: A Transport Protocol for Real-Time Applications, July 2003.
- IETF, RFC 3711: The Secure Real-time Transport Protocol, March 2004.
- IETF, RFC 4028: Session Timers in SIP, April 2005.
- IETF, RFC 5853: Requirements from SIP Session Border Control Deployments, April 2010.
- IETF, RFC 7118: The WebSocket Protocol as a Transport for SIP, January 2014.
- IETF, RFC 8760: SIP Digest Access Authentication Update, March 2020.
- IETF, RFC 8866: SDP: Session Description Protocol, January 2021.
- IETF, RFC 9293: Transmission Control Protocol, August 2022.
- IANA, Session Initiation Protocol (SIP) Parameters, updated October 2026.
Indian regulators and reporting
- TRAI, Telecom Commercial Communications Customer Preference (Second Amendment) Regulations, 2025, February 2025.
- TRAI, Recommendations on Revision of National Numbering Plan, February 2025.
- TRAI, Press release 91/2026 on the 1600 and 140 series, July 2026.
- TRAI, Telecom Commercial Communications Customer Preference (Third Amendment) Regulations, 2026, September 2026.
- Inc42, Centre Directs Telcos To Display Caller Names From November 1, October 2026.
Vendor references
- Fortinet, SIP ALG and SIP session helper (FortiOS 8.0.0).
- GetVoIP, What is a SIP Protocol and How Does it Work?, updated December 2023.
- VideoSDK, SIP Session: The Definitive Guide.
- Dialogic, Acknowledging a call, 2010.
If you're wiring a voice AI agent into SIP, Vobiz provides SIP trunks and phone numbers built for AI voice agents.
Top comments (0)