Direct Routing SBC failover planning in carrier hosted setup (derived trunk model)

Copper Contributor



I am trying to setup Teams Direct Routing in our network using the hosted carrier model using two SBCs which are in active/active setup for outbound and inbound calls. I haven't begun any configuration on the O365 part but have completed the SBC side config.

Originally I was planning on using the following using an example base carrier domain
Using the following FQDNS to register an example customer A in a customer tenant on 2 SBCs.

A trunk will be registered in the customerA tenant to connect to (sbc 1)
A trunk will be registered in the customerA tenant to connect to (sbc 2)

and repeated for every customer. I have already purchased a wildcard cert *


However, reading this week, I see there is a new architecture where SIP trunks are only registered to the carrier tenant and not the customer tenants (as before), which makes sense since only two trunks need be created in total. Trunks in customer tenants do not need to be created and are simply derived from the two carrier trunk associations in the voice routing policy.

I am trying to work out how I can accomplish this.

Do I now need two base domains,etc ?

i.e and

wild certs:

carrier tenant will be registered to sip trunk for sbc 1
carrier tenant will be registered to sip trunk for sbc 2


FQDNs for customerA will be :



19 Replies

I would also like to know this. How is it possible that this is still unanswered 6 months later

@Carolyn Blanding (MS TEAMS) 


Hi We are also trying to setup Teams with Direct routing for the first time using the derived trunk model. so far we have a carrier trunk  which I will call Following the advice on the link  but we are stuck on this bullet point


In the customer tenant, the carrier need only to add the derived trunk FQDN to the voice routing policies of the users. There is no need to run New-CSOnlinePSTNGateway for a trunk.


To try and follow this We have done the following but the pstn calls are not working


1) Created a subdomain on the customer tenant called

2) Activated the subdomain as explained on the document link above

3) Created a DNS entry for to point to the public ip of the SBC

4) on the customer tenant using the teams admin GUI we added an SBC called then we created a voice route and associated  fqdn

5) Enabled user on the customer tenant


Are we missing  a step at this point? Any help would be greatly appreciated





The failover section does not cover it full I think and is missing things. 

The doc shows base domain of:

Yet for failover the domain has swapped to that of the customer:

The is no explanation of what is going on. Does the carrier domain stay the same, it would suggest not by that example? Do you need 2x carrier domains as & or a single Why is it now the customers domain, are derived trunks not used for failover and its back to the old method?
best response confirmed by ThereseSolimeno (Microsoft)

@Shihab Azimullah 


For hosting provider failover routing, the hosting provider will need to configure multiple PSTN gateways in their tenant. For example: 


This will require multiple wildcard san names to support each namespace. For example:

  • *
  • *

Each customer will be provide two FQDN's to be added to Tenant domain and a single user licensed for SfB Online in the namespace to create the domain in the service forest. For example:


Then a route will be created for each of these gateways. 



Sorry for delayed response here and hope you have resolved this. If not, please respond and let me know. 


Summary steps for carrier model. 

  • Carrier creates PSTN Online gateway in their tenant with namespace of For failover they would also create a 2nd one, e.g.
  • Carrier will create wildcard certificate with SAN names for each namespace, e.g. *, *
  • Carrier will create DNS records resolving to each of the gateway names
  • Carrier will provide customers with unique FQDNs, e.g.,
  • Customer adds FQDN name as tenant domain name and licenses one user for SfB Online Plan 2 in this domain namespace; e.g.,
  • Once domain namespace has been added to tenant service forest, customer adds route specifying SBC FQDN. If provided two FQDN's they will create two routes. 
Thanks for clearing this up. In regards to certificate why would * not work?



You're welcome. Working to fine tune docs as well. 


When defining a wildcard certificate, name spaces that are covered by the wildcard is just one level to the left. So wildcard of * would cover: 

Wildcard of * would cover: 



That makes sense. In regards to carrier tenant Domains we would add & ? In non failover base domain is but this is no longer valid?




These were all just examples. Let me try to make this simpler without specific names. 


Carrier Tenant Online PSTN Gateway(s), can be one or greater if failover is being handled by multiple FQDNs. 


Carrier certificate SAN names

  • *
  • *

Customer Tenant Domain Name and SBC named used in Route configuration


The pattern here is that the carrier PSTN Gateway is the base name for which customer names are derived. The customer names will be a single level child of the base domain. 


Hope that helps. 

Yes that does clarify thanks. This is how I set mine up. But unfortunately it doesn't work and I get 404 not found.

The other unfortunate thing is MS support team seem to have no idea how this should work. Also their SIP knowledge seems none existent at 1st line stages anyway. They are trying, but this makes me want to cry.

