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
Hi. We tested it and it worked, but with a limitation.
When adding the second PSTN usage to the policy, if the Primary SBC was alive, but no routes were available to carry the call onward to the PSTN, the SIP messaging is sent back to MS PBX from the Primary SBC to try the second PSTN Usage and SBC. In this scenario, the fallback worked and the call routed over the second SBC.
However if the primary SBC is not responding whatsoever. I.E. is completely offline, the fail over does not occur. MSPBX simply tries the primary PSTN usage forever.
This was tested after 30 minutes and signing in and out. This proves the VRP is able to fail over to a backup usage upon receiving a 'no route available' or similar message back from the primary SBC, but does not work when the primary does not respond at all.
Is this a bug, limitation or something that could be resolved by further configuration?
There are several ways in which outbound routing will attempt to find another path due to SBC "outage":
- Sip Options Failure
- 10 second 18X timer
- SIP Failover Response Code
During your testing, did you see the SBC reported as offline in the Admin Center (Voice>Direct Routing>SBCs)? If the SBC was truly offline (from the perspective of Microsoft), you should see the TLS connectivity status and SIP options status showing "Inactive" and "Warning".
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-health-dashboard
If the outbound routing re-route is working with a SIP Response Code (this was your scenario where there was no trunk available from the PSTN), it should work in scenario where the entire SBC is "offline".
- Make sure the -SendSipOptions and -FailoverTimeSeconds parameters are enabled on your CsOnlinePstnGateway object for your SBCs.
- https://docs.microsoft.com/en-us/powershell/module/skype/set-csonlinepstngateway?view=skype-ps
- Make sure you are using separate and unique FQDNs/IPs for each of your SBCs. You cannot share a single FQDN/IP across multiple SBCs in geographically disperse data centers.
- https://docs.microsoft.com/en-us/microsoftteams/direct-routing-trunk-failover-on-outbound-call
- https://docs.microsoft.com/en-us/microsoftteams/direct-routing-monitor-and-troubleshoot#monitoring-availability-of-session-border-controllers-using-session-initiation-protocol-sip-options-messages
- Make sure your SBC is truly offline and has zero alternative Layer-3 network routes to reach M365. If your SBC is multi-homed (which it should be if it is deployed on-premises), you need to make sure that Options requests aren't somehow routing out another NIC to M365, and making it look "up" when it should be down.
- Try disabling the SBC in Direct Routing through the -Enabled $False param instead of manipulating the SBC in the data center.
Would strongly suggest opening an M365 support incident and/or involve a Ribbon partner to troubleshoot further. Something tells me you're still missing configuration, either on the SBC or within Direct Routing.