Introduction

In this training we will talk about SIP transactions and how to identify them.

Requirements

Training: Understanding SIP Packets

SIP Transactions

SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses.

In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. The reason for this separation is due to the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them, and the UAC alone takes responsibility for acknowledging them with ACK. Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.

Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. The client transaction sends the request, and the server transaction sends the response. These transactions are logical functions and they exist within user agents and stateful proxy servers.

Consider the following example where the UAC executes the client transaction, and its outbound proxy executes the server transaction. The outbound proxy also executes a client transaction, which sends the request to a server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends the request to a server transaction in the UAS.

Now to better understand how this happens here is a timeline schema of an invite method and its following responses:

A stateless proxy does not contain a client or server transaction.

The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent. The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the "Transaction User" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction.

Validation

For validation, first ask permission to use one of our SIP Proxy servers (Kamailio Server), and then create a document with a header and footer according to the guidelines and place screenshots with the results of the tasks in a dedicated chapter named “Validation”:

1. In your Ubuntu console, apply a timestamp followed by an echo of your name and the ssh to the server;

2. Execute a ngrep of the first 15 SIP packets that pass;

3. Identify a Request packet for a method (either INVITE or REGISTER) and identify the ones that follow it (up until an ACK).

4. Create a Timeline Diagram of the transactions made for that method

References

http://www.unappel.ch/2/support/100722-training-employees/i/

https://www.ietf.org/rfc/rfc3261.txt.pdf

End of document

* * *