Teams Direct Routing SIP 488 Not Acceptable Here: SDP Codec & SRTP Mismatch Fix
What causes SIP 488 “Not Acceptable Here” in Microsoft Teams Direct Routing? A SIP 488 Not Acceptable Here response occurs when the Session Border Controller (SBC) or Microsoft Teams SIP proxy cannot accept the Session Description Protocol (SDP) media offer. In 90% of enterprise environments, this failure is triggered by one of four root causes: (1) SRTP encryption mismatch (Teams mandates RTP/SAVP with AES_CM_128_HMAC_SHA1_80, but the carrier or PBX offers unencrypted RTP/AVP), (2) Unsupported audio codecs (e.g., carrier offers G.729 or AMR without DSP transcoding enabled on the SBC), (3) Media Bypass ICE negotiation failure (BackToBackBypass offer declined by peer), or (4) RFC 2833 DTMF dynamic payload type clashes.
When an enterprise voice engineer sees a SIP 403 Forbidden or a SIP 408 Request Timeout, the troubleshooting path is straightforward: authentication, licensing, or IP reachability failed. But SIP 488 Not Acceptable Here is uniquely deceiving. The SIP signaling handshake (TLS socket connection, domain routing, and user lookup) completes successfully—only for the call to be instantly rejected at the media description phase.
Even worse, SIP 488 often manifests intermittently. Inbound calls from mobile carriers might connect seamlessly, while outbound calls to specific toll-free numbers fail with fast busy. Alternatively, initial calls succeed, but placing a caller on hold or attempting a consultative transfer immediately drops the line—leaving telecom teams chasing phantom carrier issues.
In this technical break-fix runbook, we deconstruct the exact SDP signaling failures behind SIP 488 Not Acceptable Here in Microsoft Teams Direct Routing, provide step-by-step configuration fixes for AudioCodes Mediant and Ribbon SBCs, and supply an automated PowerShell diagnostic script to isolate the root cause from Teams Call Analytics.
The SIP 488 Diagnostic Matrix: Root Causes & SIP Warning Headers
In SIP signaling, a 488 Not Acceptable Here response is almost always accompanied by a Warning header or a Reason header generated by Microsoft Teams or your SBC. Reading this header in your Wireshark trace or SBC syslog instantly reveals the exact mismatched SDP parameter:
| SIP Warning Header / Diagnostic Code | Primary Root Cause | Affected Leg | Immediate Actionable Resolution |
|---|---|---|---|
Warning: 399 ... "SDP Offer media transport RTP/AVP not allowed" |
SRTP Encryption Mismatch. SBC sent plain unencrypted RTP to Microsoft Teams. | SBC → Teams SIP Proxy | Enforce RTP/SAVP and SDES crypto profile on Teams IP Profile / Media List. |
Warning: 399 ... "Failed to negotiate codec" / 488 Incompatible media format |
Codec Mismatch. Carrier offered only G.729 / AMR, which Teams does not support. | Carrier ↔ SBC ↔ Teams | Enable DSP transcoding on SBC between carrier codec and Teams G.711u / G.711a / SILK. |
Reason: Q.850;cause=65 / Warning: 399 ... "BackToBackBypass offer declined by peer" |
Media Bypass ICE Failure. Teams client cannot reach SBC public IP/ports directly. | Teams Client ↔ SBC | Configure ICE-Lite/STUN on SBC WAN interface, or disable Media Bypass on PSTN Gateway. |
Warning: 399 ... "Unsupported crypto suite" / No common crypto suite |
Crypto Algorithm Conflict. SBC offered unapproved SRTP ciphers (e.g. AES-256 only or AEAD). | SBC ↔ Teams | Add AES_CM_128_HMAC_SHA1_80 to the SBC crypto suite list. |
SIP/2.0 488 Not Acceptable Here (on mid-call re-INVITE) |
Call Hold / Transfer SDP Renegotiation. PBX or carrier rejected a=sendonly or packet size change. |
SBC ↔ PSTN PBX | Configure SBC to handle hold locally or translate inactive/sendonly to RFC 3264 standard. |
1. Root Cause #1: SRTP vs. RTP Profile Mismatch (The Encryption Trap)
According to Microsoft’s official Teams Direct Routing Media Protocol Specifications, Microsoft Teams requires strict Secure Real-Time Transport Protocol (SRTP) for all audio streams between the SBC and Microsoft’s Media Processors. Plain RTP (RTP/AVP) is categorically rejected.
What Happens in the SIP Ladder
In standard enterprise voice architectures, the PSTN SIP trunk from your carrier (e.g., Lumen, Verizon, AT&T, Vodafone) delivers unencrypted RTP over private MPLS or dedicated SIP circuits:
[Carrier PSTN Trunk sends unencrypted SDP to SBC]
m=audio 16428 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
If your SBC is configured for Media Passthrough (Transparent B2BUA) instead of active Media Security Transcoding / Termination, the SBC simply passes the carrier’s RTP/AVP media line directly to Microsoft Teams on port 5061:
[Faulty Outbound INVITE sent by SBC to sip.pstnhub.microsoft.com]
INVITE sip:+14155550199@sip.pstnhub.microsoft.com:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS sbc1.contoso.com:5061;branch=z9hG4bK7810
...
m=audio 6000 RTP/AVP 0 101 <-- FATAL ERROR: RTP/AVP (Unencrypted) instead of RTP/SAVP!
[Immediate Rejection by Microsoft Teams Cloud Proxy]
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TLS sbc1.contoso.com:5061;branch=z9hG4bK7810
From: ;tag=99102
To: ;tag=1c8842
Call-ID: 8820491-ms-01
CSeq: 1 INVITE
Warning: 399 52.114.75.24 "SDP Offer media transport RTP/AVP not allowed; Secure RTP (SAVP) is required"
Reason: Q.850;cause=88;text="Incompatible destination"
Content-Length: 0
Fixing SRTP Encryption Mismatch
To eliminate this error, the SBC must perform media security conversion: terminate unencrypted RTP/AVP on the PSTN/Carrier interface, and negotiate encrypted RTP/SAVP with Microsoft Teams using RFC 4568 SDES (Session Description Protocol Security Descriptions).
The mandatory crypto-suite that MUST be advertised in the SDP offer to Teams is:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:W1VuZGVmaW5lZElubGluZUtleUZvclRlYW1zMDE=
2. Root Cause #2: Unsupported Audio Codecs & Dynamic Payload Clashes
A frequent trap when migrating legacy PBX systems (Cisco Unified Communications Manager, Avaya Aura, Mitel) to Microsoft Teams is assuming Microsoft supports standard enterprise telephony compression codecs such as G.729 or AMR-WB.
Crucial Architecture Fact: Microsoft Teams Direct Routing does NOT support G.729 on its SIP trunk interface. Teams natively accepts only SILK (wideband and narrowband), G.722, G.711u (PCMU), and G.711a (PCMA). If an incoming call from a branch office PBX offers exclusively G.729, Teams responds with SIP 488 Incompatible media format unless your SBC has DSP transcoding hardware or software licenses enabled.
DTMF Dynamic Payload Type Mismatch
Even when G.711 is used, calls can fail with SIP 488 during call setup or interactive voice response (IVR) navigation due to RFC 2833 / RFC 4733 Dual-Tone Multi-Frequency (DTMF) negotiation:
- Microsoft Teams expects
telephone-event/8000with dynamic payload type 101 (standard across North America and Europe). - Certain legacy PBX systems and international SIP providers assign DTMF to dynamic payload numbers such as 96, 100, or 102.
- If the SBC offers
a=rtpmap:96 telephone-event/8000and refuses to remap to 101, or if packetization timing (a=ptime) is set to an unsupported value (e.g.ptime:10orptime:40instead of the standardptime:20), Teams rejects the SDP with SIP 488.
3. Root Cause #3: Media Bypass Failure (BackToBackBypass Offer Declined)
When Media Bypass is enabled on your Microsoft Teams PSTN Gateway (Set-CsOnlinePSTNGateway -EnableFastConnect $true -MediaBypass $true), voice media (SRTP) bypasses the Microsoft Cloud Media Processors and flows directly between the internal Teams desktop/mobile client and your SBC’s WAN IP interface.
While Media Bypass drastically reduces latency and eliminates cloud processing hops, it introduces a fragile dependency on Interactive Connectivity Establishment (ICE-Lite) and client-to-SBC UDP port reachability.
The “BackToBackBypass Offer Declined” Sequence
- When a user places an outbound PSTN call, the Teams client generates an SDP offer containing multiple candidate IP addresses (local LAN, VPN, STUN reflex candidates) and SRTP keys.
- Microsoft’s SIP Proxy forwards this complex SDP directly to the SBC with
a=candidateICE lines. - If the SBC does not support ICE-Lite, has an expired TLS certificate, or fails to parse the complex multi-candidate SDP offer, the SBC responds to Teams with
SIP 488 Not Acceptable Here. - Alternatively, if the SBC accepts the offer with a
200 OK, but the remote Teams user is working from a hotel or restricted home Wi-Fi where UDP 50000–50019 is blocked, ICE connectivity checks fail within 5 seconds. Microsoft’s media engine tears down the bypass attempt with:Reason: Q.850;cause=65;text="BackToBackBypass offer declined by peer"
If your enterprise topology includes remote work-from-home users who do not connect via split-tunnel VPN, review our companion guide on Teams Direct Routing One-Way Audio Troubleshooting to verify perimeter firewall pinholes.
4. Vendor Step-by-Step Configuration Fixes
Fix A: AudioCodes Mediant SBC (VE, CE, and Hardware Appliances)
For on-premises Mediant appliances as well as cloud-native deployments (see our AudioCodes Mediant CE Azure Setup Guide and AudioCodes Teams Direct Routing Guide), configure the IP Profile and Media Realm to enforce SRTP and enable automatic transcoding:
- Configure Teams IP Profile:
- Navigate to Setup → Signaling & Media → Coders & Profiles → IP Profiles.
- Select your Teams IP Profile (e.g.,
IPP_Teams). - Under Media Security, set SDR Media Security to
Enable. - Set Media Security Method to
SRTP. - Set Symmetric MKI to
Enable. - Under Media Handling, set Transcoding Mode to
Only If Needed(requires DSP resources). - Set Extension Coders to
Enable. - Under SBC Media, set RFC 2833 Dynamic Payload Type to
101.
- Configure Coder Group for Microsoft Teams:
- Navigate to Coders & Profiles → Coder Groups.
- Add a Coder Group for Teams containing:
SILK(Payload 103, 104)G.711Ulaw(Packetization 20ms)G.711Alaw(Packetization 20ms)G.722(Packetization 20ms)
- Apply AudioCodes INI Message Manipulation to Strip Unsupported Codecs:
If an upstream carrier or legacy PBX sends an SDP containing G.729 alongside G.711, and the SBC lacks DSP hardware to transcode, you can strip G.729 from the outbound SDP offer sent to Microsoft Teams using this condition:
; AudioCodes INI Rule: Remove G.729 payload 18 from Outbound SDP to Teams
[MessageManipulations]
Index = 488
ManipulationName = Strip_G729_From_SDP
TargetHeader = SDP.Media
ActionType = Remove
Param1 = 18 ; Payload for G.729
Condition = Request.Request-URI.Host contains 'pstnhub.microsoft.com'
Fix B: Ribbon Communications SBC (SBC Core / SWe Lite / 1000 / 2000)
On Ribbon SBCs, SIP 488 errors almost always stem from an incomplete SDES-SRTP Crypto Suite Profile or mismatched Media List attached to the Signaling Group:
- Verify SDES-SRTP Crypto Suite Profile:
- In the Ribbon WebUI, navigate to Media → SDES-SRTP Profiles.
- Create or edit the profile attached to your Microsoft Teams trunk (e.g.,
Teams_SDES_Profile). - Ensure Crypto Suite 1 is configured as:
AES_CM_128_HMAC_SHA1_80. - Ensure Crypto Suite 2 is configured as:
AES_256_CM_HMAC_SHA1_80. - Set Key Life Time to
2^48(RFC standard).
- Configure Media List for Teams Trunk:
- Navigate to Media → Media List → Select
Teams_Media_List. - Set Supported Audio Codecs in order of preference:
G.711 U-Law (PCMU)(20 ms)G.711 A-Law (PCMA)(20 ms)G.722(20 ms)
- Set Silence Suppression to
Disabled. - Set Telephone Event (RFC 2833) to
Payload Type 101. - Set Media Security to
Mandatoryand attach theTeams_SDES_Profile.
- Navigate to Media → Media List → Select
- Adjust Signaling Group Media Bypass / ICE Settings:
- Navigate to Signaling → Signaling Groups →
Teams_Sig_Group. - If using Media Bypass, verify that ICE-Lite is set to
Enabled. - If Teams users experience sporadic SIP 488 drops when working remotely, toggle Media Bypass Mode in Ribbon from Direct to Relayed / Transcoded to force media through the SBC’s public interface.
- Navigate to Signaling → Signaling Groups →
5. Production PowerShell Diagnostic Script: Isolate SIP 488 in Teams
When end-users report dropped calls or fast-busy tones, you don’t need to dig through gigabytes of SBC syslog files. Use this automated PowerShell diagnostic runbook to inspect your PSTN Gateway configuration and query Teams Call Analytics for SIP 488 diagnostic headers:
<#
.SYNOPSIS
Diagnoses SIP 488 "Not Acceptable Here" errors on Microsoft Teams Direct Routing trunks.
.DESCRIPTION
Checks PSTN Gateway settings, validates Media Bypass configurations, and inspects
Call Quality Dashboard (CQD) and PSTN Gateway logs for SDP/SRTP mismatches.
.AUTHOR
Satya Pathak (SkypeExchange4U.com)
#>
[CmdletBinding()]
param (
[Parameter(Mandatory = $false)]
[string]$GatewayFqdn = "sbc1.contoso.com"
)
Write-Host "`n==================================================================" -ForegroundColor Cyan
Write-Host " TEAMS DIRECT ROUTING SIP 488 DIAGNOSTIC SUITE (SDP & SRTP) " -ForegroundColor Cyan
Write-Host "==================================================================`n" -ForegroundColor Cyan
# 1. Inspect Teams Online PSTN Gateway Configuration
try {
Write-Host "[*] Querying Microsoft Teams PSTN Gateway Configuration for $GatewayFqdn..." -ForegroundColor Yellow
$Gateway = Get-CsOnlinePSTNGateway -Identity $GatewayFqdn -ErrorAction Stop
Write-Host " [+] Gateway Identity : $($Gateway.Identity)" -ForegroundColor Green
Write-Host " [+] Media Bypass Enabled : $($Gateway.MediaBypass)" -ForegroundColor $(if($Gateway.MediaBypass){"Yellow"}else{"Green"})
Write-Host " [+] EnableFastConnect : $($Gateway.EnableFastConnect)" -ForegroundColor Green
Write-Host " [+] FailoverResponseCodes : $($Gateway.FailoverResponseCodes -join ', ')" -ForegroundColor Cyan
Write-Host " [+] ForwardCallHistory : $($Gateway.ForwardCallHistory)" -ForegroundColor Cyan
Write-Host " [+] ForwardPai : $($Gateway.ForwardPai)" -ForegroundColor Cyan
# Audit Media Bypass Configuration
if ($Gateway.MediaBypass -eq $true) {
Write-Warning "Media Bypass is ENABLED. If your SBC does not support ICE-Lite or remote users block UDP 50000-50019, calls will fail with SIP 488 'BackToBackBypass offer declined by peer'."
Write-Host " [RECOMMENDATION] If experiencing SIP 488 on outbound calls, test with: Set-CsOnlinePSTNGateway -Identity '$GatewayFqdn' -MediaBypass `$false" -ForegroundColor White
}
# Verify if 488 is in Failover Codes
if ($Gateway.FailoverResponseCodes -contains 488) {
Write-Host " [+] SIP 488 is registered as a trunk failover trigger. Teams will attempt secondary SBC routes." -ForegroundColor Green
} else {
Write-Warning "SIP 488 is NOT in FailoverResponseCodes. If an SBC rejects SDP with 488, Teams will DROP the call immediately instead of routing to a backup SBC!"
Write-Host " [FIX] Run: Set-CsOnlinePSTNGateway -Identity '$GatewayFqdn' -FailoverResponseCodes @{Add=488}" -ForegroundColor Yellow
}
} catch {
Write-Error "Failed to query Get-CsOnlinePSTNGateway. Ensure you are connected via Connect-MicrosoftTeams."
}
# 2. Check TLS Handshake & Certificate SAN Match
Write-Host "`n[*] Verifying Public FQDN Resolution & TLS Port 5061..." -ForegroundColor Yellow
$NetTest = Test-NetConnection -ComputerName $GatewayFqdn -Port 5061 -WarningAction SilentlyContinue
if ($NetTest.TcpTestSucceeded) {
Write-Host " [+] TCP Port 5061 is OPEN on $GatewayFqdn ($($NetTest.RemoteAddress))" -ForegroundColor Green
} else {
Write-Error " [!] TCP Port 5061 is CLOSED or UNREACHABLE on $GatewayFqdn."
}
# 3. Best Practice Media Settings Summary for Teams Direct Routing
Write-Host "`n[*] Mandatory SDP / Media Profile Standards for Teams Direct Routing:" -ForegroundColor Cyan
$MediaStandards = @(
[PSCustomObject]@{ Parameter = "Media Transport"; RequiredValue = "RTP/SAVP (SRTP Mandatory)"; FailureSymptom = "SIP 488 RTP/AVP not allowed" },
[PSCustomObject]@{ Parameter = "Crypto Suite"; RequiredValue = "AES_CM_128_HMAC_SHA1_80"; FailureSymptom = "SIP 488 Unsupported crypto suite" },
[PSCustomObject]@{ Parameter = "Audio Codecs"; RequiredValue = "G.711u, G.711a, G.722, SILK"; FailureSymptom = "SIP 488 Failed to negotiate codec (G.729 rejected)" },
[PSCustomObject]@{ Parameter = "Packetization"; RequiredValue = "ptime:20 (20 ms)"; FailureSymptom = "SIP 488 Incompatible media format" },
[PSCustomObject]@{ Parameter = "DTMF Relay"; RequiredValue = "telephone-event / Payload 101"; FailureSymptom = "SIP 488 or In-call DTMF failure" }
)
$MediaStandards | Format-Table -AutoSize | Out-String | Write-Host -ForegroundColor White
Related Production Troubleshooting Guides
To build a resilient enterprise Microsoft Teams Direct Routing infrastructure, explore our deep-dive break-fix library:
- Teams Direct Routing Calls Dropping After 30 Seconds: SIP ACK & Timer H Fix — Resolve asymmetric routing, Contact header NAT leaks, and 15-minute session timer drops.
- Teams Direct Routing One-Way Audio Troubleshooting Guide — Fix symmetric RTP, firewall NAT pinholes, and missing RTCP keepalives.
- Teams Direct Routing SIP 486 Busy Here & 603 Decline Guide — Resolve user busy states, simultaneous ring timeouts, and PSTN carrier rejections.
- Teams Direct Routing SIP 403 Forbidden Troubleshooting Runbook — Diagnose Enterprise Voice licensing, voice routing policies, and trunk FQDN certificate mismatches.
- Microsoft Teams Direct Routing & SBC Automation Runbook — Automate SIP OPTIONS pings, TLS cert renewals, and Teams webhook incident alerting.
Related M365 Automation Runbook: Preparing for AI deployment? Run our production audit script before licensing users: Microsoft 365 Copilot Security Audit: PowerShell Script to Detect Overshared SharePoint Sites & Sensitive Data.
Need to Quarantine a Sensitive Site from Copilot? Enforce perimeter security using our step-by-step runbook: Restricting Microsoft 365 Copilot from Sensitive SharePoint Sites: PowerShell & Restricted Access Control (RSA) Guide.
Frequently Asked Questions (FAQ)
Can I use G.729 audio codec directly with Microsoft Teams Direct Routing?
No. Microsoft Teams Direct Routing does not support G.729 natively on its cloud SIP interface. Teams accepts only SILK (wideband and narrowband), G.722, G.711u (PCMU), and G.711a (PCMA). If your carrier or legacy PBX sends only G.729, your Session Border Controller (SBC) must have DSP transcoding enabled to translate G.729 into G.711 or G.722 before forwarding the call to Teams. Otherwise, the call will fail immediately with SIP 488 Not Acceptable Here: Failed to negotiate codec.
Why do calls fail with SIP 488 only when placing a user on hold or transferring?
When a Teams user places an active call on hold or initiates a consultative transfer, the Teams SIP proxy issues a re-INVITE containing modified SDP parameters (such as a=sendonly, a=inactive, or a change in media port and packetization). If the connected carrier trunk or legacy PBX does not properly implement RFC 3264 hold semantics or rejects mid-dialog SDP renegotiation, it returns a 488 Not Acceptable Here response, terminating the hold or transfer attempt.
How do I fix “BackToBackBypass offer declined by peer” in Teams Call Analytics?
This error occurs when Media Bypass is enabled on the PSTN Gateway, but the Teams client cannot establish direct peer-to-peer UDP media connectivity with the SBC’s WAN interface (usually due to restrictive corporate firewalls or remote home networks blocking UDP 50000–50019). You can resolve this immediately by running Set-CsOnlinePSTNGateway -Identity <SBC_FQDN> -MediaBypass $false in PowerShell to proxy media through Microsoft’s cloud Media Processors.