Running Sonus SWe Lite "To-Go"

Finally, the Sonus SWe Lite is out, and its exciting times. This is a great VM to use in your environment, but it also means that you can have your very own SBC to test configs, and play with any time you like.

If you are like me, I use Oracle VirtualBox for all my VMs on my machine. I am not going to go into the reasoning as to why I use VirtualBox, I am sure many out there can explain it better than I can.

However, the SWe Lite VM only comes in 3 flavours, Hyper-V, VMWare, and KVM hypervisors. I took the VMWare package and imported it into VirtualBox, but it failed straight off the bat. After several trials, I have finally found the tweaks to make this work...

First, create your own virtual machine, and do not import the OVF (or OVA) file...

After creating the VM (with no disks attached); copy the VMDK files from the OVA file to their new home...

 

Next attach the disks to the VM using the Oracle VBox GUI (or the CLI if you like that sort of thing)...

Now for the trick that took me a few hours to figure out. You need to have 5 NICs and not 4 (the maximum you can see in the GUI). The only way to do this, is via the command line interface

N.B. If you are feeling brave, you can add it manually by editing the vbox file (Yes ... it says don't edit it .. but you can .. as long as you have VBox closed while you do it). Just in case you are, here is a screenshot of what mine looks like now...

 Once you have set this up correctly, you should now see in your GUI, the 5 interfaces...

Now you are ready to start the SWe Lite and configure the SBC. I recommend you have a read of Greig's well written post on the subject.

Sonus SBC Call Actions

I haven't found a place that explains the real life use case for this; so I thought I would write one for anyone that may search one day for how to do this.

I usually use this as a first step in the call flow, to manipulate the call before it gets to the routing stage.

As a simple example (don't want to get too complicated here). Let's say you want to mask certain caller IDs based on the "department" field in AD.

First thing, you need to setup the AD integration (lots of details on Google about how to do this), and make sure you synchronise (or otherwise leave it set to online) the AD attributes:

• msRTCSIP-Line
• department

Once you have got that working, you should create a manipulation table that will make the required changes to your call based on certain rules. In our case, it should check the "department" field and change the CallingNumber based on that.

Next an "Action" needs to be created to direct the call flow. In our example, we need to call to continue down its path regardless of the outcome.

This action will need to be used in an "Action Set" to modify the call flow. Again, in this case, we will allow the call to continue down the same path regardless. Quick gotcha here, the "Continue" option in the "Action Set" does not mean continue the call; it means continue the processing of the rules, so if you put "Continue" the call will fail...

Finally, you need to apply this "Action Set" to a signalling group for it to take affect. In our case, we will apply it to the "To/From SfB" so that it will be intercepted before the call is made out to the PSTN...

Sonus SBC AD Lookup Gotchas

I have recently been troubleshooting issues with a Sonus SBC 1000 doing call routing using AD lookups.

There are many blogs out there about how to do this, including the guide from Sonus themselves which is pretty descent.

Let me however, go into some of the gotchas that caught me by surprise, and are not well documented on the Sonus site...

AD Cache Lookup

There is a very clear note saying that it is "recommended" to have a USB stick attached to the SBC if you are going to use the AD Lookup in cached mode.

What there is no mention of, is the way the Sonus SBC uses the cache, and how it gets updated. This information was provided to me from Sonus TAC/Engineering, and is current as of the date of publishing this blog post; this applies to having the AD Configuration in "Updates" mode...

1. All domain controllers configured are treated equally; i.e. if any one of them responds back with a successful query, than the cache is valid, even if all the other queries fail.
2. The cache is dropped before the new cache is read; thus if the AD query fails, the system is left with "NO CACHE" unless you have a USB stick with a backup cache to be used.
3. if "ALL" domain controllers fail to respond, the SBC switches to online mode, and tries to query the domain controllers in order for the user in question.
4. The system will not try any failed domain controllers again until the next update cycle as configured in the "Cache Settings"

they have said that they are working on improving the process...

Case Sensitive Lookup

Apparently the lookup is case-sensitive; while simply testing for "=msRTCSIP-Line=" in your transformation table may work most of the time, if a Lync administrator decides to type "Tel:+xxxxx" instead of "tel:+xxxx" the query will fail to return a positive match.

To overcome this issue the recommendation is to use "(?i)=msRTCSIP-Line=" which would make the lookup case-insensitive.

Of course you can use the same "(?i)" in other locations too for matching without case.

 Lookup Limits

Transformation table lookups on the SBC have a hard limit of 256 characters for the string being manipulated. This is a hard limit and as per the Engineering team, the registers were never meant to hold large strings of data (such as memberof fields.

This is a major draw-back if you do routing based on group memberships or on other fields which may exceed this hard limit.