Snom management (Part II)

I had a dream last night… for which I sincerely apologize now.

Since long time ago, when I woke up, I’ll turn on the TV and flip through the news channels with hope to hear the news that the Federal Government balanced the budget last night. So I did this morning, only to find out that since 47 years ago, no one is allowed to have a dream on this day. Oh well…

Managing Snom phone environment is not a dream. It takes, however, time and mental discipline to understand what a German mind wanted to say when wrote this manual. And now, I have even bigger problem to explain it in simple words. You see, we, whose native language is different from English, will construct every sentence on our language, translate it to English and say it, write it, whatever. So now I have to “decode” the German idea written on English, to Bulgarian and then back to English. What a mess…

With Snom, we have three core important components:

1. General Settings - settings which we want to apply to ALL Snom devices in our environment, for example, Language, Time Zone, Date Format, Time Format, VLAN’s, QoS tagging and so on.
2. Phone Specific Settings – settings to be applied to each individual phone. I do not intend to elaborate on this too much since you don’t want to use it in your OCS/Wave14 environment – I will explain later.
3. Firmware settings – information about the firmware version that MUST be installed on the unit.

In this example, I will refer to Snom300, but the concept is the same for all models. My domain is drago.ws and I have a webserver service installed on machine with FQDN - provisioning.drago.ws

Let’s put all his together.

Upon boot, snom300 will submit “Vendor Class Identifier” via DHCP Option 60 (“snom300” in this case). In this post, we configured our DHCP server to respond with “Predefined Options” (that is, Options we want to supply to any device that reports THIS particular “Vendor Class”. The reason is – we might have configured DHCP to respond with “Provisioning URL = http://provisioning.drago.ws “ to all snom300 phones, but “Provisioning URL = fox.drago. ws” to all snom370, snom820 and snom870.

Once my snom300 obtains the Provisioning URL, the unit will send HTTP GET request to the URL in format http://provisioning.drago.ws/snom300.htm – snom300 (the vendor Identifier) is appended at the end of the URL. This is by design and for simplicity – you don’t have to worry about encapsulating Option 67 within Option 43, although this is possible and must be used in some cases. I might elaborate on this topic some other day… To reply to this request, we must have, indeed, file named “snom300.htm” in the rood of our webserver with the following content:

<?xml version="1.0" encoding="utf-8"?>
<setting-files>
<file url="https://provisioning.drago.ws/general.xml"/>
</setting-files>

We have just told the unit to look for file named “general.xml” at this URL – https://provisioning.drago.ws. First – note that I want any further exchange between the phone and the webserver to be encrypted and second, told the phone what is the URL. This is because I could redirect the phone to a different URL if I had reason to do so.

Look at this sample “general.xml” file content:

<?xml version="1.0" encoding="utf-8"?>
<settings>
<phone-settings>
<settings_refresh_timer perm="RW">3600</settings_refresh_timer>
<language perm="RW">English</language>
<web_language perm="RW">English</web_language>
<tone_scheme perm="RW">USA</tone_scheme>
<timezone perm="RW">USA-5</timezone>
<date_us_format perm="RW">on</date_us_format>
<time_24_format perm="RW">on</time_24_format>
<ntp_server perm="RW">10.0.0.91</ntp_server>
<ntp_refresh_timer perm="RW">86400</ntp_refresh_timer>
<retry_after_failed_register perm="RW">60</retry_after_failed_register>
<codec_tos perm="">184</codec_tos>
<signaling_tos perm="">184</signaling_tos>
<update_policy perm="RW">auto_update</update_policy>
<firmware_interval perm="RW">480</firmware_interval>
<firmware_status perm="RW">https://provisioning.drago.ws/firmware.xml</firmware_status>
</phone-settings>
</settings>

Line by line breakdown:

<settings_refresh_timer perm="RW">3600</settings_refresh_timer> - 3600 is the number in seconds the phone should request, obtain and apply this file again, in case we want to push any change of settings.
<language perm="RW">English</language> - Language to be applied to the phone display
<web_language perm="RW">English</web_language> - Language to be used for the phone's web interface
<tone_scheme perm="RW">USA</tone_scheme> - DTMF tone scheme to be applied to the phone
<timezone perm="RW">USA-5</timezone> - Time Zone (Eastern Standard Time in this case)
<date_us_format perm="RW">on</date_us_format> - Date format
<time_24_format perm="RW">on</time_24_format> - Time format (US or "the rest of the world")
<ntp_server perm="RW">10.0.0.91</ntp_server> - IP address or FQDN of NTP server to be used by the phone for the phone clock
<ntp_refresh_timer perm="RW">86400</ntp_refresh_timer> - 86400 is the number in seconds before the next time sync.
<retry_after_failed_register perm="RW">60</retry_after_failed_register> - interesting parameter that forces the phone to reboot itself when registration fails for number of seconds - 60 in this case.
<codec_tos perm="">184</codec_tos> - Here we instruct the phone to tag the RTP traffic with DSCP Option 46 (Expedited Forwarding) QoS Type Of Service.
<signaling_tos perm="">184</signaling_tos> - same as the above, but tagging SIP (signaling) traffic.

The last three lines require special attention.

<update_policy perm="RW">auto_update</update_policy> - here we tell the phone to apply the firmware update automatically without user interaction/approval
<firmware_interval perm="RW">480</firmware_interval> - Hre we tell the phone to check every (480 in this case) minutes if new firmware is available.
<firmware_status perm="RW">https://provisioning.drago.ws/firmware.xml</firmware_status> - ...and finally, where the phone should check for the most current firmware the admin wants to apply.

To wrap up, here is an example of work flow:

We unbox new unit. Connect it to the network and powered it. The phone tells DHCP which model it is. DHCP returns info where the phone should go first for settings. The phone downloads the settings, applies (time, language, firmware URL etc) and…

…reads “firmware.xml” file with the following content:

<?xml version="1.0" encoding="utf-8"?>
<firmware-settings>
<firmware perm="">https://provisioning.drago.ws/300/snom300-OCS-8.5.3-SIP-f.bin</firmware>
</firmware-settings>

Here we just told that the phone MUST have version “snom300-OCS-8.5.3-SIP-f.bin” currently installed. At this point, the phone will compare the current FW version to the one in the “firmware.xml” and now we have two possibilities – the firmware on the phone is the same (the counter is reset and new cycle of 480 minutes begins), or the firmware does not mach. If the phone is not on call or off-hook, it will reboot, download the new firmware, apply it, read the general.xml and firmware.xml and register if provisioned with a valid account.

I placed the .bin file in separate folder - “300”, in order to keep some consistency i.e. firmware for model 300 is located in folder “300”, the one for model 870 in folder… “870” and so on.

Next week we will discuss where the parameters like "date_us_format" - come from and how we can add additional parameters to our provisioning files to get the most of the manageability story of Snom VoIP phones.