Blog Move

I've decided to move to hosting my blog myself. So from here on out head over to TrippleHelix.net for new posts.

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

CUCM SQL Magic (well really just queries) - Part 2

So last time we figured out how to read from the CUCM DB directly using SQL statements. This time we're going to start changing things. So like last time I recommend you take a backup and don't do anything you think could end in creating a fissure in the space time continuum.

Last time we learned that DN 1234 had a voice mail profile of 16c584ea-6a81-4138-9ea1-af452de8f75a. But maybe we want to change this, to say no voice mail. We learned that this had a PKID of NoVoiceMail 00000000-1111-0000-0000-000000000000. So we just need to update the DN to reflect this. With an easy SQL statement.


run sql update numplan set fkvoicemessagingprofile = '00000000-1111-0000-0000-000000000000' where dnorpattern = '1234'

What we've said above is update the numplan table and set the fkvoicemessagingprofile field to the value 00000000-1111-0000-0000-000000000000 where the DN is 1234. If all is well you should get the following output:

Rows: 1

Meaning that 1 row in the table was updated. If you go and check in the GUI your new voice mail profile change is reflected. Now it would be easy to break this into a nice long excel document output that in plane text and you're a copy paste away from easy DB updates that you otherwise couldn't do in the GUI.