Your Teams call queue suddenly stops ringing after your network team updates the firewall. Calls go straight to voicemail or fail with a busy tone. The root cause is almost always a blocked or misdirected connection to Microsoft 365 services. This article explains the exact ports and endpoints the call queue needs and gives you a step-by-step fix to restore ringing.
You will learn how to verify the firewall rules, test connectivity with PowerShell, and confirm the call queue policy is still assigned. You will also see a comparison of the legacy and new Teams clients because each uses different connection paths. By the end, your call queue will ring again without a ticket to Microsoft.
Key Takeaways: Restore Teams Call Queue Ringing After a Firewall Change
- Microsoft 365 Common and Office URLs and IP ranges: The official list of endpoints your firewall must allow for Teams to work.
- Teams admin center > Voice > Call queues: Verify the call queue is still assigned to the correct resource account and routing method.
- Test-CsTeamsCallQueue PowerShell cmdlet: A direct connectivity test that tells you if the call queue can reach Microsoft 365.
Why a Firewall Change Blocks Teams Call Queue Ringing
Teams call queues rely on a specific set of network connections. When a caller dials the queue number, the call is routed through Microsoft 365. The Teams client or the calling device must maintain a connection to the Teams service to receive the call. If the firewall blocks any of these connections, the call cannot reach the queue and the queue does not ring.
The most common culprits are outbound HTTPS connections to the Teams endpoints and the media path used for audio. The Teams client uses port 443 for signaling and ports 3478 to 3481 for media. A firewall change that restricts outbound UDP or TCP on those ports will break call queue ringing. Another frequent cause is a proxy or security appliance that intercepts HTTPS and breaks the certificate chain, so Teams cannot authenticate.
What Endpoints Does the Call Queue Need?
The call queue service uses the same endpoints as regular Teams calls. You must allow outbound HTTPS to the following domains:
- teams.microsoft.com
- login.microsoftonline.com
- graph.microsoft.com
- sfbassets.com and all subdomains
- teams.skype.com and all subdomains
For media, allow UDP and TCP on ports 3478 through 3481. If your firewall only allows TCP, you must also allow UDP for voice quality. Without UDP, the call may connect but with severe audio issues.
How the Firewall Change Affects the Call Flow
When a caller dials the queue, the call is first routed to the Microsoft 365 phone system. Then the system sends an invitation to the resource account that is assigned to the queue. The resource account is a special user object that represents the queue. If the firewall blocks the connection from your network to the Teams service, the invitation never reaches the resource account. The caller hears a fast busy tone or is sent to voicemail.
The firewall can also block the connection from the Teams client that is used by an agent. Even if the queue is healthy, if the agent’s client cannot reach the Teams service, the call will not ring on that agent’s device. This is why you must test both the server-side connectivity and the client-side connectivity.
Steps to Diagnose and Fix the Call Queue After a Firewall Change
Follow these steps in order. Each step verifies a different part of the call path. Do not skip the connectivity test because it pinpoints the exact blocked port.
- Check the Microsoft 365 service health
Go to the Microsoft 365 admin center and open Service health. Look for any incident related to Teams calling or phone system. If there is an active incident, the firewall change may not be the cause. Wait for the incident to resolve and test again. - Review the firewall rules for Teams endpoints
Open your firewall management console. Find the rules that apply to outbound traffic to the domains listed above. Confirm that HTTPS on port 443 is allowed. Confirm that UDP and TCP on ports 3478 to 3481 are allowed. If any rule was changed, restore it or add a new allow rule. Use the official Microsoft 365 URLs and IP ranges page to get the current list of IP addresses. - Test connectivity with PowerShell
On a machine that is on the same network as the call queue, open Windows PowerShell as an administrator. Run the following command to test the media path:Test-NetConnection teams.microsoft.com -Port 443
If the result shows TcpTestSucceeded : True, the signaling path is open. Then test the media ports with:Test-NetConnection teams.microsoft.com -Port 3478
If this fails, the firewall is blocking UDP or TCP on that port. Adjust the rule and test again. - Verify the call queue policy assignment
Open the Teams admin center and go to Voice > Call queues. Select your call queue and check the Resource account field. The resource account must be licensed for Phone System and must have a valid phone number. If the resource account is missing a license, the queue will not ring. Reassign the account if needed. - Test the call queue with a direct call
Dial the queue number from a phone that is not on your network. If the call rings, the problem is client-side. If it does not ring, the problem is server-side. If the call rings on your test phone but not on the agent’s device, check the agent’s Teams client connectivity and the agent’s presence. The agent must be set to Available or Be Right Back to receive calls. - Use the Test-CsTeamsCallQueue cmdlet
Install the Teams PowerShell module if you have not done so. Run the following command to test the call queue configuration:Test-CsTeamsCallQueue -Identity "YourCallQueueName"
This cmdlet checks the resource account, the routing method, and the connectivity to the phone system. It returns a pass or fail result. If it fails, read the error message. It often tells you exactly which endpoint is unreachable.
If the Call Queue Still Does Not Ring
Teams Client Shows a Red Banner About Network Issues
When the Teams client cannot reach the Teams service, it shows a red banner at the top of the window. The banner says “You’re having network issues.” Open the client’s diagnostic logs by pressing Ctrl+Alt+Shift+1. Look for entries that contain “media” or “ice”. If you see a failure to allocate a UDP port, the firewall is blocking the media ports. Fix the firewall rule and restart the client.
Call Queue Rings Once Then Drops
This usually means the signaling path is open but the media path is not. The call connects for a second then drops because the audio stream cannot be established. Check the firewall rules for ports 3478 to 3481. Make sure both UDP and TCP are allowed. Also check if your firewall is performing deep packet inspection on the media packets. If so, add an exception for the Teams media IP ranges.
The Call Queue Is Not Listed in the Teams Admin Center
If the call queue disappears from the admin center, the resource account may have been deleted or unlicensed. Go to Users > Manage users and find the resource account. Confirm that it has a Phone System license and a calling plan. If the account was deleted, you must recreate it and assign it to the queue. This is not a firewall issue, but it can happen after a network change if the IT admin also cleaned up user accounts.
New Teams Desktop vs Teams on the Web: Call Queue Connection Differences
| Item | New Teams Desktop | Teams on the Web |
|---|---|---|
| Signaling port | TCP 443 | TCP 443 |
| Media port range | UDP and TCP 3478-3481 | UDP and TCP 3478-3481 |
| Proxy support | Uses system proxy | Uses browser proxy |
| Firewall exception needed | Yes, for the app executable | Yes, for the browser executable |
| Diagnostic tool | Ctrl+Alt+Shift+1 | Browser developer tools |
The new Teams desktop client and the web client use the same ports. The difference is that the desktop client can be blocked by a firewall rule that targets the Teams.exe executable, while the web client is blocked by a rule that targets the browser. If you use both, you must update both firewall rules.
Conclusion
You now know the exact ports and endpoints that Teams call queues depend on. You can verify the firewall rules, test connectivity with PowerShell, and confirm the call queue policy. Start by checking the Microsoft 365 service health, then review the firewall rules for ports 443 and 3478-3481. Use the Test-CsTeamsCallQueue cmdlet to get a precise diagnosis.
After you fix the firewall, test the queue with a call from an external phone. If the call rings, the fix is complete. If it still fails, run the client diagnostic with Ctrl+Alt+Shift+1 to find the exact blocked connection. As a next step, consider setting up a call queue analytics report in the Teams admin center to monitor call failures. That report will help you spot future firewall issues before users notice.