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:
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.
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.