Exchange 2010 Blind Transfer

Scenario

Edward executive admin answers the phone for Edna executive. This is setup in CUCM so that Edward
has two line appearances. His x1000, and then Edna’s on his second line button x1001. When someone
calls Edna both her and Edward’s phones ring. Occasionally Edward would answer Edna’s line and the
caller would ask to be transferred to her voicemail. Under the Unity voicemail system this was not a
problem Edward would press transfer on his phone dial *1001 and then transfer again to connect the
caller to Edna’s voicemail greeting, the caller would leave a message and all was well with the world.

Problem

With Exchange UM this was not the case. When Edward would dial *1001 from Edna’s line he would be
greeted with the user PIN prompt as if he was trying to check Edna’s voicemail. As we know Exchange
UM relies on the SIP diversion header information to know who the call is from. In this case the call
appeared to be from Edna meaning Exchange UM assumes that Edna is trying to check voicemail so play
the login greeting.

Solution

The root cause of the problem is the default settings on the SIP trunk going from CUCM to Exchange
UM. On the Outbound Calls section, Calling Party Selection this is defaulted to Originator. Meaning the
directory number sent in the diversion header to Exchange is going to be the first call leg in the transfer,
in the above example this would be Edna’s directory number.
Changing this setting to Last Redirect Number results in the last device to be connected to the call leg
having its caller ID used in the diversion header. In this example that would be the caller that is currently
being transferred to Edna’s voicemail. This results in the desired behavior of the caller being prompted
to leave a voice message for Edna.

HOWEVER this then means that during a normal call no answer scenario the last device connected in the
call leg is Edna’s phone which brings us back to where we started. The user would be greeted with the
login prompt for voicemail and not the option to leave one. This is resolvable however by creating a
special trunk used only for blind forwarding. The blind forwarding trunk will have its Calling Party
selection set to Last Redirect Number. While the normal voicemail trunks will be set to Originator
solving both use case needs. This also requires the creation of a separate voicemail pilot number to be
created so it can be pointed at this specific blind forward trunk.

Summary

Normal Voicemail Trunk

Blind Forward Trunk

Permanent link to this article: https://tripplehelix.net/exchange-2010-blind-transfer/

9 comments

Skip to comment form

  1. Hello. I was wondering if I could get more details on how to fix this issue. I set up a new trunk and pilot number (with associated CTI route point). When I dial the blind transfer I receive a fast buy. Any insight would be awesome.

    James

    1. Did you add the new pilot number to the Exchange UM Hunt group on the exchange side? Exchange will only pick up if it has the pilot number programmed under UM IP Gateways > UM Hunt Groups.

      Thanks.

  2. Pardon my CUCM ignorance, but how do you divert only the “transfer” calls to the new trunk?

    From what I can see, the 1001 directory number can only have one VM profile, and that profile can only have one pilot. This forces me to choose between the pilot number routed out the trunk with the “Original” setting and the trunk with the “Last Redirect Number” setting.

    1. You’re correct you can only have one VM profile set per DN. This is where you get clever. In CUCM build a CTI Route Point of *XXXX (where XXXX is the number of digits in your extensions you’ll want to send to Exchange). On this DN you’ll set this to be the transfer voice mail profile and check forward all calls to voice mail. So from an end user standpoint they would Dial *1234 and this would transfer the call right into voice mail for the mailbox 1234.

      If you need more information let me know and I’d be happy to write up a guide on it.

      Hope that helps,

      Tim

      1. Thanks, I see that now. Apparently we already had *XXXX set up as a DN with a “CTI Port” associated.

        When I use that to route over the secondary VM profile, the diversion works.

        There is one quirk, the “source” identity provided to Exchange is the CTI’s, not the person who first picked up the phone to initiate the call.

        #
        A call was received with the following parameters:
        Calling Party: “sip:*2119@10.152.0.36”,
        Called Party: “sip:6003@bma-um-01.xyz.net”,
        Diversion Information: “”CTI for Transfers”;privacy=off;reason=unconditional;screen=yes “,
        Referred-By Header: “”,
        #

        Is there a way to configure the trunk to provide the original caller ID info in the Diversion Information?

    • Colin Holloway on December 12, 2014 at 9:27 am
    • Reply

    Tim,

    I can’t make a secondary trunk because I’ve only got a single Exchange server IP to which to point and Call Manager throws an error as there is already a trunk pointing to that IP and port (5060). How did you get around this?

    1. The way I got around this was the trunk I used for my primary voicemail I referenced via IP address. The blind transfer trunk I used the FQDN of my Exchange UM server. This does depend on you have name resolution available to you in Call Manager. Hope that helps.

      • Colin Holloway on December 12, 2014 at 11:39 am
      • Reply

      Tim,

      Never mind I got this sorted. I ended up just assigning a secondary number to the NIC on the Exchange 2010 UM server rather than muck about with setting up self signed certs to utilize the TLS port

    • Joshua Fontenot on August 9, 2016 at 8:40 am
    • Reply

    Very helpful write up. I just applied this to my current CUCM and Exchange Server. Works now.

Leave a Reply