SIP INVITE Message: Structure and Headers

Every SIP call begins with an INVITE. It is the request a calling user agent sends to start a session, and it is also the message engineers spend the most time reading when something goes wrong. An INVITE carries the calling and called identities, the routing trail the call has taken so far, the codecs and transport parameters the caller is offering, and a long list of optional fields that influence everything from caller ID display to STIR/SHAKEN attestation.

This article is a structural reference for the INVITE itself. It walks through the three sections of the message, every mandatory header an INVITE must carry, the SDP body, and the optional headers that show up most often in production traces. For a broader overview of how SIP works as a protocol, see SIP signaling fundamentals.

The Three Sections of an INVITE

RFC 3261 defines a SIP message as three parts separated by carriage-return/line-feed sequences: a start line, a set of header fields, and an optional body. The start line of an INVITE is the request line. The headers carry routing, identity, and capability information. The body, if present, carries the SDP offer that describes the media the caller wants to negotiate.

The blank line between the last header and the body is structural. It is how a parser knows the headers have ended. A missing CRLF here is one of the more common reasons a malformed INVITE gets rejected by a strict SIP stack before it even reaches the routing logic.

The Request Line

The request line is a single line in the form METHOD Request-URI SIP-Version. For an INVITE it always begins with the literal word INVITE, followed by the Request-URI, followed by SIP/2.0.

The method tells the receiving stack what to do. INVITE means “establish a session.” Other methods that share most of the same header structure include ACK, BYE, CANCEL, OPTIONS, REGISTER, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE, and PRACK. INVITE is the most common SIP method that creates a dialog. Other methods such as SUBSCRIBE can also establish dialogs depending on the extension in use.

The Request-URI indicates where the request is currently being sent. This is not necessarily the original destination. As the INVITE travels through proxies and SBCs, the Request-URI can be rewritten so the next hop knows where to forward. The To header represents the logical destination identity of the call and is normally preserved across transit, even when the Request-URI is rewritten for routing purposes. Confusing the Request-URI with the To header is one of the more common mistakes when reading a trace; the Request-URI answers “where is this going right now,” while the To header answers “who was this originally meant for.”

The SIP version has been SIP/2.0 since RFC 3261 was published in 2002. There is no SIP/3.0 in production.

The Mandatory Headers

RFC 3261 requires six headers on every SIP request: Via, Max-Forwards, To, From, Call-ID, and CSeq. INVITE requests almost always include Contact, because it provides the target for subsequent in-dialog requests such as BYE and re-INVITE. When the message carries a body, Content-Type and Content-Length become mandatory as well.

Via

The Via header records the network path the request has traveled. Every hop that forwards an INVITE adds a new Via at the top. Responses follow the Via chain in reverse order to return toward the sender. The branch parameter inside each Via uniquely identifies that transaction at that hop. RFC 3261 mandates that branch values begin with the magic cookie z9hG4bK.

Example: Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9

Max-Forwards

A hop counter that prevents routing loops. Set to 70 by default; decremented at each hop; rejected with 483 Too Many Hops when it reaches zero.

To

The logical destination of the call, expressed as a URI. Not changed in transit. The answering UAS adds a To-tag in the 200 OK response, and that tag binds the dialog together on the callee’s side.

From

The caller’s claimed identity. Always carries a tag set by the calling UA. The From URI is what the caller claims to be, which is not the same as what an upstream provider has authenticated (that is P-Asserted-Identity).

Call-ID

A globally unique identifier for the entire dialog. Every request and response within the dialog carries the same Call-ID.

CSeq

Command Sequence: a number followed by a method name (e.g. CSeq: 314159 INVITE). Increments per new request within a dialog; reused for retransmissions.

Contact

Direct routing target for in-dialog requests such as BYE and re-INVITE, typically used together with any Route set established by Record-Route. Almost always contains the actual IP and port of the endpoint, which is why topology hiding at an SBC almost always involves rewriting Contact.

Content-Type and Content-Length

When the INVITE carries a body, both are mandatory. Content-Type is almost always application/sdp; Content-Length is the body size in bytes.

A Complete INVITE in Practice

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 198.51.100.10:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
To: "Bob" 
From: "Alice" ;tag=1928301774
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@atlanta.com
CSeq: 314159 INVITE
Contact: 
P-Asserted-Identity: 
Identity: eyJhbGciOiJFUzI1NiI...JSON-WEB-SIGNATURE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 156

v=0
o=alice 2890844526 2890844526 IN IP4 198.51.100.10
s=SIP Call
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000

