locked
Transferred Calls from Exchange Auto Attendant Problem RRS feed

  • Question

  • Hi there,

    I crossposted this to the Exchange 2013 Forums as well, as I initially though this was a UM problem, but the more I dig I'm not so sure.

    We have a speech-enabled autoattendant living in Exchange 2013, with a 5 digit extension, sip uri based dial plan.  If a caller dials an internal extension from this AA, the transfer completes with no problems -- everything's groovy.  Additionally, if a caller bypasses the AA entirely and calls a user's DID (not everyone has one, for cost reasons) -- no issues there, either.

    If a caller attempts to use the directory -- that's where the problems start.  The AA is able to successfully locate the desired party, and upon confirmation, it will attempt to transfer the call.  At this point, the call passes to SFB mediation -- I can verify that by watching it happen in a SIP trace on the server itself,  but the transfer is being treated as a telephone\extension based transfer rather than a SIP URI transfer.  Furthermore, it's using what's stored in the intended recipient's AD "Telephone" attribute for the lookup.  Now, normally I wouldn't expect this to be a problem -- the numbers are E164 formatted (ex:  +12345678900;ext=12345) .  No problem there -- I have normalization rules in the Global dial plan to convert to the user's 5 digit line uri --  TEL:+12345.  However, what's happening...and I can verify this in both the SIP trace and in verbose UM call routing logging...the transfer is omitting the extension portion and transferring the call back to the main number\auto attendant -- 12345678900 in this example!  So where the AA transfer seems like it's successful, it's only successful in creating an endless loop that causes every directory transfer to route back to the main number.  Why this happens...I am at my wit's end.  

    To reiterate, every other scenario works as intended...outside callers can dial the 5 digit extension from the AA and connect.  Internal callers can dial the 5 digit extension and connect.  I can even click on the E164 formatted number in the Outlook contact card and connect...the ONLY instance in which this isn't working is via Auto Attendant transfer!

    The reason that I'm near certain it's a problem with the way that SFB is normalizing the AD telephone attribute is that I can work around the problem by changing that field for a test user to be just their extension -- 12345.  If I do that, the AA transfer completes as expected!

    I've read some articles that state that there was an issue when SFB was first released (we did an in-place upgrade from Lync 2013) and that a CU was released that fixed it.  However, we are current on our CUs(I installed March 2016 as part of my troubleshooting).  The symptoms otherwise align -- in the UM logs, I see that the AA is treating it as a blind transfer in these cases.

    I really don't want to have to change everyone's AD telephone to their five digit extension, especially given that we generate extracts that go to customers so that they have individual department contact info...can anyone take a shot at this?

    Thursday, March 31, 2016 6:56 PM

Answers

  • Okay, I finally figured out what the issue was, although I'm still having one unrelated problem.

    We are utilizing Exchange Hybrid...about 3 quarters of our users are migrated to Office 365, but our auto attendants were still living on premise.  The users themselves were set up for cloud UM, but the auto attendants were failing when trying to transfer to a user that had been migrated.  Since the bulk of our users are already migrated and the rest will be shortly, I have recreated the the auto attendants in Exchange Online and and got them in place and handling calls on our original pilot numbers, and that issue has gone away.


    • Marked as answer by jafnelson Friday, April 15, 2016 2:45 PM
    Friday, April 15, 2016 2:45 PM

All replies

  • Hi,

    Please check that if the transferred number from the AA to SFB Server normalize to other format which not be defined on SFB Server side. If yes, then the number may be defined to be a external number.

    If it is the number, try to modify the number to the E.164 format and match the true users then test the issue again.

    Best Regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    • Marked as answer by Eason Huang Thursday, April 14, 2016 6:59 AM
    • Unmarked as answer by jafnelson Thursday, April 14, 2016 2:20 PM
    Monday, April 4, 2016 9:00 AM
  • As stated in the original post, the numbers are already E164 formatted, and if I test the number in the Skype call routing test, it normalizes properly.   There's something else going on.
    Thursday, April 14, 2016 2:21 PM
  • Okay, I finally figured out what the issue was, although I'm still having one unrelated problem.

    We are utilizing Exchange Hybrid...about 3 quarters of our users are migrated to Office 365, but our auto attendants were still living on premise.  The users themselves were set up for cloud UM, but the auto attendants were failing when trying to transfer to a user that had been migrated.  Since the bulk of our users are already migrated and the rest will be shortly, I have recreated the the auto attendants in Exchange Online and and got them in place and handling calls on our original pilot numbers, and that issue has gone away.


    • Marked as answer by jafnelson Friday, April 15, 2016 2:45 PM
    Friday, April 15, 2016 2:45 PM