Not So Snomtastic
Disclaimer: This post is purely my own opinion and is based on my personal experience using Snom products against Lync Server 2010 circa Fall 2011.
Awhile back I was involved with a migration involving moving a customer from an OCS 2007 R2 Enterprise Voice deployment where they were using a large installation of Snom phones. There were a number of problems which could have probably been alleviated by keeping the Snom device firmware reasonably up to date before we started the project, but the scenario we started with was one where all the phones were running firmware approximately 2 years old. No big deal, right?
Updates
The first major issue with these phones is they are not updated using the same device update feature which is built right in to both Lync and OCS. This means you cannot download a Microsoft-produced UCUpdates.cab and load it on the phones the same way you update all of your other UC devices. All updates for these devices come from Snom and must be distributed to each phone through some other manner.
You have two options – you can manually update each device, or use the freely available Snomtastic server software (which is not actually produced by Snom so good luck on finding quality support or documentation around this product.) Manually updating the phones has the approximate success rate of hitting the jackpot in Vegas, and is probably worth an entire post in itself. Let’s just say it involves knowing the secret code to press on the phones as they boot (Up, Up, Down, Down, Left, Right, Left, Right, A, B, A, B, Select, Start… ok, just kidding.) In reality, it’s a crapshoot if you pressed the right sequence in time to even kick the phone into an updateable mode. And the odds of the update bricking the phone when coming from these old versions was about 50/50 from our testing.
Updating hundreds of phones manually isn’t practical, so you’re probably looking at using Snomtastic to perform these updates. In my case Snomtastic was already deployed, but it was an old version which was apparently single-threaded. Sidenote: it also appears to be in contention for the World’s Worst User Interface, but it’s free so I suppose you take what you get if you don’t want to manually update each phone. The single-threaded limitation meant we could only safely update 10-15 phones at a time. If you attempted to do more than that the software would come to a screeching halt with the CPU pegged, and the phones would be stuck trying to load the firmware. The end result was you had to go physically touch and manually kick them out of this mode before they were operational again. Updating to a new version of Snomtastic was out of the question as it was going to involve physically touching each phone once more to change VLANs around.
Any Day Now…
In the end we turned a blind eye to the update process and began validating the product against Lync. This customer had a ton of Snom 3xx devices which did not actually have a firmware release for Lync quite yet. Snom was touting their “UC Edition” firmware which is the version which runs against Lync, but that firmware only existed for their newer 8xx series phones when we started. This meant we were stuck with the older 8.5.8.1 “OCS Edition” version for the 3xx phones. We were told the UC Edition for the 3xx’s was coming “any day now” when the project started. 3 months later the story hadn’t changed, so the confidence in quick updates and issue resolution was not high. We did notice the 8.5.8.1 phones had MRAS issues aginast our Lync Edge server pool which was using DNS load balancing, but we were assured by support that the UC Edition firmware would solve this issue, whenever it came out. Surely the OCS Edition couldn’t be expected to support DNS load balancing when that feature did not exist for OCS.
DNS Load Balancing
While waiting for the 3xx update Snom support encouraged us to test the 8xx devices because the code would be identical. This seemed like a good idea so we started doing some tests against the environment Again we noticed that even the 8xx devices couldn’t communicate with remote users. Internal calls worked fine, but any time a call required Edge traversal the call would fail. This was only occurring when the Snoms were involved, and a full Lync or Lync Phone Edition client received MRAS credentials just fine. We eventually tracked this down with Snom support to a problem with DNS load balancing in their code. The gist was if the Snom phone got more than one name back for the Edge pool it freaked out and wouuldn’t get any MRAS token. Snom support got us a “fix” in a nightly beta snapshot which I was told ignores any DNS entry other than the first one. Yes, you read that correctly – the fix was to essentially turn off the HA features of the Snom client so there was no resiliency to DNS load balancing of the Edge pool. It would be good to point out this was the initial public release of the UC Edition code, which specifically advertised support for DNS Load Balancing and had been stamped with the official “Qualified with Lync” label.
Snom support eventually gave us a beta version of the UC Edition for 3xx devices which had the exact same problem. The UC Edition introduced support many Lync-specific features, but it was really hard to have any confidence in any of these claims when it was obvious that a pretty major new feature wasn’t working at all. I have no clue if this bug has been fixed to this day, or if the code still ignores anything past the first DNS record returned for the pool.
The Big Switch
In light of these issues the customer made the tough call to switch out all the phone hardware and went with one of the devices which carries the “Optimized for Lync” label from one of the major Lync Phone Edition vendors. The end-user and administrator feedback with this switch was overwhelmingly positive. Call quality was perceived as better by the users, and we were able to back up those claims with the quality reports from the Monitoring server. The administrative experience for updating and monitoring phones was also much improved by using the native reporting and management tools.
There are plenty of other Lync Phone Edition options available which may seem likea larger initial investment in total price, but you really need to consider a number of factors in that decision other than per-device pricing. With a lower-end device you’re likely to spend an incredible amount of time troubleshooting issues which wouldn’t normally be a problem. You also have additional overhead in terms of management for these devices since you now have to maintain a Snomtastic server (with no real support) alongside your Lync deployment, when you could just be using the native Lync tools for updates. The end-users are going to have a much nicer experience via the USB tethering abilities of Lync Phone Edition clients, and it’s important to note that the Snoms also do not support RTAudio. They advertise wideband audio support, but it is G.722 only which uses nearly twice the bandwidth of wideband RTAudio. This can be a concern for bandwidth-constrained branch sites.
I’m not advocating a boycott of Snom products here. I’m sure others have had different, and hopefully more positive experiences, but mine was incredibly poor with Lync for a number of reasons I’ve mentioned above. And I’m sure Snom is making a strong effort to improve these products, but my perspective at this point is that they just doesn’t seem Enterprise-class. They are not an option I would present to a customer today over any of the vendors producing Lync Phone Edition devices.