Should MIC be using the DIVERSION information in the SIP INVITE to match to a VMB? The reason I ask is when ours was being installed calls were not going to voicemail boxes on redirects but rather to the "please enter your voicemail box number". The solution was to replace the Called information with the Redirect information at the Gateways. Now that we're trying to get a CUCM to talk to the MICs, it wants to send the Called information in the DIVERSION area of the SIP msg, with no built in way to control it like the Gateways. Any ideas how this could/should be handled better?

It should look for History-Info first, then Diversion if History-Info isn't there, I think. Whichever it finds should be put into Eic_RedirectingTn. That should be preferred for redirection calls to a mailbox. If you're not getting there, then either SIPEngine has changed and Diversion is no longer being used, or that header is empty or not matching any mailbox, or the MIC handlers have changed since I last worked on them. You should be able to see it by debugging UM_IncomingCall. I think it is in the call to SystemParseSIPAddress where it decides whether to use Eic_RedirectingTn or Eic_LocalTn... Hope this helps - it's been a looong time since I've looked at this stuff.

Thanks for the reply Andy. I did run debug, it has all the values it needs, and the sRedirectingTn and LocalTn are passed into the SystemParseSIPAddress, but it is defaulting out without actually reassigning the LocalTn. The Assignment step after it comes back out to UM_IncomingCall has the value being assigned as "Test(StrLower(LocalTn)="anonymous", "", LocalTn). In other paths it is assigned as "Test(StrLen(sRedirectingTn)>0, sRedirectingTn, LocalTn)" or "Test(StrLen(sDNIS)>0,sDNIS,LocalTN" Our vendor has an open ticket with ININ. Earlier in the handler, Eic_RedirectingTn is assigned to sRedirectingTn.

Also know that the handler is looking for the the RedirectTN to have "tel:" or "sip:" preceding it for it to be valid.