Team Dial Plans not working in Teams Client

Copper Contributor

Hi All,

 

We are in the process of setting up a pilot for Teams Direct Routing.

Direct route is working fine and all is working when using the default Service Country plan for Belgium.

 

I have created a new dialplan to also include extension dialing and to make the step towards Teams Phone System smaller. The problem is that this dialplan is not working in the Teams Client, though the Get-CsEffectiveTenantDialPlan -Identity xxx@yyy.com command tells me that the dial plan is correctly applied to the user.

 

It is not client related, as I have the same issue on my Audiocodes C450HD phone and my Teams App on my mobile.

 

Any ideas? 

12 Replies

Hi,

 

Can you send an example of the Dial Plan that doesn't work? Do you have any other custom Dial Plans that does work or can you create a new simple one and test that one. It could be something wrong with the DP you created.

@Linus Cansby 

This is the first dialplan we have created.

This what I have:


NormalizationRules : {Description=BE-Service;Pattern=^\+?(1\d{2,3}|116\d{3})$;Translation=1200$1;Name=BE-Service;IsInternalExtension=False, Description=BE-Extensions;Pattern=^(\d{3})$;Translation=3201$1;Name=BE-Extensions;IsInternalExtension=False}
ExternalAccessPrefix : 0
OptimizeDeviceDialing : False

 

Should be straight forward. I have done a test in PS and this works:

PS C:\Users\[]> Get-CsEffectiveTenantDialPlan -Identity xxx@yyy.com | Test-CsEffectiveTenantDialPlan -DialedNumber 112


TranslatedNumber : 1200112
MatchingRule : Description=BE-Service;Pattern=^\+?(1\d{2,3}|116\d{3})$;Translation=1200$1;Name=BE-Service;IsInternalExtension=False

 

Hi,

 

Sorry for a late answer. The Translation should be a E.164 number, ex: Translation=+3201$1. If not and you dial 123 will end up calling +323201123.

 

I see that you have a ExternalAccessPrefix, is that intentional? 

 

If you from your client dials 300 what happens? 

 

Hello,

I would like to continue this thread because I currently have the same issue.

As the person described before me the rule seems to work at least when checking with Powershell.

 

When I actually try to call lets say 499, the number changes in Teams to just +43 499

 

And not to the number that I have set with the rule.

 

I hope it is okay to continue this thread because I have the same question :)

 

BrS

@nirispa So, I guess you are located in Austria. So the normalization for Austria kicks in. The number will always be in E164 format when it leaves Teams. So your normalisation rule have to do that. 

@Linus Cansby 

 

This is correct.

My normalization rule should add +43XXXXX before the number if it is a 3 Digit extension.

 

So it should've been+43XXXXX499 and not  +43499 which it is, so there is something wrong here.

 

I don't have a dial plan besides the global default one.

 

BrS

@nirispa Did you get this solved? I am stuck with exactly the same issue. Using PowerShell and checking the policy for the User, everything works perfectly fine. But in the Teams Client, it does not. I even waited for 24 hours now, just in case it takes time for the Teams Client to pick up the policies. No change...

 

A small edit: When looking at the Dial Plan via PowerShell I see 3 additional normalization rules on that User which I can not see anywhere in the Admin interface. Are there additional normalization rules on a tenant level maybe which are causing our problems?

Hello @rbuedi,

 

yes I do still have this issue, Microsoft couldn't help me so far.

I hae also found the "additional" Normalization rules, those are provided automatically and depend on your "Country" settings in Office365. So this is the "Service Country" dial plan.


More about dial plans:

https://blog.kloud.com.au/2019/09/19/inheritance-in-office-365-tenant-dial-plans/

 

I'm still trying to find a solution and I will have a meeting soon where I might get this solved and will share the solution here :)

BrS

 

Hello @nirispa,

 

this is super helpful. Thank you very much for the link. Now I know that those 3 rules are there by default and this should not be the root of my problem (although I checked the regex in those rules and they did not seem to interfere with mine or create the outcome I am seeing here).

 

I´d be happy if you share your results, no matter how they look. I was tempted to also create a ticket, but this is still an option if yours does not lead to a positive result :)

 

Hello @rbuedi,

 

so the External Consultant who has GREAT knowledge about the SBC and SIP told me that I did everything right with the Dial Plan, he also doesn't know what exactly is going wrong here... but he has also told me that MS is not his strength and gave me the name of someone else to contact.

For now, we have made rules on the SBC (Audiocodes Mediant VE hosted in Azure) to translate the rules and so on but I think this is not the way to go because it is to much manual work... so I will do this now with the SBC but also will keep trying to find a solution for the Cloud Phone System (Teams) to do this.

I will keep you in the loop :)

 

BrS

@rbuedi 

Solution Found!

 

Hello,

 

I had more calls in the past Months/Weeks and Yesterday the solution was delivered to me by the Office 365 Premier Support. It's kinda sad that the quality of the default Office couldn't solve this issue within 2 tickets and multiple weeks of time but the "premier" support did it in one day...

 

So the Dial plan was assigned to early, you may ask what does this mean?

Well after creating it, wait 24-48 Hours and then assign it, assigning it after creating it, and waiting 24-48 Hours doesn't work.

 

Kinda annoying that this is NOWHERE in the official Doc:
https://docs.microsoft.com/en-us/microsoftteams/create-and-manage-dial-plans

@nirispa Service Country dial plan turned out to be the keyword.

 

https://docs.microsoft.com/en-us/microsoftteams/what-are-dial-plans tells us that Teams would add your country code no matter what. You can just improve this, but they want all numbers to start with your location country.

 

The people who designed this did not seem to come across their own use case - dialing both PSTN and PBX destinations via Direct Routing. https://docs.microsoft.com/en-us/microsoftteams/cloud-voice-landing-page (Phone System with own PSTN carrier with Direct Routing)