Nov 05 2019 02:59 AM
Nov 05 2019 02:59 AM
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 sbc.operator.com.
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 customerA-SBC1.sbc.operator.com (sbc 1)
A trunk will be registered in the customerA tenant to connect to customerA-SBC2.sbc.operator.com (sbc 2)
and repeated for every customer. I have already purchased a wildcard cert *.sbc.operator.com
However, reading https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-sbc-multiple-tenants 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 sbc1.operator.com and sbc2..operator.com
carrier tenant will be registered to sbc1.operator.com sip trunk for sbc 1
carrier tenant will be registered to sbc2.operator.com sip trunk for sbc 2
FQDNs for customerA will be :
Dec 13 2019 09:31 AM
I would also like to know this. How is it possible that this is still unanswered 6 months later
May 21 2020 12:16 PM
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 customers.company.com. 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 cust1.customer.company.com
2) Activated the subdomain as explained on the document link above
3) Created a DNS entry for cust1.customer.company.com to point to the public ip of the SBC
4) on the customer tenant using the teams admin GUI we added an SBC called cust1.customer.company.com then we created a voice route and associated fqdn cust1.customer.company.com
5) Enabled user on the customer tenant
Are we missing a step at this point? Any help would be greatly appreciated
Jul 07 2020 07:29 AM
Jul 07 2020 07:37 AMSolution
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.
Jul 07 2020 07:46 AM
Sorry for delayed response here and hope you have resolved this. If not, please respond and let me know.
Summary steps for carrier model.
Jul 07 2020 09:01 AM
Jul 07 2020 09:38 AM
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 *.contoso.com would cover: anyname.contoso.com.
Wildcard of *.sbc1.contoso.com would cover: anyname.sbc1.contoso.com.
Jul 07 2020 01:11 PM
Jul 08 2020 11:42 AM
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.
Jul 09 2020 09:43 AM
Jul 09 2020 12:19 PM
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?
Jul 29 2020 05:35 PM
Aug 11 2020 06:17 AM
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.
Aug 12 2020 11:25 PM
Aug 12 2020 11:43 PM
Jul 06 2021 02:11 AM
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 *.customer1.ourdomain.com and Microsoft would not accept this for some reason so reverted to getting a cert for each SBC.