The Background
The company I work for has been users of Sonus/Ribbon SBC’s for just shy of 10 years and in that time the devices have become an absolute pain in the backside to support. We have been seeing one minor routing change or an Access Control Entry re-number in our firewalls that completely stops communication between the Ribbon SBC and Teams.
We decided the time was up on these SBCs and the plan was to move to a hosted solution, unfortunately, we found out one of the directors had signed a multi-year agreement with Gamma on our SIP service. In the end, we purchased an AudioCodes SBC, specifically a virtual one.
I hope the below may help you in configuring your AudioCodes device with Teams and prevent you from coming into the same issues we faced.
The Problems
The first problem we came across when we installed the SBC and followed the AudioCodes guide for Teams Direct Routing was the re-writing of specific headers or lack thereof. We noticed that the SIP TO header wasn’t being modified as it was being sent out to Gamma. We submitted a support ticket and all AudioCodes were saying is we needed to remove the Message Manipulation that we were trying to implement on the outbound leg to Gamma. After back and forth with them, we ended up just pursuing the issue with Gamma as turning off Message Manipulation wasn’t the answer. What was being sent to Gamma in the SIP TO header was: +441234567890@siptrunk.example.com. siptrunk.example.com being our FQDN of our TLS connection to Teams which had nothing to do with the outbound leg to Gamma who were expecting their gateways IP Address. After a load of back and forth with Gamma’s excellent support team, we identified five manipulations that needed to take place for both connectivity and also Caller ID:
FORMAT Index = ManipulationName, ManSetID, MessageType, Condition, ActionSubject, ActionType, ActionValue, RowRole;
MessageManipulations 0 = "To URL Host", 0, "", "", "Header.To.URL.Host", 2, "Param.Message.Address.Dst.IP", 0;
MessageManipulations 1 = "Contact Header Name", 0, "", "", "Header.Contact.Name", 2, "'01332333000'", 0;
MessageManipulations 3 = "P-Asserted-Identity", 0, "", "", "Header.P-Asserted-Identity", 2, "'<tel:01332333000>'", 0;
MessageManipulations 4 = "From Header URL User", 0, "", "", "Header.From.URL.User", 2, "'01332333000'", 0;
MessageManipulations 6 = "Request URI to Destination", 0, "", "", "Header.Request-URI.URL.Host", 2, "Param.Message.Address.Dst.IP", 0;So the first and last manipulation was needed so we could send the correct information to Gamma which was the Request-URI.URL.Host and TO.URL.Host had their SIP gateways IP Address in it rather than siptrunks.example.com. The other three were needed so that when we dialled out a customer would see the call coming from 01332333000.
Now that we got connectivity and are able to make and receive calls we migrated across to the new platform. That’s where the second problem occurred. What we identified was we were able to transfer blindly between a PSTN call and two users within Teams but were unable to perform a consultative transfer. We spent just over four hours checking and rechecking the REFER header configuration which is required in transferring within Teams however, we got nowhere.
In the end, we found a thread on the Microsoft forum relating to an issue with the lack of Music on Hold for consultative transfers, following this thread we re-read the AudioCodes integration document: https://www.audiocodes.com/media/13253/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-enterprise-model-configuration-note.pdf and noticed that it was an optional extra to configure this. We bit the bullet and set this up downloading a WAV sample file and using the DConvert utility available from AudioCodes to convert it to a .DAT file. We then set the IP Profile to use the internal audio file and hey presto Consultative Transfers started working.
I guess the issue here was with there being no audio being sent from Teams the AudioCodes SBC decided that the call was dead and decided to terminate the call.
What’s weird about this solution is we found that the original Teams music on hold was being played to the caller, not the one we uploaded (We purposely chose something completely different). However, it worked.
Random IT Stuff 