Hi all,
a short one after quiet a while. A customer mentioned that their doorbell wouldn’t be working in combination with MS Teams. They suspected the DTMF to not „go through“ or being blocked at some point.
The scenario is that there is a doorbell with a phone number which is calling a number on MS Teams, once a button is pressed. Teams user is going to accept the call and the audio stream itself is fine.
Then the person pressing the button can hear the MS Teams user and vice versa. Once the Teams user decides to open the door, he or she presses the asterisk (*) on the dial-pad. But nothing happens.
This is where we started.
I checked a call in the syslogs of the AudioCodes SBC. From the signaling perspective all looked fine. Microsoft delivered a payload type of 96 being used for DTMF:
As I did not see any issues in any calls from the doorbell, we did a live trace and recorded all the media packets as well. A guide explaining how this could be done, is to be found here: https://www.audiocodes.com/media/13565/audiocodes-quick-reference-guide-how-to-debug-voice-with-wireshark.pdf , more details on the user manual.
… so we did the trace on the SBC and found out, that Microsoft is not sending what they showed us beforehand. I searched for ‚rtpevent‘ in the .pcap file, filtered for the UDP stream and see what I found:
We see there is a huge difference between what Microsoft told us in SIP (SDP) they would use for DTMF and what they are actually sending. To overcome this issue quickly – one can change the IP-Profile that is configured for the MS Teams side of this call.
- Just set the RFC2833 mode to ‚Extend‘ and the DTMF Payload Type to what Microsoft is sending to you (most likely it will be ‚101‘ always):
In our case this was a quick fix – and much faster than opening a case with Microsoft to ask them why they’re not doing what they said they would do.
Hope this could help anybody in the future.
Cheers,
Enrico
