Understanding SIP Headers: A Complete Reference
SIP headers carry every piece of metadata a voice or video session needs. Where the call came from, where it should go, what codecs are on offer, who claims to be calling, whether the trunk has been authenticated, how long the session is good for. The signaling protocol delivers all of this as a stack of named fields inside each SIP message, and the value in each field controls a specific behaviour at the next hop. Reading and reasoning about those fields is the difference between a working interconnect and a trace-watching afternoon.
This page is the field-by-field reference. It groups the headers you will encounter into practical categories, shows the syntax of each one, and explains what it actually does on the wire. If you want the conceptual overview of how SIP works at the protocol level, the companion piece SIP Signaling Fundamentals covers roles and architecture; SIP Call Flow Explained Step by Step walks every message in a typical call in order. This page is what you reach for when you already know the flow and need to know the fields.
Field-Name: field-value. Each header carries a discrete piece of routing, identity, content, or capability information.sip:user@domain or sips:user@domain (TLS-secured). Most addressing headers carry a SIP URI in angle brackets, often with parameters.f for From, t for To, v for Via).The Anatomy of a SIP Message
Every SIP message has three parts: a start line, a block of header fields, and an optional body separated from the headers by a single blank line. The start line is either a request line (for example, INVITE sip:bob@provider.com SIP/2.0) or a status line (for example, SIP/2.0 200 OK). The header block is a sequence of Field-Name: field-value lines, one per logical header. The body, when present, is described by the content headers (most commonly SDP for media negotiation).
A few mechanical rules apply across the entire header block. Field names are case-insensitive: From, FROM, and from are the same header. Many headers also have a compact single-letter form for use over space-constrained transports; f equals From, t equals To, v equals Via, m equals Contact, i equals Call-ID, l equals Content-Length, and c equals Content-Type. Header values may extend across lines by starting the continuation with whitespace, and multiple values for the same header can be sent as one header with a comma-separated value or as several separate headers with the same name.
The order of headers does not generally affect protocol behaviour. The order of parameters within a single header value sometimes does, particularly in Via, Route, and Record-Route. Many endpoints and intermediaries assume a typical header ordering when parsing, so a defensive implementation tolerates any order but produces a familiar one.
Dialog and Addressing Headers
These headers identify who is involved in the call, identify the dialog itself, and tell each party where to send further messages.
From identifies the logical originator of the request. The value is a display name plus a SIP URI in angle brackets, with a mandatory tag parameter that uniquely identifies this end of the dialog: From: "Alice" . The From-tag stays constant for every request and response in the dialog. Note that From is not necessarily the actual caller; in many enterprise and carrier topologies it is rewritten or asserted separately through P-Asserted-Identity (covered below).
To names the logical recipient of the request and follows the same syntax as From: To: "Bob" . The originating side sends the request with no tag; the recipient appends a To-tag on the first non-100 response and from that point the To-tag is part of the dialog identifier. The Request-URI on the start line can differ from the To URI as the request is routed.
Call-ID is a globally unique string that identifies a single SIP dialog across every message it produces: Call-ID: a84b4c76e66710@192.0.2.10. It is generated by the originating endpoint and never changes for the life of the dialog. A B2BUA produces two separate Call-IDs, one per leg, because it operates two independent dialogs.
Contact tells the other side where to send future in-dialog requests for this session: Contact: . The value is normally the actual transport address of the endpoint, not a domain name, because routing must reach a specific instance after the initial setup. SBCs frequently rewrite Contact during topology hiding, replacing the internal address with the SBC’s own public address.
Reply-To indicates an alternative address that should be used for any reply that the caller wants directed somewhere other than the From URI. It is rare in practice and largely advisory.
Routing Headers
Routing headers tell the network where the request has been and where it should go next, so the response can find its way back through the same path.
Via records each hop a request has traversed. Every proxy adds a Via header before forwarding the request. A B2BUA generates a new request with its own independent Via chain on the outbound leg. Responses traverse the Vias in reverse order to reach the originator. A typical Via looks like Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK776asdhds. The branch parameter is the transaction identifier; values that start with z9hG4bK are RFC 3261-compliant. Multiple Via headers appear stacked when several intermediaries are in the path.
Max-Forwards caps how many hops a request may take before being rejected: Max-Forwards: 70. Each proxy decrements the value by one and discards the request when it reaches zero, returning 483 Too Many Hops.
Route carries an explicit list of intermediaries a request must transit. The originating endpoint writes a Route header for each hop it has been told to use, and each hop pops its own entry off the top before forwarding. This is how loose routing works in practice and how SBCs steer traffic that would otherwise be free to pick its own path.
Record-Route works in the opposite direction: a proxy or B2BUA that wants subsequent in-dialog requests to traverse the same path inserts itself into Record-Route on the initial request. Each endpoint then copies the Record-Route list into Route headers on subsequent requests, anchoring the dialog to that path. Record-Route is essential for any intermediary that needs to remain in the signaling for accounting, media anchoring, or policy enforcement after the call is established.
Transaction and Sequencing Headers
SIP overlays a transaction model on top of unreliable transports, and a small set of headers and parameters keep requests and responses correctly matched.
CSeq carries a sequence number plus a method name: CSeq: 314159 INVITE. The number increments by one for each new request the originator sends within the dialog, and the method matches the request being sent (or the original request, in the case of ACK, which keeps the INVITE’s CSeq number but changes the method). CSeq is how a responding endpoint matches a 200 OK to the right INVITE when several are in flight, and how it knows that a re-INVITE is a new request rather than a retransmission of an old one.
The tag parameter on From and To uniquely identifies one end of a dialog. The From-tag is generated by the originator at INVITE time; the To-tag is generated by the recipient on the first non-100 response. The two tags plus the Call-ID together form the dialog identifier; any request bearing these three values is treated as in-dialog.
The branch parameter on Via identifies a single transaction. Each request gets a fresh branch value, and the corresponding response copies the branch back so the originator can match it.
Content Headers
When a SIP message carries a body, the content headers describe it. The body itself is most often SDP for media negotiation, but SIP can carry any MIME type, including text/plain, application/pidf+xml for presence, multipart/mixed for several bodies in one message, and image/jpeg or message/sipfrag for less common uses.
Content-Type declares the MIME type of the body: Content-Type: application/sdp. For multipart bodies, the type also names a boundary parameter that separates the parts.
Content-Length gives the size of the body in octets: Content-Length: 142. A wrong Content-Length over a stream transport breaks message framing.
Content-Disposition tells the recipient how to handle the body. Values like session (the body describes the session, the default for SDP), render (display this to the user), and signal (a body that affects signaling, such as a referred-to URI) help endpoints route multipart contents to the right subsystem.
Content-Encoding describes any encoding (compression, typically gzip) applied to the body. The recipient reverses the encoding before parsing.
Accept advertises which body types the sender will accept on a response. Accept-Encoding and Accept-Language serve the corresponding negotiation roles. These headers matter most for capability discovery via OPTIONS.
Capability Headers
Capability headers let each side describe what it can do and what it requires the other side to do. They are how SIP extensions remain backwards-compatible.
Allow lists the SIP methods the sender supports: Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, NOTIFY, UPDATE. Published on OPTIONS responses, 405 responses, and the 200 OK that establishes a dialog.
Supported advertises optional SIP extensions the sender understands, by name (timer, 100rel, path, replaces). Informational only.
Require takes the next step and demands that the recipient understand a named extension. If the recipient does not, it responds with 420 Bad Extension and lists the unrecognized options in Unsupported.
Unsupported appears only in 420 responses and lists the extensions named in Require that the recipient cannot honour.
User-Agent identifies the originating software or device. Server performs the same role on responses. Both are advisory.
Caller Identity and Privacy Headers
Identity in SIP is layered. The From header is what the caller says; the headers in this section are what intermediaries assert about the caller, who is allowed to see it, and what historical handling has happened along the way. These fields drive caller ID display, carrier interconnect behaviour, and STIR/SHAKEN attestation, and they are the most common targets of SIP header manipulation at the SBC edge.
P-Asserted-Identity (PAI) conveys the calling party identity as asserted by a trusted intermediary, typically the originating carrier: P-Asserted-Identity: . Many receiving PBXs read caller ID from PAI rather than From when both are present.
P-Preferred-Identity (PPI) is the request side of the same relationship. An endpoint that holds several valid identities sends PPI to indicate which one it wants the network to assert.
Privacy requests withholding of identity information. Common values are id (strip PAI from messages that leave the trust domain), header (strip headers that reveal user identity), and none.
Diversion records that the call was redirected, naming the original destination and the reason: Diversion: .
History-Info serves the same purpose as Diversion but is the standards-track replacement, with structured handling of multi-step redirection chains. Both coexist in production networks today.
Remote-Party-ID predates PAI and carried both identity and privacy information in a single header. It is still encountered in legacy deployments; modern interconnects expect PAI plus Privacy.
Authentication Headers
SIP authentication uses HTTP Digest, with one pair of headers for endpoint challenges and a parallel pair for proxy challenges.
WWW-Authenticate appears on a 401 Unauthorized response and challenges the requester to authenticate. Carries a realm, nonce, and algorithm.
Authorization carries the response on the retried request. The endpoint computes a digest hash from the nonce, the request URI, the method, and its shared secret.
Proxy-Authenticate and Proxy-Authorization work identically but are used when a SIP proxy issues the challenge with 407 Proxy Authentication Required.
Session Timer, Subscription, and Notification Headers
These headers govern how long a session or subscription is valid and what each side does as expiry approaches.
Session-Expires sets the maximum lifetime of an established session: Session-Expires: 1800;refresher=uac. The refresher parameter says which side will send the refresh.
Min-SE states the minimum acceptable session interval. A recipient receiving Session-Expires lower than its own Min-SE rejects with 422 Session Interval Too Small.
Expires appears on REGISTER, SUBSCRIBE, and occasionally on INVITE. Values are integers in seconds.
Event names the event package on SUBSCRIBE and NOTIFY (presence, message-summary, refer).
Subscription-State rides on every NOTIFY and describes the state of the subscription: active, pending, or terminated with a reason.
Transfer and Reference Headers
Call transfer in SIP is implemented through the REFER method, which uses a small set of headers to name the target and report progress.
Refer-To names the target of a transfer on a REFER request: Refer-To: . For attended transfer, the URI carries a Replaces parameter.
Referred-By records the party that initiated the transfer.
Replaces is carried as a parameter inside Refer-To or as its own header on an INVITE, telling the recipient to replace an existing dialog with the new one.
Reason carries a status reason on BYE or CANCEL, typically a Q.850 cause code or a SIP status, explaining why the dialog is ending.
The Identity Header (STIR/SHAKEN)
Identity is the header that carries the signed PASSporT in STIR/SHAKEN call authentication. The value is a signed PASSporT object serialized as a JSON Web Signature (JWS) plus parameters naming the certificate URL and the attestation level the originating provider claims: Identity: eyJhbGciOi....
The Identity header is large by SIP standards (often 1–2 KB) and is one of the main reasons modern interconnects need transports that handle SIP messages above the typical UDP fragmentation limit. TCP or TLS is preferred for any trunk that signs or verifies.
Custom, Vendor, and P-Headers
SIP allows any party to introduce its own headers, and in practice nearly every vendor does. Two naming conventions cover the bulk of these extensions.
P-headers use the P- prefix and are intended for use within a private network or between cooperating networks under explicit agreement. Several are standards-track (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector, P-Access-Network-Info).
X-headers carry the X- prefix and signal a vendor or application extension that is not standardized. Any system that does not understand a given X-header simply ignores it.
The practical rule for both categories is that custom headers should be stripped before a call leaves the controlled environment.
How SBCs Treat SIP Headers
A Session Border Controller in B2BUA mode operates two SIP dialogs glued together by internal routing logic, which means the headers on the inbound leg are not the same headers on the outbound leg. Each leg has its own Call-ID, its own Via chain, its own Contact, and its own CSeq counter. The SBC reconstructs every header on the outbound leg from policy: what the upstream system needs to see, regardless of what arrived on the inbound side.
This is the foundation of SIP normalization. A carrier that delivers caller identity in P-Asserted-Identity can be peered with a PBX that reads From; the SBC reads PAI on the inbound leg and rewrites From on the outbound leg. The full landscape of these treatments is covered in SIP Header Manipulation with an SBC.
Frequently Asked Questions
Are SIP header field names case-sensitive?
No. Field names are case-insensitive, so From, FROM, and from all refer to the same header. Field values, however, may be case-sensitive depending on the specific header (for example, scheme names like sip: are case-insensitive, but the user portion of a URI typically is not).
When should I use the compact form of header names?
Compact forms (f for From, t for To, v for Via, and others) exist to reduce message size over UDP, where staying under the MTU avoids fragmentation. Modern deployments using TCP or TLS rarely need them, and the long form is more readable in traces. Either is correct and accepted everywhere; just do not mix forms unnecessarily on the same message.
Why do some SIP traces show multiple Via headers stacked together?
Each SIP proxy prepends a Via header before forwarding the request. B2BUAs generate their own Via chains on outbound requests.
What is the difference between a P-header and an X-header?
P-headers are intended for private use between cooperating networks under explicit agreement, and several of them (P-Asserted-Identity, P-Preferred-Identity, P-Charging-Vector) are standardized. X-headers are vendor or application extensions with no standardized meaning; any system that does not understand them ignores them. The practical guidance is the same for both: strip them at the trust boundary unless the next domain has agreed to consume them.
If a header is required by an extension my system does not understand, what happens?
A Require header naming an extension the recipient does not support triggers a 420 Bad Extension response, with the unsupported options listed in an Unsupported header. The originator can then retry without the offending extension, or fall back to a different path. Supported, by contrast, is advisory and never causes a failure.
Conclusion
SIP headers are the metadata layer that makes everything else in voice signaling work. Routing, identity, capability negotiation, authentication, session lifecycle, transfer, and STIR/SHAKEN all live as named fields inside messages whose structure is otherwise simple. Fluency with these fields is what turns a SIP trace from an unreadable wall of text into a sequence of decisions you can follow and reason about, and it is the foundation of every interop fix, every normalization rule, and every carrier integration.
The conceptual mechanics are in SIP Signaling Fundamentals; the per-message walkthrough is in SIP Call Flow Explained Step by Step; and the rules-based engine that rewrites headers in production lives in SIP Header Manipulation with an SBC.
How ProSBC Handles Every Header in the Reference
ProSBC is a true B2BUA, which means every header on the page above is something it constructs from scratch on the outbound leg of every call. Inbound From, To, Contact, PAI, Diversion, and History-Info can be parsed, rewritten, swapped, or stripped by per-NAP rules. The same engine drives STIR/SHAKEN signing and verification on the Identity header, topology hiding on Via and Record-Route, and Authorization handling on Digest challenges.
For carrier interconnects, Microsoft Teams Direct Routing, and any multi-vendor environment where two endpoints speak slightly different dialects of SIP, this header-level control is what turns “almost interoperable” into “production.” ProSBC supports up to 1,024 trunk groups per server with independent header rules on each.
Prefer to evaluate on your own first? Start your 30-day free trial.