The Short Answer

If a Microsoft Teams Direct Routing SBC becomes Inactive after a certificate renewal, start with the TLS and SIP connection between Microsoft Teams and the SBC.

Do not immediately change your Teams dial plan, PSTN usage, voice routing policy, or voice routes. Those settings control call routing. They do not repair a failed TLS connection or a broken SIP OPTIONS relationship.

Once that connection is healthy, move on to call routing and media troubleshooting if calls are still failing.

What Does “Inactive” Mean in Teams?

Imagine a simple Direct Routing deployment:

Everything was working normally until the SBC certificate was renewed.

After the renewal, the SBC management interface shows:

But Microsoft Teams still reports:

That does not automatically mean that the new certificate is bad. The certificate may be perfectly valid while the SBC-to-Microsoft TLS or SIP OPTIONS connection is still broken.

Microsoft uses SIP OPTIONS as part of Direct Routing SBC health monitoring. That makes OPTIONS one of the first things worth checking when an SBC suddenly becomes inactive.

Why a Certificate Renewal Can Expose an Existing Problem

Certificate renewals often happen during maintenance windows. Several things can change at the same time.

For example, an administrator might:

• Install a new certificate.
• Replace the intermediate certificate.
• Change the TLS context.
• Restart the SBC.
• Modify a firewall rule.
• Update the SBC firmware.
• Change the SBC FQDN.
• Update the Microsoft 365 gateway.

If Teams becomes inactive immediately afterward, the certificate renewal gets blamed.

Sometimes that is correct. Sometimes the renewal simply exposed another problem.

Step 1: Check the SBC FQDN

Start with the simplest question:

What FQDN is Microsoft Teams configured to use for the SBC?

For example:

sbc1.example.com

Now compare that with the certificate.

If Teams expects sbc1.example.com but the certificate was issued for sbc-old.example.com, the certificate may be valid from a general PKI perspective but still wrong for the Direct Routing configuration.

Step 2: Check the Certificate SAN

The Subject Alternative Name (SAN) is one of the first fields I check during a certificate-related Direct Routing incident.

Suppose your SBC FQDN is:

sbc1.example.com

The certificate should contain that name in the appropriate identity field.

For example:

Subject Alternative Name:

DNS:sbc1.example.com

A common mistake is renewing the certificate for an old hostname because that certificate was used by the SBC for years.

The certificate can be perfectly valid and still fail the actual Direct Routing requirement because the name doesn’t match the SBC FQDN.

Step 3: Check the Complete Certificate Chain

This is probably one of the most common things to miss after a certificate renewal.

A certificate normally sits inside a chain:

An administrator may install only the new leaf certificate:

sbc1.example.com.crt

The certificate looks valid in the SBC interface, but the required intermediate certificate is missing.

That can result in a TLS trust failure.

That distinction matters.

Step 4: Make Sure You Renewed the Right Certificate

An SBC can use certificates for several different services.

This creates an easy trap.

You renew a certificate, open the SBC management page, and see that everything looks good.

But Microsoft Teams is not connecting to the SBC’s management interface.

Teams is communicating with the SIP/TLS interface.

Therefore, verify that the renewed certificate is actually bound to the Teams-facing SIP/TLS listener.

For example:

sbc1.example.com:5061

should present the certificate you expect.

Step 5: Check the TLS Version

Current Microsoft Direct Routing deployments should use the TLS versions and cipher suites supported by Microsoft and the SBC vendor for the deployed configuration.

Microsoft’s current Direct Routing troubleshooting guidance requires TLS 1.2 or higher for the SBC connection.

If you’re troubleshooting an old SBC configuration, don’t assume that because it worked several years ago it still meets today’s requirements.

Step 6: Check Microsoft’s Certificate Trust Requirements

Another common mistake is assuming that a certificate trusted by your company is automatically trusted by Microsoft.

For example:

Corporate laptop trusts certificate
        ≠
Microsoft Teams trusts certificate

Microsoft documents the certificate authority requirements for Direct Routing. The SBC certificate needs to meet Microsoft’s current trust requirements.

