locked
Speech-Enabled Auto Attendant Transfer Issue RRS feed

  • Question

  • Hi there,

    We are running Exchange 2013\Skype For Business 2015 and for the most part, everything works as intended.

    However, I was recently notified that while dialing a user's five-digit extension from the UM AA works, if you attempt to search for a user...either dialing by name or via speech, the user is located as expected and the transfer is initiated.

    Whereas dialing the extension directly would then connect to the user and ring their desk phone, when utilizing the directory lookup, the call seems to transfer successfully, but what it actually does is just go back to the auto attendant.

    I was able to resolve this by changing the telephone field in AD for my own account to simply be my five digit extension, but on the whole this isn't practical, as we have a lot of other systems that populate their data via AD, some of which are shared externally, and thus we need the full e 164 path... 123-456-7890;ext=12345.  I've verified that our normalization rules work, and in fact we actually extract just the extension from that string and pass that within the dial plan.  Dialing the extension alone works, calling a number in that format within Skype works...but no matter what I've tried, when the auto attendant attempts to transfer the call it just goes into an endless loop of autoattendant.

    Any idea what I could look at?  Additionally, since we know that if UM sees only the five digit extension in the telephone AD attribute, is there some way to configure UM to look at another attribute...perhaps a less visible attribute that we could "hide" the extension in?

     
    Tuesday, March 29, 2016 9:18 PM

All replies

  • Just to add -- I would guess this is a normalization problem, but I made sure there's a global normalization rule within Skype that matches our AD format, and verified that the addressbook process doesn't throw any errors for that field.  Additionally, if i test the normalization rules within Skype itself, the as-formatted number normalizes properly.  I'm pretty much out of ideas.  I set the event logging for UM to high and can see that the system is treating the redirect as a blind transfer, and in the UM router logs rather than seeing the SIP-based transfer I would expect, I instead see TelExtn:Unknown .
    Wednesday, March 30, 2016 10:38 PM