If you are using an Audiocodes SBC to connect your SIP Trunk to Microsoft Teams Direct Routing, you had probably the situation, where inbound calls are failing.
I had this situation a few days ago and spent some time for analyzing it.
488 – Not acceptable here
More and more customers must deploy SIP Trunks. As a result, more and more different PBX configurations are out there in the world. Some SIP providers normalize the SIP messages according to a defined RFC standard. Other providers transmit the SIP messages unfiltered 1:1 to the remote site.
So, it is quite difficult and challenging to define the own SBC to understand and interpret all inbound SIP communication the right way.
Some users reported missed calls in Microsoft Teams even the soft client didn’t ring. First thought: Perhaps the same problem as described here in my other blog post.
Troubleshooting – Part 1
Luckily, I configured the Audiocodes SBC to send Syslog messages to my
The SIP call flow window already showed me the problem: the call was rejected with SIP error 488 – not acceptable here by Microsoft Teams SBC.
Troubleshooting – Part 2 – some deeper analyze
But what is the reason for the 488 failure? Looking into the
As our SIP trunk provider only supports G.711 A/mu-Law and G.729 as audio codec, the SBC adds the supported and suggested codecs SILK narrow and wideband to the outgoing SIP INVITE to Microsoft Teams. The payload type for SILK is dynamic and the administrator can define the value on his own (RFC). And here is the problem.
The Audiocodes SBC is using by default the payload type of 103 for SILK. When adding the SILK codec to the outbound SIP INVITE message to Microsoft Teams, actually the Audiocodes SBC doesn’t check for an already existing payload type with the same value. Under some circumstances, existing codecs can have the same payload type as the added SILK codec. For example, if the remote site PBX system is configured to use payload type 103 for DTMF.
And in this situation the Microsoft Teams SBC will reject the call.
Workaround
Actually, there is no solution to this problem. I have informed Audiocodes about this behaviour and they will check it in their lab. I guess, there will be fix in one of the next upcoming firmware releases. For the meantime, the best solution is to define another payload type for the SILK Codecs.
To do this, open the Admin page of your SBC and go to the codec profile page for the Microsoft Teams IP profile. Here you can change the payload type for both SILK codecs to a value between 110 and 129.
UPDATE: Audiocodes confirmed the problem and will
I opened the according syslog file and used the SIP flow diagram function to find the problematic call.
We actually had the same issue regarding DTMF. Took us a few days to recognize the exact cause. Nice to see that confirmed here.