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. 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.

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”.

Direct Trunk Select?

Herein “DTS” is an old PABX term I’m reviving in the age of SfB and Teams.

Back before we used letters to address things (whether they be an “-identity” or a SIP Address) it was all numeric. 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. From any (suitably enabled) phone you could dial maybe a feature access code, then a trunk access code, then some destination digits. This meant you could easily override LCR and put the call on a given path and confirm the results are as expected.

In a meshed network of PABXs you could bounce from one to another until your call fell into a hole, which told you which link (or PABX!) was dead. I didn’t realise it then, but we were doing what tracert would later do when testing an IP network: progressively take one step further towards your destination until it fails.

DTS in SfB

To do all of this in Skype for Business I use a currently spare country code to serve as my “access code”: +83 to the rescue! After that I designate a 1- or 2-digit code to indicate the SBC I want to target, and anything beyond that is deemed dialled digits. We wrap the whole thing in a PstnUsage, create some specific routes (one per SBC), then add the new Usage to the applicable Voice Policies.

Here’s all you need to add this to SfB. In this example I’ve gone with a 2-digit SBC identifier and 4 SBCs:

Set-CsPstnUsage –Identity global –Usage @{Add='SBC-TEST'}
New-CSVoiceRoute -Name 'SBC-TEST-sbc01' -Priority 0 -PSTNUsages @{Add="SBC-TEST"} -PSTNGatewayList @{add="sbc01.contoso.com"} -NumberPattern '^\+8301'
New-CSVoiceRoute -Name 'SBC-TEST-sbc02' -Priority 0 -PSTNUsages @{Add="SBC-TEST"} -PSTNGatewayList @{add="sbc02.contoso.com"} -NumberPattern '^\+8302'
New-CSVoiceRoute -Name 'SBC-TEST-sbc03' -Priority 0 -PSTNUsages @{Add="SBC-TEST"} -PSTNGatewayList @{add="sbc03.contoso.com"} -NumberPattern '^\+8303'
New-CSVoiceRoute -Name 'SBC-TEST-sbc04' -Priority 0 -PSTNUsages @{Add="SBC-TEST"} -PSTNGatewayList @{add="sbc04.contoso.com"} -NumberPattern '^\+8304'

In a multinational SfB deployment you might want to only add the PstnUsage to “your” in-country voice policies (demarcation, billing accountability and all that) but for a smaller in-country deployment you’ll probably be inclined to add it to all voice policies. BEWARE here though: make sure you exclude any internal-only VP’s that are perhaps used by courtesy phones, or other restrictive ones (i.e. that limit the user to only local calls), otherwise you’re adding a potential weak-spot your users may exploit.

Set-CsVoicePolicy –identity <varies> -PSTNUsages @{Add=’SBC-TEST'}

The final step to this is to add a rule to your SBC that converts your dummy country code back to your own, or something that won’t disrupt the flow. I usually create a rule just like this one and move it to the very top of the “SfB to Carrier” Transformation Table in each SBC:

Want to do more?

Why not use one of the identifying digits to suppress CallerID? Using the 2-digit identifier setup above with less than 10 SBCs lets you use the leading digit as a CLID Toggle. Dial “+8301nnnn…” to place the call with your CallerID, or dial “+8311nnnn…” to suppress it! (Careful though – you might need to tweak the SfB route’s NumberPattern if you get adventurous here).

Alternatively you can hard-code ANY test changes into the Transformation Table, but provided the Input Field Value is a Called Number of “+83\d\d”, the only calls that will be affected are your test calls. (That’s the disabled rule in the example above).

The beauty of this is that it can all happily coexist with your normal outbound routing – and of course while I’ve shown Sonus examples here, the same applies regardless of SBC vendor.

It’s not working?

Ahh, OK, I’m used to this one. I’ve encountered a couple of problems with this in practice.

The weird one steadfastly refused to follow the new routing rules: my calls either failed or went out the wrong SBC. I needed to restart the Mediation service on my Front-Ends before that deployment started to behave! This “fix” shouldn’t be your first line of defence if the deployment’s in production, but if it’s still in build it’s a more viable proposition.

If you ever find your test calls succeed but go out the wrong SBC, you might find they’re going to the correct one but it’s failing, and then SfB is sending them to another. Here it’s LCR / OBR that’s catching you out: you probably have a Voice Policy that will let you dial International, and it’s following the generic international Usage after the test one fails. The fix here is to block “+83” in the overseas calling route:

Hopefully those are the worst you’ll encounter.

Publication History

4th April 2018: This is the initial post.

 
– G.