Exchange UM Auto-Attendant to Lync extension transfer error


  • Hi! I have Lync 2010 and Exchange 2010 in my infrastructure. Exchange 2010 has UM role deployed. I need to route calls to internal user extensions. I have configured an UM Auto Attendant. I can call from Lync and PSTN to AA number. Then i enter 4-digit extension. The call is being transfered to the user. But if the user doesnt pick up the phone or the number doesnt exist, than AA says:"The call cannot be transfered. Returning to the main menu" and once again "The call cannot be transfered. Returning to the main menu". As if it is not possible to transfer to the extension and then back to AA number.

    Log Name:      Application
    Source:        MSExchange Unified Messaging
    Date:          3/27/2011 7:15:32 PM
    Event ID:      1079
    Task Category: UMCore
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    The VoIP platform encountered an exception
    Microsoft.Rtc.Signaling.OperationFailureException: Failed to transfer,
    successful refer notification not received
       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)
       Detected at System.Environment.get_StackTrace()
       at Microsoft.Rtc.Signaling.OperationFailureException..ctor(String
    sender, ReferStateChangedEventArgs e)
       at Microsoft.Rtc.Signaling.WorkitemQueue.ProcessItems()
       at Microsoft.Rtc.Signaling.SerializationQueue`1.ResumeProcessing()
    method, Object state)
       at System.Threading.ExecutionContext.runTryCode(Object userData)
    code, CleanupCode backoutCode, Object userData)
       at System.Threading.ExecutionContext.Run(ExecutionContext
    executionContext, ContextCallback callback, Object state)
       at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object
    FailureReason = 0 during the call with ID be4a01a2-8b1e-4e09-9703-783acb07c145. 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.

    And the following error:

    Log Name:      Application
    Source:        MSExchange Unified Messaging
    Date:          3/27/2011 7:15:32 PM
    Event ID:      1136
    Task Category: UMCore
    Level:         Warning
    Keywords:      Classic
    User:          N/A
    An error occurred while transferring a call to "201". Additional
    information: The call transfer type is "Blind.", the transfer target is
    "phone number", and the caller ID is: "be4a01a2-8b1e-4e09-9703-783acb07c145".

    What might be the reason?

    • Edited by EvgePr Wednesday, January 11, 2012 3:19 PM
    Monday, December 19, 2011 3:53 PM

All replies

  • Guys, any ideas?
    Wednesday, January 11, 2012 3:20 PM
  • Try creating in-country rule groups on the UM dial plan.  So if you create an "extensions" rule with a number mask that matches your extensions (e.g.:  2xxx mask/2xxx dialed number), you then need to apply that rule to the auto-attendant.

    You might also need to create a normalization rule on your front-end server/pool as well.  In that case, you would need to create a rule that normalizes incoming calls to match your extension range.

    Wednesday, January 11, 2012 4:52 PM
  • Trevor, thank you!

    I have already created in-country rules by specifying any number (* is put in all field).

    But if set Auto Attendant key mappings to transfer to the same extension and the user doesnt answer a call - than the call successfully returns to the AA. The only problem is with transfering to users by dialing their extensions.

    Thursday, January 12, 2012 12:15 PM
  • I'm a bit confused....

    So when a user dials an extension at the AA, the call gets transferred to the Lync user and their phone rings....correct?  If they don't answer it should roll to Exchange UM that not happening?

    Friday, January 13, 2012 2:39 PM
  • Trevor, if the voicemail is activated for the user - then everything is Ok. But in our environment it is enabled just for some users, because each Voice Mailbox requires Exchange Enterprise Cal and not everybody needs voice mail.
    • Edited by EvgePr Friday, January 13, 2012 3:18 PM
    Friday, January 13, 2012 3:17 PM
  • Guys, any ideas?
    Thursday, February 02, 2012 2:27 PM
  • It sounds like it is functioning as designed.  If the user does not pick up the call and there is nowhere for the call to be forwarding (typically voicemail) then the call cannot be transferred.  What are you expecting it to do?
    Monday, February 06, 2012 7:53 PM
  • Eric, I expect the call to return to Auto Attendant after the message "The call cannot be trasferred". But it repeating "The call cannot be transferred" phrase makes me think the call cannot be transferred to user and then it cannot get back to Auto-Attendant.

    I have tried to set Key Mapping to transfer the call to extension (like response group or particular user) by pressing "1". And in this case if the user doesnt answer the call and has no voice mail activated - then the call successfully returts to Auto Attendant.

    Monday, February 06, 2012 8:02 PM
  • Sorry I must not have understood your issue initially.  So the call is not returning to the AA to allow the caller to select another option.  Increase your logging levels in UM and see where the transfer back to the AA is failing.  You might have to compare the success of the one you said it did return to the AA correctly with the ones that failed.

    Monday, February 06, 2012 8:07 PM
  • Guys, I should have mentioned that we have an Exchange UM Auto Attendant with disabled Speach Recognition and Directory Lookup. If i enabel either Speach regonition and Directory lookup, or Directory lookup - then everything works fine.

    After dialing the extension in AA the call is transferred to the user. If the user doesnt answer the call and has no Voice Mail enabled, AA says that the call cannot be transferred and returns the caller back to AA.

    But we do not need directory lookups and speech-enabled AAs.

    Can somebody with Lync and Exchange UM deployed try to create AA with disabled Speech recognition and directory lookups (only allow transfers to extensions) and verify the behaivour of call during transfer to extension which is not UM enabled.

    Tuesday, February 07, 2012 3:14 PM
  • Guys, does anyone fixed this issue ? we have the same problem with our Echange 2010 UM and Lync 2010... if the person didnt response, the call tried to be trasfered to AA back but without succes, AA says "The call cannot be trasferred" twice and hung up

    Have found such thing when logging Lync Server 

    EVENT: refer;id=1
    SUBSCRIPTION-STATE: Terminated;reason=Noresources
    SUPPORTED: ms-dialog-route-set-update
    SUPPORTED: gruu-10
    USER-AGENT: RTCC/ MediationServer
    CONTENT-TYPE: message/sipfrag
    Message-Body: ----****MESSAGE BODY DELETED****----

    • Edited by Vigorian Friday, April 13, 2012 9:41 AM
    Friday, April 13, 2012 8:07 AM
  • Hi, check

    1. Exchange 2010 SP1

    2. Certificate UM role CN = FQDN server.

    3. Default setting of supporting SIP REFER and using an unsupported gateway with LYNC 2010

    MCITP. Знание - не уменьшает нашей глупости.

    Wednesday, July 11, 2012 2:38 PM
  • Hi Oleg,

    I have exactly same issue. It looks like many people have this issue too. I have Exchange 2010 SP2, and Lync 2010. When caller is pressing "0" to be transferred to Operator (while listening to voicemail greeting of the Lync user) call cannot be transferred. If the caller is Lync user this does work. But if the caller is PBX or PSTN user, call cannot be transferred.

    Any idea what else I can try to fix this issue?

    Friday, September 14, 2012 2:32 PM
  • Friday, September 14, 2012 5:46 PM
  • Ok, here is an update: problem is fixed!

    I gave up and decided to open Microsoft case for this. The guy from India was very professional and helped to find root cause and resolve issue under 30 minutes.

    Root cause: apparently SSL certificate used by UM service role should have Subject Name the same as FQDN of the UM server. When Exchange and Lync talk to each other during call transfer thing, they need to have a handshake secure channel established. If SN on SSL does not match FQDN of the UM server - no honey!

    In my case I was using one SSL with 20 SAN names in it - Lync, Exchange, external/internal names etc. Even though all looks good, it did not work. Since Exchange and Lync are internal and trust AD, here is what I did:

    1. Requested new SSL for each of my UM servers (MMC --> get SSL online from AD CA) with Server and Client authentication purposes.

    2. Re-assigned UM service role from my Commercial SSL certificate to new AD-based certificate

    3. Re-started Unified Messaging service on all UM servers

    Now everything is working. Knowing how many people having this issue, I would assume that this can be potential solution for other people too, so I will copy/paste this information into other threads as well.

    My issue is now resolved. It was a good experience though.

    • Proposed as answer by lync15 Friday, September 14, 2012 7:25 PM
    Friday, September 14, 2012 7:25 PM