If you have multiple SBCs (and trunks) in your Direct Routing deployment, you may have a scenario where a call comes in one trunk and then is automatically redirected out a different trunk by an Auto Attendant or Call Queue.

This could be because the destination is in a different country or rate center and you want to avoid long distance charges. I’ve also seen this in scenarios where a call comes in from the PSTN but then needs to be forwarded out a different trunk to a PBX or contact center, typically with an extension or private number that can be routed via the PSTN.

Resource Accounts that are under the hood of call queues and auto attendants need to have a voice routing policy assigned to them in order to send calls out a direct routing trunk. If that voice routing policy contains the SBC that was used for the inbound call, that SBC will automatically be selected for the outbound call, regardless of any priorities that you configure. If everything is configured properly, a REFER message will have the SBC (or something further upstream!) handle the forward and remove Teams from this loop.

However, if you need the call that came in via the first SBC to egress via the second SBC, you will need to create a voice routing policy that uses the second SBC and does NOT contain the first SBC. This voice routing policy gets assigned to the resource account for the call queue or auto attendant that is doing the forwarding.

If you are in a scenario where you have an auto attendant that is doing forwarding to numbers that must be reached via both of the SBCs, you will need to have one of the SBCs involved, or you’ll need configure the SBCs to route between each other and have Teams configured for direct routing to only the main SBC. Ideally, this would be your configuration anyway – Teams is not an SBC or session manager and should only be used as a last (hopefully temporary!) resort for oddball routing scenarios like this.

Failing that approach, you may be able to have the auto attendant or call forward to a Teams user and have that user set to call forward via the second SBC. You will need to test this, it’s entirely possible that there is/was something in my lab configuration and/or Teams call routing when I configured this, that does not apply to your scenario.