Do you remember that scene from the movie The Wizard of Oz where Dorothy comes to the fork in the yellow brick road and the Scarecrow points her in both directions at the same time?
Dorothy: Are you doing that on purpose or can’t you make up your mind?
Scarecrow: That’s the trouble. I can’t make up my mind. I haven’t got a brain.
Unfortunately, SIP can be a little like that. Despite the fact that it’s an IETF (Internet Engineering Task Force) standard, there isn’t always one way to solve a problem. While that may be just fine in some situations, mismatched approaches can lead to unexpected results and broken services.
One of the most common mismatches comes in how a SIP system records a session’s (e.g. call’s) history. For example, if Andrew calls Sarah and Sarah’s phone is forwarded to Debbie, the INVITE that Debbie receives will note the fact that the call originally went to Sarah.
Unfortunately, there are two different ways in SIP to designate session history. I discussed one of those methods in last week’s article – An Introduction to the SIP Diversion Header. The second approach uses a different header to accomplish the same thing – History-Info.
The basic format of a History-Info header conveys the diverting address, reason for diversion, and the index of the diversion. Optionally, it may contain privacy information. Since a session may go through multiple diversions, there may be multiple History-Info headers or a combined header that conveys all diversions.
An example History-Info header might look like the following:
History-Info: <sip: diverting_user1_address; privacy=none >; index=1,<sip: diverting_user2_address; cause=408?privacy=history>;index=1.1, <sip: diverting_user3_address; cause=486?privacy=none>;index=1.1.1, <sip: last_diverting_target; cause=302>;index=1.1.1.1
History-Info is similar to Diversion with a few important distinctions. Let’s start with the similarities:
- Both contain the diverting party.
- Both contain the reason why the call was diverted.
- Both allow for privacy.
- Both indicate the order of the diversion.
You need to be aware of one big difference. The order of Diversion headers is the last diversion is listed on top and the first is on the bottom. With History-Info, it’s the opposite. The first diversion is on top and the last is on the bottom. Not understanding that can lead to some unexpected behavior.
What’s the Big Deal?
You can see that the Diversion and the History-Info headers look pretty similar and for all extents and purposes, they do the same thing.
This is a problem.
Imagine a SIP PBX that uses the Diversion header to store call history sending a caller to voice mail server that expects to see that information in History-Info. How will it know which mailbox to use if it doesn’t know the originally dialed number?
Although History-Info is the IETF recognized way to record diversion within a SIP message (documented in RFC 4244), the Diversion header appeared first as a draft proposal and lots of people started using it without any official blessing. This means that you are likely to find inconsistency between the products of different vendors. Some like Diversion, some like History-Info, and some appear to like both.
While writing this article, I tried to come up with a list of who’s-who of support, but I failed. Perhaps someone knows of such a list and is willing to share it with me.
To help address the requirement to simultaneously support both approaches, RFC 6044 was written. This document details call flows and two-way translations that facilitate conversion between Diversion and History-Info. Since Diversion appears to be here for a while, this RFC satisfies a very important need.
That’s it for today. The important points to remember are:
- Diversion and History-Info do pretty much the same thing.
- Diversion came first, but was never accepted as a standard.
- Lots of people implemented Diversion despite it not being a standard.
- History-Info is the correct way to indicate diversion, but to be safe, SIP components need to provide support for both approaches.
Happy History-Info diverting!
Tao, Zen, and Tomorrow 
Thanks, this article helped clear up some confusions I had about the competing standards!
Thank you, Joel. I am happy to hear that my article was helpful.
Some carriers (e.g. AT&T) require that you populate the Diversion header with CPN to ensure that calls are billed correctly, when you want your CPN and Caller-ID to be different. Because of this, we have had no end to troubles with making and receiving calls.
Is there a better way for carriers to implement this functionality? (P-CPN header perhaps?)
From what I read from the industry as a whole, using the Diversion header for such things extends the life of a header that really should go away. Wouldn’t P-Asserted-Identity be a better choice for what the carrier is trying to do?
On some carriers, such as AT&T, the P-Asserted-Identity will change the caller-id presented to the called-party.
As usual Grate Article,. Thank you
Thanks!
The article is really clear and helpful.
Can I know when both history-info and diversion almost similar, why two came into picture and only History_info is standardized.
Two competing factions within the IETF. Diversion came first and people starting using it before the RFC was ratified.
Thanks for your reply
Thank you for explaining this. I am running into a problem between Microsoft Exchange 365 UM and Avaya Aura Communication Manager with Session Manager 6.3. Avaya places the forwarding extension in the 2nd to last History-info header, with the last History info header containing the phone number for the UM. Microsoft wants to always read the 2nd history info header. Under certain circumstances Avaya will send 4 history-info headers with the 3rd containing the forwarding extension. UM reads the 2nd, and sends to the wrong mailbox. Any advice? Have you or your students ever heard of this issue before? Your explanation seems to indicate that Avaya’s way is correct.
Without an SBC, you may be out-of-luck. Here is everything you can do with an Avaya system (as far as I am aware). http://www.avaya.com/blogs/archives/2015/11/learning-to-work-with-avaya-aura-session-manager-adaptations.html
Thank you for your reply and for providing the information. We have an AudioCodes Mediant 1000 SBC and both Microsoft and Avaya are looking into ways to manipulate the headers using the SBC. I will continue to update as we move forward in the hopes of helping others. I’ve seen a lot of users asking the same questions that I have on other message boards with no answers. Your blog is terribly important. Can’t find this info anywhere else. Thank you again.
I appreciate that. I’ve been so busy and haven’t written many deep in the weeds articles lately, but I hope to find the time for a few of those before too long.
I appreciate the way you help us clear the concepts. This article was very helpful. I am going to try these in one of our task wherein we have to integrate Avaya CM, SM and MS Unified Messaging.