What I have done:

Carrier Tenant has these domains: (Default)

DNS entires exist for theses sbc's, I have an old test sbc on which is still working for inbound calls on carrier tenant for carrier users.

Powershell commands ran on carrier tenant:

New-CSOnlinePSTNGateway -FQDN -SIPSignalingport 5061 -MaxConcurrentSessions 50000 -ForwardCallHistory $true -Enabled $true

New-CSOnlinePSTNGateway -FQDN -SIPSignalingport 5061 -MaxConcurrentSessions 50000 -ForwardCallHistory $true -Enabled $true

In MS Team portal sbc's show and are active for TLS and Options

Customer tenant has these domains:

DNS entries exist for the domains point to my SBC’s.

Powershell commands ran on customer tenant:

Set-CsOnlinePstnUsage -Identity Global -Usage @{Add="UK"}

New-CSOnlineVoiceRoute -Identity "All" -NumberPattern "^\+44(\d{9,10})$" -OnlinePstnGatewayList,,-Priority 1 -OnlinePstnUsages "UK"

New-CSOnlineVoiceRoutingPolicy "UK" -OnlinePstnUsages "UK"

Grant-CsOnlineVoiceRoutingPolicy -Identity “” -PolicyName UK

Set-CsUser -Identity "" -OnPremLineURI tel:+441713325555 -EnterpriseVoiceEnabled $true -HostedVoiceMail $true

Below is an example of my invite obfuscating my ips. To this invite I get a 404 not found. In my carrier tenant for this sbc in direct routing I can see the call inbound attempts although no details of the calls they just show in the graph.

INVITE;user=phone SIP/2.0
Record-Route: <;transport=tls;r2=on;lr>
Record-Route: <sip:x.x.x.x:5060;r2=on;lr>
Via: SIP/2.0/TLS;branch=z9hG4bKf311.85766bf10fd192be4a966f1d2f5db163.0
Via: SIP/2.0/UDP x.x.x.x:5080;received=x.x.x.x;rport=5080;branch=z9hG4bKp5S81QXcvSaKa
Max-Forwards: 63
From: "+447842111700" <sip:+447842111700@x.x.x.x.x>;tag=DvrB7p3B4g4jK
To: <>
Call-ID: a85bb1c9-3ca0-1239-45ad-90b11c4c90db
CSeq: 22601531 INVITE
User-Agent: SIP Agent
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 1495
Contact: <;transport=tls>



Apologies about the snags you are hitting. Are you ok with sharing the case # that you have open so I can take a peek at the real details and potentially get you past your speed bump? 




Hi, Was there ever a solution to this issue?

Like others I have followed the steps and cannot get the derived trunks working and accepting calls.
I also had a support call with Microsoft yesterday and it was suggested to wait another 24 hours after creating the subdomain in the customers domain.



The above was resolved. Issue was that the FQDN on inbound invites to customer tenant had carrier SBC FQDN defined. Therefore, the lookup for matching user phone numbers was to the carrier tenant and returned a 404. 


The wildcard certificate to be applied on DR-SBC is * in your example. What about name? Does it need to be included in certificate too?
Thankyou for the reply.

Mine started working around 36 hours after configuration. So I guess even more patience is needed. Strange thing was I did another 2 setups within 20 minutes and they were OK to go after an hour. I have also completed another 3 and they took between 1 and a few hours.

@Carolyn Blanding (MS TEAMS) 

The use of wildcards is really not the best solution in my experience as it really doesn't provide any advantage over and above using a normal fqdn cert, and adds to the cost if purchasing them. 
We've chosen now to create a standard cert for each SBC, this keeps it simple.  

Also I'm sure we tried 

With the wildcard as * and Microsoft would not accept this for some reason so reverted to getting a cert for each SBC.


@sadwinuser  Failover is configured at SBC level and not in Teams, What you need to do is point the redundant SBC's at Teams Direct Routing with correspondent FQDN's 

We are getting ready to offer direct routing for our customers but first, we would like to deploy it on a couple of accounts in our organization. We have followed the steps as outlined in the above mentioned post by adding 2 additional base domains ( and along with 2 wildcard certs to match. We will then activate these 2 new base domains by creating 2 new test accounts: email address removed for privacy reasons and email address removed for privacy reasons. In order to get this to work on my account, I will need to add a Teams Calling Plan license (or equivalent) but will I need to change my UPN to match the FQDN of one of our SBCs? Or would it be better to simply use one of these 2 accounts with the proper UPNs and assign the appropriate licensing?

This brings up another question regarding licensing: I currently have Business Standard. What is the cheapest and easiest add-on license to make and receive calls from the PSTN - no need to call outside of Canada.