VOSS Adaptations - Your Dial Plan, Your Way
Rob Hamlin, Rob Hamlin, Director Solutions Engineering, VOSS
When you talk to engineers about dial plans you learn that dial plans are funny things. Anyone who has logged into a CallManager knows that the idiom, “there’s more than one way to skin a cat” could not apply more to any one communications application. If you gave me a room with 10 IPT engineers and asked them all to complete a complex task in a CallManager, you would get at least four different ways of doing it.
You also learn in speaking to engineers that dial plan definitions are a overwhelmingly personal thing. Most IPT engineers love the way they do things and prefer to use their approach in most cases. At VOSS we are committed to providing tools that enable IPT engineers to run their CallManagers their way.
Next generation dial plan management is the newest way we enable the IPT architects and engineers to maintain and establish dial plans. No engineer that I have ever met looks forward to configuring a CallManager from scratch. Many times I have heard what they really want is a way to define a dial plan that let others push it out into CallManagers. This is exactly the approach we take for next generation dial plan management.
Dial plans are stored in what we call models. Models comprise all of the dialing instructions put into a VOSS structure using macro language to allow one overarching dial plan model to be applied repeatedly without update or intervention of any kind to that specific model. The models can also be created to push both global and site/local dial plan elements.
Models are loaded into VOSS-4-UC via an Excel spreadsheet commonly called a bulk loader. These spreadsheets are where the dialing definitions are entered for bulk upload to the system. The tooling caters for easy removal of a dial plan in its entirety for easy replacement via bulk loader.
In this example of a Media Resource Groups List the name of the MRGL is derived from the VOSS customer name with the literal extension of -MRGL. The associated MRGL is defined in the same manner with the -MRGL extension. Because the naming is dynamically set, the model can be applied repeatedly.
For arguments sake, let’s say that the customer name is not really ideal for a given dial plan definition and the IPT engineer wants to use a different naming structure that is unique to the organization. VOSS supports this as well.
In next generation dial plan management VOSS caters for data input at a global or site level. These data structures allow the dial plan designer to bring data from areas other than what might be available in VOSS-4-UC or the UC applications. The fields on the global and site level dial plan input data is completely optional. If a field is not used in the dial plan model it can be readily hidden away using the field display policy.
The dial plan data tab allows for input of data which is as a standard are found in many dial plans. One unique aspect is the Local Area Codes. If you had a locality that contains a large number of area codes, those area codes could be defined within this form and built to your dial plan specifications. In the translation and route pattern dial plan models there is a special designation for these patterns. If there was a need to add a mixture of route and translation patterns, that is supported as well. This is an example of where local routing patterns can be established in CallManager, without adjusting the dial plan model.
The Aggregation SIP input data tab allows the SIP trunk model to gather the IP and port information dynamically. The IP may be entered as free text, and ports are available via pre-established dropdowns.
The custom dial plan data tab is a place to define those data elements that are unique to the situation. In the example below, a country code, Customer ID and Country ISO are gathered to meet the input requirements of a specific dial plan. The field display policy has been updated to make the required input unmistakable to the administrator preparing to push the dialplan. In the dial plan model, the data is referenced with a specific set of macros. For example the Country Code would equal macro.DP_Site_CVal01.
Once the dial plan input is ready, it is time to push the dial plan into a CallManager. For this action, a tool is provided that has the ability to not only push but pull that data back out. In a case where the wrong dial plan was pushed, it can easily be removed with the same input.
The dial plan maintenance tool is a mechanism to maintain the dial plans in a CallManager. The inputs are minimal and dropdown driven. The administrator pushing the dial plan needs only to choose the dial plan name, the target CallManager, the push operation and all elements to push. The tool provides the ability to choose a specific CallManager to provide full support of loading dial plans into multi cluster environments.
When all the dial plan maintenance is complete, it is useful to have a record of the changes that have been made. At a glance, the dial plan log gives administrators a view of the actions that have been taken per hierarchy from a dial plan perspective. The system records the time of the action in UTC, the dial plan model that was changed, the dial plan elements included, the action whether it be push or remove, the target CallManager identifier, who performed the action, and at what hierarchy the action was taken.
At VOSS, we believe these new and advanced approaches to dial plan tooling will provider IPT architects with the ability to define any possible dial plan model imaginable and allow daily administrators to apply that dial plan to the UC servers without any outside intervention. This set of tools will allow the individual IPT architect to run their system their way.
For more information about VOSS Adaptations, please contact us.