The general structure of a SIP message is based on Internet Message Format (RFC5322, RFC2822). With some minor differences in character sets the SIP message syntax is identical to HTTP 1.1 (but surely the SIP is not an extension of HTTP).

The SIP messages start with the Start-line, which is followed by a number of header fields in the format name:value. An empty line separates the header fields from the optional message body. As the SIP is a textual protocol, with just a little practice with Wireshark or a similar tool, it is not that difficult to analyze the massages. But to truly understand the headers in the context of IMS requires some experience. In this post we will highlight the most important message parameters.

 

We already know that in SIP we have two types of messages – Requests and Responses. Requests are distinguished by having a Request-Line for a Start-line. The Request-Line contains a method name (REGISTER, INVITE, SUBSCRIBE ..), a Request-URI (R-URI), and the protocol version separated by a single space (SP) character.

REGISTER sip:tas01site.ims.mnc123.mcc456.3gppnetwork.org SIP/2.0

The Request-Line is very important, because it identifies the recipient and the Request-URI is also being used for routing.

In case of Response is the Start-line called Status-Line and consists of the protocol version followed by a Status-Code (200, 401, 603, ..) and its associated textual phrase. The separator is again a single space. The textual phrase has only an informational value.

SIP/2.0 200 OK

SIP header fields are similar to HTTP header fields in both syntax and semantics. A complete list can be fount at http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2.

Some header fields only make sense in requests or responses. If a header field appears in a message not matching its category (such as a request header field in a response), it has to be ignored.

Request

A valid SIP request sent by a UAC contains, at a minimum, the following headers: To, From, CSeq, Call-ID, Max-Forwards, and Via. Note that the order of the header fields is not given.

To

The To header specifies a “logical” recipient of the request. That means the field contains recipient’s identity which is displayed by a software client. As in the case of the SMTP Protocol, this information shouldn’t be trusted. We also already know that the routing towards the recipient is done based on the R-URI. The exception is the IMS registration, where the To header contains the public user identity (IMPU) of the originator.

The To header field contains a SIP URI, SIPS URI, or TEL URI.

From

As in the case of To header, the From header contains a “logical” identity of the sender. Although the SBC/P-CSCF verifies this header, for any decision in IMS we use rather P-Asserted-Identity field inserted by P-CSCF or P-Served-User inserted by S-CSCF.

Call-ID

Many engineers are looking for some trace-id. The Call-ID header acts as a unique identifier for messages within the same dialog. It should be the same also in each registration from one UA. However never forget that B2BUA can change its value. More about Call-ID along with from-tag and to-tag in a dedicated post.

CSeq

The CSeq header field consists of a sequence number and a method. The method matches that of the request in Request-Line. The sequence number is used to identify the order of requests within a transaction. Note that the CSeq of the first request can have an arbitrary value (< 2^31).  The header is mainly used to match requests and responses.

Max-Forwards

The Max-Forwards header is easy to understand –  it’s used to avoid routing loops. Each proxy which handles a request decrements the Max-Forwards value by one. Once it reaches zero, the request it discarded.

Via

The Via header is used to keep track of all the proxies a request has traversed. The response uses these Via entries so that it can backtrack the same proxies as the request did, just in the reverse order.

Response

In the response except the Status-Code we will find To, From, CSeq, Call-ID and Via. Note that the order of the headers can be different.

As we can expect, the value of Call-ID and CSeq remains the same. In wireshark we can find many 200 OK messages belonging to one dialog. That means with the same Call-ID. But we need to distinguish, which is 200 is for PRACK, which for UPDATE and which is for the initial INVITE. That’s where CSeq is useful.

The values of To and From headers also don’t change (no swap). Again Registration has to be treated separately. To identify the originator of the response we use the P-Asserted-Identity. For the routing we use the Via header, which we will discuss in more detail the next time.

More headers

Although the SIP protocol requires only a few headers, in IMS and particularly in VoLTE/RCS network we use much more message attributes. Let’s mention few of them.

P-Associated-URI, P-Preferred-Identity, P-Asserted-Identity

As mentioned, the P-Asserted-Identity is a very important header which identifies the originator of a sip message within a “trusted” domain. The header is defined in RFC3325.

The P-Associated-URI (PUI) header field contains a set of URIs which are associated with the subscriber (registered address-of-record). The header is sent by S-CSCF in the 200 OK response to REGISTER message. The list of URIs is stored by P-CSCF to be later inserted into a subsequent message (e.g. SIP INVITE, SIP MESSAGE) as P-Asserted-Identity.

P-Associated-URI: <sip:+123456789012@operator.com>,<sip:+123456789012@operator.com;user=phone>

The P-Preferred-Identity (PPI) header field is defined in the RFC7315. It can be sent from UE to P-CSCF to carry the identity the user  wishes to be used for the P-Asserted-Identity field. If an incoming SIP message does not contain the PPI or its values are not matching with the stored list, a default identity is picked from the top of the list.

The P-Asserted-Identity (PAI) is used only within the IMS network (trusted domain) to identity the user sending a SIP message as it was verified by authentication. Note, there may be one or two P-Asserted-Identity values. If there is one value, it is a sip, sips, or tel URI. If there are two values, one value is a sip or sips URI and the other is a tel URI.

P-Asserted-Identity:<sip:+123456789012@operator.com>

P-Asserted-Identity:<tel:+123456789012>

