Understanding the SIP INVITE Method: Core Call Setup and SDP Offer/Answer

Overview

The SIP INVITE request is the cornerstone method of the Session Initiation Protocol used to establish, modify, or re-negotiate multimedia communications. This guide explains the structure of a SIP INVITE message, its role in the SDP offer/answer model, the transaction lifecycle, and in-dialog re-INVITE operations. Engineering teams will gain a clear understanding of how INVITE requests govern call setup across modern VoIP networks.

Key takeaways

• SIP INVITE is an RFC 3261 method designed to initiate interactive multimedia sessions such as voice, video, and messaging.
• The request encapsulates mandatory headers (Via, From, To, Call-ID, CSeq, Max-Forwards) that manage routing and state.
• Media negotiation relies on Session Description Protocol (SDP) payloads embedded within the INVITE body (Early Offer) or in subsequent messages (Late Offer).
• INVITE setup involves a distinct three-way handshake (INVITE -> 200 OK -> ACK) to ensure reliable session state across unreliable transport layers.
• Re-INVITE requests modify existing dialog parameters to perform features like call hold, codec shifts, or media IP changes.

Prerequisites

• Fundamental understanding of IP networks and transport protocols (UDP, TCP, TLS).
• Basic knowledge of the Session Initiation Protocol (SIP) client/server architecture.
• Familiarity with plain-text protocol structures similar to HTTP.

Guide

1. section #1

   The Role of INVITE in Session Initiation In the Session Initiation Protocol (SIP), the INVITE method signals a user agent's desire to establish a communication session with another party. Defined in RFC 3261, INVITE creates the initial session context and initiates an INVITE transaction. Unlike non-INVITE requests (such as OPTIONS or REGISTER), the INVITE transaction involves a unique state machine designed to accommodate human reaction times during call ringing and to ensure reliable delivery over un-reliable transport protocols like UDP.

2. section #2

   Anatomy of a SIP INVITE Request A SIP INVITE request consists of a Request-Line, multiple SIP header fields, a blank line divider, and an optional message body (typically SDP). The Request-Line defines the method, Request-URI (destination), and SIP version. Key headers govern transaction tracking, routing, and dialog state: Via tracks the path taken by the request; From and To represent logical identities; Call-ID uniquely identifies the call; CSeq counts sequence numbers; Max-Forwards prevents infinite routing loops; and Contact provides the direct IP endpoint address for future in-dialog requests.

   INVITE sip:alice@example.com SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK776asdhds
   Max-Forwards: 70
   To: Alice <sip:alice@example.com>
   From: Bob <sip:bob@example.com>;tag=1928301774
   Call-ID: a84242c2672484918a97c1938da15@192.168.1.50
   CSeq: 314159 INVITE
   Contact: <sip:bob@192.168.1.50:5060>
   Content-Type: application/sdp
   Content-Length: 142
   
   v=0
   o=bob 2890844526 2890844526 IN IP4 192.168.1.50
   s=-
   c=IN IP4 192.168.1.50
   t=0 0
   m=audio 49170 RTP/AVP 0 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000

3. section #3

   The SDP Offer/Answer Model Media parameters such as IP addresses, RTP ports, codecs, and DTMF preferences are negotiated using the Session Description Protocol (SDP) following RFC 3264. In an 'Early Offer' flow, the UAC includes the SDP offer in the initial INVITE body, and the UAS responds with an SDP answer in a 200 OK (or provisional 183 Session Progress) message. In a 'Late Offer' flow, the UAC sends an INVITE without an SDP body; the UAS includes the SDP offer in its 200 OK, and the UAC completes negotiation by providing the SDP answer in the ACK message.

4. section #4

   Transaction Lifecycle and the Three-Way Handshake Because setting up a call requires alerting human participants, the INVITE lifecycle uses a three-way handshake: INVITE -> 200 OK -> ACK. When a proxy or endpoint receives an INVITE, it immediately returns a provisional response (100 Trying) to stop client retransmissions, followed by optional provisional updates such as 180 Ringing or 183 Session Progress. Once the user answers, the UAS sends a 200 OK final response. The UAC confirms receipt by returning an ACK request directly to the Contact address provided by the UAS, finalizing the dialog setup.

5. section #5

   In-Dialog Re-INVITE Requests Once an initial INVITE creates an established dialog (identified by To tag, From tag, and Call-ID), either party can send a new INVITE within the same dialog, known as a Re-INVITE. A Re-INVITE re-uses the existing Call-ID and incremented CSeq number to modify active session characteristics. Common use cases for Re-INVITE include putting a call on hold by altering SDP directionality attributes (e.g., changing 'a=sendrecv' to 'a=sendonly' or 'a=inactive'), shifting media pathways during call transfers, or renegotiating codecs to switch to T.38 fax transmission.

6. section #6

   Engineering Considerations and Best Practices When implementing or troubleshooting SIP INVITE interactions, ensure that Session Timers (RFC 4028) are configured to detect silent media failures or hung calls. Session Border Controllers (SBCs) must properly handle NAT traversal by updating Contact headers and rewriting SDP IP/port fields via hosted NAT traversal (HNT) mechanisms. Additionally, always secure INVITE exchanges using TLS for signaling encryption and Digest Authentication to prevent unauthorized call placement and SIP spoofing attacks.

Further reading

• RFC 3261 - SIP: Session Initiation Protocol
• RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)
• RFC 4566 - SDP: Session Description Protocol
• RFC 4028 - Session Timers in the Session Initiation Protocol (SIP)