When Microsoft Teams Phone Error Code 488 appears, the call usually fails because Teams and the Session Border Controller could not agree on the media details carried in the SIP/SDP exchange. The dialed number may be valid. The route may even be valid. Still, the call stops because the media offer is not acceptable for that call leg.
For Teams Phone, 488 is not a generic mystery code. It becomes much easier to fix when you pair the final SIP code with the Microsoft subcode. If the Microsoft response code starts with 560, the final SIP response was generated by the SBC. If it does not start with 560, a Microsoft service generated the final SIP response. [✅Source-1]
Most 488 cases in Teams Phone sit in Direct Routing media negotiation, not in number normalization. Read the subcode, SIP phrase, and SDP together. That is the shortest path to a clean fix.
Contents on This Page
What Error Code 488 Means
In SIP terms, 488 Not Acceptable Here means the remote side received the INVITE or re-INVITE but rejected the offered session description because the proposed media, bandwidth, or addressing style was not acceptable. Administrators often compare this behavior with other documented Microsoft Teams voice signaling errors to confirm whether the rejection comes from codec negotiation, SRTP requirements, or media bypass negotiation. In other words, the call setup reached media negotiation and failed there. [✅Source-2]
For a Teams Phone admin, that wording matters. 488 does not tell you that Teams itself is down. It tells you that the media offer, answer, or update was unacceptable on that path. Not the dial string, but the media offer, is what usually breaks the call.
- SIP carries the signaling messages.
- SDP inside those messages describes codecs, transport, crypto, ports, and media addresses.
- SBC sits between Teams Phone and the carrier or PBX side in Direct Routing.
- Media bypass can change which endpoint negotiates media directly with the SBC.
Where This Error Usually Appears
Teams Phone Error Code 488 is most useful in Direct Routing troubleshooting, because that is where Microsoft’s SIP proxy, media services, and your SBC exchange SDP. Microsoft also states that these response codes are surfaced in the Teams admin center and in the Power BI Quality of Experience report for PSTN.
If you see Final SIP Code 488 together with a Microsoft subcode, start by matching the subcode to the exact media problem. If you see a 560-prefixed Microsoft code, start on the SBC side first. That split saves time, and plenty of it.
The Four Microsoft 488 Patterns
Microsoft currently documents four main 488 combinations for Teams Direct Routing. Each one points to a different media branch, so reading only the SIP phrase is not enough. Read the exact Microsoft subcode and the wording that follows it. [✅Source-3]
| Microsoft Subcode | Teams Phrase | What It Usually Means | Main Repair Direction |
|---|---|---|---|
| 531000 | CannotSupportAnyMedia / Invalid SDP offer: no media acceptable | The offered media format or attributes are not acceptable to Teams on that leg. | Align codecs, transport, payload mapping, and media address details. |
| 531000 | SrtpEncryptionRequired / Remote participant did not offer required SRTP support | The Microsoft-facing leg did not offer the SRTP support Teams expects. | Enable and verify SRTP on the Teams side of the SBC. |
| 531027 | There are no ICE candidates in the SDP. Non-ice endpoints cannot use bypass | Media bypass is in play, but the SBC did not provide ICE candidates. | Enable ICE Lite or test without media bypass for that route. |
| 531052 | Cannot negotiate a new modality with blackhole media | The SDP includes blackhole media behavior, commonly tied to 0.0.0.0 or hold logic. | Remove unsupported blackhole media behavior on the Teams-facing side. |
How To Pinpoint the Exact Failure
The Teams admin center SIP call flow is one of the fastest ways to see where 488 happened in the signaling ladder. Microsoft documents the navigation path, notes that SIP call data can take up to 30 minutes to appear, and states that call records older than 30 days are not available in that view. [✅Source-4]
- Open the failed call and record the Final SIP Code, Final Microsoft Subcode, and final SIP phrase.
- Check whether the 488 happened on the initial INVITE or on a later re-INVITE.
- Export or capture the matching SBC trace for the same timestamp.
- Compare the SDP in the failed call against a known-good call on the same route.
- Mark whether the call was inbound, outbound, transfer, forwarding, or hold/resume.
Simple calls may work. Transfers and hold/resume flows may fail. Often, it is the second SDP exchange, not the first, that exposes the mismatch.
How To Fix Each 488 Branch
Fix 531000 When Teams Says No Media Is Acceptable
This branch points to a rejected media offer. Microsoft states that the Direct Routing leg between the SBC and Cloud Media Processor, or between the SBC and the Teams client in media bypass, can use four codecs: SILK, G.711, G.722, and G.729. The same document also notes that media re-targeting is not supported when a re-INVITE changes media IP, port, or transport, and it recommends at least two ports per concurrent call on the SBC. [✅Source-5]
- Check the m=audio line and confirm the offered codecs are expected on that route.
- Compare payload type numbers, rtpmap, and fmtp between a failed call and a working call.
- Verify that the SBC is not offering a new media target later in the call when Teams is already locked on the original path.
- Confirm that the media IP and port in SDP are reachable and belong to the right interface.
- If the issue appears only during transfer, inspect the re-INVITE SDP, not just the first INVITE.
Fix 531000 When SRTP Support Is Missing
Microsoft’s Direct Routing standards state that the RTP traffic must be protected with SRTP and that the SBC must be able to establish keys using SDES. If the Teams-facing leg does not offer the expected SRTP support, the call can fail with 488 and the SRTP-required phrase. [✅Source-6]
- Make sure the Microsoft-facing trunk on the SBC is using TLS/SRTP, not plain RTP.
- Inspect the SDP for valid crypto lines and confirm the SBC is not stripping them.
- Review any interworking rule between the carrier side and the Teams side so that the Teams-facing leg still advertises SRTP correctly.
- Retest with one clean inbound and one clean outbound call after the change.
Fix 531027 When ICE Candidates Are Missing
This branch is tied to media bypass. Microsoft’s media protocol documentation says the SBC must support ICE Lite, must offer only one candidate, and currently supports only IPv4 candidates in that offer. If the SDP has no ICE candidates, bypass cannot work on that call leg. [✅Source-7]
Microsoft’s media bypass planning document adds more useful numbers. For direct media between the Teams client and SBC, the client-to-SBC path uses UDP/SRTP 50000-50019. For Transport Relay scenarios, Microsoft documents 50000-59999 between the relay and the SBC, with 3478-3481 also listed for another relay version. [✅Source-8]
- Search the failed SDP for a=candidate lines.
- Confirm that ICE Lite is enabled on the Teams-facing SBC interface.
- Verify that the Teams client can reach the public SBC media address when direct media is expected.
- If bypass is optional in your design, disable it for a short test and compare the result.
Fix 531052 When Blackhole Media Appears
This 488 branch usually appears when the Teams-facing SDP introduces blackhole media behavior. Microsoft also documents a Direct Routing deviation for hold and resume: the SIP proxy supports a=inactive, but does not understand a=sendonly or a=recvonly from the SBC on that leg. [✅Source-9]
- Look for c=IN IP4 0.0.0.0 in the failing SDP.
- Review the SBC’s hold/resume template on the Teams trunk.
- Replace unsupported hold signaling with a=inactive where needed.
- Retest the scenario that actually fails: blind transfer, consult transfer, forward, or resume.
Checks That Save Time
Microsoft’s monitoring documentation gives two operational details that are easy to miss. Direct Routing uses SIP OPTIONS from the SBC to monitor health, and an SBC is considered healthy when OPTIONS are sent at the regular one-minute interval and were seen during the last three minutes. The same document also says that descriptive error details are reported to Call Analytics or SBC logs, while rejected INVITEs and pairing issues may require SBC logs first. [✅Source-10]
What To Collect From Teams
- Final SIP Code
- Final Microsoft Subcode
- Final SIP Phrase
- SIP call flow timestamp
- Call direction (inbound, outbound, transfer, forwarding)
What To Collect From the SBC
- Full SDP body for the failed leg
- Codec list and payload mapping
- SRTP and crypto details
- ICE candidate lines
- Any re-INVITE sequence around hold, resume, or transfer
A Practical Repair Order
- Match the failure to the exact Microsoft subcode.
- Open one working call on the same route and compare the SDP line by line.
- Fix the Teams-facing leg first before changing carrier-side logic.
- Test with media bypass on and off if your design allows that comparison.
- Run a small matrix: inbound, outbound, transfer, and resume.
- Change one setting at a time. Small edits make the winning change easier to prove.
Error Code 488 is usually solvable once you stop treating it as one single error. Split it into its real branches: unsupported media, missing SRTP, missing ICE, or blackhole media behavior. After that, the repair path gets much shorter.
FAQ
Does Error Code 488 always mean a codec mismatch?
No. Codec mismatch is only one branch. In Teams Phone, 488 can also point to missing SRTP, missing ICE candidates during media bypass, or blackhole media behavior during re-INVITE handling.
Is Error Code 488 a user-side Teams app problem?
Usually not. Most documented Teams 488 cases are media negotiation issues in Direct Routing between Microsoft services and the SBC. That is why the SIP call flow and SBC trace matter more than desktop app reinstall steps.
Why do normal calls work while transfers fail with 488?
Because transfers, forwards, and hold/resume often trigger a new SDP exchange. The first INVITE may be acceptable, while the later re-INVITE introduces unsupported media, a bad hold state, or a new path that Teams does not accept.
Should I disable media bypass to test a 531027 case?
That is a sensible test. If the call works without media bypass, the failure likely sits in ICE Lite, candidate formatting, or media reachability on the bypass path rather than in the dial plan.
What is the first thing to read in Teams admin center?
Read the Final SIP Code, Final Microsoft Subcode, and final phrase first. Then open the SIP call flow and check whether the 488 happened on the initial INVITE or on a later re-INVITE.
Can a non-560 Microsoft code still require SBC changes?
Yes. A non-560 code means Microsoft generated the final SIP response, but the trigger can still be an SBC offer that Teams rejected. The Microsoft side explains the failure; the SBC configuration often provides the fix.