The P-Asserted-Identity can be present only in SIP INVITE, REFER, BYE, SUBSCRIBE, NOTIFY, OPTIONS, MESSAGE. In special cases we can find it in responses (e.g. emergency).

P-Charging-Vector, P-Charging-Function-Address

P-Charging headers are define as a part of SIP extension for 3GPP in the RFC7315.

There are three types of correlation information attributes that can be transferred in the P-Charging-Vector header: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifier (IOI).

ICID is a unique identifier of a dialog or a transaction outside a dialog. It is used to correlate the charging records.

The IOI identifies both the originating and terminating networks involved in a SIP dialog or transaction outside a dialog.

P-Charging-Vector: icid-value=abcd12345-xyz.567;icid-generated-at=10.10.11.3;orig-ioi=12345

There can be an IOI generated on each side of the dialog to identify the network associated with each side.

P-Charging-Vector: icid-value=123456-abcx.xyz;term-ioi=12345;orig-ioi=98765

The P-Charging-Vector and  P-Charging-Function-Address are usually inserted in messages by SBC.

P-Charging-Function-Addresses: ecf="aaa://PECF.operator.com";ccf="aaa://PCCF.operator.com";ecf="aaa://SECF.operator.com";ccf="aaa://SCCF.operator.com"

P-Served-User

The header is defined in RFC5502.  3GPP has identified some issues with the linking in of a Application Servers (e.g. in case of Call Diversion) that are most appropriately resolved by defining a new SIP P-header. The P-Served-User identifies a user whose services should be applied by a proxy or AS. The header is added in a message by S-CSCF. More in detail we will discuss in some other post.

P-Served-User: <sip:+987654321012@rcs.mnc123.mcc456.3gppnetwork.org>;sescase=orig;regstate=reg

Contact

The Contact header field is vital for the service. It provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. Moreover in the Contact header we can find the capabilities of the device and so-called “+sip.instance”, which is a unique identifier of the software client and enables the multi-device feature.

Contact: <sip:1234567890abcdef@sbc01site.ims.mnc123.mcc456.3gppnetwork.org:5060;id-12a-3bcd>;
+g.3gpp.smsip;
+g.oma.sip-im;audio;
+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";
+sip.mobility="mobile";
+sip.instance="<urn:gsma:imei:12345678-123456-0>"
reg-id=1;
video;

Route, Record-Route, Service-Route, Path

These headers are important for SIP routing. In more detail we’ll discuss next time.

P-Access-Network-Info, P-Visited-Network-ID

UA does use P-Access-Network-Info to pass information about the access network such as radio access technology and radio cell identity to IMS. The value is often updated by SBC. Within the IMS network we use the information for example to distinguish the messages coming over Wifi from those coming over LTE. It can be also used for location service e.g. in case of emergency services.

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890abcdef;network-provided

 The P-Visited-Network-ID is used by operator to identify home/visited networks e.g. in case of roaming. The header is inserted by SBC based on the access realm.

P-Visited-Network-ID: sbc01-epc3.volte.operator.com

Of course, there are many other headers. Some of them we will touch in next posts. We should mention that there exists also a Compact Form of SIP message headers. That’s a mechanism which allows to represent common header field names in an abbreviated form. There are some advantages and reasons to use this option, but I personally believe that it is mainly confusing. Btw. you can send a request in a compact form, but the response often comes in a Standard Form ..

MESSAGE sip:+123456789012@ims.operator.com;user=phone SIP/2.0
v:SIP/2.0/TCP 172.12.18.1:5090;branch=z9hG4bK123456abcde
v:SIP/2.0/UDP 172.12.18.2:5070;branch=z9hG4bKxyz
Allow:MESSAGE
P-Access-Network-Info:3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=12345678901234567
f:<sip:+112233445566@ims.operator.com>;tag=123456abcd
t:<sip:+123456789012@ims.operator.com>
i:3153075167@172.16.18.172
CSeq:1 MESSAGE
Max-Forwards:68
l:31
P-Asserted-Identity:<sip:+112233445566@ims.operator.com>
P-Asserted-Identity:<tel:+112233445566>
P-Charging-Vector:icid-value=343443543543c;orig-ioi=ims.operator.com
P-Served-User:<sip:+112233445566@ims.operator.com>;sescase=orig;regstate=reg
Route:<sip:10.20.30.1:5060;transport=TCP;orig;lr;mode=originating>
Route:<sip:isc@scsc01site.ims.operator.com:5090;lr>
c:application/vnd.3gpp.sms
d:no-fork

Body

Requests, as well as the responses, can include a Body. To interpret the Body, we have two important headers Content-Type and Content-Length. In case of any encoding such as compression, it is indicated by the Content- Encoding header field; otherwise, Content-Encoding is omitted.

If applicable, the character set of the message body is indicated as part of the Content-Type header-field value. When no charset is provided by the sender, we use as the default charset the UTF-8.

In SIP we can use the “multipart” MIME type as defined in RFC 2046. That is typical e.g. for REGISTER message, where we can have include initial REGISTER message in the body of 3rd party registration. So SIP can be in a body of another SIP message.

Related posts:

• VoLTE Illustrated: Beginners Guide
• How to read tcpdump – Registration
• IMS from 10.000 feet

• SIP Illustrated 1: Basics
• SIP Illustrated 3: Routing and IMS Registration
• SIP Illustrated 4: SIP Session
• SIP Illustrated 5: SIP Session Routing
• ??