Officedocs-skypeforbusiness: How is failover supposed to work in a multitenant setup?

[lagerstedt]

In the example described in
https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-sbc-multiple-tenants
each customer has its own FQDN with the operator. Customer1 will
have customer1.customers.operator.com, customer2 will have
customer2.customers.operator.com and so forth.

The FQDN is added to the customer tenant and then the trunk is
configured. That's fine, but how are you supposed to do failover
in this setup?

The only description of failover that you have is here:

https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-trunk-failover-on-outbound-call

but that does not really cover multi tenant direct routing as it would require two FQDNs and to configure two separate
trunks in the customer tenant.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1cb0c2ef-6274-9167-ecc6-3695d7460a8d
• Version Independent ID: aacf7318-02fc-a1c3-369c-65e6936fdb3c
• Content: Configure a Session Border Controller for multiple tenants
• Content Source: Teams/direct-routing-sbc-multiple-tenants.md
• Service: msteams
• GitHub Login: @CarolynRowe
• Microsoft Alias: crowe

[scanum]

@lagerstedt Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

[j0rt3g4]

Hello @lagerstedt

On this example each customer has

• Customer1 will have customer1.customers.operator.com,
• customer2 will have customer2.customers.operator.com

So basically they are coming from the base domain that is "operator.com"
So it's sort of a DNS round-robin if root fails goes to the next and so far and so forth that's what I understand of those graphics.

[lagerstedt]

Hello @lagerstedt

On this example each customer has

• Customer1 will have customer1.customers.operator.com,
• customer2 will have customer2.customers.operator.com

So basically they are coming from the base domain that is "operator.com"
So it's sort of a DNS round-robin if root fails goes to the next and so far and so forth that's what I understand of those graphics.

I've not seen anything in the documentation that Teams supports dns based failover for an sbc. It support failover between different gateways but that's what I would like to avoid.

[j0rt3g4]

@lagerstedt that's what I would understand from the reading but... let's get the author to double-check what he has to say about this, Manuela please involve the author (@scanum )

[scanum]

@CarolynRowe Hi Carolyn! Could you please aid us on the next steps for solving this issue? Thanks!

[SerdarSoysal]

@NMuravlyannikov can you please review and comment?

[scanum]

@NMuravlyannikov Hi Nikolay, any updates on this? Thanks.

[scanum]

@NMuravlyannikov Following up on this issue. Please let me know if there are any updates. Thanks!

[nmurav]

We don't support failover based on DNS

[j0rt3g4]

@NMuravlyannikov So, can you be more explanitive in how the failover works so I can update accordingly?

[azrabi]

I need to understand this as well.
Originally I was planning on using the following.Example base domain operator.com and a carrier trunk of sbc.operator.com
Using the following to register a single customer in a customer tenant for out 2 SBCs.
cusName-SBC1.sbc.operator.com
cusName-SBC2.sbc.operator.com
I recently where through the process of gettign a wildcard *.sbc.operator.com
However, reading today, I see there is a new architecture where SIP trunks are only registered to the carrier tenant.

cusName1-SBC1.sbc.operator.com
cusName1-SBC2.sbc.operator.com

I need to understand this as well.
Originally I was planning on using the following. Example base domain operator.com and a carrier trunk of sbc.operator.com
Using the following to register a single customer in a customer tenant for out 2 SBCs.
custName-SBC1.sbc.operator.com
custName-SBC2.sbc.operator.com
I recently went through the process of getting a wildcard *.sbc.operator.com

However, reading today, I see there is a new architecture where SIP trunks are only registered to the carrier tenant only.
Does this mean I need a new carrier trunk domain and cert.

eg.

custName1.sbc.operator.com
custName1.sbc1.operator.com ( new sip trunk domain and wild card cert)
I am in the process of setting this up so a prompt reply would be appreciated.

[azrabi]

Please Ignore the previous comment..

I need to understand this as well.
Originally I was planning on using the following. Example base domain operator.com and a carrier trunk of sbc.operator.com
Using the following to register a single customer in a customer tenant for out 2 SBCs.
custName-SBC1.sbc.operator.com
custName-SBC2.sbc.operator.com
I recently went through the process of getting a wildcard *.sbc.operator.com

However, reading today, I see there is a new architecture where SIP trunks are only registered to the carrier tenant only
Does this mean I need a new carrier trunk domain.

