Forum Discussion
AA Direct routing - 404 Not Found
Hi,
I've an issue with Teams and Auto Attendant (AA).
I've created an resource account, assigned a virtual phone system license to it (the free one) and assigned an available phone number to that account which is available on my local SIP trunk via SBC.
After that I assigned that RA to my AA.
When I call the AA number , this isn't working. In My SBC logs the calls get disconnected with an error 404 NOT FOUND - UNASSIGNED NUMBER. It seems that MS isn't aware of my on prem number.
For testing purposes I removed the number for my RA and assigned it directly to a user, and this is working as expected..
After Googling some time it seems that this is a 'know' issue, where time will fix the issue. At the moment i'm waiting for more than 5 days, and it is still not working.. Also created an case with MS, but they can't get it fixed. Now they are telling me that the issue is that my calling numbers aren't formatted in E.164 format.. Could be, but why is it than working when I assign that number to a user directly..
I added some manipulation to my sbc config in a way that my numbers are E.164 compliant, but no luck.
Does anyone have any idea how to get this fixed so that we can migrate our numbers to DR?
Brg,
I have seen so many entries in different forums with no actual fix, so hopefully adding this helps someone else.
In this case, I replicated and E.164 format was the issue.
We could see this in SIP trace. The FROM number was always formatted properly but the TO was not ( even when coming from Teams client).
- When you were calling a number to a user - this didn't matter, Teams seemed to normalize this internally and connected the call.
- When you called a resource account number- this would fail and Teams would return a 404 Unassigned number.
We had to add inbound manipulation (Audio Codes) for our resource account numbers to add +1 so it was a proper E.164 Number. This worked immediately.
We have the same issue. A few weeks ago, we created with SkypeOnlineConnector (PowerShell-Module)
a new CsOnlineApplicationInstance with the following commands:
New-CsOnlineApplicationInstance -UserPrincipalName aara@contoso.com -ApplicationId “11cd3e2e-fccb-42ad-ad00-878b93575e07" -DisplayName "Auto Attendant Resource Account"
Set-CsOnlineApplicationInstance -Identity aara@contoso.com -OnpremPhoneNumber +49xxxxxxxxxx
and it works like a charme.
Yesterday we removed that already working Resource Account and tried to create a new one, but in the meantime it's not possible on this way anymore...we got this error-Message:
WARNING: Attention: On-premises domain must use on-premises cmdlet. Please copy and paste the below commands and run them with appropriate admin privileges in your on-premises Skype for Business environment.
WARNING: New-CsHybridApplicationEndpoint -ApplicationId 11cd3e2e-fccb-42ad-ad00-878b93575e07 -DisplayName "Auto Attendant Resource Account" -SipAddress aara@contoso.com -OU [A_VALID_OU]
This cmdlet is for online domain only. Please run corresponding on-premises cmdlets for on-premises domain.
+ CategoryInfo : InvalidOperation: (:) [New-CsOnlineApplicationInstance], InvalidOperationException
+ FullyQualifiedErrorId : Microsoft.Rtc.Management.Hosted.PlatformService.ApplicationInstance.NewCsOnlineApplicationInstanceCmdlet
+ PSComputerName : admin0e.online.lync.com
So we created it on our On-premise Skype for Business Server like recommended and it works, too.
BUT!
We changed to Microsoft Teams with direct Routing, because we want to switch off the Skype for Business server!
So, we thought it will be a good idea for the future (without any Skype for Business Server) to create all Objects we will need Online at Office 365 only.
So, we tried again Online with SkypeOnlineConnector the following commands:
New-CsOnlineApplicationInstance -UserPrincipalName aara@contoso.onmicrosoft.com -ApplicationId “11cd3e2e-fccb-42ad-ad00-878b93575e07" -DisplayName "Auto Attendant Resource Account"
Set-CsOnlineApplicationInstance -Identity aara@contoso.onmicrosoft.com -OnpremPhoneNumber +49xxxxxxxxxx
but this time with a not synchronized domain: @contose.onmicrosoft.com
Unfortunately, we get the 404 Error on the SBC like you described before 😞
Regards,
Klaus
- Just a little Update. We did that around 24 hours ago. But in the meantime I followed the link from the reply by bibawa (replied to Linus Cansby 08-28-2019 12:26 PM) and there were are People, whom was waiting for 72 hours. So, I keep hoping 🙂
bibawa I had a similar problem when started to assign DR numbers to resource accounts for QC/AA. I had to start a support case with Microsoft and it took them a while to escalate the ticket to 2nd line that did a "synchronisation" to get it to work.
LinusCansby Yeah I also opened a case for one week now and also referenced them to this blog https://ucstatus.com/2019/05/14/how-to-assign-a-direct-routing-number-to-an-auto-attendant-or-call-queue-in-microsoft-teams-phone-system/
IN the comments you see a lot of people with the same 404 not found error.. I also asked them to run a synchronisation but it seems that guys can't escalate this case..
They now tell us that the numbers aren't E.164 normalised blabla.. But it is working when you assign the number directly to a user so this has nothing to do with sbc/number normalisation..
brg,
I think your only hope is to get them to escalate the ticket. There should be a mail address to a support manager in the emails that you get from Microsoft Support, add that person to your conversations.
