An Introduction to the SIP Diversion Header

We all want to think that we are unique in some way and I expect that most people can find a few things about themselves that are different from the people around them. Sometimes those differences can be life defining. Take a look at most great basketball players and tell me that their height wasn’t a major factor in being able to play at the professional level. The same can be said for an NFL tackle where the average weight is above 300 pounds. You can be a tough-as-nails 180-pound badass, but you won’t get a shot at the big leagues unless you put on some pounds.

So, what makes me unique? At just shy of 6’ 2” I am too short for basketball and no one in their right mind would ever put me on a football field as anything other than a tackling dummy.

Sadly, I’m not even unique in the field of communications. There are others that know more about this stuff than I will ever dream to know.

However, there is something that makes me different from just about everyone else on this planet.

I was born in Arizona and spent my childhood and young adult years living in the Phoenix valley (Scottsdale, Mesa, and Tempe).  That in itself isn’t unique, but the fact that I now live in Minnesota makes me quite the rarity. Let’s face it, there are lots of Minnesotans in Arizona, but you will be hard pressed to find the opposite.  I never have.

Simply put, my uniqueness is based on diversion. I started out life in Arizona, was happy as a clam living there, met a Minnesota girl who became my wife, and found myself diverted to Minnesota.

Which leads me to today’s topic of discussion. The SIP Diversion header.

Okay, that’s a stretch, but cut me some slack. It’s hard coming up with new blog subjects and making them sound personal.

The SIP Diversion Header

RFC 5806 defines SIP diversion as follows:

• A change to the ultimate destination endpoint of a request. A change in the Request-URI of a request that was not caused by a routing decision. This is also sometimes called a deflection or redirection.
• A diversion can occur when the “user” portion of the Request-URI is changed for a reason other than expansion or translation.
• A diversion can occur when only the “host” portion of the Request-URI has changed if the change was due to a non-routing decision.

This usually boils down to the scenario where A calls B and A is redirected (not transferred) to C.

Imagine Sarah setting call forward on her SIP telephone to send all incoming calls to Debbie. Now, when Andrew calls Sarah, his call will be automatically sent to Debbie. Debbie’s SIP telephone will know that the call was diverted by the presence of a Diversion header in the INVITE request she receives from Andrew.

Who inserted the Diversion header? It won’t be Andrew since he is unaware of the state of Sarah’s telephone. It won’t be Sarah since her telephone never saw Andrew’s call. It certainly can’t be Debbie since it’s her telephone that is ringing. This means that it must be something between Andrew and Debbie.

That something will be some form of a Back-to-Back User Agent (B2BUA) and in most cases it will be a SIP proxy that is aware of the forward conditions of the endpoints it serves. The Diversion header will be added by the proxy when it sees Andrew’s INVITE to Sarah. That altered INVITE will then be proxied to Debbie.

---

You can read all about  B2BUAs in my article, The Back to Back User Agent (B2BUA).

---

In my example, I stated that Sarah’s telephone was forwarded to Debbie. Of course, there are a number of different call forward conditions. In the SIP world, these are designated as diversion-reasons with the following permissible values:

• unknown
• user-busy
• no-answer
• unavailable
• unconditional
• time-of-day
• do-not-disturb
• deflection
• follow-me
• out-of-service
• away

Additionally, a Diversion header supports three other parameters:

• counter: This contains the total number of diversions that have occurred.
• screened: This indicates if the diversion number is user provided (“no”) or network provided (“yes”).
• privacy: Certain conditions require that the diversion information be encrypted.  This parameter shows how privacy has been applied.

The following is an example of a fully populated Diversion header:

Diversion: <sip:2000@192.168.254.254>;privacy=off;reason=no-answer;counter=1;screen=no

Anyone receiving an INVITE with this header knows that 2000 was the originally called number, no privacy was applied, the call was forwarded due to a no answer condition, this is the only diversion, and the diversion number was user provided.

A single INVITE may contain multiple Diversion headers. Those headers are ordered such that the last or most recent diversion is at the top of the list and all subsequent diversions are below it.

Making SIP Trunks Happy

In the past, I have encountered situations that required a Diversion header that had nothing to do with call forwarding. The most common is when you need to call out through a carrier SIP trunk and the From header in the INVITE contains a number not provisioned by the carrier. The carrier would look at the From value, not recognize it, and subsequently reject the call. In some cases, a Diversion header can be used to provide the carrier with a number that it does recognize.

The reasons why the carrier might reject the call are varied, but the most common one I’ve encountered is that carriers need to see a number in its pool of DIDs to properly handle 9-1-1 calls. The value in the Diversion header can be used to satisfy that requirement.

Mischief Managed

This article was meant to be an introduction to the Diversion header and I hope that I accomplished that. You are more than welcome to dig through the SIP RFCs for a deeper explanation, but for most of you that won’t be necessary.

Happy diverting!

Advertisement

Tags: Diversion Header, SIP, Unified Communications, VoIP