Forum Discussion
Teams with SBC no DTMF tones
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
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:20My 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:20Reply 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^31So 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=sendrecvand 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 Matej_Maric So after trying all the possible steps to fix this, I thought let me put on my glasses 😛 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.
Jason Benway I too have this issue.
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-15and 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.
- Hi,
tested this with Webex and it is working from my Teams App (iOS) and a Anynode SBC.
Regards,
Paul
