Anatomy of a SIP message

4.1 Four parts: start line, headers, empty line, body

SIP is a text protocol. A SIP message looks like an email or an HTTP message, and you can read it in any packet capture. Requests and responses have the same structure:

Explore one message. Point at a line — or at one part of the start line — to see what it means. Turn on Show line endings to see the two invisible bytes at the end of every line, and turn off Separate the layers to see the message as it travels.

The request line

The first line of a request has exactly three parts, separated by single spaces:

INVITE sip:bob@203.0.113.20:5060 SIP/2.0
└─┬──┘ └──────────┬────────────┘ └──┬──┘
method       Request-URI         version

The Request-URI is the current target. A proxy replaces it as it routes the request (Module 3), so the same INVITE has a different Request-URI on each hop. It is a bare URI — never in angle brackets:

The status line

The first line of a response also has three parts:

SIP/2.0 180 Ringing
└──┬──┘ └┬┘ └──┬──┘
version code  reason phrase

The three-digit status code carries the meaning. The reason phrase is only for people: a phone that sends 180 Ringing, please wait or 180 Sonnerie sends the same response. Module 6 covers the codes.

4.2 Headers

Each header row is a name, a colon, and a value:

Max-Forwards: 70

Spaces around the colon are allowed, but the usual form is no space before the colon and one space after it. RFC 3261 also allows a long header to continue on the next line, if that line starts with a space or a tab — but some parsers handle this badly, so senders avoid it.

Six headers in every request

An INVITE also needs a Contact: the address where the other side sends its next requests. Responses copy Via, From, To, Call-ID, and CSeq from the request.

Order and repeated headers

The order of headers with different names does not matter. The order of rows with the same name does: the top Via is the most recent hop.

When a header can hold a comma-separated list, several rows can become one row, and one row can become several. These two forms are the same message:

Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bKpb721e
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK74bf9

Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bKpb721e, SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK74bf9

The four authentication headers are the exception. Their values contain commas of their own, so they always stay on separate rows:

In the message above, select INVITE and turn on Combine repeated headers: the two Via rows become one, and the byte count changes. The meaning does not.

4.3 Compact forms

The most common headers have a one-letter name. A message may mix long and short names freely, and every receiver must accept both.

Compact forms save bytes. That matters over UDP, where a message larger than about 1300 bytes should move to TCP (Module 2). Turn on Compact form in the message above to see how much it saves.

4.4 The empty line and the body

Every line ends with two bytes: CR (carriage return, 0x0D) and LF (line feed, 0x0A). The headers end with an empty line: a CR LF on its own. That empty line is always there — even when the message has no body.

Select REGISTER in the message above: it has no body, but it still ends with the empty line, and its Content-Length is 0.

Everything after the empty line is the body. Its type is in Content-Type:

4.5 Content-Length, framing, and multipart bodies

Content-Length is the size of the body in bytes. It does not count the start line, the headers, or the empty line.

Its real job is framing: telling the receiver where a message ends.

• Over UDP, each datagram carries exactly one message. If Content-Length disagrees with the datagram, the receiver discards extra bytes, or rejects a message that is too short.
• Over TCP (and TLS), messages follow each other in one byte stream, with nothing between them. The receiver finds the empty line, then counts Content-Length bytes — and the next byte must be the start of the next message.

Break the INVITE and watch the receiver. Over TCP, one wrong number destroys every message after it on the connection.

Multipart bodies

A message can carry several bodies at once with multipart/mixed. A boundary string, declared in Content-Type, separates the parts. Each part has its own small headers and its own empty line. The last boundary ends with --.

Content-Type: multipart/mixed; boundary=boundary1

--boundary1
Content-Type: application/sdp

v=0
…
--boundary1
Content-Type: application/pidf+xml
Content-ID: <alice-loc@atlanta.example>

<?xml version="1.0" encoding="UTF-8"?>
…
--boundary1--

Select Multipart INVITE in the message explorer at the top of this module: an emergency call that carries both the SDP and the caller’s location (RFC 6442). Content-Length counts the whole multipart body, boundaries included.

4.6 Case rules

Some parts of a message ignore upper and lower case. Others do not, and a mismatch silently breaks matching.

4.7 Header parameters and URI parameters

To, From, Contact, Route, and Record-Route hold a URI, and both the URI and the header can have parameters. Angle brackets decide which is which.

Contact: <sip:alice@192.0.2.10:5060;transport=tcp>;expires=3600
          └──────────── the URI ────────────────┘ └ header ┘

Inside the brackets, transport=tcp belongs to the URI: it tells the next sender how to reach Alice’s phone. Outside them, expires=3600 belongs to the Contact header: it says how long the registration lasts. Without brackets, every parameter belongs to the header:

So Contact: sip:alice@192.0.2.10:5060;expires=3600 is correct: expires is a header parameter either way. But Contact: sip:alice@192.0.2.10:5060;transport=tcp is a bug: transport is now a header parameter, and the next request to Alice goes over UDP. That is why RFC 3261 requires brackets whenever the URI itself has parameters:

Pick an example, or type a header line, and see who owns each parameter.

Common mistakes

Summary

• A SIP message has four parts: a start line, headers, an empty line, and an optional body. Every line ends with CR LF.
• A request line is METHOD Request-URI SIP/2.0. A status line is SIP/2.0 code reason. Software reads the code, never the reason phrase.
• Header rows with the same name keep their order, and can be combined with commas — except the four authentication headers. Most common headers also have a one-letter compact form.
• Content-Length is the body size in bytes. Over TCP, it is the only way to find where a message ends; a wrong value breaks the whole connection.
• A multipart body carries several parts, separated by a boundary. Content-Length counts all of it.
• Header names and most values are case-insensitive. Methods, Call-IDs, quoted strings, and the URI user part are case-sensitive.
• Angle brackets decide ownership: parameters inside belong to the URI, parameters outside (or without brackets) belong to the header.