Teams Direct Routing 488 Not Acceptable Here: SDP, Codecs, SRTP
Short answer: Teams Direct Routing 488 (488 Not Acceptable Here) means Microsoft and your SBC finished enough SIP to negotiate media, then rejected the SDP. It is not an Inactive trunk (that is OPTIONS/TLS) and not a 403 (that is Contact/domain/identity). Read the Microsoft response code on the 488, then fix codecs, SRTP, ICE for media bypass, or a blackhole c= line.
Teams Direct Routing 488 is an SDP problem
You already have an INVITE. The SBC is usually Active. A capture shows 488 Not Acceptable Here from Microsoft (or from the SBC toward Teams) with an SDP offer or answer that Teams cannot accept.
Before you touch dial plans or voice routes, confirm the bucket:
| You see | Bucket | Start here |
|---|---|---|
| SBC Inactive, no INVITE | Signaling | Direct Routing troubleshooting |
| INVITE + 403 | Identity | Contact FQDN, verified domain, license |
| INVITE + 488 | Media / SDP | This guide |
| 200 OK, one party silent | RTP path | NAT, bypass, one-way audio section of the hub |
If OPTIONS never completed, stop. A 488 will not appear until Microsoft is willing to send or accept an INVITE.
Read the Microsoft code on the 488
Teams attaches an internal diagnostic on many 488s. Match that string before you change codecs for sport.
| Microsoft hint | What it means | First fix |
|---|---|---|
CannotSupportAnyMedia / Invalid SDP offer: no media acceptable | No overlapping codec or media format Teams will accept | Offer SILK, G.711, G.722, and/or G.729 on the Teams leg; enable transcoding toward a G.729-only PBX |
SrtpEncryptionRequired | Offer used plain RTP or missing SRTP crypto Teams requires | Force RTP/SAVP (or UDP/TLS/RTP/SAVP in bypass) with AES_CM_128_HMAC_SHA1_80 |
No ICE candidates / Non-ice endpoints cannot use bypass (531027) | Media bypass is on, SBC offered no usable ICE candidates | Enable ICE Lite on the SBC, or turn Media Bypass off on the gateway while you fix it |
Cannot negotiate a new modality with blackhole media (531052) | SDP connection address is 0.0.0.0 | Stop advertising blackhole media; put a real reachable address in c= |
Microsoft documents these combinations for Direct Routing PSTN calls. Calling Plan and Operator Connect are out of scope for that article.
Codec mismatch (the common 488)
On the leg between the SBC and Microsoft’s media path, Direct Routing expects codecs Teams actually uses: SILK, G.711, G.722, G.729. If the SBC only offers something Teams will not take (or forwards a carrier/PBX offer with no intersection), you get CannotSupportAnyMedia.
- Offer at least one common codec toward Teams. G.711 is the usual safety net.
- If the PSTN or PBX side is G.729-only, the SBC must transcode. Accepting G.711 toward Teams while the other leg cannot decode it is how you get a 488 or a one-way after a bad answer. See SBC transcoding with a legacy PBX.
- Strip unused payload types and ICE lines before you forward a huge SDP to a UDP trunk that will reject it. Do not strip the codecs Teams needs on the Teams-facing leg.
- Payload-type conflicts and “we answered a codec we cannot send” show up as 488 or as silent media after 200. Confirm the answer list matches licensed transcoder capacity.
PowerShell will not fix this. The dial plan and voice routing policy already did their job if the INVITE reached the SBC. See Teams dial plan vs voice routing policy only if the call never leaves Teams.
SRTP required
Teams Direct Routing does not do plain RTP on the Microsoft media leg. The SBC must offer and answer SRTP with AES_CM_128_HMAC_SHA1_80 in the SDES a=crypto line Microsoft expects.
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:<key||salt>|2^31
If the Teams-facing profile is set to RTP only, or crypto is optional and the offer goes out without it, Microsoft returns SrtpEncryptionRequired. Fix the Teams SIP interface / media security profile on the SBC. Do not “temporarily” allow RTP to Microsoft to debug audio.
Media bypass and missing ICE
With Media Bypass enabled on the online PSTN gateway, the SBC must behave as ICE Lite and put candidates in the SDP. No candidates → 531027 488: non-ICE endpoints cannot use bypass.
- Confirm
MediaBypasson the gateway:
Get-CsOnlinePSTNGateway | Select-Object Identity, Fqdn, MediaBypass, Enabled, SipSignalingPort
- On the SBC, enable ICE Lite for the Teams signaling group / media realm.
- As a controlled test, set Media Bypass off for that gateway. If 488 disappears and audio works through Microsoft media processors, your problem is ICE/candidates/firewall, not codecs.
- When bypass is back on, clients must reach the advertised candidate (or a working relay path). Split-tunnel VPN and missing UDP pinholes are the usual weekend burners. Detail: Media Bypass vs Local Media Optimization and Teams media bypass.
Blackhole SDP (c=0.0.0.0)
Some SIP stacks put c=IN IP4 0.0.0.0 to hold or reject media. Microsoft’s SIP stack does not accept that as a way to negotiate a new modality. You get 531052 488. Advertise a real address the peer can use, or reject the extra m= line cleanly (port 0 on non-audio lines you will not support) instead of blackholing the session.
Capture checklist for one failed call
- SBC Active? If not, leave this article.
- Direction: Teams→SBC or SBC→Teams? Who sent the 488?
- Copy InternalDiagCode / reason phrase from the 488.
- In the offer that was rejected, list
m=audiopayload types,a=crypto, ICE candidates, and thec=line. - Change one variable: codec list, SRTP, bypass off, or ICE Lite. Retest the same numbers.
Useful context for the path: Direct Routing call flow and how an SBC works with Teams.
Fix order that saves time
- Confirm Active + INVITE (signaling is done).
- Read the 488 reason / Microsoft code.
- SRTP + crypto cipher if
SrtpEncryptionRequired. - Codec intersection + transcoding if
CannotSupportAnyMedia. - Bypass off test, then ICE Lite / candidates if bypass-related.
- Remove
0.0.0.0/ blackhole media if that is the phrase. - Only then chase NAT and one-way audio if you already have 200 OK.
Do not rebuild certificates for a 488. Certs belong to Inactive and some TLS failures. Do not rewrite the Contact FQDN for a 488 unless you also see 403.
