Teams 3PIP phones getting the wrong Dial Plan?

By | January 23, 2021

Hey all, Welcome back. Today I have another interesting one.

I had a situation recently where a customer’s Polycom VVX phones that were signed into Teams, couldn’t successfully make calls unless they dialled numbers in E164 format. (You know, that weird “+61432500648” one)

Sounds like a classic case of a wrong Dial Plan, or so I thought!


Before we dive too deep into this one. It’s important to understand a few “behind the scenes” things of how Teams 3PIP works.

3PIP?

3PIP is short for “3rd Party IP Phone” and its Marketing Speak for a Skype Certified handset designed and built by anyone but Microsoft. Take, for example, the Polycom VVX series, the Yealink T4X series or the Legacy AudioCodes series.

Yealink handset running Skype firmware

This is different from a Lync/Skype Optimized handset. Which was built by a third party, with design requirements and software provided by Microsoft. These were known as “Lync Phone Edition” and included the Polycom CX series, HP 41xx series and Aastra 672x series

“Limited Exchange Connectivity” this…

They were terrible and need to die in a fire. But let’s not get into that.

What does this have to do with Teams?

Microsoft understands that customers have an investment in their existing handsets for Skype for Business, and as such let these phones continue to function after migrating to Teams using the”3PIP gateway for Teams”.

Thing is, this 3PIP gateway for Teams, is actually just Skype for Business Online, but with policies set that only 3PIP phones can sign in.

3PIP vs Teams Policies

When a Desktop, Mobile or Teams Phone client signs in, they are communicating directly with Teams using its APIs and thus downloading Teams policies.

When a 3PIP phone signs in, it registers using SIP and downloads its policies from Skype for Business Online.

These are usually synced between the two platforms without issue, so any Dial Plan you create in Teams, pops up in Skype Online (including Voice Routes for Direct Routing…..not sure what you could have used that for)

During our testing phase, we had tested 3PIP phones using our test accounts and the Dial Plans worked perfectly. They were handed down to the phone and the phone translated digits as expected.

The Issue

When we created Common Area Phones, however, No matter what we did, the Dial Plans were stuck on the default US one.

^011(\d+)[email protected]+$1|^((\+)?(\d+))(;)?(ext|extn|EXT|EXTN|x|X)(=)?(\d+)[email protected]$1;ext=$7|^1(\d+)[email protected]+1$1|^(\d{10})[email protected]+1$1|

The only difference, the Common Area Phone accounts were born in the cloud. Not migrated from On-Prem like all the other user accounts we had used for initial testing.

User attributes showing Dial Plan and Pure Cloud Status
Cloud Born User

But the users we were testing with were migrated from on-prem

User attributes showing Dial Plan and Hybrid Cloud Status
Migrated User

The Reason

The issue here is, as part of the customer’s previous setup for Skype for Business Hybrid. Their integrator had enabled Hybrid Dial Plans. (This is enabled by default when setting up Hybrid)

Get-CsTenantHybridConfiguration showing UseOnPremDialPlan is set to True

This means that Skype for Business Online (not Teams, remember) would typically honour any On-Prem Dial Plan that had been set when they migrated from on-prem into to the cloud.

The Fix

Fixing this was as simple as running the following cmdlet on their SFBO tenant

Set-CsTenantHybridConfiguration -UseOnPremDialPlan $False

Then, just waiting for replication and signing the phone in again.

Boom correct Dial Plan.

VVX Phone Status page showing the correct Dial Plan being applied

Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.