The request line is on the first row, the mandatory and optional headers follow, the blank line marks the end of the header block, and the SDP offer fills the body. Values are illustrative; real-world INVITEs vary in field order and the exact set of optional headers, but every conforming INVITE carries the same mandatory fields and the same three-section structure.

The SDP Body

The body is almost always a Session Description Protocol (SDP) offer (RFC 8866, which obsoleted RFC 4566 in 2021). Key lines:

• v= protocol version (always 0)
• o= origin: session ID + originator address
• s= session name
• c= connection: IP where the originator expects to receive media
• t= time (almost always 0 0 for real-time SIP)
• m= media line: type, port, transport, payload-type list
• a= attributes: rtpmap, fmtp, sendrecv/sendonly/recvonly/inactive, crypto (SDES), fingerprint (DTLS-SRTP)

SDP follows the offer/answer model (RFC 3264). The INVITE carries the offer; the 200 OK carries the answer. A deployment using SRTP with SDES keying must protect the signaling path with TLS, otherwise the master keys cross the network in clear text inside the a=crypto line.

Optional Headers That Matter in Production

Allow, Supported, and Require

Allow enumerates the SIP methods the UA can handle. Supported lists extensions the UA understands. Require lists extensions the UA insists the other side support (e.g. timer, 100rel, replaces, gruu).

Route and Record-Route

Route is a preset list of hops the caller wants the request to traverse. Record-Route is set by intermediaries that want to stay in the signaling path for subsequent in-dialog requests.

P-Asserted-Identity and P-Preferred-Identity

PAI (RFC 3325) is the carrier-asserted caller identity. PPI is what the UA would like the network to assert. Carriers normalize PAI between formats when interconnecting with downstream providers.

Privacy

RFC 3323 signals what the caller wants concealed. Values: id, header, session, none.

Diversion and History-Info

Carry the redirection history when a call has been forwarded. Two competing standards: Diversion (older, informational) and History-Info (RFC 4244). Vendors prefer different formats.

Identity (STIR/SHAKEN)

RFC 8224 carries the STIR/SHAKEN PASSporT: a signed JWS binding the caller’s number to a cryptographic identity.

Session-Expires and Min-SE

RFC 4028 refresh interval for the SIP dialog; prevents half-closed ghost sessions.

User-Agent

Identifies the software making the call. Informational, useful for trace correlation, minor fingerprinting risk.

From INVITE to Dialog

An INVITE that reaches the destination triggers a sequence of responses: 100 Trying immediately, then one or more 18x provisional responses (180 Ringing, 183 Session Progress), then 200 OK with the To-tag set when the callee answers. The caller acknowledges with ACK, and the dialog is fully confirmed.

Re-INVITEs within an existing dialog reuse the same Call-ID, To-tag, and From-tag with a higher CSeq, modifying the session (codec change, hold, transfer). The provisional, success, and failure response codes that complete the INVITE transaction follow the same 1xx through 6xx pattern used everywhere else in SIP.

Where SBCs Touch the INVITE

A B2BUA Session Border Controller terminates the inbound INVITE and constructs a fresh outbound INVITE on the other leg. Every header on the outbound message is built from scratch, which means an SBC can strip proprietary fields, rewrite identity headers, normalize Diversion to History-Info (or vice versa), inject the STIR/SHAKEN Identity header from an external signing service, and rewrite Contact and Via to hide the originator’s internal topology. The mechanics of those rewrites are covered in SIP header manipulation; the architectural reason a proxy cannot do the same thing is covered in SIP proxy vs SBC.

Frequently Asked Questions

Why does an INVITE have both From and P-Asserted-Identity?

The From header carries the identity the caller claims. PAI carries the identity the upstream provider is willing to vouch for after authenticating the user.

What is the difference between the Request-URI and the To header?

The Request-URI is the address the request is currently aimed at (changes as proxies/SBCs forward it). The To header is the original logical destination (does not change in transit).

Can an INVITE have no body?

Yes. A “delayed offer” INVITE has no SDP. The callee responds with its SDP offer in the 200 OK; the caller’s ACK carries the answer. Uncommon in modern carrier deployments but still seen with some legacy click-to-call scenarios.

Why is Max-Forwards initialized to 70?

RFC 3261 convention. High enough to traverse any realistic SIP path, low enough that loops are detected and broken quickly.

What is the branch parameter in the Via header for?

Identifies a single SIP transaction at a single hop. Each hop inserts a fresh branch when it forwards. Compliant SIP/2.0 branches must begin with z9hG4bK.