SIP INVITE Explained (With Call Flow)

The SIP INVITE method is the fundamental request used to initiate a multimedia session, such as a voice or video call, within the Session Initiation Protocol. It signals an intention to establish communication, carrying session description information (SDP) that details the media capabilities and parameters for the proposed connection. It's the "hello, I want to talk" message in SIP.

Before SIP, establishing real-time communication sessions involved complex, often proprietary, signaling systems. The SIP INVITE method was designed to standardize and simplify call initiation across diverse IP networks. It solves the problem of interoperability by providing a unified way for VoIP endpoints and servers to negotiate and establish sessions. By carrying participant addresses, session type, and media codecs, INVITE enables universal communication setup, caller ID, call routing, and media negotiation, crucial for modern unified communications.

The SIP INVITE method kicks off the intricate sip call flow for establishing a communication session. Here's a typical sequence:

1. Initiation: A User Agent Client (UAC), like your VoIP phone, sends a SIP INVITE sip request to a SIP Proxy Server (or directly to another User Agent Server, UAS). This INVITE contains critical information about the proposed call.
2. Proxying/Routing: If sent to a proxy, it forwards the INVITE, potentially through several other proxies, until it reaches the intended UAS.
3. Ringing Indication (180 Ringing): The UAS, upon receiving the INVITE and determining availability, typically sends a 180 Ringing provisional response. This informs the calling party that the callee's phone is ringing. Other responses like 100 Trying or 183 Session Progress (with early media) might precede this.
4. Callee Accepts (200 OK): When the callee answers, the UAS sends a 200 OK final response. This confirms the callee is ready. If the INVITE contained an SDP offer, the 200 OK will contain the callee's SDP answer.
5. Caller Acknowledges (ACK): The original UAC then sends an ACK (Acknowledgement) message. This finalizes the handshake, confirming receipt of the 200 OK, and signaling that media exchange can begin.
6. Media Exchange: After the ACK, media (voice, video) flows directly between the UAC and UAS (peer-to-peer) or via a media server, based on the negotiated SDP.

Understanding the SIP INVITE means knowing its key headers, crucial for routing, managing, and identifying the session.

• From: Identifies the request initiator. Contains the caller's SIP URI and a tag parameter.
  • From: "Alice" <sip:[email protected]>;tag=9fxced76sl
• To: Identifies the intended recipient. Contains the callee's SIP URI. A tag is added by the UAS in the 200 OK.
  • To: "Bob" <sip:[email protected]>
• Via: Records the path taken by the sip request. Each SIP entity forwarding the message adds its own address, essential for routing responses back.
  • Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
• Contact: Indicates the direct URI where the User Agent (UA) can be reached for subsequent requests.
  • Contact: <sip:[email protected]:5060>
• Call-ID: A unique identifier for a specific sip call flow. All messages for the same call share this ID.
  • Call-ID: 2f7a9g8j0h9f8d7s6a
• CSeq (Command Sequence): A decimal number and method name (e.g., INVITE). Orders transactions, ensuring reliable delivery. Increments for each new request.
  • CSeq: 1 INVITE

The SIP INVITE typically carries a Session Description Protocol (SDP) payload, describing media characteristics like codecs, IP addresses, and ports.

• INVITE with SDP (Offer): Most common. The UAC sends an INVITE with its proposed media capabilities (an SDP "offer"). The UAS responds with a 200 OK containing its chosen capabilities (an SDP "answer"), following the SDP Offer/Answer model.
  • Example SDP offer in INVITE body:

        
v=0
        o=alice 2890844526 2890844526 IN IP4 192.0.2.4
        s=SIP Call
        c=IN IP4 192.0.2.4
        t=0 0
        m=audio 5004 RTP/AVP 0 8 101
        a=rtpmap:0 PCMU/8000
        a=rtpmap:8 PCMA/8000
        a=rtpmap:101 telephone-event/8000
        a=fmtp:101 0-16
        a=sendrecv

• INVITE without SDP: Less common. The INVITE is purely a setup sip request. The UAS might send an SDP offer in a provisional response (183 Session Progress) or 200 OK, and the UAC would respond with an ACK containing its SDP answer ("delayed offer").

Often, before a SIP INVITE can be successfully processed, the calling party needs to authenticate with the SIP server. This is handled through a challenge-response mechanism:

1. INVITE (unauthenticated): The UAC sends an initial SIP INVITE.
2. 401 Unauthorized or 407 Proxy Authentication Required: The SIP server (either a Registrar/Proxy or an Outbound Proxy) rejects the INVITE with one of these sip response codes. It includes a WWW-Authenticate (for 401) or Proxy-Authenticate (for 407) header, specifying the authentication scheme (e.g., Digest) and a nonce value.
   • SIP/2.0 401 Unauthorized
   • WWW-Authenticate: Digest realm="voicemail.example.com", nonce="dcd98b7102ddb493ad5ce556c071d3c2", qop="auth"
3. INVITE (authenticated): The UAC, having received the challenge, re-sends the original SIP INVITE but now includes an Authorization (for 401) or Proxy-Authorization (for 407) header. This header contains the username, password hash, nonce, and other parameters required to prove its identity.
4. Success: If authentication is successful, the server then processes the INVITE normally.

Let's visualize a simplified sip call flow for a successful call using a Mermaid sequence diagram.

sequenceDiagram
    participant UAC as Caller (UA Client)
    participant Proxy as SIP Proxy Server
    participant UAS as Callee (UA Server)

    UAC->>Proxy: F1 INVITE (SDP Offer)
    Proxy->>UAS: F2 INVITE (SDP Offer)
    UAS-->>UAC: F3 180 Ringing (via Proxy)
    UAS-->>UAC: F4 200 OK (SDP Answer, via Proxy)
    UAC->>UAS: F5 ACK (via Proxy)
    Note over UAC,UAS: Media (RTP) Flow

Several issues can derail a SIP INVITE initiated call:

• NAT Traversal: A widespread problem. UACs behind NATs have private IPs in Contact and SDP, making them unreachable externally. Solutions include STUN/TURN/ICE or SIP-aware proxies (SBCs). Misconfigured NAT often causes one-way or no audio.
• SDP Mismatch: If the SDP offer/answer disagree on codecs, media types, or transport, the call connects without media or with poor quality. Debug by checking INVITE and 200 OK for SDP payloads.
• Firewall Blocks: SIP (5060 UDP/TCP) and RTP media ports (e.g., 10000-20000 UDP) must be open bi-directionally. Firewalls can silently drop SIP INVITEs or media.
• Authentication Failures: Incorrect credentials or realm configs lead to 401 Unauthorized or 407 Proxy Authentication Required responses, preventing call setup. Logs clearly show these sip response codes.
• Registration Issues: If a callee's phone isn't registered, the INVITE can't locate the target, resulting in 404 Not Found.
• CSeq Issues: While less common in basic flows, incorrect CSeq handling in complex scenarios can cause transaction failures or messages to be ignored; CSeq values must increment.

To deepen your understanding of SIP, explore these related concepts:

• SIP Call Flow Explained: For a broader view of a complete call lifecycle, including termination, check out our detailed guide on /blog/sip-call-flow-explained.
• SDP Offer/Answer Model: Dive deeper into how media capabilities are negotiated between endpoints with our article on the /blog/sdp-offer-answer.
• SIP Response Codes: Understand the various signals SIP entities use to communicate status and errors by reviewing /blog/sip-response-codes.
• SIP Register: Learn how endpoints announce their availability to a SIP network through the REGISTER method.
• SIP REFER: Discover how calls can be transferred by one party telling another to establish a new call.