Protocol scope and method
SIP Content-Length counts body octets, not JavaScript characters. Line endings before the body are not part of the body length.
actualLength = UTF-8 byte length after the first blank line.
Diagnostic scenario
Use the complete redacted SIP message with its original body and line boundary. Compare the declared Content-Length with UTF-8 body octets after the first empty line, then repeat after any XML or SDP edit before sending the test message.
How to interpret the result
Content-Length counts octets rather than JavaScript characters or displayed glyphs. Multibyte text, a changed newline and an editor-added byte-order mark can make character counts look right while the wire length is wrong.
Input reference
- Complete SIP message
- Example default: Sample input included
Common mistakes
- Using an unredacted production capture with vehicle, credential or network identifiers.
- Counting Unicode characters instead of encoded body bytes.
- Treating a successfully parsed sample as standards compliance or interoperability proof.
Before using the result
- Confirm the protocol edition, transport framing and vendor profile before interpreting fields.
- Preserve encoding and recalculate after every body modification.
- Keep a redacted known-good and known-bad sample as a regression pair.
Questions to check during diagnosis
Does the SIP Content-Length Checker leave my browser?
No application upload is used. Avoid putting sensitive production data in shareable URLs.
Is this a standards compliance test?
No. Confirm the edition and vendor profile with licensed documents and your target platform.
Offline diagnostic aid. Verify fields, version and vendor extensions before production use.