A tricky UM routing problem

A colleague who earned his Exchange 2010 last year recently contacted me with a bit of an odd UM question. Here’s the basic scenario: Steve Secretary answers the phone for Betty Bosswoman. This was set up in Cisco Call Manager such that Steve’s phone has two extensions: 1000 (Betty’s extension) and 1001 (Steve’s extension). When someone calls Betty, both phones ring, and Steve can answer it as necessary. Sometimes Steve would answer the phone and the caller would ask for Betty’s voicemail; Steve could oblige by doing a blind transfer to Betty’s extension and the call would be routed to the voicemail system.

Things were all fine with this configuration until the advent of Exchange UM. Call answering and delivery worked fine until Steve tried to transfer a call to Betty’s voicemail, now hosted on Exchange UM. The caller whose call was transferred was getting Steve’s voicemail.. not at all the right result.

This was happening because when the call was transferred, CUCM was emitting a diversion header that indicated that the call was being sent to Steve. Why? Because Steve had Betty’s extension assigned as a secondary extension! Remember, Exchange UM uses the SIP diversion information to determine where the call’s from, who it’s to, and why Exchange is getting it. If any of these three data are incorrect or missing, Exchange will fall back to assuming that the call is to the voicemail pilot number, and you’ll hear “Welcome to Microsoft Exchange. Please enter your mailbox extension” (or whatever; the exact phrase escapes me) instead of the correct greeting.

My interlocutor wanted to know if there was a way to change this behavior on the Exchange side. Sadly there isn’t– whatever diversion header information is provided, Exchange will consume. There’s no way to rewrite, edit, or otherwise control the diversion data on the Exchange side, nor can you create rules or filters that modify the actions that Exchange takes. That’s what the call coverage map on the PBX is for, see?

Anyway, after a little head scratching, some consultation with a CUCM engineer, and the sacrifice of a chicken, it was discovered that CUCM had a way to modify the extension information sent as part of a blind transfer. The change was made so that transferring a call from Steve’s phone emitted Betty’s extension instead, and the problem was solved. Unfortunately I don’t know exactly what change was made, or I’d document it here. Such are the perils of not being a CUCM guy…