unable to make teams calls to external numbers

Dear @M365 Admin, 

Good day, and I appreciate the clear explanation of your concern.   

The key point is that the SBC receives no SIP signaling when a call is made from Teams to the PSTN, which means the call is being blocked within the Microsoft cloud before outbound routing occurs. While inbound PSTN to Teams confirms the SBC connection is healthy, outbound calls require correct user and tenant routing configuration so Teams can select a matching voice route to the SBC. 

Please see the following workarounds that will help you verify the issue:  

Option 1: Validate that the dialed number matches a voice route 

If the dialed number does not match any voice route pattern, Teams cannot select an SBC, so no SIP INVITE is generated. 

Open Microsoft 365 admin center > Show all > Teams Admin Center and navigate to Voice > Direct Routing > Voice routes. 

Confirm that at least one voice route exists with a dialed number pattern that matches the exact number format users are dialing. 

Ensure the voice route is associated with the correct Online PSTN Gateway that represents your SBC. 

Test using a full E.164 number format, for example starting with a plus sign, to confirm basic routing works. 

Option 2: Confirm the user has the correct voice routing policy and PSTN usage 

Voice routing policies link users to PSTN usages, and PSTN usages link users to voice routes. If any part of this chain is missing, outbound routing will fail even though inbound calls work. 

Open Teams Admin Center and navigate to Users > Manage users. 

Select the affected user and check that a voice routing policy is assigned. 

Open the assigned voice routing policy and confirm it includes the PSTN usage record where the relevant voice route is defined. 

Verify the user is enabled for Teams Phone with Direct Routing. 

Additional information is available in the following resource: Configure call routing for Direct Routing - Microsoft Teams | Microsoft Learn 

Option 3: Contact Microsoft Support 

If the issue persists, I sincerely recommend creating a support ticket through the Microsoft 365 Admin Center > Support > Help & Support for further investigation.  

A technical support engineer can perform a remote session to investigate the situation, verify the backend configurations, and run any necessary synchronization tools to resolve the problem. If the issue requires further attention, they can escalate it to a specialized team for deeper analysis.     

As community moderators, we kindly ask for your understanding that our access to internal development details is limited. Our primary role is to guide users toward the appropriate resources and support channels. While we may not have visibility into performing deeper backend analysis, we’ll continue doing our best to support you within the scope of our responsibilities.  

I hope this information is helpful. If you have any questions or need further support, please don’t hesitate to reach out at any time. 

Thank you for your patience and understanding. 

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have any extra questions about this answer, please click "Comment".            

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread. 

SIP 504 with “connection actively refused” and no INVITE logs on the SBC indicates that, although SIP OPTIONS/TLS are healthy, the media/signaling path used for real calls from Teams to the SBC is not reachable or not accepted.

Based on the documented 504 variants, the main areas to check are:

1. Verify SBC reachability for INVITE (not just OPTIONS)
   • 504 errors such as:
     • “No connection could be made because the target machine actively refused it”
     • “A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond”
   • Recommended actions:
     • Confirm the SBC is functional.
     • Confirm the SBC is reachable on the specific IP and port used for Direct Routing (from Microsoft to SBC), and that firewalls/NAT devices allow that traffic.
     • Ensure the same IP/port that responds to SIP OPTIONS is also listening for INVITE and not blocked by any security policy.
2. Check TLS negotiation and certificate trust for call signaling
   • Several 504 variants are caused by TLS negotiation failures (wrong principal name, untrusted root, expired certificate, TLS decryption issues).
   • Even if OPTIONS work, a different TLS profile or certificate might be used for call traffic.
   • Recommended actions:
     • Verify the SBC certificate is signed by a trusted public CA listed under “public trusted certificate for the SBC,” not self‑signed.
     • Confirm the certificate is not expired and the SBC is using the correct TLS profile for the Direct Routing interface.
     • If there are multiple TLS profiles, ensure the one used for Teams trunks is the one with the trusted, valid certificate.
3. Validate DNS and FQDN configuration
   • 504 variants such as “No such host is known” or “The requested name is valid, but no data of the requested type was found” point to DNS issues.
   • Recommended actions:
     • Confirm the SBC FQDN configured in Teams can be resolved to the correct IP via DNS.
     • Ensure A/AAAA records exist for the SBC FQDN (not just TXT records used for verification).
4. Confirm SIP message format from SBC is valid
   • 504 variants like “Invalid Request/Response line” occur when the SBC sends unsupported or malformed SIP.
   • Recommended actions:
     • Check that SIP messages use SIP/2.0 in the Request-URI, Via, and other relevant headers.
     • Review SBC configuration to ensure it does not send invalid or non‑standard SIP to Microsoft.
5. Use 504 in Direct Routing failover logic (if multiple SBCs)
   • By default, 408, 503, and 504 are used as failover response codes in Direct Routing.
   • If multiple SBCs are configured in the voice routing policy, a 504 from one SBC should trigger failover to another SBC, provided no provisional (non‑100) responses are received.
   • Confirm the OnlinePSTNGateway and voice routing policy are configured so that 504 from the first SBC allows retry on an alternate SBC.

Given that OPTIONS and TLS appear healthy but no INVITEs reach the SBC, focus on:

• Firewall/NAT rules for the call signaling path (IP/port from Microsoft to SBC).
• Correct SBC FQDN, DNS records, and certificate (trusted CA, not expired, correct principal name).
• Ensuring the SBC listens and accepts INVITEs on the same interface/profile used for OPTIONS.

References:

• SIP response code 504
• SBC connectivity issues
• Trunk failover on outbound calls