Error Code 405 in Microsoft Teams Phone usually points to a method mismatch, not a random call failure. In SIP terms, 405 means Method Not Allowed: the request reached the other side, that side understood the request type, and then rejected the method being used. In real Teams Phone troubleshooting, this usually appears in Direct Routing, call transfer, SBC interoperability, or SIP device paths. Start there. [✅Source-1]
Do not treat 405 as a generic “Teams calling is broken” message. Microsoft documents that the visible final SIP code can be generated either by the Session Border Controller or by a Microsoft service. That split matters. If the Microsoft response code starts with 560, the final SIP code came from the SBC, which means the first serious stop is almost always the SBC trace, not the Teams client. [✅Source-2]
Page Map
Read This First If the problem happens only during transfer, park, consult transfer, or on a SIP desk phone, the signaling method is the first thing to verify. If the dial pad is missing or the number assignment is incomplete, clear those prerequisites before reading deep meaning into the 405.
What Error Code 405 Means in Teams Phone
Teams Phone sits on top of several moving parts: the user account, the Teams Phone license, the PSTN connectivity model, routing policy, the Teams service, and sometimes an SBC or a compatible SIP device. Administrators often compare the behavior with other documented Microsoft Teams SIP error codes to determine whether the rejection originates in the user configuration layer, routing logic, or the SBC signaling path. Error Code 405 becomes useful only when you map it to the layer that rejected the method.
| Where You See It | What 405 Usually Means | Check First |
|---|---|---|
| Teams admin center with a final SIP code | A SIP entity rejected a method in the call flow | Whether the code was generated by Microsoft or by the SBC |
| SBC trace during transfer | REFER or an INVITE with transfer-related handling was not accepted | ALLOW header, transfer support, firewall, TLS path |
| User reports “calls fail” but the dial pad is missing | Usually not a real 405 root cause; user state is incomplete | License, Enterprise Voice, calling policy, PSTN model |
| Legacy desk phone or SIP endpoint | Policy, firmware, provisioning, or compatibility path is not aligned | SIP Gateway policy, provisioning URL, minimum firmware, device support |
Common Causes of Teams Phone Error Code 405
SBC Rejects a SIP Method
This is the pattern behind many real 405 cases. Microsoft’s Direct Routing SIP specification shows that call transfer behavior depends on the capabilities reported by the SBC. If the SBC says it supports REFER, the SIP proxy can send REFER to the SBC. If the SBC does not advertise that method, Teams changes the transfer behavior. In practice, a stale ALLOW list, partial transfer support, or an SBC profile that no longer matches the deployed firmware can trigger the rejection. [✅Source-3]
Transfer Path Is Not Aligned End to End
Many teams chase the wrong component here. A call can work normally and still fail on blind transfer or consultative transfer. Microsoft notes that if REFER is not supported, transfer can fall back to INVITE with a Replaces header, and if that still does not work, an internal transfer path is used. Microsoft also notes that SIP Refer can arrive on a new TLS connection from any Microsoft signaling IP, so narrow firewall pinning is a classic reason a transfer starts and then fails. [✅Source-4]
User State Is Not Fully Ready for Teams Phone
A Teams Phone license is only one piece. Microsoft is very clear that the PSTN solution is separate from the Teams Phone license. The user can be licensed for the phone application and still fail to place or complete PSTN calls if the tenant has not been lined up with Direct Routing, Calling Plan, Operator Connect, Teams Phone Mobile, or Shared Calling. That split causes a lot of false diagnosis. [✅Source-5]
If the user cannot even present a dial pad, stop and correct that before blaming signaling. Microsoft lists the dial pad prerequisites very plainly: the user needs a Teams Phone license, must be homed online, must be Enterprise Voice enabled, must have Make private calls enabled in the Teams Calling Policy, and also needs a valid PSTN connectivity option to place the call. [✅Source-6]
Enterprise Voice still matters. In Microsoft’s own setup flow, admins can turn Enterprise Voice on in the Teams admin center or use Set-CsPhoneNumberAssignment in PowerShell. When the number is assigned online, the same command automatically enables Enterprise Voice for the user. Small checkbox, large impact. [✅Source-7]
SIP Gateway and Desk Phone Specific Breaks
For compatible SIP devices, the policy path is easy to miss. Microsoft’s SIP Gateway configuration article states that the setting AllowSIPDevicesCalling defaults to False, and users cannot use SIP devices for calling until that policy is enabled. The same article notes that policy propagation can take up to 24 hours. It also requires the provisioning server URL to use HTTP, not HTTPS, which is another quiet failure point on desk phone deployments. [✅Source-8]
Firmware and compatibility still matter, even in a clean tenant. Microsoft’s SIP Gateway troubleshooting content tells admins to verify device compatibility, minimum supported firmware, credentials, policy state, and network reachability to the SIP Gateway service. When the symptom appears only on a subset of legacy phones, that is the right lane to investigate first. [✅Source-9]
How to Isolate the Failing Layer Fast
- Confirm the user can actually use Teams Phone: license, PSTN model, Enterprise Voice, and dial pad state.
- Run the built-in Direct Routing diagnostic for the affected user.
- Open the SIP call flow for the failed call and inspect the exact SIP message that returned 405.
- Compare the final SIP code with the Microsoft response code. That tells you whether to begin at the SBC or in Microsoft’s side of the path.
- If the failure happens only on transfer, inspect whether
REFER,NOTIFY, and transfer fallback behavior are all supported consistently. - If the failure happens only on a SIP desk phone, verify calling policy and device provisioning before touching the voice route.
Microsoft provides a tenant-side Direct Routing diagnostic that checks whether the user is configured correctly and returns next-step guidance for tenant, user, and policy problems. That should be the first admin action before packet captures. [✅Source-10]
The SIP call flow view in Teams admin center is the fastest way to see the chronology of messages between the SBC and Microsoft SIP Proxy. Microsoft documents the exact path: Analytics & Reports → Usage Reports → PSTN Usage Report → Direct Routing → Final SIP Code or SIP Call Flow. Microsoft also states that SIP call data can take up to 30 minutes to appear and that SIP call flow is not available for calls older than 30 days. [✅Source-11]
For longer pattern hunting, use CQD rather than the ladder view. Microsoft says CQD records are typically available within about 30 minutes of call end and remain for 12 months, while end-user identifiable fields are removed after 28 days. That is useful when 405 appears in bursts after a firmware change, an SBC template update, or a policy rollout. [✅Source-12]
| Operational Window | What It Affects | Why It Matters During 405 Troubleshooting |
|---|---|---|
| Up to 24 hours | SIP Gateway policy propagation | A desk phone can keep failing after a correct policy change if you test too early |
| About 30 minutes | SIP call flow processing | A fresh failed call may not appear in Teams admin center immediately |
| 30 days | SIP call flow availability | Older call traces require another evidence source |
| 12 months | CQD retention | Useful for trend analysis after config or firmware changes |
| 28 days | EUII retention in CQD | Do not wait too long if you need user-identifiable evidence |
Admin Checks That Usually Clear the Issue
User-Side Verification
- Teams Phone license is assigned
- A valid PSTN connectivity model exists
- Enterprise Voice is enabled
- Make private calls is enabled in calling policy
- The phone number is assigned correctly, or Shared Calling is configured correctly
- The user is homed online
Routing and SBC Verification
- The correct gateway is enabled
- The voice route pattern matches the dialed number
- The online voice routing policy contains no hidden invalid characters
- The SBC advertises only the methods it really supports
- Transfer-related methods are handled cleanly end to end
- Firewall rules allow Microsoft signaling traffic on new TLS sessions
Microsoft’s outbound-call troubleshooting article is still one of the most useful checkpoints here. It calls out three quiet but common admin errors: missing dial pad because the user is not fully provisioned, voice route patterns that do not match the dialed number, and invisible invalid characters in the online voice routing policy after copy-paste from rich-text editors. It also tells admins to verify that the target SBC gateway is actually enabled. [✅Source-13]
Get-CsOnlineUser -Identity "user@contoso.com" | fl Identity,EnterpriseVoiceEnabled,HostedVoiceMail,OnPremLineURI,LineURI
Get-CsPhoneNumberAssignment -AssignedPstnTargetId "user@contoso.com"
Get-CsOnlinePSTNGateway | fl Identity,Fqdn,SipSignalingPort,MaxConcurrentSessions,Enabled
# If the user has no Enterprise Voice flag yet:
Set-CsPhoneNumberAssignment -Identity "user@contoso.com" -EnterpriseVoiceEnabled $true
# If the user needs a Direct Routing number assigned online:
Set-CsPhoneNumberAssignment -Identity "user@contoso.com" -PhoneNumber "+14255388797" -PhoneNumberType DirectRoutingFixes That Match the Way 405 Appears
- 405 only during transfer
Check the SBC’s advertised methods, especiallyREFERandNOTIFY. Then verify whether fallback handling forINVITEwithReplacesworks and whether new TLS sessions from Microsoft signaling IPs are allowed. - 405 only for one or two users
Stop looking at the SBC first. Verify the user path: license, PSTN model, Enterprise Voice, online homing, number assignment, and voice routing policy. - 405 only on SIP desk phones
CheckAllowSIPDevicesCalling, propagation delay, provisioning URL, compatibility list, minimum firmware, and device sign-in state. - 405 after a recent change window
Look for the nearest change in SBC firmware, SBC template, policy assignment, hidden route edits, number assignment, or device reprovisioning. These are the changes that most often move a healthy call path into a method mismatch. - 405 with no useful client detail
Use the Teams admin center ladder first. Then export the evidence set: failed timestamp in UTC, caller, callee, final SIP code, Microsoft response code, exact SIP message that returned 405, gateway used, and whether transfer or hold was involved.
What Saves Time A short escalation bundle works better than a long narrative. Send the failed UTC timestamp, user UPN, called number, whether the action was dial, transfer, or resume, the final SIP code, the Microsoft response code, the ladder screenshot, and the SBC trace for the same call. That packet gives the next engineer something concrete to follow.
FAQ
Does Error Code 405 Always Mean a Licensing Problem?
No. In Teams Phone, 405 usually points to a SIP method rejection. Licensing and user provisioning still matter because an incomplete user state can hide the real voice path, but the number itself is much more closely tied to signaling behavior than to simple licensing.
Where Should I Confirm Whether Microsoft or the SBC Generated the 405?
Use the Teams admin center and compare the final SIP code with the Microsoft response code. If the Microsoft response code starts with 560, begin with the SBC logs. If it does not, investigate the Microsoft-side call path and the user configuration next.
Why Do Normal Calls Work While Transfer Fails With 405?
That pattern usually means the basic call path is healthy but the transfer method path is not. The SBC may not be handling REFER, NOTIFY, or the transfer fallback behavior the way Teams expects. Firewalls that allow the initial session but block new Microsoft signaling TLS sessions can produce the same pattern.
Can a Missing Dial Pad Cause Error 405?
Not directly. A missing dial pad usually means the user is not fully ready for PSTN calling. Fix the prerequisites first: Teams Phone, PSTN connectivity, Enterprise Voice, online homing, and calling policy. Only then does the 405 investigation become clean and trustworthy.
How Long Should I Wait After Changing SIP Gateway Policy?
Microsoft notes that policy propagation can take up to 24 hours for SIP Gateway changes. Test too early and you can misread a propagation delay as a continuing configuration fault.