Forum Discussion
Direct Routing - routing outbound calls based on SBC rather than dialled number...
solidpro Each of your SBCs needs its own PSTN Usage and Voice Route, and each of your PSTN usages must be ordered in your desired routing manner within your voice policies. You cannot combine all SBCs into a single PSTN usage and single voice route within a single voice policy, otherwise you will have the scenario you are experiencing.
The voice policy defines the Class of Service your users are allowed to call & outbound routing paths/failover. Your PSTN Usage and Voice Routes work to define number types and class of service, plus egress routing paths (including ordered failover) to your PSTN gateways. Proper design gets you a configuration that looks similar to below
AllEnterprise-NANPA (Voice Policy):
PSTN Usage Voice Route PSTN Gateway AllEnterprise-NANPA-NYDCEgress AllEnterprise-NANPA-NYDCEgress sbc1.contoso.com AllEnterprise-NANPA-TXDCEgress AllEnterprise-NANPA-TXDCEgress sbc2.contoso.com AllEnterprise-NANPA-CADCEgress AllEnterprise-NANPA-CADCEgress sbc3.contoso.com Outbound routing in the Teams/Skype world is firstly based of dialed digits, so your voice routes need to have some level of matching of DNIS for the call to work. If you are using wildcard (.*) then simply having unique voice policies for your specific use cases, along with ordered PSTN Usages and Voice Routes will get you what you want.
All that being said, I am not a fan of wildcard routes and I generally never advise customers to deploy in that manner. It's the "easiest method" but it also does not allow for any separation of class of service for calls and potentially allows calls to number types which you do not want (9XX, for instance). You should also be normalizing all numbers into E.164 format in your dial plans and structuring voice routing configuration based on E.164 concepts. If you don't need to break out things like local dialing restrictions, or mobile dialing restrictions, or premium number dialing restrictions, then you would not need a wildly complex routing configuration. Regardless, I strongly suggest you have all configuration utilizing E.164 from dial plans, to voice routes, to trunk translations, as that is the way a proper design should be.
Very few items have changed since the Lync days, as the concepts are largely still the same for Teams (basically brought forward). If you need to gain a better understanding, check out these videos or get in contact with a voice partner that can assist you.
https://channel9.msdn.com/Events/Lync-Conference/Lync-Conference-2014/BEST301
https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Fvideo.ch9.ms%2Fsessions%2Fteched%2Feu%2F2013%2FOUC-B401.pptx
Examples First:
If you want both SBCs to be utilized for calls within a single "Class of Service", you'd have a voice policy that has a single PSTN Usage assigned:
| PSTN Usage | Voice Route | PSTN Gateway |
| AllEnterprise-NANPA-USDCEgress | AllEnterprise-NANPA-USDCEgress | sbc1.contoso.com sbc2.contoso.com |
In this instance, Outbound Routing should Round-Robin the calls to each PSTN Gateway assigned to the Voice Route. Effectively no ordering here and operates more of a HA pair for all SBCs in the Voice Route.
If you want ordered failover for calls within a single "Class of Service", you'd have a voice policy that has two PSTN Usage assigned:
| PSTN Usage | Voice Route | PSTN Gateway |
| AllEnterprise-NANPA-NYDCEgress | AllEnterprise-NANPA-NYDCEgress | sbc1.contoso.com |
| AllEnterprise-NANPA-WADCEgress | AllEnterprise-NANPA-WADCEgress | sbc2.contoso.com |
In this instance, Outbound Routing will NEVER attempt to route to the second PSTN usage unless the first path is deemed "Offline". This could be SIP OPTIONS pings failing or certain SIP 5XX response failures, but there is explicit ordering here that will always use the first path and only use that path until a failure occurs.
Testing recommendations:
- After any change is made in the Admin Center or through Voice Routing, you need to wait at least 15 minutes. There are notorious replication delays within M365 so do not make a change and then immediately make a call - chances are your changes are not yet effective within the service.
- After your 15 minute waiting period, you need to sign-out and sign-in within the Teams app. The app itself uses caching to handle offline scenarios and improve general performance, so do not make a change and then immediately make a call - chances are your changes are not yet effective on the client.
SBC Notes:
- The SIP failure an SBC will provide when it cannot route a call to an upstream peer (either SIP or T1/E1 related) varies with each vendor and reason for upstream failure. If a call from Teams reaches the SBC and the SBC has nowhere to send it, you must look at the SIP Call Ladder post-call to determine what failure is being sent back to Teams. If that failure is not a 5XX level failure, Outbound Routing in Teams may not attempt to find another route. This may require SIP manipulations on the SBC to "fix".
- Make sure you are using an approved SBC vendor and that you are running at least the minimum firmware https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-border-controllers. Anything outside of that list is just futility and is a waste of your time.
Your desire for ordered SBC usage is absolutely possible - The service supports it and we've deployed as such many, many times.
Thanks again.
We did exactly as you suggested - "voice policy that has two PSTN Usage" and virtually the same as you described, and it never failed over to the other one. Although the difference was we didn't wait at least 15 minutes.... Maybe it's best to try again....
"The SIP failure an SBC will provide when it cannot route a call " - in our testing we take the primary SBC out of service altogether - the SBC is entirely offline and there is no response to it's FQDN whatsoever - so in this case there would not be a response whatsoever from the SBC to route the call. Specifically this testing is not proving that the SBC sends the correct information back that no route is available or for the SBC to find alternate onward routes, it's for MS Phone System to seek out a different SBC when making an outbound call when the primary is not available whatsoever...
These are Ribbon SBCs so they definitely qualify...