Today I came across an interesting but equally painful problem when configuring Skype for Business IVRs with Exchange Online Auto Attendant workflows. My customer has scenarios whereby IVRs are used as main line entry points for branch offices. The standard workflow dictates that there are three main options that process the call into a agent queue, but the fourth option transfers the caller to the branch site’s auto attendant service located in Exchange Online. The auto attendant allows the caller to search for a user by name, email address or extension. However, to account for user miss-dialing we need an escape back to the IVR from the auto attendant service. I decided to use the operator function within the auto attendant and entered the extension of the IVR. On the Skype for Business side a normalization rule was created to convert the extension to the full line uri of the IVR.
During testing, I found that when I called the IVR from an internal customer client, I was transferred to the auto attendant from the IVR, and I was able to press ZERO to return to the IVR. When calling from a PSTN end point I was transferred to the auto attendant and was able to escape back to the IVR. Both these scenarios worked as I expected. Great!
However, there is one scenario that didn’t. The IVR is enabled for federation, so what happens if a partner organisation attempts to call the IVR using SIP federated call?
In this scenario the following was experienced. IVR answers the call from the federated partner on SIP address. IVR successfully transfers the call to the auto attendant service. The federated partner can search the exchange dial plan for users and extensions. If the federated caller chose a specific user or dialled a correct extension, the user was found and the auto attendant transferred the call to the intended recipient. However, if the federated caller tried to escape the auto attendant back to the IVR, the call failed with fast busy.
At this point I performed some troubleshooting from both sides of the conversation, i.e. customer’s front end server and my SIP client signed in with my federated account. To be clear the operator extension I used was a fake 4 digit extension number because the Exchange Online dial plan was limited to 4 digit extensions e.g. 2000. Exchange should pass this call to the Skype for Business front end servers where a normalization rule is waiting to translate into the line uri of the IVR e.g. ^2000$ –> +441270212000. We know this works because from the PSTN the call is handled right and from internal too!
But it fails when you call via federated call. Why?
In short the refer message sent from Exchange Online is wrong. Looking at the trace I can see the REFER like
This causes my client to issue an INVITE message to my own Skype for Business deployment like so
INVITE sip:2000;email@example.com;user=phone;phone-context=dialstring SIP/2.0
Via: SIP/2.0/TLS 192.168.1.148:65255
So now the call is being attempted against my own pool and as a result fails my normalization rules (expected)
ms-diagnostics: 14011;reason=”Called Number translated”;source=”SFB01.myfluffy.cloud”;RuleName=”CRE-UNRES”;CalledNumber=”2000″;TranslatedNumber=”2000“;appName=”TranslationService”
and as expected the call fails
From: “Mark Vale”<sip:firstname.lastname@example.org>;tag=7d0c30c3c5;epid=59a56b22fe
CSeq: 1 INVITE
ms-diagnostics: 1003;reason=”User does not exist”;destination=”email@example.com”;source=”sip.myfluffy.cloud”
But this does not answer why a federated user can use the auto attendant to search for and dial a customer user successfully. The reason this works is because of the way Exchange Online handles the extension dialling for users. Let me explain.
When you use the auto attendant to search for users, the auto attendant first looks at all UM enabled mailboxes that have the dial plan’s UM policy assigned to them. When you search by name, this is the list that is used to determine if a user can be found or not. When you ask the auto attendant to dial by extension i.e. “if you know the extension number press #” and you enter the extension number of the user, the same logic is used. The auto attendant searches all UM Enabled mailboxes within the dial plan to match the extension you entered to a user mailbox.
The end result of this is that the auto attendant retrieves the user’s SIP address from their proxyaddressess attribute and that is used to transfer the call from the auto attendant to the intended user.
This is very important to understand, because it now explains why I am experiencing the above issue. The operator extension is an unattached extension, therefore exchange RNL service will not find a SIP address to transfer the call to. Instead it will just transfer to the extension number assigned to it. The end result is that my federated account will try and call that extension as if it was my own, rather than handing it back to the customer’s front end server for normalization.
The more I think about this situation, the more I believe it is by design, but nevertheless a potential bug.
I have tried to think about ways in which I can allow a federated user to escape the auto attendant back to the IVR. At first it seemed that potentially what if we UM enabled the IVR SIP AD Object? That was soon discounted as the object is hidden in the RTC Service / Application Contacts OU of the AD Configuration partition, and finding it, well thats no easy task! Plus, even if I was able to enable it for UM I don’t know what the implications of doing that would be.
The other thought I had was to change the extension length in the UM dial plan to 11 digits so that I could enter the full DDI of the IVR as the operator extension. However, that would mean a whole bunch of changes to Exchange UM mailboxes and Skype for Business configurations for users. In addition, the dial by extension feature of the auto attendant would be surplus to requirements because the caller would need to know the full DDI of the user to call. If you knew that, then you’d just call them direct!
Logically I think it would work in this case and get around the problem. However, in the way in which federated calls appear to be handled would mean that transferring back to the IVR from the AA would turn the federated call into a PSTN call. This means that the federated partner must have enterprise voice enabled for a start, and also they are now paying for what otherwise would be a free internet call if the transfer was handled properly.
In summary there is no easy solution to this problem. In reality as long as the PSTN and internal methods work as intended I doubt that anyone would actually come across this as a fundamental requirement. But on the off chance that you ever experience this, then hopefully I have explained the reasons behind why it doesn’t work.