SIP Header Fields - NormB/sipnab GitHub Wiki
Every header field in the IANA registry, its compact form where one exists, and the RFC that defines it.
Source. https://www.iana.org/assignments/sip-parameters/sip-parameters-2.csv — the IANA Header Fields registry, retrieved 2026-07-30, 134 fields. The same arrangement as SIP request methods and SIP response codes: RFC 3261 defines 47 and later RFCs register the rest.
Compact forms
Nineteen fields have a single-letter alias. RFC 3261 section 7.3.3 makes them exactly
equivalent to the long form, so a parser that misses one misreads the message —
and an attacker who knows which ones a tool ignores can hide a header in plain
sight. COMPACT_HEADERS in src/sip/parser.rs carries
all nineteen, and compact_headers_match_the_iana_registry holds it to this
table.
| Compact | Header field | Defined in |
|---|---|---|
a |
Accept-Contact | RFC 3841 |
b |
Referred-By | RFC 3892 |
c |
Content-Type | RFC 3261 |
d |
Request-Disposition | RFC 3841 |
e |
Content-Encoding | RFC 3261 |
f |
From | RFC 3261 |
i |
Call-ID | RFC 3261 |
j |
Reject-Contact | RFC 3841 |
k |
Supported | RFC 3261 |
l |
Content-Length | RFC 3261 |
m |
Contact | RFC 3261 |
o |
Event | RFC 6665, RFC 6446 |
r |
Refer-To | RFC 3515 |
s |
Subject | RFC 3261 |
t |
To | RFC 3261 |
u |
Allow-Events | RFC 6665 |
v |
Via | RFC 3261, RFC 7118 |
x |
Session-Expires | RFC 4028 |
y |
Identity | RFC 8224 |
All header fields
The Description column quotes RFC 3261 section 20 for the fields it defines. A field registered by a later RFC carries its reference without a description, because no single section defines them all — follow the link.
| Header field | Compact | Defined in | Description |
|---|---|---|---|
| Accept | RFC 3261 section 20.1 | The Accept header field follows the syntax defined in [H14.1]. | |
| Accept-Contact | a |
RFC 3841 | |
| Accept-Encoding | RFC 3261 section 20.2 | The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are acceptable in the response. | |
| Accept-Language | RFC 3261 section 20.3 | The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. | |
| Accept-Resource-Priority | RFC 4412 | ||
| Additional-Identity | 3GPP TS 24.229 v16.7.0 | ||
| Alert-Info | RFC 3261 section 20.4 | When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. | |
| AlertMsg-Error | RFC 8876 | ||
| Allow | RFC 3261 section 20.5 | The Allow header field lists the set of methods supported by the UA generating the message. | |
| Allow-Events | u |
RFC 6665 | |
| Answer-Mode | RFC 5373 | ||
| Attestation-Info | 3GPP TS 24.229 v15.11.0 | ||
| Authentication-Info | RFC 3261 section 20.6 | The Authentication-Info header field provides for mutual authentication with HTTP Digest. | |
| Authorization | RFC 3261 section 20.7 | The Authorization header field contains authentication credentials of a UA. | |
| Call-ID | i |
RFC 3261 section 20.8 | The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. |
| Call-Info | RFC 3261 section 20.9 | The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. | |
| Cellular-Network-Info | 3GPP TS 24.229 v13.9.0 | ||
| Contact | m |
RFC 3261 section 20.10 | A Contact header field value provides a URI whose meaning depends on the type of request or response it is in. |
| Content-Disposition | RFC 3261 section 20.11 | The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. | |
| Content-Encoding | e |
RFC 3261 section 20.12 | The Content-Encoding header field is used as a modifier to the "media-type". |
| Content-ID | RFC 8262 | ||
| Content-Language | RFC 3261 section 20.13 | See [H14.12]. | |
| Content-Length | l |
RFC 3261 section 20.14 | The Content-Length header field indicates the size of the message- body, in decimal number of octets, sent to the recipient. |
| Content-Type | c |
RFC 3261 section 20.15 | The Content-Type header field indicates the media type of the message-body sent to the recipient. |
| CSeq | RFC 3261 section 20.16 | A CSeq header field in a request contains a single decimal sequence number and the request method. | |
| Date | RFC 3261 section 20.17 | The Date header field contains the date and time. | |
| DC-Info | 3GPP TS 24.229 v19.4.1 | ||
| Encryption (Deprecated) | RFC 3261 | ||
| Error-Info | RFC 3261 section 20.18 | The Error-Info header field provides a pointer to additional information about the error status response. | |
| Event | o |
RFC 6665, RFC 6446 | |
| Expires | RFC 3261 section 20.19 | The Expires header field gives the relative time after which the message (or content) expires. | |
| Feature-Caps | RFC 6809 | ||
| Flow-Timer | RFC 5626 | ||
| From | f |
RFC 3261 section 20.20 | The From header field indicates the initiator of the request. |
| Geolocation | RFC 6442 | ||
| Geolocation-Error | RFC 6442 | ||
| Geolocation-Routing | RFC 6442 | ||
| Hide (Deprecated) | RFC 3261 | ||
| History-Info | RFC 7044 | ||
| Identity | y |
RFC 8224 | |
| Identity-Info (deprecated by [RFC8224]) | RFC 8224 | ||
| In-Reply-To | RFC 3261 section 20.21 | The In-Reply-To header field enumerates the Call-IDs that this call references or returns. | |
| Info-Package | RFC 6086 | ||
| Join | RFC 3911 | ||
| Max-Breadth | RFC 5393 | ||
| Max-Forwards | RFC 3261 section 20.22 | The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. | |
| MIME-Version | RFC 3261 section 20.24 | See [H19.4.1]. | |
| Min-Expires | RFC 3261 section 20.23 | The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. | |
| Min-SE | RFC 4028 | ||
| Organization | RFC 3261 section 20.25 | The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs. | |
| Origination-Id | 3GPP TS 24.229 v15.11.0 | ||
| P-Access-Network-Info | RFC 7315 | ||
| P-Answer-State | RFC 4964 | ||
| P-Asserted-Identity | RFC 3325 | ||
| P-Asserted-Service | RFC 6050 | ||
| P-Associated-URI | RFC 7315 | ||
| P-Called-Party-ID | RFC 7315 | ||
| P-Charge-Info | RFC 8496 | ||
| P-Charging-Function-Addresses | RFC 7315 | ||
| P-Charging-Vector | RFC 7315 | ||
| P-DCS-Billing-Info | RFC 5503 | ||
| P-DCS-LAES | RFC 5503 | ||
| P-DCS-OSPS | RFC 5503 | ||
| P-DCS-Redirect | RFC 5503 | ||
| P-DCS-Trace-Party-ID | RFC 5503 | ||
| P-Early-Media | RFC 5009 | ||
| P-Media-Authorization | RFC 3313 | ||
| P-Preferred-Identity | RFC 3325 | ||
| P-Preferred-Service | RFC 6050 | ||
| P-Private-Network-Indication | RFC 7316 | ||
| P-Profile-Key | RFC 5002 | ||
| P-Refused-URI-List | RFC 5318 | ||
| P-Served-User | RFC 5502, RFC 8498 | ||
| P-User-Database | RFC 4457 | ||
| P-Visited-Network-ID | RFC 7315 | ||
| Path | RFC 3327 | ||
| Permission-Missing | RFC 5360 | ||
| Policy-Contact | RFC 6794 | ||
| Policy-ID | RFC 6794 | ||
| Priority | RFC 3261 section 20.26 | The Priority header field indicates the urgency of the request as perceived by the client. | |
| Priority-Share | 3GPP TS 24.229 v13.16.0 | ||
| Priority-Verstat | 3GPP TS 24.229 | ||
| Priv-Answer-Mode | RFC 5373 | ||
| Privacy | RFC 3323 | ||
| Proxy-Authenticate | RFC 3261 section 20.27 | A Proxy-Authenticate header field value contains an authentication challenge. | |
| Proxy-Authorization | RFC 3261 section 20.28 | The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. | |
| Proxy-Require | RFC 3261 section 20.29 | The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. | |
| RAck | RFC 3262 | ||
| Reason | RFC 3326 | ||
| Reason-Phrase | RFC 6873 | ||
| Record-Route | RFC 3261 section 20.30 | The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy. | |
| Recv-Info | RFC 6086 | ||
| Refer-Events-At | RFC 7614 | ||
| Refer-Sub | RFC 4488 | ||
| Refer-To | r |
RFC 3515 | |
| Referred-By | b |
RFC 3892 | |
| Reject-Contact | j |
RFC 3841 | |
| Relayed-Charge | 3GPP TS 24.229 v12.14.0 | ||
| Replaces | RFC 3891 | ||
| Reply-To | RFC 3261 section 20.31 | The Reply-To header field contains a logical return URI that may be different from the From header field. | |
| Request-Disposition | d |
RFC 3841 | |
| Require | RFC 3261 section 20.32 | The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. | |
| Resource-Priority | RFC 4412 | ||
| Resource-Share | 3GPP TS 24.229 v13.7.0 | ||
| Response-Key (Deprecated) | RFC 3261 | ||
| Response-Source | 3GPP TS 24.229 v15.11.0 | ||
| Restoration-Info | 3GPP TS 24.229 v12.14.0 | ||
| Retry-After | RFC 3261 section 20.33 | The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with | |
| Route | RFC 3261 section 20.34 | The Route header field is used to force routing for a request through the listed set of proxies. | |
| RSeq | RFC 3262 | ||
| Security-Client | RFC 3329 | ||
| Security-Server | RFC 3329 | ||
| Security-Verify | RFC 3329 | ||
| Server | RFC 3261 section 20.35 | The Server header field contains information about the software used by the UAS to handle the request. | |
| Service-Interact-Info | 3GPP TS 24.229 v13.18.0 | ||
| Service-Route | RFC 3608 | ||
| Session-Expires | x |
RFC 4028 | |
| Session-ID | RFC 7989 | ||
| SIP-ETag | RFC 3903 | ||
| SIP-If-Match | RFC 3903 | ||
| Subject | s |
RFC 3261 section 20.36 | The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. |
| Subscription-State | RFC 6665 | ||
| Supported | k |
RFC 3261 section 20.37 | The Supported header field enumerates all the extensions supported by the UAC or UAS. |
| Suppress-If-Match | RFC 5839 | ||
| Target-Dialog | RFC 4538 | ||
| Timestamp | RFC 3261 section 20.38 | The Timestamp header field describes when the UAC sent the request to the UAS. | |
| To | t |
RFC 3261 section 20.39 | The To header field specifies the logical recipient of the request. |
| Trigger-Consent | RFC 5360 | ||
| Unsupported | RFC 3261 section 20.40 | The Unsupported header field lists the features not supported by the UAS. | |
| User-Agent | RFC 3261 section 20.41 | The User-Agent header field contains information about the UAC originating the request. | |
| User-to-User | RFC 7433 | ||
| Via | v |
RFC 3261 section 20.42 | The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. |
| Warning | RFC 3261 section 20.43 | The Warning header field is used to carry additional information about the status of a response. | |
| WWW-Authenticate | RFC 3261 section 20.44 | A WWW-Authenticate header field value contains an authentication challenge. |