Upcoming phone provisioning features - Translation Maps

Welcome back to part 2 of new Phone Provisioning features. This article will focus on the changes to Time Zone maps.

Translation Maps

Previous versions of Thirdlane had a component called Time Zone maps for the purposes of writing timezone values to various models of phones based on the vendor and the format of data the device is expecting for a specific timezone. A Polycom might write -18000 for EST5EDT where a Yealink might write -5 or a Cisco SPA might write GMT-05:00. The way the system knew which table to tie to a specific model of phone was via a rather convoluted and round-about association using Phone Model Groups. This was rather circular and not needed. It often involved declaring device types to templates and then to a specific Time Zone Map.

At the same time I felt that the previous provisioning section 'Variables for replacement in provisioning templates' under Device Provisioning -> Settings made little to no sense. In essence its purpose was to define a variable CAT and wherever ${CAT} was placed in a template it would write SIAMESE as the replacement. My opinion was that if I wanted to put SIAMESE in my templates, I would just put SIAMESE in my template and not ${CAT} since there could be no other value that could exist. It seemed that we already had a good variable substitution method in place for time zones and a rather obscure way of tying those time zones to a device

After some brain storming with Alex, it made sense to recycle the Time Zone maps engine, and expand it to allow other variables where you can declare a variable, and then list multiple values that the variable can represent. It also made sense to shed that rather circular and convoluted method of tying a map to a model of phone and instead just declare the map name in the models file of the provisioning template. Returning to our ${CAT} example, now when provisioning a phone, you can set and be given the choice of SIAMESE, RUSSIAN BLUE, TABBY, PERSIAN. The practical applications of this are rather endless, from whether or not a device needs to declare an outbound proxy to having different groups of phones enabling specific features that other phones should not have.

The final result consists of declaring translationmap= in the models file to match the name of the table that appears in Device Provisioning -> Translation Maps. This table contains two sections. The top section is an empty table where you can insert a custom variable multiple times, where each row contains a new potential choice for its replacement. For example you could insert CAT 4 times and each row set the values to SIAMESE, then RUSSIAN BLUE, etc. The lower section is our ever familiar time zone mapping where we list the time zone names, as well as the default value, and its subsequent value the device is expecting to see in its less-than-human-readable format.

I hope you are excited as I am about the new empowerment that this new mechanism brings to your base templates; moving what used to be command-line customization, into the UI for ease of end-user selection.