I've been working with AudioCodes products since the early 2000s. My first encounter was a couple of Mediant 2000s with 16 PRIs each. The configuration of those boxes for the most part was handled by following a document provided by Nortel. The funny thing is that most of the documentation over the years that has really helped has been solution specific guides done by a product manufacturer so that Audiocodes can work with their product.
The problem with Audiocodes is that its capabilities are so diverse and flexible that writing a single document that actually helps you through your specific configuration is nearly impossible. Years ago, you could actually download ready made configurations depending on what your PRI connection it was and you would be 99% there. Fast forward to today and configurations aren't that simple anymore.
The number one complaint I hear about Audiocodes is that it is so hard to configure and other products are ready to go in minutes. While I can't create any fancy wizards for Audiocodes configs, I can try to help people understand key parts of the AudioCodes configuration process so that the product is not as frustrating.
Global vs Profiles
One of the big concepts to get with Audiocodes is that there are many parameters that can be set at a Global Level and then overridden by a profile that applies to that feature. Profiles are useful for changing the behavior of communications to a particular system. For instance, if one system supports Early Media, but another does not, with Profiles you can adjust the signalling for each system. This applies not only to the IP side of the gateway, but also the TDM side if applicable.
Another key concept with profiles is where you can have them applied. Some profiles, like IP Profile can be chosen in several different areas, which I think adds to the confusion on configuration sometimes. For example if I am using an IP Group, I can specify not only a Proxy Set, but also an associated IP Profile. If I'm not using IP Group but instead specifying a single target IP in the routing area, again I can specify an IP Profile on the route itself.
As a best practice, I always use profiles to control the various different features for each system, even if they need similar settings, they each get their own profiles so I can adjust individual settings in the future.
Before I go any further I need to mention a couple of basics. First of all, when looking at the menu's I always recommend changing to the the Advanced or Full view depending on the system you are looking at.
Also, whenever you hit "Submit" the change takes effect immediately unless the system tells you it needs a reset. However, if the system has a power loss and you have not hit "Burn" then the changes are not saved permanently to the configuration. It is a good habit to burn frequently. It only takes once of having to redo your configuration to learn the lesson.
I also highly recommend doing backups of the configuration. Which can be done manually or you can use my
PowerShell script to do the backup
IP Groups
IP Groups are awesome because they pull together several different key pieces to communicating with other SIP systems. I use IP Groups primarily because I can specify a Proxy Set which allows for me to specify multiple IP addresses or DNS names for the system to send SIP signalling to, but I can also specify an IP Profile to be used too. This is key if you have multiple servers you need to communicate with that act as a pool or cluster.

