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 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.
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
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.
When we created Common Area Phones, however, No matter what we did, the Dial Plans were stuck on the default US one.
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.
But the users we were testing with were migrated from on-prem
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)
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.
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.
Hope this helps.