In relation to my previous post regarding Exchange2010 integration with Lync 2010, I encountered Event ID 1400. The certificate issued in the Exchange UM Server was not using its FQDN (EXCHANGE.domain.com) as the Subject Name (SN), instead the SN was owa.domain.com. The owa.domain.com certificate was issued before in the Exchange Server by the Exchange Admin. It was not me who issued it, but I have to be honest, it took me the whole day to realize that I need to check the Exchange certificate's details. Good thing I did!
Event ID: 1400 Source: MSExchange Unified Messaging
The following UM IP gateways did not respond as expected to a SIP OPTIONS request.
Transport = TLS, Address = lyncfe.domain.com, Port = 5061, Response Code = 0, Message = This operation has timed out.
Symptom
UM Cannot make a TLS connection to the OCS 2007 Server
Cause
The UM server was using a wildcard cert. This type of cert cannot be used for TLS connectivity with OCS
Resolution
Re-issued a cert with the fqdn of the UM server as the subject name.
The resolution? I created a new certificate and assigned it to the Exchange UM role only with the FQDN as its Subject Name. :)
Tuesday, January 25, 2011
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".
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
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.
at Microsoft.Exchange.UM.UcmaPlatform.UcmaCallSession.<>c__DisplayClassd.
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.
An error occurred while transferring a call to "
An error occurred while transferring a call to "
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
Subscribe to:
Posts (Atom)