

This meant you could easily override LCR and put the call on a given path and confirm the results are as expected. From any (suitably enabled) phone you could dial maybe a feature access code, then a trunk access code, then some destination digits.


Each group of “lines” or trunks, perhaps called a “route” or a “trunk group” had maybe one or both of a numeric identifier, or a numeric access code (an “ACOD”) we could use to select it. Herein “DTS” is an old PABX term I’m reviving in the age of SfB and Teams.īack before we used letters to address things (whether they be an “-identity” or a SIP Address) it was all numeric. If your SBCs are in different states or countries you can usually take advantage of the Least Cost Routing (LCR) you’ve built into the deployment to achieve this – but what if they’re across town from each other in the same calling zone, or butting up against each other in the same rack in a load-sharing config? Enter “Direct Trunk Select”. By being able to directly focus my outgoing calls on just one SBC I can confirm all sorts of things: that it’s talking to SfB OK, its carrier connection is working correctly, it’s sending the expected CallerID outbound to the PSTN, it’s handing calls from “unknown” calling numbers (foreign to the services attached to the SBC)… It’s also helpful if you want to test calls *in* to a different SBC, and you don’t want your outgoing call to muddy the logging captures on the SBC under test. At about the same time any given Skype for Business deployment gains its second PSTN gateway / Session Border Controller, the old diagnostician in me wants a means to be able to directly send calls to each one individually.
