Microsoft Teams Phone: Error Code 504 Fix – Causes & Troubleshooting

A 504 error in Microsoft Teams Phone usually means the signaling path did not finish on time. In many real-world phone deployments, the trail leads to Direct Routing: Microsoft’s SIP proxy tries to talk to the Session Border Controller (SBC), and something in that path blocks, delays, or rejects the exchange. Not every case looks the same. Some tenants see the code during all outbound calls, some only during transfers, and some only after a certificate rollover. That pattern matters more than the number alone.

For phone workloads, this error is often infrastructure-facing rather than a simple local app glitch. So before changing random settings, pin down the scope: all users or one user, all calls or one route, all sites or one SBC. That one distinction can cut a long troubleshooting session down to a few focused checks.

Table of Contents

What 504 Means in Teams Phone

At the practical level, 504 means timeout or failed delivery of SIP signaling. In Teams Phone, that usually shows up when an INVITE or ACK cannot be delivered, when TLS negotiation breaks, or when DNS points Microsoft to the wrong destination. For admins, the right question is not “How do I hide the code?” but “Which hop failed, and why?” If you regularly investigate these patterns, it helps to keep a broader Microsoft Teams error codes reference nearby so you can compare signaling failures with other Teams-specific errors that appear during calls, meetings, or authentication.

If your tenant does not use Direct Routing, do not force the SBC path into the investigation. Start with tenant scope, recent changes, and service health. If you do use Direct Routing, the 504 pattern becomes much more specific, and the checks below usually land very close to the fault.

Why the Error Appears

Microsoft’s Direct Routing troubleshooting material ties recurring 504 failures to a short list of causes: SBC inactivity, TLS certificate problems, untrusted or expired certificates, DNS resolution problems, and Direct Routing misconfiguration. It also calls out situations where SIP OPTIONS are not received, the SBC does not respond, or the SBC is marked inactive in the admin center. That is why broad “clear cache and retry” advice rarely solves this phone-specific error.[✅Source-1]

SBC Reachability and Firewall Paths

If the SBC is down, listening on the wrong interface, refusing connections, or hidden behind a firewall rule that is too narrow, Teams Phone can throw a 504 even though the tenant itself is healthy. Seen often, this one. In practice, timeouts and actively refused connections tend to point here first.

TLS Certificate and Trust Problems

A certificate can break the call path in more than one way: expired, wrong principal name, untrusted root, or a profile mismatch on the SBC. A call may look normal until the handshake begins, then fail fast with a 504. Quietly, but completely.

DNS and FQDN Record Mistakes

If Microsoft cannot resolve the SBC FQDN, or finds only a TXT record instead of an A or AAAA record, the signaling path breaks before the call can settle. This is one of the easiest issues to miss after domain work, certificate updates, or DNS migrations.

SIP Message Format Issues

Some 504 variants come from invalid SIP request or response lines. When the SBC sends a malformed or unsupported SIP message, Microsoft can reject the exchange even though the network path itself is open. So yes, a 504 can be a formatting problem, not only a timeout.

Microsoft Response Codes That Narrow the Fix

The plain 504 label is not enough on its own. The Microsoft response code attached to the event is what turns a vague fault into a short suspect list. Microsoft’s official mapping for SIP 504 errors includes timeout, refused connection, TLS negotiation failure, expired certificates, DNS lookup failures, and wrong record types.[✅Source-2]

Microsoft Response Code	What It Usually Points To	First Action
549002	TLS transport disconnected or invalid SIP request/response line	Check SBC status, verify reachability, confirm SIP/2.0 formatting
569002	Timeout, connection refused, TLS negotiation failure, wrong target principal name, or TLS decryption failure	Check firewall path, IP/port reachability, certificate name, and TLS profile
569003	TLS negotiation failed because the certificate is not trusted or is no longer valid	Confirm trusted CA and certificate validity dates
569008	Remote certificate expired	Renew the SBC certificate and clear old TLS sessions
569015	SBC host name cannot be resolved	Fix DNS resolution for the SBC FQDN
569016	Name exists, but the wrong record type is returned	Make sure the SBC has a valid A or AAAA record, not only TXT

What to Check First in Admin Tools

In the Teams admin center, the Health Dashboard for Direct Routing is one of the fastest ways to separate an SBC problem from a routing problem. Microsoft states that this dashboard lets you add, edit, and view SBCs, voice routes, and PSTN usage records so you can monitor the connection between the SBC and the Direct Routing interface.[✅Source-3]

Before you assume the fault is local, open Microsoft 365 Service Health. The service health page in the admin center shows whether there is an active service issue and lists the health state of each cloud service. That single check can keep you from changing a healthy SBC while the real problem sits upstream.[✅Source-4]

