SIP Header Checker
Validate SIP message headers for malformed Via values, missing branch cookies, Contact hints, Content-Length mismatches, and SDP issues.
AK
appkiro.comPaste your SIP message (request or response) below.
Valid Headers
9
Warnings
2
Errors
0
Total Headers
11
Detailed analysis for the selected header
Analysis
Without transport=udp/tcp/tls downstream proxies may pick the wrong transport.
Recommended format: <sip:user@host:port;transport=udp>
Best Practice
Specify the transport parameter (udp/tcp/tls) in Contact header for better compatibility.
RFC Reference
RFC 3261 §20.10.2 - Contact
SIP Header Checker reads a single SIP message — request or response — and walks every header against the rules in RFC 3261 plus the common interoperability checks teams accumulate in production. The page is a static client component, so the message you paste never leaves the tab.
Start line, Via with branch cookie and known transport, Max-Forwards range, From and To with URI and tag, Call-ID format, CSeq pairing, Contact with transport hint, Content-Type and Content-Length consistency, plus a minimal SDP body sweep when the body is application/sdp.
Errors are RFC violations that will break interop with most stacks. Warnings are common pitfalls — missing transport on Contact, mismatched Content-Length, branch parameter without the magic cookie — that cause silent failures or strange routing.
Pick any row in the results table or use the dropdown to focus the bottom panel on a single header. The panel echoes the raw value, the line number, and the status, plus an Analysis / Best Practice / RFC Reference for context.
The capture is parsed inside the page; nothing is uploaded. Closing the tab discards every byte. Use this tool freely with messages from production logs.
Any plain-text SIP request or response in canonical RFC 3261 form. The first line must be either a request line (e.g. INVITE sip:[email protected] SIP/2.0) or a status line (SIP/2.0 200 OK). Headers follow until the blank line; the optional body comes after.
No. Parsing, syntax checks, content-length comparison, and SDP validation all run inside this tab. Closing the tab discards every byte — there is no copy on a server.
Errors are RFC 3261 violations that will trip up most SIP stacks: missing Via, malformed CSeq, request lines without SIP/2.0. Warnings are interoperability issues that work today but cause friction with strict implementations — for example, a Contact header without an explicit transport parameter.
The checker counts the bytes after the blank line that separates headers from body and compares with the header value. A mismatch is flagged because the receiving stack will most likely truncate the body or reject the message.
When the Content-Type is application/sdp the body is parsed line by line. The checker confirms the mandatory v=, o=, s=, c=, t=, and m= lines are present, then surfaces a warning when one is missing or when an unknown attribute appears.
Without an explicit transport=udp/tcp/tls parameter, downstream proxies may pick the wrong transport. Adding the parameter makes the URI unambiguous and prevents quiet failures with strict registrars.