Tag Archives: wrong voicemail

Good to Know: Explaining Exchange UM Diversion Header Preference

What’s the Issue?

Here’s another one that I’ve personally fought a few times with clients that use Exchange 2007, 2010, or 2013 Unified Messaging with Avaya, Cisco or other PBX systems.  We’ve also seen it come up a few times on TechNet.  After bouncing around within voicemail, calls don’t end up where we might expect them too.  An example call flow is as follows:

  1. A call comes into an Exchange UM Automated Attendant.
  2. The caller presses a key to be transferred to User A.
  3. User A doesn’t answer.

The question is: when User A doesn’t answer, what do you expect to hear?  Do you expect to go back to the Automated Attendant or do you expect to hear User A’s voicemail?  With Microsoft Exchange, you’ll go back to the Automated Attendant, while many used to other more traditional voicemail systems are expecting to hear User A’s voicemail.   Why is this?   Simply, it’s diversion headers.

What’s a Diversion Header?

If you’re not familiar with diversion headers within your SIP packets, they’re defined a bit in RFC 5806. In a nutshell they’re used to signal a change to the ultimate endpoint that will receive a call.  We see these used heavily in voicemail systems.  When a call is routed to voicemail, the SIP INVITE is sent to the voicemail subscriber access or dial plan number with a diversion header specifying the phone number that corresponds to the mailbox.  To see this, let’s say a call comes in from the phone number 555-555-5555 to a user with phone number 888-888-8888, the Exchange dial plan has the phone number 88895 assigned.   The SIP INVITE would look like the following:

 INVITE sip:88895@10.19.10.21;user=phone SIP/2.0 
 Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac214495832;alias
 Max-Forwards: 70
 From: <sip:555555555@10.19.10.131>;tag=1c213481216
 To: <sip:88895@10.19.10.21;user=phone>
 Call-ID: 213439323315201145819@10.19.10.131
 CSeq: 1 INVITE
 Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
 Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
 Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
 Diversion: <tel:8888888888>;reason=no-answer;counter=1;screen=no;privacy=off
 User-Agent: Mediant 1000/v.6.60A.030.010
 Content-Type: application/sdp
 Content-Length: 231
 v=0
 o=AudiocodesGW 212414200 212414170 IN IP4 10.19.10.131
 s=Phone-Call
 c=IN IP4 10.19.10.131
 t=0 0
 m=audio 8330 RTP/AVP 0 101
 a=ptime:20
 a=sendrecv
 a=rtpmap:0 PCMU/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-15

The issue comes in when the call bounces around and the diversion headers stack up.  Let’s look at another invite.  This time, a call comes in from the phone number 555-555-5555 to an automated attendant with phone number 666-666-6666, the Exchange automated attendant has the phone number 88895 assigned.  The caller hits a key and the call is transferred to a user with the phone number 777-777-7777.  The 7777 number doesn’t answer and is sent back in toward Unified Messaging.  The INVITE coming back in now looks like this:

INVITE sip:88895@10.19.10.21;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac1145709558;alias
Max-Forwards: 70
From: <sip:555555555@10.19.10.131>;tag=1c1145125933
To: <sip:88895@10.19.10.21;user=phone>
Call-ID: 1145084972315201145825@10.19.10.131
CSeq: 1 INVITE
Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Diversion: <tel:7777777777>;reason=no-answer;counter=1;screen=no;privacy=off
Diversion: <tel:6666666666>;reason=unknown;counter=1;screen=no;privacy=off
User-Agent: Mediant 1000/v.6.60A.030.010
Content-Type: application/sdp
Content-Length: 233
v=0
o=AudiocodesGW 1143825135 1143825105 IN IP4 10.19.10.131
s=Phone-Call
c=IN IP4 10.19.10.131
t=0 0
m=audio 6990 RTP/AVP 0 101
a=ptime:20
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Exchange sees the last diversion header and sends it right back to the Automated Attendant listening on 666-666-6666 and we’re back in the menu.  The telephony team may have instead preferred that Exchange looks at the first diversion header and transfer to the 777-777-7777 user’s voicemail.

How Do You Change It?

Within Exchange, there is no method to alter this.  With most session border controllers or IP gateways, such as Sonus, AudioCodes, etc, you do have options.  Some of these come in the form of checkboxes, sometimes you’re working with SIP message manipulations.   Armed with this understanding and your own SIP trace files, you should be able to work with your gateway or PBX vendor to find a solution.  I have intentionally left instructions to manipulate the SIP messages in various systems out of the article as a misstep can cause disaster for a production systems, please work with your vendor for more specific help.