Teams with SBC no DTMF tones

Iron Contributor

We have an AudioCodes SBC connected to Teams. We have about 10 users on it currently and 5 team room systems.

We cannot get DTMF tones to pass when calling from Teams. We've tested with webex and zoom dial-in numbers, godaddy support, and two other call centers we know about. none of them 

 

We opened a ticket with Microsoft and after lots of logs, they are saying this is a known issue.

 

Wondering if others have this issue or if its working for others using a SBC.

 

Thanks!

9 Replies
Hi,

tested this with Webex and it is working from my Teams App (iOS) and a Anynode SBC.

Regards,

Paul

@Jason Benway Is the problem still active ?  i hat a similar issue at a customers and found a misconfiguration in the SDP and Codex-description. So do you have the initial INVITE from Teams to your SBC as a trace?  the content of the SDP would be interersting. teams shoulf offer a 

 

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

and the SBC should answer. And if you enter DTMF in the teams client, you should receive the DTMF as "inband RTP-data" with the Codec "101". 

I can see that in my audiocodes Syslogs.  Check this and if thats working, then Microsoft is not the problem here.

 

You SBC should be able so see that and forward it to the other side. maybe it has to transcode it.

 

 

@Jason Benway  I too have this issue. 

@Jason Benway 

 

I have this issue too. And actually I see the where it is and only way for me to fix is to downgrade the call from SILK 16khz to 8khz. what happens actually is in order of precedence(removed unnecessary lines):

 

INVITE sip:+xxx97912293@xxxx;user=phone;transport=tls SIP/2.0
FROM: sip:+xxx611338147007@sip.pstnhub.microsoft.com:5061;user=phone>;tag=026e7e72646840f99212547e039cdb24
TO: <sip:+xxx97912293@xxxx:5067;user=phone>
CSEQ: 1 INVITE
CALL-ID: f642931530e0550ea9f08efab72d7927
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK4bab5048
RECORD-ROUTE: <sip:sip-du-a-eu.pstnhub.microsoft.com:5061;transport=tls;lr>
CONTACT: <sip:api-du-b-euwe.pstnhub.microsoft.com:443;transport=tls;x-i=a6a69dbd-c0c6-4291-819f-02fc2faa0987;x-c=/v1/ngc/call/f642931530e0550ea9f08efab72d7927/d/8/f040914ef8414a31b8393c5d0a174cb3>

v=0
o=- 115412 0 IN IP4 127.0.0.1
s=session
c=IN IP4 52.114.96.200
b=CT:10000000
t=0 0
m=audio 49608 RTP/SAVP 104 117 9 103 111 18 0 8 97 101 13 118
c=IN IP4 52.114.96.200
a=rtcp:49609
a=mid:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0KHVNa4xBWtHiVboykPbddnMSQ9Mlx5PQ0msi+7n|2^31
a=sendrecv
a=rtpmap:104 SILK/16000
a=rtpmap:103 SILK/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=ptime:20

 

My SBC forwards this to PSTN with PCMA and telephone-event 8khz. Reply(200OK) that comes from PSTN is:

 

s=SIP Media Capabilities
c=IN IP4 10.59.51.138
t=0 0
m=audio 5116 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

 

Reply forwarded to TEAMS is:

 

s=SIP Media Capabilities
t=0 0
m=audio 20164 RTP/SAVP 104 118
a=rtpmap:104 SILK/16000
a=rtpmap:118 CN/16000
a=label:main-audio
a=mid:1
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:SuPHLA6YgrTfVYL0jGiQiQToEtWFdjCXPvAQyxuj|2^31

 

 

So that SBC doesn't send any telephone-event back and actually I read this as perfectly normal behavior as i want my call to be transcoded from PCMA to SILK 16khz, however since initial offer havent had any telephone-event 16khz SBC cannot propagate in in asnwer. If i force my SBC to make transcoding PCMA to SILK 8khz last reply to MS looks as:

 

t=0 0
m=audio 20164 RTP/SAVP 103 101 13
a=rtpmap:103 SILK/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=label:main-audio
a=mid:1
a=ptime:20
a=sendrecv

 

and expectedly  all works then.

 

so question for Microsoft would be why there is not telephone-event 16kHz in client offer in similar fashion they offer CN?

 

thanks

Hi @Matej_Maric 

this is a bit strange. 

well first of all you are saying it is question to Microsoft but I would see this as question to SBC vendor because you mentioned it's in reply message from SBC to Teams. I would really focus more on the SBC setup in this case.

 

We are using Audiocodes SBC and DTMF tones are working bothway, also using transcoding for Teams clients to leverage SILK 16khz. 

(also using Media Bypass)

 

This is example of OK SDP response on provider's OK with SDP that is sent to Teams:

  • a=ice-lite
  • m=audio 51200 RTP/SAVP 104 101
  • a=rtpmap:101 telephone-event/8000
  • a=ptime:20
  • a=rtcp:51201
  • a=maxptime:200
  • a=ice-ufrag:YvsyU9OSVT3XpZet
  • a=ice-pwd:aGS4+u+UBXO+UL6sMwPaUYxb
  • a=candidate:123861241 1 udp 2130706431 ,,,,,, 51200 typ host
  • a=candidate:123861241 2 udp 2130706430 ,,,,,, 51201 typ host
  • a=rtpmap:104 SILK/16000
  • a=fmtp:104 maxaveragebitrate=50000; useinbandfec=0; minptime=20
  • a=crypto:1 AES_CM_128_HMAC_SHA1_32

@DaveChomi  @Jason Benway  So first of all I would let you know that DTMF is working absolutely fine in my other POC SBC's with SILK 16khz itself. I compared each and every setting with this SBC and non DTMF working SBC. The only difference I noticed is we got a license key from AC which has only 2 DSP channels where as working SBC has 100 DSP channels. I am quite sure that this shouldn't be the cause, but may be if you guys have anything to comment here. 

@DaveChomi 

 

Have to disagree as telephone-event is required to run with the same clock rate as audio codec negotiated. SDP you have posted I  understand works but it's not the way to do it.

 

sharing the same m line both this PTs are tied to a same SSRC and having different clock rate would cause different timestamps and then you have **bleep** load of mess ...it can work in theory indeed but this still a pure MS BUG.

 

BR

@DaveChomi @Matej_Maric So after trying all the possible steps to fix this, I thought let me put on my glasses :p and go through each and every config on Direct Routing Doc from Audiocodes, so found that Ice lite was disabled. So I enabled it and boom it started working, to make double sure that this was the cause, I disabled it and tested DTMF fails and when enabled it works. I know it doesnt make sense, but I think this is something to do with AC SBC version 7.20A.254.202. The POC AC SBC where all DTMF works with IceLite being disabled as well and the SBC version is latest - 7.20A.254.475. To conclude it looks like AC would have fixed this in latest version. 

@Roshan Kashinath 

 

glad this works for you and likely as you say something got improved in recent AC patches. what I'm trying to say is that ietf recommends different handling, something that may seem to work lovely from outside is actually error prone under surface. 

 

https://mailarchive.ietf.org/arch/msg/avt/Hx8rEwIQr9FYrTjP8D-TK41XCag

 

you don't want to deal with above unless is your last resort option. for those willing to make a deeper dive will be clear what I'm trying to say.