eg.

custName.sbc.operator.com
custName.sbc1.operator.com ( new sip trunk domain and wild card cert)
I am in the process of setting this up so a prompt reply would be appreciated.

[fowler9]

@lagerstedt I'm in the same boat as you trying to work out failover. We have no docs from Microsoft or @NMuravlyannikov or @scanum but thinking about it.

From a customer point of view, you verify the customer sub domain e.g. customer1.voice.hybrit.cloud and add that using Set-CsOnlineVoiceRoute.

Customer1.voice.hybrit.cloud points to the IP Address of the SBC

Now, if you have a secondary SBC with a different IP address for resilience. Would you not just add that into the OnlinePSTNGatewayList so it consists of 2 values e.g.

customer1.voice.hybrit.cloud and customer1Secondary.voice.hybrit.cloud

Ensuring public DNS is setup so customer1secondary.voice.hybrit.cloud points to public IP of second SBC.

Customer1secondary is then also setup as a Validated Domain in the customer tenant. Presumably a user will need to be setup also with this SIP address?

Then, calls can egress out of either SBC. 1 fails the other takes over.

From an ITSP SIP carrier, set the trunk as Active\Active so both SBC's can make\receive calls.

Am I missing something in my logic?

[nmurav]

I need to follow up on this with our dev team. I'll update shorthly

[j0rt3g4]

@NMuravlyannikov Thank you very much!

[fowler9]

@lagerstedt I'm in the same boat as you trying to work out failover. We have no docs from Microsoft or @NMuravlyannikov or @scanum but thinking about it.

From a customer point of view, you verify the customer sub domain e.g. customer1.voice.hybrit.cloud and add that using Set-CsOnlineVoiceRoute.

Customer1.voice.hybrit.cloud points to the IP Address of the SBC

Now, if you have a secondary SBC with a different IP address for resilience. Would you not just add that into the OnlinePSTNGatewayList so it consists of 2 values e.g.

customer1.voice.hybrit.cloud and customer1Secondary.voice.hybrit.cloud

Ensuring public DNS is setup so customer1secondary.voice.hybrit.cloud points to public IP of second SBC.

Customer1secondary is then also setup as a Validated Domain in the customer tenant. Presumably a user will need to be setup also with this SIP address?

Then, calls can egress out of either SBC. 1 fails the other takes over.

From an ITSP SIP carrier, set the trunk as Active\Active so both SBC's can make\receive calls.

Am I missing something in my logic?

Just as an update as I await @NMuravlyannikov further comments following his chat with the dev team.
I setup the above and shut down the primary SBC to mimic an outage. However, it doesn't failover despite a SIP 503 going back to Microsoft. 503 is defined as the message which should initiate going out over the other SBC.

[scanum]

@NMuravlyannikov Any updates on this? Thanks.

[scanum]

@NMuravlyannikov Any updates on this? Thanks.

[AngusWarren]

@NMuravlyannikov, do you have any updates on this?

[scanum]

@NMuravlyannikov Any updates on this? Thanks.

[nmurav]

Yes the failover works the same way as for regular scenario. Meaning carrier need to provision two trunks to every tenant (these trunks can be shared by multiple tenants).

[scanum]

@j0rt3g4 See above comment by @NMuravlyannikov Thanks!

[cdhayward]

Hello, I also need an answer to this as it's not clear.

"Yes the failover works the same way as for regular scenario. Meaning carrier need to provision two trunks to every tenant (these trunks can be shared by multiple tenants)."

So normal scenario I create:

Carrier tenant
Domain = customers.mydomain.com
PSTN Gateway = customers.mydomain.com:5068 (Derived trunk)

Customer 1 Tenant
Domain = sbc1.customers.mydomain.com
PSTN Gateway = None, just point voice policies to sbc1.customers.mydomain.com:5068

The question still stands, how do we add multiple gateways to the carrier Tenant (i.e. multiple derived trunks)? Do we have to use a different port?

i.e.
Carrier Tenant
customers.mydomain.com:5068
customers.mydomain.com:5069

Customer Tenant
sbc1.customers.mydomain.com:5068
sbc2.customers.mydomain.com:5069

Or as original poster suggests do we need a different DNS name for each derived trunk?

Carrier Tenant
uk1.customers.mydomain.com:5068
uk2.customers.mydomain.com:5068

