Zoom Phone Error Code 488 usually points to a call setup problem where the other side rejects the media offer before the call can fully connect. It is commonly seen when a SIP trunk or a managed voice device tries to negotiate audio, but the offer is not acceptable to the far end.
If the Zoom Phone app shows a longer number (for example, “Call failed (code: 2202xxx)”), Zoom documents that the error code is the last 3 digits. That is why a message ending in 488 is typically treated as “488” for troubleshooting. [✅Source-1]
Table of Contents
What Error Code 488 Means in Zoom Phone
In SIP terms, 488 is “Not Acceptable Here”. It indicates that the request could not be accepted by the specific endpoint you reached, usually because the session description (SDP) offered no compatible media options. [✅Source-2]
Practical meaning: Your call attempt reached something that speaks SIP, but it did not like the offer. This often feels confusing because you may have perfect internet, yet the call still ends immediately.
- Zoom Phone app (desktop/mobile): you might see “Call failed” with a code ending in 488.
- Desk phones / SIP devices: the device log may show 488 during the INVITE/SDP exchange.
- BYOC-P / SBC environments: the SBC trace usually shows the 488 response coming back from the far end (Zoom cloud, carrier, or PBX side).
Most Common Triggers Behind 488
In Zoom Phone deployments that involve an SBC (BYOC-P or BYOP-P), Zoom documents several requirements that map directly to 488 symptoms: Zoom expects SIP Early Offer on INVITEs, and lists a codec set for SBC interoperability (including Opus, G.722, G.711 µ-law/A-law, and G.729). When the offer does not include at least one usable option, a 488-style rejection becomes likely. [✅Source-3]
Negotiation Issues That Trigger 488
- No overlapping audio codec between the offer and what the far end can accept.
- SDP is altered by an SBC normalization rule (for example, stripping payload types or rewriting addresses in a way the far end rejects).
- Early Offer is missing or delayed when the far end expects it.
- Media line is present but “inactive/zeroed” in a way the far end treats as unusable (some platforms reject certain SDP patterns).
Tip: When you can capture a SIP trace, focus on the INVITE SDP and the first 488 response. That pair usually explains the “why” faster than guessing.
Environment Issues That Can Look Like 488
- One-way media expectations (for example, NAT traversal complications) that cause a device to offer unusable media addressing.
- Device profile mismatch (desk phone model settings or a SIP device template offering media that the peer will not accept).
- Mixed routing paths where some calls go native Zoom Phone while others go via BYOC, creating different negotiation behavior.
If calls to some destinations work but others fail, that pattern often points to a routing or interoperability difference rather than a general outage.
Fast Fix Steps That Usually Resolve 488
Start simple, then move toward negotiation details. The goal is to identify whether the problem lives in the client, the network, or the SIP interop layer.
- Confirm the call path: Is this a native Zoom Phone number, a BYOC number, or a call routed through an SBC? Knowing the path tells you where to look first.
- Try a control test: Call a known-good internal extension (or another destination you have seen work). If only one destination fails, the issue is often interop or routing.
- Switch the endpoint: If you used the desktop app, try mobile (or a desk phone), and vice versa. A change in endpoint changes the media offer and can quickly isolate the culprit.
- Reset network variables: Temporarily disable VPN, switch Wi-Fi to wired (or cellular to Wi-Fi), and retest. This checks whether the offer contains a problematic media address or port mapping.
- Move to SIP evidence: If you have an SBC or device logs, capture the INVITE and the 488 response. That pair is the shortest path to the real fix.
BYOC and SBC Checks Where 488 Often Lives
If your setup includes an SBC, treat 488 as a negotiation mismatch until proven otherwise. Small policy differences (codec order, SRTP requirement, early offer behavior) can change whether a call succeeds.
SBC Checklist That Directly Impacts 488
- Codec overlap: Ensure the SBC offers at least one codec the peer accepts. Keep the offer tight; avoid offering many rarely used codecs “just in case.”
- Early Offer behavior: Make sure the SBC sends an INVITE that contains SDP when that is required for your route. If your SBC supports a policy toggle, prefer the profile that produces predictable SDP.
- DTMF method consistency: Mismatched DTMF handling rarely causes a pure 488, but it can lead to interop rules that modify SDP in unexpected ways.
- SDP normalization rules: Review any rule that rewrites c= (connection address), strips payload types, or forces a specific ptime. Over-aggressive normalization is a common hidden cause.
- Media anchoring and NAT: If the SBC advertises an unroutable private address or an unreachable port range, the far end may reject the offer as unusable.
Step 1 Identify The Call Route
Native Zoom route behaves differently from BYOC/SBC routes. Separate the two before changing settings.
Step 2 Compare Working vs Failing Calls
Look for one difference in the SDP offer: codec list, encryption, or media address.
Step 3 Make One Safe Change
Prefer ordering or enabling overlap over big changes. Retest and capture a new trace.
Step 4 Confirm The Result
When 488 disappears, confirm calls to multiple destinations, not only one.
Network and Firewall Checks for Zoom Phone
A strict firewall or proxy can cause call setup side effects that show up as 488-like failures, especially when the endpoint cannot establish the expected signaling or relay paths. Zoom publishes specific Zoom Phone firewall rules, including ports used for Zoom Phone signaling and TURN support. [✅Source-4]
Network Items Worth Checking First
- Outbound ports: confirm the required TCP/UDP ports used by Zoom Phone are allowed from the affected network.
- TURN behavior: if UDP relay support is blocked, the endpoint may offer media details that the peer refuses.
- SSL inspection/proxy: if a proxy breaks TLS expectations, it can destabilize signaling and lead to “immediate fail” call behavior.
- Network changes: retest from a different network (hotspot or another LAN) to confirm whether the issue is environment-specific.
Security and Encryption Checks That Affect Negotiation
A security policy mismatch can also lead to a rejected offer. Zoom explains that Zoom Phone uses SIP over TLS 1.2 for signaling and uses SRTP for media protection in common app and device scenarios, with device encryption options that can be managed by admins. If your SBC or device is configured to require an encryption mode that the peer does not offer (or vice versa), the negotiation can fail early. [✅Source-5]
Red Flags in Traces
- SRTP required on one side but not offered on the other.
- Crypto suites do not overlap (device/SBC offers one set, peer expects another).
- Signaling TLS fails or is intercepted, leading to unstable setup and confusing symptom codes.
If you change encryption settings, keep it consistent across routes. Partial enforcement is a frequent source of inconsistent results.
Safe Adjustments to Try
- Prefer matching policy over “turning security off.” Align what the SBC/device requires with what the peer offers.
- Keep one route consistent during testing (same caller, same destination, same trunk).
- Document each change and retest immediately so the result is traceable.
When a change works, validate more than one call type: internal extension, external PSTN, and a known interop destination.
Troubleshooting Matrix for Zoom Phone Error Code 488
| What You See | Likely Cause | What to Do Next | Who Usually Fixes It |
|---|---|---|---|
| Call fails instantly with 488 on only some destinations | Interop mismatch on that route (codec, encryption, early offer) | Compare a working and failing SIP trace; adjust one negotiation variable | Admin/SBC team |
| Fails on one network but works on another | Firewall/proxy or NAT behavior affects media offer | Test without VPN; confirm required Zoom Phone ports are allowed | Network team |
| Desk phone fails but app works | Device profile offers different SDP (codec/encryption) | Review device/SIP template; align codec order and encryption policy | Admin |
| BYOC calls fail after a change window | SBC rule/policy drift | Rollback recent normalization/security changes; retest with a clean trace | Admin/SBC vendor |
| Only secure routes fail | SRTP requirement mismatch | Align SRTP requirements and crypto suites across both ends | Admin/Security |
What to Collect Before Escalating
When you hand this off to an admin, carrier, or an SBC vendor, a clean evidence bundle shortens the fix time. Keep it minimal but complete.
- Exact timestamp (with time zone) and how many retries you tested.
- Caller and callee information (extensions or masked numbers if needed).
- Endpoint type (Zoom desktop app, mobile app, desk phone model, SIP device).
- Network context (VPN on/off, Wi-Fi vs wired, office vs home).
- SIP trace excerpts: the INVITE with SDP and the 488 response (plus any Warning header if present).
- Recent changes (codec policy, SRTP enforcement, SBC normalization, firewall rules).
FAQ
Does Zoom Phone Error Code 488 Always Mean a Network Problem?
No. The most common theme is SDP negotiation being rejected. A restrictive network can contribute, but codec overlap and encryption expectations are equally important.
Why Do Some Numbers Work While Others Fail With 488?
This usually indicates a route difference. The working call may traverse a path with compatible codecs and policies, while the failing call hits a peer that rejects the offered media parameters.
What Should I Check First in a BYOC-P Setup?
Check the SBC offer for codec overlap, confirm the INVITE includes SDP when required, and review any SDP normalization rules that might be rewriting the offer.
Can VPN or NAT Changes Trigger 488?
Yes. VPN/NAT changes can affect the media address and port behavior advertised in SDP. A fast test is to place the same call without VPN and compare the offers.
What If a Desk Phone Fails but the Zoom App Works?
That often points to the device’s SIP profile. Compare the desk phone SDP with the app SDP; fix the mismatch by adjusting codec order, enabling overlap, or aligning encryption settings.
What Information Helps an Admin Fix 488 Quickly?
Provide a timestamp, the calling path (native vs BYOC), endpoint type, and the INVITE/488 pair from a trace. That evidence makes the root cause much clearer than repeated retries.