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

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.

Advertisements

7 thoughts on “It is about quality!

  1. Pingback: A magic box called SBC – introduction | Real Time Communication

  2. Pingback: A magic box called SBC | Real Time Communication

  3. Pingback: Summer & IMS | Real Time Communication

  4. Pingback: WebRTC GW | Real Time Communication

  5. Pingback: VoLTE flows – close encounters | Real Time Communication

  6. Pingback: VoLTE in IMS | Real Time Communication

  7. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s