It is about quality!

One of the marketing reasons why one should prefer VoLTE instead of common VoIP is the Quality of Service. The framework for Policy and Charging Control is described in its own post. Here we’ll focus QoS support in SIP/SDP protocols. Note that this post goes in details and expects that you’re familiar with SIP/SDP session negotiation procedure. When we want to support QoS during the session negotiation we need to add so-called preconditions in the SIP INVITE:

Require: precondition

The details can be found in the RFC 4032 and RFC 3312. The preconditions can be of several types as  qos, connectivity or security. In order to support QoS there are dedicated fields in SDP:

 
      current-status     =  "a=curr:" precondition-type
                            SP status-type SP direction-tag
      desired-status     =  "a=des:" precondition-type
                            SP strength-tag SP status-type
                            SP direction-tag
      confirm-status     =  "a=conf:" precondition-type
                            SP status-type SP direction-tag
      precondition-type  =  "qos" | token
      strength-tag       =  ("mandatory" | "optional" | "none"
                         =  | "failure" | "unknown")
      status-type        =  ("e2e" | "local" | "remote")
      direction-tag      =  ("none" | "send" | "recv" | "sendrecv")

The logic is very simple. Each participant will define whether he/she has some desired status he/she wants to reach. Then during the SDP offer/answer negotiation they are simply checking if the current state >= desired state. Let’s have an example.

QoS preconditions

In the first SIP INVITE the originator has not reach any current state but he has some target desired state. His desired state is to have a QoS set on both ends of the communication (local, remote)

a=desired mandatory local sendrecv
a=desired optional remote sendrecv

And on each of these endpoints the QoS needs to be for both incoming and outgoing media (sendrecv).   In the 183 the recipient informs that he also hasn’t reached any current state yet and confirms the desired state. In the SIP UPDATE the originator reserves the resources and informs that he has reached his local state:

a=curr local sendrecv

In the 200 OK the recipient informs that he also reached his local state (which is remote from the SDP point of view):

a=curr remote sendrecv

Again in practice this would be more complex as the involved SBCs can split the negotiation in several legs.