This becomes especially important when older SBC trust stores are involved.

Step 7: 2026 Certificate Authority Changes Matter

This is particularly important for current troubleshooting.

Microsoft has been transitioning its Teams SIP infrastructure certificates during 2026. Older SBC trust stores may therefore need to be reviewed against Microsoft’s current certificate requirements.

If your SBC has been running unchanged for years, don’t assume its trust store is automatically current.

A certificate renewal on your SBC may expose this issue because the renewal often leads to a fresh TLS connection and a fresh certificate-validation process.

Step 8: Clear Old TLS Sessions

This is an easy one to overlook.

Imagine the SBC had:

Old certificate
Expires: September 2026

You install:

New certificate
Expires: September 2027

The certificate has changed, but an existing TLS session doesn’t automatically become a brand-new TLS session.

Microsoft recommends closing old TLS connections and establishing new connections after renewing the SBC certificate. Depending on the SBC, this may involve restarting the SBC during a maintenance window or using the vendor’s procedure for clearing TLS sessions.

Step 9: Check DNS

DNS is often forgotten because the SBC worked yesterday.

Verify that the SBC FQDN resolves correctly:

sbc1.example.com

Then verify the Microsoft SIP FQDNs used by the SBC.

Microsoft documents the Direct Routing SIP endpoints using FQDNs rather than requiring administrators to permanently configure one resolved IP address.

That matters because Microsoft’s service infrastructure can change.

Step 10: Check the Microsoft SIP Endpoints

The Microsoft Direct Routing service uses these SIP FQDNs:

sip.pstnhub.microsoft.com
sip2.pstnhub.microsoft.com
sip3.pstnhub.microsoft.com

The first is the primary endpoint, with the other two providing additional connectivity and geographic redundancy.

Your SBC should use Microsoft’s current documented configuration rather than hard-coding old resolved IP addresses.

Step 11: Check TCP 5061

For Microsoft Teams Direct Routing SIP signaling, TCP 5061 is the standard TLS signaling port.

A simple troubleshooting model is:

If the TCP connection cannot be established, SIP OPTIONS cannot work.

So before spending an hour looking at SIP headers, make sure the basic network connection works.

Step 12: Check the Firewall in Both Directions

A firewall may allow the SBC to initiate a connection while still causing problems with return traffic.

Think about the complete path:

Check for:

• Incorrect Microsoft IP allowlists
• SIP ALG
• TLS inspection
• Asymmetric routing
• Stateful firewall timeouts
• NAT problems
• Incorrect return routes
• Expired firewall objects

Microsoft recommends allowing the documented signaling traffic rather than locking the firewall to one IP address that happened to be returned by DNS at one point in time.

Step 13: Check SIP OPTIONS

Now we get to the most important test.

What does the actual SIP trace show?

You want to see a healthy signaling relationship, not simply a green certificate on the SBC web interface.

If OPTIONS is failing, the Teams health status can remain unhealthy even though your PSTN routing configuration is completely correct.

How to Read the TLS Failure

Step 14: Check Contact and Record-Route

A certificate can be completely correct while SIP headers still identify the SBC incorrectly.

For example, your Teams gateway is:

sbc1.example.com

But the SBC sends a Contact header containing:

Contact: <sip:203.0.113.10:5061>

That can create identity and routing problems.

The exact header behavior depends on the SBC and deployment, but Microsoft specifically documents checking the SBC FQDN in SIP signaling such as Contact and Record-Route when troubleshooting Direct Routing OPTIONS.

Step 15: What If OPTIONS Returns 200 OK but Teams Still Says Inactive?

This is where things get confusing.

You capture the traffic and see:

OPTIONS
↓
200 OK

The TLS handshake is successful.

The certificate is valid.

The firewall is allowing the connection.

Yet the Teams Admin Center still shows Inactive.

Don’t immediately start changing call-routing configuration.

Instead, check the Teams Direct Routing health information and confirm whether TLS and SIP OPTIONS are consistently healthy.

Also remember that monitoring information may not update instantly after a configuration change.

A Real-World Certificate Renewal Example

