Call Transfer and Call On Hold with Direct Routing


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.

12 Replies

Hi Ben,


I am also facing the same issue. have you got the resolution for the same?

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 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?  Modify


Yes, I am using Audiocodes SBC only. When I am clicking on call hold in teams client, it is disconnecting imeediately.

That's the same issue we had and making the message manipulation fixed it.

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= in response to the Re-Invite with Hold request from Teams. Microsoft Media Stack doesn’t support this format. So, SBC will replace 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.  

Yes, I also fixed this issue last week after doing the same configuration on audiocodes sbc. For call transfer I encountered "400 bad request" at sip trunk provider end. Probably you can check the refer settings in audiocodes sbc.

For what it's worth,  can confirm issue does not present on Ribbon (Sonus) SBC 1000 running firmware version 8.x

In Ribbon there had to be accommodations made to handle the null Refer message that is send from Microsoft when transferring occurs, e.g. normal refer message would have a from header of . the message for transfer sent is only, which is allowed by ITU standards.

For hold and Direct Routing we require that a=inactive is use. Legacy method with SDP containing CN with IP of 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. 

For those using Anynode SBC you can update to the just released Version 3.20.7 to fix this issue.



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.... :)





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.