The purpose for a SBC is to route calls – matching and modifying telephone numbers, adding diversions, applying calling names. Call Routes and Transformation Tables are the tools typically selected to perform these functions, but they are not the only, nor the most powerful, manipulation tools available in the SBC.
Action Sets operate similarly to Call Routes, but because Action Sets are performed before call routing, Action Sets provide the capability to perform a high degree of number normalization before engaging the call router. Even more importantly, Action Sets incorporate a powerful set of programmatic functionality that permits the construction of calling applications.
In this article you will learn the basics of Action Sets and their capabilities beginning with a quick review of basic call routing, look at the Action Set components, reveal the steps to create an Action Set, and finally follow the Action Set processing step-by-step.
Mapping SIP and ISDN Calling Numbers Into UX Information Elements
When a call arrives at SBC, the information contained in the incoming message (called number, calling number, name, etc.) is stored into variables within SBC. These variables are called Information Elements, a nomenclature lifted from ISDN definitions. So, for example, when a SIP call arrives, the number in the FROM header is stored in SBC's Calling Number IE. All arriving SIP headers or ISDN messages are similarly stored.
With the IEs stored, we need a way to compare and manipulate those IEs as a function of routing calls. Within the SBC, Transformation Tables provide this functionality. For instance, in a Transformation Table, called numbers can be matched and changed, caller's names can be looked up in AD and recorded in the Calling Name IE, or diversion headers can be added. This Transformation Table functionality works the same regardless of whether it is called from a Call Route or Action Set. However, there is a difference in Actions Sets and the Call Router when it comes to the persistence of manipulations. We'll talk about that in a second.
With basic call routing, Transformation Tables are tied to Call Routes. As a call route is executed, the associated Transformation Table is used to match, and possibly, manipulate the data within the IEs. For example, a Call Route to Lync can be associated with a Transformation Table that checks the called number IE against Active Directory's msRTCSIP-Line attribute. If a match is found, the call is routed to Lync. If the Transformation Table fails, all the IEs are restored to their original values before the next Call Route Entry is executed.
Call Routes (group into Call Route Tables) are executed in order from top to bottom. This processing path is immutable--every entry in a call Route Table is processed one at a time from top to bottom (unless the call route entry is disabled).
This fixed top-to-bottom processing works perfectly well for the vast majority of circumstances. But what if we wanted to do further processing based upon success or failure of the msRTCSIP lookup? Maybe the circumstances are such that we want to send the call to a different Call Route Table if the msRTCSIP succeeds, possibly to a shared Transformation Table that performs all the static transformations. This can't be done from a Call Route. From a Call Route, when the Transformation Table succeeds, the call is automatically routed.
In order to perform additional processing, we need a function that permits programmatic call processing. Action Sets are the answer. They perform a similar function as the Call Route Table, but with a completely different approach to processing.
Action Sets are called from the ingress Signaling Group and bypass the Call Route Table setting (if one is configured in the SG). Action Sets provide the opportunity to process transformations before sending the call to the call router. Think of it as a chance to normalize all the IEs before routing a call.
Not only do Action Sets provide normalization, but they also provide two levels of if/then logic: Actions and Execute If. These two features are the foundation for creating SBC calling application solutions.
Actions are configured from the Action Configuration menu. The available Actions are:
Action | Usage |
---|---|
Route Call | Route a call to the specific call route table |
Send Alert | Send Alert/Ring. To be implemented in the future with the One Number Fax function |
Send Connect | Send Connect/200 OK. To be implemented in the future with the One Number Fax function |
Route Call, Await Connect Timer | Routes the call and starts a timer. Automatically continues execution of the Action Set if the call is not answered before the timer expires. Can be used to create applications to send unanswered calls to a local voicemail store. |
Generic Timer | Provides a delay function in processing entries in the Action Set |
Invoke Action Set | Invoke a different Action Set. Provides the ability to continue execution with a different Action Set. |
Using these Actions, we can do things like:
Once some Actions are created, you need a way to use them. That's where Action Sets come into play.
An Action Set Table contains the list of entries that are executed when that particular Action Set is called (from the ingress SG). Unlike a Call Route Table, the entries in an Action Set are not necessarily processed in sequential order. Instead, by using Action On Success, Action on Failure, or Execute If (in any combination), you can control which Action Set entries are processed.
When an Action Set Entry is executed, the associated Transformation Table is evaluated to be either TRUE or FALSE (the result of whether the Transformation Table succeeded or failed in its matching). So far, exactly the same as an entry in a Call Route Table.
One difference between a Call Route and Action Set is that each entry in a Action Set contains an Action on Success and Action on Failure setting. These two settings provide control over the next step in processing based upon the outcome of the associated Transformation Set:
Processing will Continue with the next entry (if any) of the transformation is TRUE, but will disconnect the call if the transformation is FALSE.
Unlike the Call Routes, the SBC controls what happens when a Transformation Table succeeds or fails.
Using Actions, you can control how the processing proceeds: Route the call; disconnect the call; continue with the current or a different Action Set, etc.
When an Action Set is executed, the execution of individual Action Set entries is controlled by the Execute If. Call Route entries can only be Enabled or Disabled, but the execution of Action Set entries can be controlled based on success or failure of the previous entry.
If all Action Set entries are Always execute, and entries for Success and Failure are configured to Continue, regardless of the outcome, processing will continue.
Using Execute If in the order of entry execution can be controlled.
With Execute If, you can control which Action Set entries are executed based upon the success or failure of the previous entry.
Unlike Call Route entries, the IEs are not restored for each different Action Set Entry. Each change to an IE (in a successful Transformation Table) is carried throughout the entire Action Set Table. In this way, the IEs can be normalized over several entries before the call is routed. If you wish to retain a particular value, place it into one of the user-defined IEs (UserValue1-UserValue5).
Much like the configuration of Call Routes, there are a number of inter-dependencies in configuring Action Sets. The diagram (below) will help guide you through the process. Basic steps are below, refer to Creating and Modifying Entries to Action Set Tables for details.
The processing of an Action Set call includes the following steps:
SBC AD Integrated Application Solutions using Action Sets details a real-world application of Actions Sets to:
This application employs the Action Set's full capabilities. Reviewing this document should help solidify your understanding of Action Sets and put you on the path to creating your own.