I had the situation where Microsoft Teams is configured for Direct Routing and calls are dropped unexpectedly. We are using an Audiocodes SBC in Microsoft Azure and a SIP Trunk from Deutsche Telekom for the PSTN connection.
Sometimes an inbound call is signaled by Microsoft Teams for a second and then, it is dropped. In the Microsoft Teams activity feed a missed call is visible. Also, a missed call was shown in the activity feed even there was no ringing.
At first, I thought I could bring it down to cell phone calls only. But after asking my colleagues some users reported the same behaviour for calls coming from PBX systems.
Troubleshooting – Part One
As usually, I started troubleshooting with the Audiocodes Syslog Viewer. If configured correctly, the Audiocodes SBC sends a SYSLOG message for every event and you can use this output for further analyzes.
First the inbound call looks fine. But in the ongoing SIP flow there is a “SIP CANCEL” message from the remote site. Because the user didn’t report “I hanged up”, I guess it wasn’t an user action. So we had to analyse the reason for the Cancel message.
In the cancel message itself, there was no information why the call was interrupted or cancelled.
Troubleshooting – Part Two
If the call is canceled by remote site, perhaps our SBC sends some kind of SIP messages which are not supported by the remote site. So, it took a deeper look into the SIP traffic coming from Microsoft Teams.
Because the cancel was sent by the remote site after “SIP 183 – Session In Progress” I focused on this step first. During analyzing the SDP body, I noticed that Microsoft Teams is sending in the SIP messages a limit for the bandwidth with 10000000:
I guess for some PBX or SBC systems on remote site, this value provided by Microsoft is too high and that’s why the call is
To solve this problem, I’ve created a SIP message manipulation to modify the mentioned parameter in the SDP body to a lower value.
The message manipulation is applied as inbound message manipulation for the Microsoft Teams IP Group.
Final tests from a PBX system and also from a problematic cell phone provider were fine and the call could be established successfully.