Forum Discussion
Devaraj Narayanappa
Feb 26, 2020Copper Contributor
REASON Q.850;cause 18 text Call Controller timed out while waiting for acknowledgement.
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.
- Cristian ArguelloCopper Contributor
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. - Mohamed HusseinCopper Contributor
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
- if you are using UDP or TCP: then the contact IP should be the internal IP and the Firewall will be able to do the NAT and change the contact IP to the external.
- If you are using TLS: then the contact IP should be the external IP as the Firewall will not be able to do the NAT.
hope this will solve your problem
- janglissSteel Contributor
Which SBC are you using? I assume because an SBC is involved, you're using Direct Routing?
- Devaraj NarayanappaCopper Contributor
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.
- janglissSteel ContributorDo you have a syslog trace that we could take a look at? I'm curious what information is being sent back and forth. Are you using media bypass? What kind of connection is the pstn side (sip/pri/etc)?
- Eerik KiskonenCopper Contributor
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.
- Devaraj NarayanappaCopper Contributor
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.
- nicolastanskiCopper Contributor
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.
- Devaraj NarayanappaCopper Contributor
Eerik Kiskonen So far no update, all I am hearing is we are still looking into it.