SIP Messages
Tags: sip
Published: 2023-08-13 20:59:42


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](https://datatracker.ietf.org/doc/html/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:15555551000@example.com 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](https://datatracker.ietf.org/doc/html/rfc3261#section-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.