Feb 26 2020 01:49 PM
Incoming calls to Microsoft teams get disconnected automatically after 20 seconds. You can make a call from outside, teams phone rings, answer the call, 2 way communication is there but still teams client showing calling on the screen. After 17-20 seconds into the call, it gets disconnect. Sys logs on the SBC shows that Teams is sending BYE signal with
REASON: Q.850 cause 18 text all Controller timed out while waiting for acknowledgement.
Outgoing calls from the same team's client works fine without any issues. Anyone experiencing the same issues? or have a solution? Teams support is working on this issue for 3 weeks now and we do not have a solution yet.
Feb 28 2020 02:26 AM
We are seeing the exactly same issue with one customer, an another deployment works just fine. Let us know if you hear anything about the solution.
Mar 03 2020 11:10 AM
@Eerik Kiskonen So far no update, all I am hearing is we are still looking into it.
Mar 03 2020 04:26 PM
Which SBC are you using? I assume because an SBC is involved, you're using Direct Routing?
Mar 03 2020 07:25 PM
@jangliss We are using AudioCodes SBC, yes direct routing is involved. Outbound call from teams to PSTN works perfectly but inbound from PSTN is teams disconnects after 17-20 seconds.
Mar 05 2020 05:18 PM - edited Mar 05 2020 05:18 PM
Mar 05 2020 05:45 PM
Mar 10 2020 01:40 PM
@Eerik Kiskonen Our issue is finally fixed.
The solution was SBC was sending the IP address in ACK messages for 200 OK it received from Teams. Teams expect contact header FQDN from the 200 OK in the ACK message, not the IP.
Mar 16 2020 05:44 AM
Apr 18 2020 06:24 PM
@Devaraj NarayanappaCould you share with us what is the correct way to send the Contact header in inbound calls?
I am trying like this but occur the same error.
Contact: <sip:CALLERID_NUMBER@SBC_FQDN:5061;transport=tls>
Thanks.
Apr 19 2020 01:47 AM
Actually for us this was not the reason, the reason was related to the network architecture and the Always Use Source Address parameter. This particular SBC is in a bit strange network configuration where the Teams-facing interface is on the public network and the internal SIP trunk and the user endpoints can only be reached via an MPLS connection of a 3rd party ISP connected to another interface.
The fix was to disable the Always Use Source Address on the SIP trunk IP Group as the SIP trunk could not be reached by Teams.
Jul 20 2020 05:17 PM
I have this problem and it is solved as the following.
- make sure the contact header in the 200 OK sent to the SIP provider is your SBC the correct IP, so the SIP provider will reply with ACK to the IP in the contact
Note: if you are using NAT or accessing a public SIP provider, so you need to NAT the IP from the internal to the external IP, then you have 2 options
hope this will solve your problem
Jul 06 2022 08:56 AM
I had problems with RTP on incoming calls. They cut off at 16 seconds. It connected the SIP part but not the RTP part.
My scenario is SBC Audiocodes VE on google cloud. The client is unable to bring up a second network interface on top of the virtual machine in the cloud. So I'm testing it for a single interface. Teams and a SIP trunk over the internet. This interface connects Public Ip --> Internal Ip.
I bring up the Teams service and the trunk - OK.
The incoming calls were cut on the Teams side because it did not receive the ACK, since the ACK was being sent to the Local IP and not to the public one for RTP.
So create a manipulation rule so that the CONTACT is the Public IP and that's it. The RTP worked and it doesn't cut out.