Unified Communications with Microsoft

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.

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 oto 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 86400 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.

Georgia Military College proudly announces successful implementation of the next generation of Microsoft’s communication and collaboration platform – code name “Wave 14” in Production environment! We are now moving users from OCS 2007 R2 to Wave 14 faster than the Congress approval rating is going down… which means – fast as we can!

I am very excited to see the product evolving in positive direction. The new features are not randomly thrown here and there (because “Cisco have it”), but rather carefully crafted based on end-user needs and feedback. I am confident that Wave 15 will be a complete Enterprise solution simply because more and more companies today see the added value of UC to the business process, which means more and more feedback will flow to Microsoft…

Indeed, to talk about the deployment steps and post screenshots now will be (most probably) irrelevant, since this is Beta and any changes can occur between now and RTM. I strongly encourage my colleagues from the EDU sector to evaluate the solution as soon as it becomes publicly available. It is a live change experience, believe me. Those who hate you will hate you even more, but “undecided” will join you faster than Arlen Specter went Democrat…

Ah, the summer is here… Actually, summer come in Milledgeville after the last day of winter. This is now we do it here – by flipping the switch of the heat pump from Hot to Cold. I was trimming the lawn while ago when remembered what good friend of mine told me when I come in USA – “When you don’t have to cut your grass and assemble your furniture by yourself – means you are rich and successful” and I ran back to write this down. Anyway, while I am on the computer…

Today is the first day of the “summer work schedule”. Some colleagues in the EDU sector know what I am talking about – half days on Fridays. Nice outside, quiet… kind of invitation to relax and think about past, present and future. I was flipping through my calendar and found that last year on this day we completed our OCS EV deployment and issued an order for disconnection of our PSTN lines. Was I scared? No. Was I under stress – big time. I knew that the timeline is too short and the lack of training will stress the folks even more and yet, if you ask me will I do it again, the answer is – Yes! As I shared in earlier posts, I take my job and role in the college with pride and determination because in my opinion the role of IT today went long way compared to 10-15 years ago. The time of the “computer gigs” is long gone. IT professionals run the operations today, like it or not. What would happen if one department in the college is closed today? Ohm, they will have twice as much to do tomorrow. Now, what would happen if IT is not operational? You got the point.

While SEO is the brain of the operations with his/her oversight of the present and vision for the future, IT is the heart. The stories of soldiers lost limbs in combat a year ago and swimming, running, hiking and claiming today never stop to amaze me. How they manage to do that?  With brain and heart -the two key components. In this regard, I don’t understand how some colleagues can lay low and get by with “why should I do it if I don’t have to”…

We jumped in the unknown exactly one year ago. We worked hard to overcome the problems and took the challenge to learn and develop. This morning one of the biggest opponents of the UC in the college stopped me in the corridor and told me “I am sure my husband called and I did not received missed call notification. Not a big deal, just… hope everything is all right with the system”. Got it? The people finally took ownership over the system!

I can now die one happy sysadmin.

Grab it from here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

And dont forget the MOC update: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d

Before we proceed with our example, I feel obligated to mention two things – Snom phones are not “Qualified Communications Devices”. This means, you cannot rely on support from Microsoft and/or your System Integrator and so, if you elect to use those, you will have to rely on Snom’s support only.

Second: I tested the script in lab environment. Further testing might be needed before deployment in production to assure proper service.

Having said all this, let’s proceed with our example.

Since Snom phone is SIP phone, interoperability with OCS R2 can be achieved only after installing special firmware. What is interesting here – while OCS firmware adds additional components, the standard SIP functions are preserved and in some cases we can take advantage of this fact and add additional functionality to our OCS environment.

A colleague asked me if would be possible to have the phone ring with distinctive tone when a call ordinates from PSTN i.e. external call. In pure OCS environment this is not possible since we don’t have Alert-Info header supplied in INVITE, as defined in RFC-3960. Even if we had it, thou, MOC and Tanjay would not respect it anyway. Snom, on other hand, will. Look under Preferences -> Alert-Info Ringer:

<?xml version=”1.0″?>
<lc:applicationManifest
lc:appUri=”http://your_FQDN_here/alert”
 xmlns:lc=”http://schemas.microsoft.com/lcs/2006/05“>
<lc:allowRegistrationBeforeUserServices action=”true” />
<lc:requestFilter methodNames=”INVITE”
  strictRoute=”false”
  registrarGenerated=”true”
  domainSupported=”true” />
<lc:responseFilter reasonCodes=”NONE” />
<lc:proxyByDefault action=”true” />
<lc:scriptOnly />
<lc:splScript><![CDATA[

    toUri = GetUri( sipRequest.To );
    toUserAtHost = Concatenate( GetUserName( toUri ), "@", GetHostName( toUri ) );

    foreach ( sessionExpires in GetHeaderValues( "Session-Expires" ) ) {
        if ( ContainsString( sessionExpires, "refresher", true ) ) {
�
            return;
        }
    }
  �
    foreach ( userAgent in GetHeaderValues( "USER-AGENT" ) ) {
        if ( ! ContainsString( userAgent, "mediation", true ) ) {

            return;
        }
    }
    AddHeader( "Alert-Info", "Alert-Info:<http://www.notused.com>;info=alert-external" );
      �
    ProxyRequest("");
  �
    return;
  �
]]></lc:splScript>
</lc:applicationManifest>

You can download the script form this link: http://blog.drago.ws/alert.am

2. Edit the line: “lc:appUri=http://your_FQDN_here/alert” to reflect your environment i.e. if your front end server’s name is ocsfe01.domain.com, the line should read: “lc:appUri=http:// ocsfe01.domain.com/alert”

3. Rename the file to alert.am

4. We will use Front End Scripts node to add our script. Go to Properties

5. In the Front End Scripts window, click Add

6. Populate the fields as shown (of course, replace ocsfe01.domain.com with your FQDN)

7. Click OK to save.

8. The script will be added on the bottom of the list. Use UP button to move it above “UserServices”

9. You should see the script listed as enabled and running.

How it works:

The script monitors the USER-AGENT header to detect if the call arrives from the Mediation server “if ( ! ContainsString( userAgent, “mediation”, true )” and if true, adds the needed header: “AddHeader( “Alert-Info”, “Alert-Info:;info=alert-external” )” in format which Snom will understand. The phone then is aware of the value – “alert-external” and applies the selected ring tone.

MSPL is very powerful tool and I am sure you can experiment and add other functionalities specific to your environment.