is there a way to assign direct routing phone numbers to Auto Attendants or Call Queues. That seems to be an obvious function but I have not found any documentation. It always refers to service numbers.

Hi,No, not yet but at Ignite Microsoft said that you will be able to use DR numbers for your AA, CQ and Dial-in in the future. I didn't hear any release date but my understanding is that they are using it internally at Microsoft.

Sorry, for the late reply. I think we need to settle with call forwards at the SBC level for now. Migrating is not possible because it is a closed number block and there are still analog devices needed.

Direct Routing customers requirement for Auto Attendant is growing daily and we are getting more and more questions as to WHEN it will be available. Nothing on the MSFT roadmap seems to speak to DR AA.

Can anyone at MSFT provide an estimated GA date for this feature (and Call Queues while we are at it)? Thank You

Here are some 'work around' I have done for some clients. I have setup direct routing and used auto attendants and call queues in O365/SfB online.

You have a couple options, either a message manipulation on the SBC to rewrite the TO header on the SIP invite to a service number assigned in the cloud (this can be a number simply acquired thru microsoft) and routing to MS via DR.

A second option is to go to a dummy user that is configured to forward all calls to the AA/CQ number.

A third option is to have your carrier with the sip trunk setup call forwarding for that specific number to the Microsoft service numbers.

I agree, customers definitely need this functionality with Teams. Auto attendant and call queues are an important piece to replacing legacy phone systems and transitioning 100% to Microsoft Teams.

With that being said, it does appear to be on the road map to be able to assign local PSTN numbers to call queues here (under Microsoft Teams - Call Queues) -

I'm trying to determine whether or not Microsoft will charge minutes if I transform the called number on the SBC to be the Service Number. Technically it is not an inbound call to the number, so I would imagine not. However, I want to make sure before I start reserving service numbers. PSTN Hub does not appear to accept SIP URI for Call Routing unfortunately (Which would be the easiest "workaround", until On-Prem Line URIs are allowed on HG/AA).

I tried the support avenues and get confusion when I ask about Direct Routing and Transformations etc.

on the launched item for CQs is the following sentence which was added in December 2018 I think:

Phase 1 of Call Queues is now available for Teams. The work primarily focused on enabling the same set of features previously available to Skype for Business Online. Additional work is ongoing for support for phone number usage via Direct Routing and is expected next quarter.

This makes we wonder what the status is considering we are approaching the end of that next quarter.

@domienxylos: As long as you do not have submenu "Call Queue" and "Auto Attendant" in menu "Voice" in Teams portal, your tenant is not already migrated to the new CQ/AA. Migration of all tenants is ongoing. Just wait, until these two submenus are available and retry then.

When executing the 'Set-CsOnlineVoiceApplicationInstance' command I get the error 'The application instance does not have a valid license. I assigned the corresponding resource account an Enterprise E1 license with Phone System add-on.

@Remco van Noorloos I am getting the same problem you mention here, unable to assign a direct routing number to a new resource account in teams. The resource account is licensed with E3 and Phone System add-on.

Exactly the same problem with my tenant, resource account needs a direct dial number and has been licensed with E3 and phone and still the command to assign comes back with license invalid.Please Microsoft, sort it out !

I found either a solution or a workaround. Instead of using Set-CsOnlineVoiceApplicationInstance, use Set-CsOnlineApplicationInstance -Identity RA_ADDRESS -OnPremLineURI +1xxxxxxxxxx. This worked for me when the Set-CsOnlineVoiceApplicationInstance gave the licensing error.

@SSchumacher_C1 Did you run anything else on-premise (new-cshybridapplicationendpoint) or is your setup a pure online one? Because I was able to run the command but still Teams is replying with a SIP 404 Not Found.

Just want to add that I have had a response from the product group about this (via a really useful MVP guy - Thanks Matt..), this is what was said.

I believe there is an update for the docs to apply a Direct Routing number to the Resource account that should go out soon. The command should be: Set-CsOnlineApplicationInstance -Identity appinstance01@contoso.com -OnpremPhoneNumber tel:+14250000000