1. Check scope: all users, one site, one queue, one transfer path, or one user.
2. Open Service Health: confirm there is no tenant-side incident affecting Teams or phone workloads.
3. Open the Direct Routing dashboard: verify SBC state, recent certificate warnings, and route visibility.
4. Pull a failed example: note time, called number, calling number, user, and route or trunk used.
5. Match the Microsoft response code: let the code decide whether you go to DNS, TLS, firewall, or SIP formatting first.

Step-by-Step Fix for Error Code 504

For Direct Routing, Microsoft documents three signaling FQDNs that the SBC must use in order: sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com. The signaling subnets include 52.112.0.0/14 and 52.120.0.0/14, and the SBC-to-SIP-proxy signaling path uses port 5061. If any of that path is incomplete, 504 errors become much more likely.[✅Source-5]

1. Confirm the failing scope. Test one internal user, one external PSTN destination, and one known-good route. If all three fail, think trunk or signaling path before user policy.
2. Verify the SBC FQDN resolves correctly. Make sure public DNS returns the expected A or AAAA record. If the record is missing or stale, 504 can appear before the first useful SIP exchange.
3. Validate the certificate presented by the SBC. Check expiry date, trust chain, SAN or CN match, and the TLS profile actually bound to the Direct Routing interface.
4. Test reachability on the signaling path. Confirm the firewall allows the required traffic, the SBC listens where expected, and no NAT or ACL rule quietly blocks return traffic.
5. Compare a failed call with a working call. If outbound fails but inbound works, look at the route, target translation, and any flow-specific SIP manipulation on the SBC.
6. Rebuild stale TLS sessions after certificate changes. If the certificate was renewed, remove old sessions and re-establish clean ones so Teams is not still talking to a path that presents outdated state.
7. Review SIP formatting. If the response code points to an invalid request or response line, check the SIP version string and any message manipulation rules introduced on the SBC.
8. Retest with exact timestamps. A clean retest after each change matters; without it, multiple edits blur the root cause.

Network and Port Values Worth Checking

Microsoft’s network connectivity tool uses clear pass values for Teams media: packet loss below 1.00%, latency below 100 ms, and jitter below 30 ms. Those numbers do not prove a 504 root cause on their own, but they help you spot whether a “sometimes it works” environment has a wider transport problem sitting behind the call failures.[✅Source-6]

Metric	Healthy Target	Why It Matters
Packet Loss	Below 1.00%	High loss can turn an intermittent signaling or media path into a call setup failure pattern
Latency	Below 100 ms	Long delay stretches handshakes and makes borderline routes fail more often
Jitter	Below 30 ms	Unstable delivery can expose hidden transport weakness during busy periods

Use these values as a supporting signal, not the only diagnosis. A perfect client network does not fix an expired SBC certificate, and a healthy certificate does not help when DNS points to the wrong place.

Why Some Calls Fail While Others Work

Not every Teams Phone call follows the same media path. Microsoft’s Direct Routing media bypass guidance shows that signaling always flows via the Microsoft cloud, while media can stay local, go through Transport Relays, or involve Media Processors depending on the scenario. It also documents direct media ports of 50000-50019 between client and SBC, and relay-related ranges such as 50000-59999 and 3478-3481 between the SBC and Transport Relays. That is one reason a normal user call may work while a transfer, queue, or another call path fails.[✅Source-7]

• Outbound only fails: inspect route selection, SBC egress logic, and destination-specific manipulation rules.
• Transfers fail but direct calls work: compare the transfer path, voice app path, and any policy tied to that scenario.
• One building fails: look for a site firewall, DNS forwarder, or NAT policy that does not match other locations.
• One number range fails: verify normalization, translation, and trunk matching before assuming the whole tenant is broken.

Patterns That Point to Network Friction

Microsoft’s CQD guidance is useful when 504 errors are intermittent, site-based, or hard to reproduce. The documentation notes that Wi-Fi often performs worse than wired connectivity for real-time media, and that TCP is a fallback transport rather than the preferred path. It also points out that rising TCP usage often traces back to missing firewall or proxy exception rules. If your 504s cluster around one office or one busy network window, that trend data is worth checking.[✅Source-8]

Details to Capture Before the Next Test

1. Exact timestamp of the failed call, in tenant local time and UTC if possible.
2. Calling and called numbers, including the normalized form seen by the SBC.
3. User, device, and location so you can tell a trunk issue from a site issue.
4. Microsoft response code paired with the 504 label.
5. SBC certificate details: subject, SAN entries, issuer, and expiry date.
6. DNS answer for the SBC FQDN, including record type returned.
7. Whether the same path succeeds for another user on the same site and route.

The cleaner the test data, the faster the fix. Scattershot changes slow everything down. A short, disciplined retest log does the opposite.

FAQ