Tuesday, January 13, 2015

AudioCodes Configuration Logic

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.

14 comments:

  1. Nicely done! I've been working with Audiocodes equipment for about nine years, and while their documentation is great for reference, it doesn't do a good job of explaining how to set up a basic configuration.

    ReplyDelete
  2. Great work as usual. I've been stalking your blog anticipating your next build. Funny. Thank you.

    ReplyDelete
  3. Hello Sir,

    Good to see you Tutorial.
    Have you word on SONUS SBC as well???? In case you have could you please relate the terms with it??
    anyways could you please explain what SIP GROUP NAME IS???
    why it is used...and how it is used?

    ReplyDelete
    Replies
    1. The configuration logic of SONUS vs Audiocodes is completely different. Not really any way to compare terms and it is why a lot of people stick to one vendor or the other. SIP GROUP NAME when configured is the portion of the SIP URI after the @ sign. So if you were doing a SIP invite with the From: being 5553331212@192.168.1.1 the SIP GROUP NAME would be 192.168.1.1. Hope that helps.

      Delete
  4. Thank you. I couldn't figure out how to route between to FXS ports on an AudioCodes MP-118 and your article helped me (Tel to Voice GW own IP, then IP to Tel).

    ReplyDelete
  5. The logic is so annoying. There is no capability to block a call so you have to manipulate numbers, and it fails more often than it works. You would think Destination Phone Number Manipulation to Tel to IP calls would allow you to block a specific source to destination number (inbound) by sending the call to some non existent number, but it rarely works. This shows up in an Exec's email/VM +85252277086 but the Audiocodes M100 ignores any rule I put in and the exec still gets spurious calls from some idiot. What's the simplest way to stop annoying stupidity from outside getting it to specific numbers? One simple block feature is all we need, but that apparently is asking too much from Audiocodes.

    ReplyDelete
    Replies
    1. I've done this many times and its pretty consistent for me. The way I go about it is that I do a syslog and I look for the pstn recv if its a PRI. Once I find that I look to see what the source number is. However that number is formatted is what you need for the next part.

      Go into your Destination Tel to IP manipulation table. Put in the number above into the "SOURCE" column and then set the rule to delete 16 digits and replace with a bogus number.

      My guess is that you are putting in the number hitting the VM with the + in front of it and that is not what is coming from the carrier. That number is prob being normalized by Lync/S4B and wouldn't match it at the time the AudioCodes is trying to manipulate.

      Delete
  6. I have an AC gateway with 2 E1 ports, 1 (first port) is already in use, connected to another SIP telephony system and PSTN.

    And subscribed another E1 (second port) line with new numbers. How could I route calls from new numbers to internal numbers attached with existing E1 port (first port) without going through PSTN and at the same time route external numbers through new E1 (2nd port)?

    Thank you.

    ReplyDelete
    Replies
    1. You have to purchase an IP to IP routing license. Then on your routing table you'd be able to use -1 to send it from IP to Tel and back through the Tel to IP tables

      Delete
  7. Hi, this is a good guide thank you. One thing I would like to know (new to Skype/audiocodes) what does SRD stand for? as in SRD table. Probably not missing much but need to know.

    ReplyDelete
    Replies
    1. It stands for Signaling Routing Domain (I had to look it up) I've always seen it as a way to specify which Network Interface is used for routing

      Delete
  8. I've been working with Sonus SBC's for the last 3 years and now have to start working with Audiocodes as well. I must say that I find the routing logic used by the Sonus SBC's much easier to understand and follow, especially when you have to route calls between multiple destinations within the environment.

    I am a big fan of using regex to normalize called and calling numbers on the SBC and usually do this to reduce/eliminate any changes required by coexisting systems. Does the AC support any sort of regex? or is the information in the dial plan section the only number manipulation supported on the AC?

    Your article does help to understand the AC a bit better, but it will take a whole lot more lab sessions to get my head around it.

    ReplyDelete
    Replies
    1. So none of the Mediants or MediaPacks do RegEx. I wish they would as well... They do have a new product called Advanced Routing Manager (ARM) that if you have a big deployment might be of help. It does do RegEx and things tend to be more graphical in that product. There isn't the notion of tel to IP or IP to tel in it.

      The biggest reason why I like AudioCodes is that they really expose lots of settings that allows me to tweak the setup in a very granular fashion. Unfortunately the downside is complexity. If you haven't looked at it yet... I strongly suggest you update the firmware to 7.2... the UI on that version is immensely better.

      Delete
    2. Actually Audiocodes does support regex, just not in the destination / source prefixes. The condition table can be used to do this and assigned to your routes. Its not as easy to see at a glance of the routing table what is going on though. I prefer Sonus over Audiocodes the logic is much easier to understand, but with 7.2 Audiocodes is much improved overall.

      Delete