SIP Messages

I'd like to break down a lot of the structure of SIP, and it seems that the easiest place to start is with a SIP message. A SIP message is just that - it's an atomic message sent from one SIP endpoint to another. Structurally and by design SIP has a close relation to HTTP (note: HTTP, not HTML). A SIP message is defined in RFC3261 section 7 and consists of:

• A start line
• One or more message headers
• An empty line indicating the end of the message headers (literally a stand alone CRLF)
• An optional message body

So - based on that it's a LOT like HTTP. Further more, all SIP messages can be classified into one of two types: Requests and responses (replies), which can be differentiated by their start-line.

Requests

A SIP request start-line begins with a method such as REGISTER, INVITE, ACK, CANCEL, OPTIONS, etc. followed by a SIP URI, which is referred to as the "Request URI", and then the SIP version (which, as of this writing should only ever be SIP/2.0). The request is easily recognized by the fact that it begins with a word and not the version. An example would be:

INVITE sip:[e-mail] SIP/2.0

Like with HTTP, the method can be thought of as the "verb" - what is the action being requested - and the URI is the target for the method.

The full definition is in RFC3261- 7.1

Responses

A SIP response will begin with the SIP version (just like with the request, as of this writing it would only ever be SIP/2.0. This is followed by a three digit numeric status code, then a "reason phrase" that is intended to be human readable. Example:

SIP/2.0 404 Not Found

The SIP version is static, and the reason phrase is relatively free-form, but the reason code is divided into specific meanings based on the first digit, again, vey similar to HTTP:

• 1xx Provisional -- request received, continuing to process the request;
• 2xx Success -- the action was successfully received, understood, and accepted;
• 3xx Redirection -- further action needs to be taken in order to complete the request;
• 4xx Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
• 5xx Server Error -- the server failed to fulfill an apparently valid request;
• 6xx Global Failure -- the request cannot be fulfilled at any server.

Headers

As stated above, after the start-line comes one or more headers (It almost always will be more than one). These are functionally key-value pairs that contain a header name (they key) and a value. It is valid for the same header name to appear more than once, and in the case of some headers the order is important for call routing.

It's also worth noting that in SIP Requests the following headers are mandatory: To, From, CSeq, Call-ID, Max-Forwards, and Via. These headers (aside from Max-Forwards) are also generally copied into the responses. RFC3261 defines those headers as well as a number of other headers that are used for message routing. Some headers are defined in other complimentary extension RFCs. Headers can also be arbitrary and have no formal definition and can be user defined.

Body

The SIP body is entirely optional, and depending on the request type might be expected to be non-existent. For VoIP the most common type of body is SDP (Session Discovery Protocol), which is used to negotiate the media used and it's endpoints, and other related parameters.

It's also possible that the body could be something like a text message, but given that the majority of SIP communication occurs over UDP, this would place a potential limit on message size, which makes it not particularly useful for this purpose.

Another type of data in the body that might become increasingly common within SIP is pidflo data that is used for identifying endpoint location when calling emergency services. This is xml data in the body of the INVITE, usually along with SDP, which changes the Content-Type from application/sdp to a multi-part type which is described using MIME - like SMTP.

SIP and client/server relationships

One of the more interesting things about SIP is the definitions of a SIP client (a UAC) and a SIP server (a UAS). The definition of a client is "a user agent that sends a request" and a server is "a user agent that sends responses".

Extrapolating those examples to HTTP is pretty simple: A web browser is a user agent which sends a SIP request to a SIP server, and it's always this way. Even when looking at web-sockets the devices are peered from the standpoint of HTTP - the server doesn't send an HTTP request to the client (at least not an un-embedded message).

With SIP, this is different. It's tempting to think of a "SIP Phone" as only a SIP client and a "SIP PBX" as only a SIP server, but in reality either one can initiate a phone call (send an INVITE) and either one can receive and respond to the request, so functionally they have to be both a UAC and a UAS.

Conclusion

A SIP message is a basic building block to understanding how VoIP works. There are sub-components such as specific headers that deserve more detail, and larger concepts to understand such as transactions and dialogs, but looking at the basic message is a good place to start for understanding each of these.