Let’s make this practical.

Suppose a company has:

The administrator installs the new certificate.

The SBC GUI reports:

Teams reports:

The administrator checks the certificate and discovers:

Leaf certificate:
sbc1.company.com

Intermediate certificate:
MISSING

The missing intermediate certificate is installed.

The old TLS sessions are cleared during the maintenance window.

A new TLS connection is established.

The OPTIONS exchange becomes healthy:

OPTIONS
↓
200 OK

The Teams health state subsequently recovers.

Notice what was not changed:

• Dial plan
• Voice routing policy
• PSTN usage
• Voice route
• Number normalization

The problem was not call routing.

It was the TLS trust chain.

Another Example: The Certificate Is Perfect

Now consider a different incident.

The certificate has:

• The correct FQDN
• Correct SAN
• A trusted public CA
• A complete certificate chain
• Valid expiration date

But Teams still shows Inactive.

A packet capture shows:

SBC → Microsoft
OPTIONS

But the expected response never arrives.

The firewall is discovered to contain an old Microsoft signaling IP allowlist.

The SBC is using Microsoft’s SIP FQDN, but the firewall is effectively permitting only a previous set of resolved addresses.

The certificate was never the real problem.

What If Only One Customer or Derived Trunk Is Inactive?

Hosted SBC and multi-tenant deployments require a slightly different approach.

You may have:

If only one derived trunk is showing a problem, check the customer-specific configuration as well as the parent SBC.

Look at:

• Customer SBC FQDN
• Certificate SAN
• Contact header
• Domain configuration
• OPTIONS behavior
• Parent SBC health

Don’t assume every customer-side problem is caused by the same certificate.

When It Is Not a Certificate Problem

This is an important distinction.

Why You Should Not Rebuild the Dial Plan

This is probably the most important troubleshooting habit in the entire article.

If the SBC cannot establish a healthy TLS or OPTIONS relationship with Microsoft, changing your dial plan won’t fix it.

Think about the architecture:

Troubleshoot the layer that is actually failing.

If TLS is broken, fix TLS.

If OPTIONS is broken, fix OPTIONS.

If the call reaches the SBC but is routed incorrectly, then investigate the routing configuration.

The Practical Troubleshooting Checklist

A Better Way to Troubleshoot an SBC Incident

When you’re sitting on a production incident bridge, the temptation is to change things quickly.

That’s usually where troubleshooting gets messy.

Instead, establish a known sequence:

1. Prove network connectivity.
2. Prove TLS.
3. Prove certificate trust.
4. Prove SIP OPTIONS.
5. Prove SBC health.
6. Prove call signaling.
7. Prove routing.
8. Prove media.

This approach gives you evidence at every stage instead of relying on assumptions.

Final Takeaway

A Microsoft Teams SBC becoming Inactive immediately after a certificate renewal does not automatically mean you need a new voice route, a different dial plan, or a rebuilt PSTN configuration.

Start with the connection between Microsoft and the SBC.

Once that path is healthy, move on to call routing if calls are still failing.

The key lesson is simple:

A valid certificate on the SBC does not prove that Microsoft Teams has a healthy TLS and SIP OPTIONS relationship with the SBC.

The fastest troubleshooting method is to prove the connection with the actual signaling rather than relying on the certificate page or Teams status alone.

Related Microsoft Teams Direct Routing Guides

• 
  Microsoft Teams Direct Routing Troubleshooting
  
• 
  Hosted SBC Direct Routing Domain
  
• 
  Teams Direct Routing 488 Not Acceptable Here
  
• 
  AudioCodes vs Ribbon vs AnyNode for Teams
  
• 
  Teams Dial Plan vs Voice Routing Policy
  

Official Documentation

For production deployments, always verify the current Microsoft Direct Routing requirements and the documentation for your specific SBC model and firmware. Microsoft can change SIP endpoints, certificate requirements, network ranges and service behavior.

Recommended sources include Microsoft Learn’s Direct Routing planning, troubleshooting, health dashboard and SIP call-flow documentation, together with the documentation supplied by your SBC vendor.