Teams Direct Routing - DTMF tones on Inbound Calls not working

[DaveChomi]

The other day of Microsoft Direct Routing life in our enterprise environment and another nice issue appeared as reported from users. Might be it will help somebody.

Long story short: Microsoft accepts also not so standard DTMF type value than the more usual 101 on inbound calls to Teams users from PSTN side but at the end it sends payload which is not expected by on-premise SBC using 101. I believe this could be a bug which is visible in very specific setup and just on inbound calls.

Just more deep dive for those who likes that :)

Imagine that. Teams User receives PSTN call from competitor conferencing service and needs to dial hash sign or some digits in order to confirm joining conference. Teams user press desired combination but nothing happens. Dialpad is beeping but other side does not receive anything. 

I love Syslog viewer from Audiocodes. Already helped me a lot. So jumping into SIP messages I do see that call is offering in INVITE payload type rtpmap:96 for telephone-event. Ups, not standard value as far as I have seen. Value was basically coming all the way through on-prem PBX from our voice ingress of one remote site from ISDN gateway which was setup with this value. Well, not a problem as Microsoft sends as response INVITE where obviously accepts that value too... see the capture with response from Teams SIP proxy. 

Okay, what could be he problem then. Seeing debug logs of the SBC I found what happened actually when I press any digit on Inbound calls to Teams. Nicely written "Totally wrong payload" :) 

Teams client was sending payload type 101 to the SBC. That's obviously not the right way.  

 So we basically changed the payload type on our ISDN gateway to provide payload type 101 which does not affect anything else but perfectly fix our issue with Teams :) Probably quicker solution than fighting over Microsoft Support. But I believe somebody will catch this article and might provide fix. 

[#2]

@DaveChomi 

in your case depends actually what has been returned back in 200OK as reply to that posted PT 96  RE-INVITE from TEAMS. Maybe 200OK carries 101? by standard TEAMS should honor the answer

PT is not something you negotiate, offerer indicates what PT payload it will receive and would prefer to send however answerer may answer different PT and offerer has to comply sending different one, so it might be asymmetric.

If your "PSTN" reply also carries PT 96 back in 200OK that would be expected(but not mandatory) then MS misbehaves.

hope it helps.

[#3]

@DaveChomi 

Tested this quickly and you are absolutely right! end to end negotiation for tel-event was 96 and MS still sends PT 101

while the very last SDP from MS was:

SIP/2.0 200 OK
FROM: sipp<sip:sipp@xxxxxx:5060>;tag=14806SIPpTag091
TO: sut<sip:+18579901522@sip.pstnhub.microsoft.com:5060>;tag=aea750caffffffff783ba42de1144988
CSEQ: 1 INVITE
CALL-ID: 1-14806@192.168.2.50
VIA: SIP/2.0/TLS 192.168.65.100:5061;branch=z9hG4bKjsrauu0050fbcetu5op0.1
RECORD-ROUTE: <sip:sip-du-a-us.pstnhub.microsoft.com:5061;transport=tls;lr>
CONTACT: <sip:api-du-b-usea.pstnhub.microsoft.com:443;transport=tls;x-i=ae3a478a-7b34-41e7-89a9-76d4539810ad;x-c=/v1/ngc/call/1f2c4d2429a35cd782ce74fac9e08a30/s/1/640ba63046144b878e093a46d3954236>
CONTENT-LENGTH: 1295
CONTENT-TYPE: application/sdp
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SERVER: Microsoft.PSTNHub.SIPProxy v.2019.11.28.2 i.USEA.0

v=0
o=- 0 1 IN IP4 52.114.73.200
s=session
c=IN IP4 52.114.73.200
b=CT:50000
t=0 0
m=audio 52284 RTP/SAVP 0 13 96
a=ice-ufrag:nTGe
a=ice-pwd:4T8BipohUSo0fd1z+Z/SOOfd
a=rtcp-mux
a=candidate:10 1 UDP 184544254 52.114.73.200 52284 typ relay raddr xxxxxx rport 50010
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6WFePvmprtmBvE9ftmV9BhgDnF8JiOd7o/XNAxZ4|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20

hope they pick it up soon
a=maxptime:200

[#4]

You are also right @Matej_Maric, I didn't provide OK message with final SDP assuming as not necessary as MS already offered my payload type, right...

At the end I just forced on my SBC to use all the time 101 for Teams side. It was also confirmed to me as behind scenes conversations that they do not expect anyway nothing else than PT 101 from customers. 

[#5]

We've had the same issue with Teams.  We have 2 different use cases where calls come in via AT&T to our SBC (AudioCodes), and then to Teams.  AT&T offers Payload Type 100.  Microsoft responds with Type 101, and the tones are not recognized by the originating system.  We even tried configuring our AT&T IP Profile to use 101, but that didn't work either.  We added some transcoding licenses to the SBC, and it resolved our issues.

[#6]

@TMullenJr what setting did you apply for transcoding on the AudioCodes device?

Thanks