Customer Tenant
sbc1.uk1.customers.mydomain.com:5068
sbc1.uk2.customers.mydomain.com:5068

Hope that makes sense? The guideline is to use your carrier base domain as the PSTN gateway in the carrier tenant, so I don't see how you can have multiples without changing the port or use separate carrier base domains.

Edit - I'm also looking to do this for fail-over and for SBCs in different global regions. i.e.

2x EMEA
2x APAC
2x AMER

[cdhayward]

I think I've answered my own question. Looks like you need a different DNS name for each derived trunk.

Whilst it's possible to create multiple PSTN Gateways in the Carrier tenant with different FQDNs and ports, it's not possible to specify a port with New-CsOnlineVoiceRoute in the customer tenants, only New-CsOnlinePSTNGateway can do this.

Therefore I think it would need to look like:

Carrier Tenant
Domains:
uk1.customers.mydomain.com
uk2.customers.mydomain.com
PSTNGateways:
uk1.customers.mydomain.com:5068
uk2.customers.mydomain.com:5068

Customer Tenant
Domains:
sbc1.uk1.customers.mydomain.com
sbc1.uk2.customers.mydomain.com

This also means different wildcard cert for each SBC. i.e. *.uk1.customers.mydomain.com

Someone correct me if I'm wrong?

[fowler9]

@cdhayward

I think you're correct. I've been trying to work it out myself as the docs aren't great on this but that's the way I've planned it. I'm doing some testing in the next few days to test resilience so will confirm then.

My only query which I'm not sure is on wildcard certs. We currently have a wildcard certificate for our 1st SBC *.uk1.customers.mydomain.com, we also have a *.customers.mydomain.com which we already have from something else so I'm wondering if it would work when applied to the 2nd SBC but not sure on that?? Just trying to save the purchase of a 2nd wildcard certificate.

I'm going to try it but may have to revert to purchasing that *.uk2.customers.mydomain.com if it doesn't work.

I'll certainly update when I know more but would be interested to hear your results also.

[fowler9]

@cdhayward Just to let you know, I tested this over the weekend and it worked well. Had load sharing between 2 SBC's. Then brought down 1st SBC and calls reverted to go out over the 2nd SBC, then reversed it and calls went out over working 1st SBC. Pretty immediate the response with no attempted failed calls.
Ended up using a certificate *.uk2.customers.mydomain.com rather than the original *.customers.mydomain.com I said I was going to try.

My setup was the same as yours so you should be OK to go.

[CarolynRowe]

I have followed up with Nikolay and updated the topic according to his recommendations. Updates will go live tomorrow. Closing this issue.

Considerations for setting up muti-tenant failover

To set up failover for a multi-tenant environment, you'll need to do the following:

For each tenant, add the FQDNs for two different SBCs. For example:
customer1.sbc1.contoso.com
customer2.sbc2.contoso.com

In the Online Voice Routing policies of the users, specify both SBCs. If one SBC fails, the routing policy will route calls to the second SBC.

[Playajay]

@fowler9 The article https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trusted-certificate-for-the-sbc states the certificate uses RFC 2818
According to this, if you use a wildcard cert *.sbc1.contoso.com, then customer1.sbc1.contoso.com will match, but test.customer1.sbc1.contoso.com will NOT match.
Therefore, you need a new wildcard cert for each base domain. In other words, you need a new wildcard cert for each physical SBC you deploy.

To show another example, if you have wildcard cert *.contoso.com
And configure carrier trunk:
SBC1.contoso.com
SBC2.contoso.com
Then in customer tenant you will use derived trunks:
customer1.SBC1.contoso.com
customer1.SBC2.contoso.com

But your wildcard cert will NOT match these derived trunk names.
Therefore, you need two wildcard certs:
*.SBC1.contoso.com
*.SBC2.contoso.com

[cdhayward]

That is correct you need a seperate wildcard cert per SBC if you have multiple super trunks & "carrier domains".

I've stuck to the old method as there's more flexibility in the solution on a per customer basis.

[cervezerg]

I Agree with @CarolynRowe but please change the example in documentation. to be consistent, it should say:

For each tenant, add the FQDNs for two different SBCs. For example:

sbc1.customers1.adatum.biz
sbc1.customers2.adatum.biz

You need two wildcard certificates. One for each SBC in the carrier.
*.customers1.adatum.biz
*.customers2.adatum.biz