This is what is configured on my end. First object is a Call Queue which is using a service number and is working, the second object (testdirectrouting) is the number locally that should be terminiating on Teams.

And indeed no need to add the tel: because otherwise you get an error message stating that you need to include it :D (small bug i guess).

For others the error message you get when adding tel: . So even if the error says add tel: don't do it :)The input of parameter "tel:+3214xxxxxx" is not in a valid format. Please provide an input with an acceptable format <tel:>+[number]", e.g. tel:+18005551234 or +14251234567.

I have been working with microsoft support, and we have narrowed down that you need to use set-csonlineapplicationinstance (no voice word), and they say you have to wait 24 hours, however i have done this and waited 24 hours, some have started working, whilst others havent.

So I had the resource account already for some time. With the info found here I applied the phonenumber using the cmdlet without the voice part. Then I also created the onprem hybrid application that has now been synced for several hours. Up until now no success.

We may be a little bit more lucky that we are online only, but I am sure I did something else to get it working, I just can’t remember. Make sure you are using the command set-csonlineapplicationinstance and NOT set-csonlineVOICEapplucationinstance

Yes, it definitely took a good amount of time for the object to begin working to some extent. Supposedly working for CCE, but cannot say for certain.

We are attempting in SfB Hybrid mode, and appears the call is hitting the online application instance via the sip2.lgw.skype.com gateway. we are seeing an attempt to REFER by the resource object created, to a user(s) configured for all calls, (temporary), in the Auto Attendant.

At which point we receive a 486 ProxyCall is not in connected state. and a verbal message of "Sorry, I couldn't help, please call back..."

Call queue with cloud service number - works, including from VVX phone

Call queue with on prem number - Connects, stays connected, but no audio (either side)

Auto attendant with on prem number to queue - Connects, stays connected, but no audio - also, if we answer from a VVX phone, instead of soft client, it connects on the VVX side, but continue to hear music on hold on caller side.

I have a ticket open, but haven't heard back, after I provided detail.

@John Joseph agreed, those are some of the same issues I have seen with some of our clients when connecting Advanced Calling Features (AA, CQ) to Teams endpoints.

The case I am attempting is SfBO Hybrid with on-prem PSTn to CLoud Auto Attendant, just to see if it would deliver to SfBO endpoint and it seems it will not. I do acknowledge MSFT has stated it is not supported to any other endpoints other than Teams.

Having said that it was almost working, the number delivers to the Auto Attendant fine through the hybrid application endpoint and resource account pairing, just would never deliver to user endpoints. Guess they are still working on that.

@Joe Williams I have not tried an on prem PSTN number with CCE AA and CQ (sort of like hybrid) in a couple of months (so not with the new architecture), but back then it wasn't working. About a year or so ago, we did a bunch of testing with CCE using a SIP hand off (converting it to SIP at the SBC) and it mostly worked, but was inconsistent (sometimes it would fail) and it definitely isn't supported by Microsoft. It would be interesting to try a SIP hand off with Direct Routing, but since Microsoft says that on prem numbers are now supported as service numbers, we are putting our efforts there. I have had a ticket open (for almost a week now - first agent mysteriously disappeared and I was assigned a new agent on Monday) and am jumping through the hoops. I had to:

Prove that this is now a supported configuration (O365 support wasn't aware of the change)

Prove that my SBC is properly configured (they made me open a ticket with Ribbon and have them sign off that my SBC is properly configured, even though it is working for user DIDs, inbound and outbound).

Since I have now completed these items; today, they agreed to escalate my ticket and told me to expect to hear from the escalation team in 24 to 72 hours (depending on workload).

Interesting, definitely good information for the Direct Routing to Teams scenarios, appreciate that.

with the Hybrid we are not technically sending via Direct Routing, or directly from the SBC. we are routing through the skype for business on-prem environment, using the new cshybridappplicationendpoint objects, so a little bit different. In the end, for our client I think we are going to table this particular method and explore other avenues of setting this up, at this point.