Hi folks,
I encountered an issue with a customer integrating their CUCM and Microsoft Teams through an AudioCodes SBC. The issue lied in the interoperability between CUCM (and UCCX) and the MS Teams cloud.
The CUCM handled numerous internal and external hotlines during the migration. During implementation tests, we needed to ensure seamless connectivity between Teams and CUCM. End users made calls from Teams to various CUCM lines, routed to UCCX in the background.
Cisco users reported an inability to hear the originating side. I took a Debug Recording from the SBC, confirming that the call was coming from MS Teams to SBC to Cisco. Cisco played an IVR announcement (g711ulaw payload) to the SBC, which was then forwarded to Teams. After that the Teams user pressed „one,“ to connect to some hotline, I confirmed the DTMF to work:
After the DTMF event(s), I could hear the CUCM audio stream from the hotline agent, who spoke a greeting and asked how she could assist. However, the agent couldn’t hear the caller, asking the caller to redial the hotline.
While reviewing the Debug Recording, I noticed that the audio stream from Teams to SBC was marked as „Modem Bypass“ traffic. The SILK coder, using payload type 103, was misclassified or misutilized – from my point of view.
Due to time constraints, I experimented a bit with the SBC settings in my lab instead of digging deeper into the modem bypass handling — something I still need to address.
Nevertheless, I identified the root cause for the missing audio on the CUCM side. The problem lies in the default settings of the SBC combined with the payload type delivered from Microsoft. They send PT 103 (SILK coder), and the SBC’s media settings default for Modem Bypass… is actually PT 103:
A simple setting to prevent such audio issues is to make the following adjustment (as example) :
These adjustments mitigate potential conflicts within SBC-configs/behaviors when dealing with the SILK codec.
Cheers,
Enrico
