Today’s post is a major milestone for me (and my team at work). We have spent 18 months developing our OCS 2007 R2 Enterprise Voice solution, and the past 12 months have been particularly eventful – not to mention busy!
Initially envisaged as an enhancement for our current NEC PABX, it became clear that even our simplest goals of RCC and Unified Messaging would be made substantially more difficult by retaining the current gear. It was also clear that NEC Australia really didn’t have much in the way of ideas or direction in this space. The real clincher came when I teased out the fact that our current PABX was no longer actively being developed, and new spare parts weren’t being manufactured. It was interesting to see the look on the NEC reps faces when I asked what their upgrade path was, and if it enabled our goals better!
Coming to a dead end with NEC, we started to refocus the project toward PABX replacement. I can certainly credit some key people like John Smith at Microsoft and Maurizio Fragasso at NET with some great help and guidance to deliver a realistic solution. Although NET certainly did well out of it – they’ve sold us our voice hardware – they also pointed us in the direction of the snom open-standard handsets that provide cost effective options for OCS-enabled telephony and redundancy!
We have been clear all along that the success of a PABX replacement would be tied to handset functionality. As a question of cultural maturity and technology adoption, we knew that for the vast majority of staff it’d be unrealistic to replace handsets with computer-based telephony. Some investigation of OCS-enabled handsets (that could operate as standalone VOIP clients to OCS) had suggested it was going to be a really costly proposition.
But then NET mentioned the snom gear. IP phones, based on Linux, that integrated OCS compatibility, and even had the capacity to ‘fall-back’ to direct SIP in the event OCS was unavailable – what geek wouldn’t think it was cool? And they were comparatively cheap – in fact, comparably cheap to our existing NEC IP handsets. And so the proof of concept (POC) and pilot processes began …
I’m … snomming around
We started out with the snom 320 model, which is a highly functional handset – with the one drawback that it had a single line display with no backlight. It worked *really* well with the OCS firmware (which you must obtain directly from snom if the handset doesn’t come preloaded). The OCS firmware did have its bugs, but we had plenty of time on our side to work through new firmware revisions and play with settings.
We got to a stable and reliable basis with the snom 320’s, to the extent we could seriously consider moving to a deployment. The single line display was our only concern – so we decided to upgrade to the snom 370’s, which are multi-line, backlit models. They have essentially the same features – which is to say that all snom models are feature rich and amazingly good value (at least 12 lines for all models is a killer in and of itself, PoE as standard, etc, etc, etc). But the multi-line display, with the ability to put custom XML (including company logo!) really makes the price difference worthwhile.
We even discovered that the snom handsets will happily work with both response groups and call delegation features!
It didn’t take long to decide that we were onto a winner, and to start planning for purchase and deployment of the Snom 370 range to all staff!
Making it realistic
One thing we hadn’t considered during POC phase was how we would realistically deploy and manage the handsets. What we were looking at was whether the handsets themselves could viably be used as standalone IP handsets with an OCS deployment. It was as we moved toward pilot that we started to think seriously about this.
The snom gear has some amazing functionality. They’ve even thought about mass deployment, and the snom wiki details pretty much every setting and mass deployment functionality. What it does not feature is a tool to bring it all together – apart from a few objective samples. A great example of how important this consideration is can be found in the requirement for the snom phones to have your network username and password in order to login to OCS. Is it realistic for users to enter this, either through the handset or via the phone’s web interface. We think not, and the web interface should ideally be locked down anyway!
It was then that I had my first brainwave. There are times when a solution arrives fully formed in my head as an inspiration. I had the good fortune to have a good .NET developer on staff, working on a number of internal projects, and when I told him of my idea, he got excited and wanted to work on it!
We’ve worked through the pilot over the past 6 months, in the process developing and testing an amazing solution for phone management – which fills in those blanks that were needed to make an enterprise snom deployment a reality for us.
Introducing … Snomtastic!
Snomtastic is a corny name, but we fell in love with it. Snomtastic is an ASP.NET 3.5 based server solution, in concert with a Windows “systray” client, that delivers the deployment, management, and inventory of your snom investment. Some of you who follow me on Twitter will have seen me allude to it and mention it over a number of months.
You can manage multiple settings and firmware revisions based on a number of factors, such as;
- phone model
- subnet
- group
- user
The beauty of the design is that settings inherit from the “default” config unless overridden – so you can do very fine-grained settings to suit your needs. And it supports the Snom permissions model for configuration settings that allows a config to be locked down as “read only”. We use this to great effect – for example to change the auto-provisioned Unified Messaging mailbox (which allows users to access voicemail via the voicemail button, without entering their PIN) to the UM pilot number so that they’re required to enter a PIN, and preserve security.
Here’s the workflow for a brand new snom handset:
- Plug the phone into the network
- Phone receives DHCP, and derives the setting server from DHCP option 66 (tftp server name)
- Phone contacts Snomtastic and is recognised (by its MAC address) as a new client
- Snomtastic provides a default XML settings file, including the current firmware revision
- Phone will update its firmware as appropriate, and sit in an “inactive” state once done
- Admin associates a user with the phone in Snomtastic.
- User is prompted by the local Snomtastic client to enter their password
- Snomtastic reboots the phone so it gets the new settings and activates
- User is ready to make calls!
There’s a lot under the hood with this to make it work. One consideration we had was how to avoid ‘spoofing’ of the MAC address – which by default would be trivial with the snom design. Another is the sending of plain text passwords – which is all Snom’s OCS firmware will accept – over the network (in spite of being encrypted in the database).
We’ve come up with a solution that gives every phone its own, unique, username and password, and SSL communications with Snomtastic to preserve the integrity of its communications. In essence, you *can* spoof the MAC address – but you won’t get any meaningful or useful settings like username and password from it!
We think the solution is strong and robust. Our pilot eventually extended to 60 users, with minimal glitches. In fact, we gained valuable feedback and learnt powerful lessons from this approach. The client in particular now features:
- End user options for re-registering and rebooting phones
- Capability to suppress Communicator “toast” popups for incoming calls – always, or while “busy”
- A second toast which allows “answer on phone” functionality – which can similarly be suppressed
It’s very cool for a version 1 product. We’re now at RTM!
Current and Future considerations
Hitting RTM is a big thing for us. It means that the internal Enterprise Voice pilot will go to production for another 240 users.
But that’s not all. We’ve also sent Snomtastic to snom themselves to look at. We think it might just be commercial grade, something which makes our business sit up and take notice. It would be very cool to be able to make this available at a low cost to anyone adopting snom for their OCS deployment!
Future versions – especially if we were to start selling this – would include a lot of “wouldn’t it be cool if …” features, such as end-user control over custom ringtones and speed dial, more functionality like click to call, and other awesomeness.
I’m very proud of both the Enterprise Voice project – which is going to be a massive success – and the agile and staged development process that has led to Snomtastic. I’m sure you can understand why! I hope to update you more on Snomtastic, and maybe get some screenshots up!
Enjoyed this post?
Help us spread the word by sharing with friends and colleagues!
Posted in: [IT Pros], [Software Devs], [Network Infrastructure / Architecture], [Telecommunications and Providers], [Windows Server], [Windows Client]
Popular tags: ocs, ocs 2007 r2, snom, enterprise voice, enterprise, microsoft, unified comms, unified messaging