Below you can see where we specify a proxy set (identified by a number) and the IP Profile as well. One thing to keep in mind is that you have to specify a SIP Group Name which ends up being the portion after the "@" in a SIP URI. The AudioCodes gateway/SBC doesn't really care what you put in here, but the far end system might. In the example I used the IP address configured on the AudioCodes network interface that communicates with that system. The network interface used is controlled by the SRD and Media Realm specified. If you have a system that uses a single IP, SRD and Media Realms is not used.
In the example below this is an SBC Enabled Mediant, so the SBC settings are exposed in the IP Group. Below are the defaults, which are fine most of the time, but if you needed to do some message manipulations for this IP Group this is where it would be specified.
IP Profiles
As mentioned before, IP Profiles control much of the SIP signalling and allow for adjustment per system we are communicating with.
I think many of the parameters are self explanatory, and if not the documentation can help understand what each of these parameters do. Most of the really good stuff in the example I've provided is in the SBC section below. If you have a TDM based gateway there options are different but many are similar.
The SBC area of the IP Profile is really one of the key aspects of SIP Signalling and truly is what makes an SBC a Back to Back User Agent and allows for the adjustment of signalling between disparate systems. As an example, one of the latest items I've had to adjust was the hold format to Intelepeer SIP Trunk that did not like the hold format Lync used.
Because this was an SBC Application enabled configuration, I could accept the hold format from Lync and send a different hold format to Intelepeer. Another piece that can be useful is controlling the REFER behavior, which sometimes has to be set to Handle Locally to keep disparate systems happy that don't understand REFER.
Coder Group
Coder Groups are pretty basic allowing you to specify a codec list and features (such as silence suppression) to be used when specified in an IP Profile above. If you have ever heard of transcoding between different codecs, this is where that magic happens for AudioCodes. You can specify G.711 for one IP Group and IP Profile and then specify G.729 in a different IP Group and IP Profile combination.
Tel Profile
This is taken from a TDM based system and not the same as the examples above from an SBC. I wanted to talk a bit about Tel Profiles because I've found having a different one for each one of your TDM lines is crucial. Tel Profile for each TDM trunk is specified in the Hunt Group area when you define what your different ports are doing.
Why?
Couple of features... Echo and Analog DID.
Controlling the volume is key for solving echo issues. Other than misconfigured microphones, the number one cause of echo issues is volume being too loud. Being able to control volume from PSTN (Input Gain) and to the PSTN (Voice Volume) for those lines that are too loud is the key feature that helps address the issue. Why is this? Because when the volume is too loud the reflected audio back from the far end isn't detected by the echo canceler and allowed to pass through as normal audio. If you wanted to see this for yourself, increase the volume to the PSTN to the point where it causes echo.
Also, if you have the unfortunate luck to encounter a site with Analog DID then Polarity Reversal and Enable DID Wink are key features in the Tel Profile you will need to enable on a per port basis.
VoIP Routing
One of the more confusing aspects of the AudioCodes configuration is VoIP routing (non SBC Application). The key is to make note of where the communications is coming from. This determines which of two routing tables you will hit. If the call is starting from the TDM/PSTN world, then you will hit the Tel to IP routing table. If you are starting from another SIP system or SIP Trunk then you will hit the IP to Tel routing table.
Sometimes, it is necessary to route from PSTN to an Analog port and in order to accomplish this you have to route the call to the gateway itself. The first line below is an example of that. Once you do this you will now hit the IP to Tel routing table which allows to routing to a Hunt Group (which in turn was assigned an Analog port).
Conversely, if you start in from another SIP system and you need to route to another SIP system through the Audiocodes, the call would hit the IP to Tel routing table first. The key to routing to the Tel to IP routing table going this direction is sending it to Hunt Group "-1". This technique may be necessary if you need to route analogs from MediaPack to MediaPack and want to keep it entirely in the AudioCodes world.
One other thing that almost always comes up is manipulation of numbers either Destination (Called) or Source (Calling). In the screenshots above the setting is to Route before Manipulation. This is my preferred method, but it is important before you start manipulating to understand if the manipulation will occur before or after routing. This will determine which numbers you put in your routing tables.
Now that I've mentioned this, I try very very hard not to do any manipulations in the gateway/SBC. I prefer to do all this in Lync. Sometimes there is no way around it, especially if you need to deal with manipulations when doing Fax or other analog solutions.
Dialing Plan Notations for Prefixes and Suffixes
AudioCodes is not nearly as flexible as
RegEx when it comes to number matching, but it isn't terrible if you know what you are doing. Below is from the AudioCodes documentation.
The dialing plan notation applies to the Number Manipulation tables, 'Tel to IP Routing' table and 'IP to Trunk Group Routing'. The dialing notation applies to digits entered for the destination and source prefixes to represent multiple numbers.
[n-m] Represents a range of numbers.
Note: Range of letters is not supported.
Example [5551200-5551300]#: represents all numbers from 5551200 to 5551300. 􀂃123[100-200]#: represents all numbers from 123100 to 123200.
[n,m,...] Represents multiple numbers. Up to three digits can be used to denote each number.
[2,3,4,5,6]#: represents a one-digit number that starts with 2, 3, 4, 5, or 6. 􀂃 [11,22,33]xxx#: represents a five-digit number that starts 11, 22, or 33.
[111,222]xxx#: represents a six-digit number that starts 111 or 222.
x Represents any single digit. 54324: represents any number that starts with 54324.
Pound sign (#) at the end of a number Represents the end of a number. 54324xx#: represents a 7-digit number that starts with 54324.
A single asterisk (*) Represents any number. *: represents any number (i.e., all numbers).
Conclusion
Give me some feedback on whether this hit the mark or not. I have a lot of information about AudioCodes up in my head and like the people that write the documentation, it is difficult to get it into a usable format for a wide audience.