Forum Discussion
Phone System Administrator Accounts
Re #1 - Not really. There are RBAC roles which provide limited configuration capabilities based on role membership, but as far as I know, a single RBAC role does not support scoping of those permissions to a group of users (such as a remote office location). It's all or none.
https://docs.microsoft.com/en-us/MicrosoftTeams/using-admin-roles
Re #2 - Once SBCs are input into Direct Routing they become available to be used globally, but usage in Outbound Routing is not active until someone adds the SBC/Gateway into the proper routing configuration. From what I know, if you have a user that is able to manipulate the Voice Routing configuration via RBAC, that applies to all configuration in Direct Routing. Again, all or none.
Re VoiceRoutingPolicy - No. Users can only be assigned a single VoiceRoutingPolicy. That is why it is important to include all potential PSTN usages and voice routes (including class-of-service restrictions and primary/alternate routes for SBC failover) in that single usage.
Re External Access Prefix (9 prefix) - This is supported. However, do not normalize the number such that the 9 appears in the dialed digits. Configuration should support allowing users to continue that legacy-PBX-trunk-habit, but proper E.164 routing configurations don't include 9+15555555555 as the normalized number the client dials. Proper configurations always stick to E.164-proper for any dialed number (+15555555555) and then you add/subtract digits as required on the Direct Routing trunk via CsTeamsTranslationRules or on your SBCs directly. It's a very common attempted shortcut to not do this, but trust me, it makes voice routing (especially global) so much easier if you stick to proper E.164. This advice has been true for a long time, even all the way back to OCS/Lync/SFB.
https://docs.microsoft.com/en-us/powershell/module/skype/new-csteamstranslationrule?view=skype-ps
https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Fvideo.ch9.ms%2Fsessions%2Flync%2F2014%2FBEST301_Lasko.pptx
Great point on the 9 + dialing. When you say, "do not normalize" 9 dialing, do you mean we should have the E.164 digit strings explicitly defined but also have a 9 + option to catch those times when users dial that way? Is the expectation that users walking down the street in London or in the office using Teams on their mobile device or workstation should always dial the full E.164 number to call a local business, as in +44 XXXXXXXXXX?
On the VoiceRoutingPolicy, that's good to know. This could lead to thousands of unique VoiceRoutingPolicy configurations that would likely be a heavy lift up front with minimal ongoing maintenance as changes to privileges/restriction come up. Is that your experience? I can see that the naming convention must be important to have established at the beginning and strictly adhered to.
Thank you,
Re Dialing:
Your Dial Plans will have normalization rules that outline dialing habits for each of your locales. Normalization rules can be structured such that you could support if a user dials 9, then 1, then 10 digits for US NANPA. Or perhaps they only dial 1, then 10 digits. Or perhaps they only dial 7 digits where available for local calls. Or maybe they fully dial the E.164 number (after all, most cell phones support this today). What types of dialing habits will depend on country, city, whether you need short-digit extension, etc. Effectively you can support any number of dialing habits but the end result of all those rules should always be an E.164 number. In your example of a London number, no they do not have to dial E.164 - you could have normalization rules set up to allow 020 + 3XXXXXXX and it gets turned into +44 20 3XXXXXXX.
Re VoiceRouting:
Correct. The bulk of your effort is the planning and design of all the different Locales, Class of Services and Various Routes your calls need to take. You can choose to implement this logic directly within Teams (in the form of voice routing policies, pstn usages, and voice routes), or perhaps look at a solution from your Direct Routing SBC vendor. The SBC solutions offer capabilities around AD lookups or advanced dial plan functionality that may negate the need to have the control within Teams Routing configurations.