REASON Q.850;cause 18 text Call Controller timed out while waiting for acknowledgement.

[Devaraj Narayanappa]

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.

[#2]

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.

[#3]

@Eerik Kiskonen So far no update, all I am hearing is we are still looking into it.

[#4]

@Devaraj Narayanappa 

Which SBC are you using? I assume because an SBC is involved, you're using Direct Routing?

[#5]

@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.

[#6]

Do 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)?

[#7]

We are using Audiocodes SBC too with recent firmware. PSTN side is a SIP trunk, no media bypass.

Unfortunately no log to provide, as I'm on vacation myself. If our technicians haven't solved that yet by my return I can provide one.

[#8]

@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.

[#9]

@Devaraj Narayanappa 

Great, have to try if that works. How did you exactly change it in the SBC?

[#10]

@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.

[#11]

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.

[#12]

@Devaraj Narayanappa 

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

[#13]

@Devaraj Narayanappa 

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.