09-26-2018 06:05 AM
09-26-2018 06:05 AM
We are having an issue and have a ticket open with Microsoft and AudioCodes, but wanted to see if anyone else was having an issue with this. Whenever we try to transfer and put a call on hold it immediately disconnects the call. This is on inbound and outbound calls. Microsoft said it had to be using G711 and we worked with AudioCodes to make sure all calls to Direct Routing use that codec.
11-14-2018 05:35 AM
For Direct Routing there is no music on hold yet. But the issue we had was that the SBC was passing an IP address of 0.0.0.0 to Microsoft. So we had to do a message manipulation on the SBC to pass the correct IP address and it started working. Are you using an AudioCodes SBC?
11-14-2018 06:18 AM
Yes, I am using Audiocodes SBC only. When I am clicking on call hold in teams client, it is disconnecting imeediately.
11-19-2018 09:44 AM
According to Audicodes documentation this is fixed by setting Remote Hold Format in IP Profile to Inactive.
"Inactive (some SIP Trunk may answer with a=inactive and IP=0.0.0.0 in response to the Re-Invite with Hold request from Teams. Microsoft Media Stack doesn’t support this format. So, SBC will replace 0.0.0.0 with its IP address)"
In our deployment Hold works but we are experiencing issues with Call Transfer. The error we receive: " [ERROR] (#3)RTS::AllocateResource Allocate Resource - cannot allocate DSP. probably lack of resources". Even after we set Allowed Audio Coders to g.711 in both IP Groups and verify that only g.711 is used the error message come through.
11-19-2018 10:13 AM
11-19-2018 11:32 PM
For what it's worth, can confirm issue does not present on Ribbon (Sonus) SBC 1000 running firmware version 8.x
11-20-2018 08:18 AM
01-31-2019 11:49 AM
For hold and Direct Routing we require that a=inactive is use. Legacy method with SDP containing CN with IP of 0.0.0.0 is not supported. To insure that remote hold format use Inactive, we requested vendors update their documentation accordingly. If the default of transparent is used, its possible that a downstream device involved in the call and handling the signaling for the hold sends legacy method.
Please be sure that your SBC is configured to set the remote hold format as Inactive.
12-05-2019 02:21 AM
For those using Anynode SBC you can update to the just released Version 3.20.7 to fix this issue.
04-03-2020 08:02 AM
Totally struggling with the call transfer. Using Anynode, the call drops as soon a transfer is instigated, including from the auto-attendant. I've looking online but nothing conclusive to fix the problem. There is reference to REFER but am not seeing anything coming back from TEAMS
Any help or suggestions is appreciated! It is driving me up the wall.... :)
04-14-2020 01:19 AM
I am sorry to hear that. We are currently running anynode 3.20.11 without any problems.
What I have learned is to always make sure the numbers that are handled by MS Teams are with country code. So I added a manipulation in anynode to change all numbers whether source or destination since our SIP provider does not take care about that regarding to local numbers. We had strange issues in different functions before doing that.
by davidmcgrath on May 21, 2020
by DaveChomi on November 04, 2019
by davidm2626 on February 27, 2019
by Matt Landis on September 28, 2017