Microsoft Teams Direct Routing and Audiocodes SBC – Conflicting Payload Type

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 ACSyslog server. I opened the according syslog file and used the SIP flow diagram function to find the problematic call.

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.

488 Not Acceptable here answer by Microsoft Teams Direct Routing

Troubleshooting – Part 2 – some deeper analyze

But what is the reason for the 488 failure? Looking into the syslog messages, the error itself was found very fast: Microsoft Teams Direct Routing reported a duplicated payload type. Next step is to look into the SIP invite message, send out to Microsoft Teams.

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.

Duplicate Payload Type for SILK and DTMF with Microsoft Teams Direct Routing and Audiocdes

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.

Modified Payload Type for SILK Codecs and Microsoft Teams Direct Routing

UPDATE: Audiocodes confirmed the problem and will provide a fix for it in the upcoming release in August 2019.

Leave a Reply

Your email address will not be published. Required fields are marked *