Exchange 2010 Auto Attendant NOT TRANSFERRING CALLS to Lync 2010

I've been having problems making Exchange 2010 Auto Attendant not transferring/forwarding calls to local numbers assigned in Lync 2010 users this past weekend, and at last today, I was able to make it work with the help of some researching, stock knowledge and some help from local MS guys.

Here is the situation in one of my deployments. The client is looking for an IVR feature or Auto Attendant basically. So we are trying to configure Exchange 2010 AA to route calls to Lync users. The reason is simply because the client prefers to use local numbers instead of DIDs for most of their users.

We have a consolidated Exchange 2010 server (with MBX, CAS, HUB, UM on it) and a Lync 2010 infrastructure. My Lync 2010 infrastructure has a FE/Mediation and Edge Server architecture. All my Lync users (ex. User1 has a local of +1000 and User2 has a local of +2000) are configured with local numbers. I have a DID assigned to my Exchange 2010 Auto Attendant. My Lync and Exchange dial plans have exactly the same name. We are configuring the Exchange Auto Attendant (as Attendant/IVR) for calls coming from external (PSTN).

My Exchange 2010 Dial Plan is set with 4 digits, SIP URI, and Secured options. ExchUCUtil.ps1 was ok. OCSUMUtil.exe was ok. I also created normalization rule in the Dialing Rules Group and set it in the Dialing Restrictions of UM (Though I'm not sure if this is necessary as I just saw it recommended in one of the forums). The idea was, in the Auto Attendant, if I dial in 1000 (XXXX), UM dialing rule would translate it to +1000 (+XXXX).

Here is the problem. When a user, whether both from internal or external, dials in to the Exchange Auto Attendant, and tries to transfer a call to a specific Lync user by saying the name (if speech enabled) or if typing the extension number (if not speech enabled), the calls do not connect to the Lync client. THE CALL IS NOT TRANSFERED!

When the Auto Attendant asks me to enter the extension of User1, using the keypad in Lync client, I type in 1000. The Auto Attendant dials in, and after a few seconds, it says call "THE CALL CANNOT BE TRANSFERRED. RETURNING TO THE MAIN MENU."

What?? Wait, you have to transfer my call! As if the AA can hear me and do what I told him to do.

I never experience a problem like this with OCS 2007 R2 before. It seems so seamless back then. Anyway, first thing I did, which I assume the same thing with everyone, is I check the Event Viewer for logs. I went to the Lync server, surprisingly, there are no warnings or errors in the logs. So, I went to Exchange UM server, Then here are the Event Logs that I saw.

Event ID: 1079 Source: MSExchaneg Unifed Messaging
The VoIP platform encountered an exception Microsoft.Rtc.Signaling.OperationTimeoutException: This operation has timed out.
at Microsoft.Rtc.Signaling.SipAsyncResult`1.ThrowIfFailed()
at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult result)
at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult result, String operationId)
at Microsoft.Rtc.Collaboration.Call.EndTransferCore(IAsyncResult result)
at Microsoft.Rtc.Collaboration.AudioVideo.AudioVideoCall.EndTransfer(IAsyncResult result)
at Microsoft.Exchange.UM.UcmaPlatform.UcmaCallSession.BlindTransferSessionState.Call_TransferCompleted(IAsyncResult r)
at Microsoft.Exchange.UM.UcmaPlatform.UcmaCallSession.SubscriptionHelper.<>c__DisplayClass5f`1.<>c__DisplayClass62.b__5e()
at Microsoft.Exchange.UM.UcmaPlatform.UcmaCallSession.<>c__DisplayClassd.b__9()
Detected at System.Environment.get_StackTrace()
at Microsoft.Rtc.Signaling.OperationTimeoutException..ctor(String message)
at Microsoft.Rtc.Signaling.SipTransactionAsyncResult`1.Transaction_Timeout(Object sender, TransactionTimeoutEventArgs e)
at Microsoft.Rtc.Internal.Sip.SingleThreadedDispatcherQueue.DispatcherCallback(Object queue)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state) during the call with ID "86149e64178b400cb843fa64034b199f". This exception occurred at the Microsoft Exchange Speech Engine VoIP platform during an event-based asynchronous operation submitted by the Unified Messaging server. The Unified Messaging server will attempt to recover from this exception. If this warning occurs frequently, contact Microsoft Product Support.
Event ID: 1136 Source: MSExchange Unified Messaging
An error occurred while transferring a call to "@domain.com". Additional information: The call transfer type is "Blind.", the transfer target is "phone number", and the caller ID is: "86149e64178b400cb843fa64034b199f". Event ID: 1136 Source: MSExchange Unified Messaging
An error occurred while transferring a call to "1000". Additional information: The call transfer type is "Blind.", the transfer target is "phone number", and the caller ID is: "86149e64178b400cb843fa64034b199f".

If you noticed the 2 Event ID 1136, I tried dialing either by local number or by name option.

Anyway, after some research, I found this resolution...

Solution - 01/04/2011 01:54 AM
Symptom
Exchange Unified Messaging 2010 SP1 audio attendant for Lync is not transferring calls from external/PSTN users to internal Lync users with event id 1079 and 1136 being generated in EUM server
Cause
By default, Lync enables REFER support that sends the REFER to the Gateway. In the customers scenario, they using a direct SIP trunk from a provider that is not using a Lync/W14 supported gateway.
Resolution
Disable REFER support in the Lync Trunk Support properties.
Additional Information
W13 the Exchange Server would send the REFER to the FE and FE would pass this to the Mediation. The Mediation would build the new invite back to the FE to be routed to the REFER-To destination.
W14 we changed this send the REFER to the Gateway. The reason for this was to support Media Bypass in a refer scenario. If you are not using a supported Gateway or SIP Provider you have to turn this off in order for a transfer to work. That way the Mediation will process the REFER instead of passing it on to the Gateway to handle.


It was just that single check box in the Trunk Configuration... And this is kinda new with Lync 2010, so I guess I'm excused for not making it work instantly... ;)

Thanks to Mark's blog... :D