Snom phones and OCS 2007 R2, a lesson learned
As Convergent Solutions has embarked upon leveraging OCS as a fully-featured, enterprise telephony solution we’ve tailored our offerings to meet the needs of clients both large and small. With tighter company purse strings, we’ve looked at many vendors to enhance the Enterprise Voice experience on the desktop that would bring a solid feature set at an affordable price. We looked to Snom Technologies to partially fill that role for end user devices; and what started out as straight forward deployments, turned into many support calls, firmware revisions and a solution that is still not fully functioning. In the spirit of full disclosure, my experience is mainly limited to the 300 model phone, which may or may not reflect across the entire product line. However, we wanted to make sure that we posted our experiences to help others in similar situations.
The first major hurdle
At the time of order (May ’09) all Snom 300s shipped without the 8.2.5 “OCS Firmware” loaded, which meant every phone had to be touched. If you do end up with “old” firmware, keep in mind that you will likely have to dedicate a large block of time to process all the upgrades and verify they completed successfully. Out of the box the phones rely on the internet for software updates, which for one or two phones isn’t an issue, but if you have a large install base you will need to setup a provisioning server. Another alternative is to manually upgrade each and every phone manually via TFTP; a laborious path that we were forced to take. The easiest, incurring a nominal upfront charge, is to have a snom distributor load the most recent OCS compatible firmware before shipping. This may at first seem unnecessary because a firmware upgrade for any device should be easy, right? Not so. I suggest that you have the devices upgraded before being sent. As a side note, as with firmware, the internet is used for NTP updates. The phones default to midnight after a reboot and if they cannot reach the internet for time OCS will not authenticate; use an internal NTP server.
The second major hurdle
Once upgraded and deployed we noticed that presence was not working properly. The phone’s default settings configuration is more suited for a traditional SIP deployment than an OCS one. The phones do not cooperate with OCS at all for presence. They will command the user’s presence regardless of the MOC client’s current status: if the phone sits idle for 15 minutes, presence is Idle; if the handset is not picked up in an hour, your presence is reported as away. The only way to “reset” your presence automatically is to make a call, or at least pickup the handset. To resolve this: turn off Machine State reporting and set the idle/away timers to zero. Be sure to keep Report Phone State on, as that will report to OCS when a user is “On a Call”.
The last straw
The largest and to date unresolved issue happens once the phones were on the desks of users for a couple of days. I began to get reports of phones losing registration, displaying NR and calls could not be placed or received. Initially the problem seemed to be an issue with AD passwords expiring and users not reconfiguring their 300’s options (the errors in the logs were “401 Unauthorized”). That was the cause of some, but many phones would randomly “fall off the grid” for no reason. The issue was intermittent and very disruptive for the users; the only way to clear the problem was to disconnect/reconnect the phone’s network connection (reboot) and wait a few minutes for it to re-register. Snom support suggested disabling Challenge Response, which did not resolve the issue, and after lengthy troubleshooting admitted that their TLS implementation was the cause. Note: while troubleshooting and testing this issue I found that many registration options (SIP Session Timer, Proposed Expiry, Subscription Expiry) were not honored. At one point support introduced us to an untested firmware version that caused phones to misdial completely.
As soon as the firmware was loaded with the test firmware certain numbers, normally long distance calls, would normalize to internal numbers. These outbound calls would end up ringing their own fax line, while others would dial the Director of IT—which certainly provided high visibility of the problem. MOC client calls were not affected at all. Once the firmware was removed from the phones they dialed normally, though the firmware had to be rolled back manually via TFTP.
Support?
Pile these issues together and the user experience deteriorates very quickly, OCS loses its “cool” factor and becomes a hurdle for a business to overcome. Snom support did not understand that these issues were deal breakers for our clients. They were very quick to suggest that the OCS Edition of their firmware was Beta, when in fact it has been released as a “stable” load since June. I had issues with Snom’s support desk: their ticketing system did not like my email address and any emails sent through it were never delivered. Even worse, it’s been over two months that our client’s NR case has been open—with no resolution in sight. It has been frustrating sitting between a valued client and a vendor, so much so that I will not suggest Snom phones as an OCS end-point until it’s proven that both the technology and the company’s support work.
![[Post to Twitter]](http://www2.convergent-solutions.com/tincupwordpress/wp-content/plugins/tweet-this/icons/tt-twitter-micro3.png){kind=icon}
![[Post to Digg]](http://www2.convergent-solutions.com/tincupwordpress/wp-content/plugins/tweet-this/icons/tt-digg-micro3.png){kind=icon}
![[Post to Reddit]](http://www2.convergent-solutions.com/tincupwordpress/wp-content/plugins/tweet-this/icons/tt-reddit-micro3.png){kind=icon}
![[Post to StumbleUpon]](http://www2.convergent-solutions.com/tincupwordpress/wp-content/plugins/tweet-this/icons/tt-su-micro3.png){kind=icon}
Hey Mike,
Thanks for publishing this. I’ve been looking at those Snom phones for some time now and it’s good to hear some feedback from someone who has tried to deploy them in production for more than a couple users. Now that the CX300 (Oak) is available, I’m guessing it will be an attractive alternative for those considering Snom for a more affordable device.
Regards,
Jamie Schwinn
I am reading this blog and thinking - it is all Microsoft’s fault. Why? Let me explain.
Back in the days, in the Unix world, we had couple of gigs in town the that knew “all about it” and the rest of us were like “Wow man, you are good!”. We did not care where my IP come because the Linux dude configured the DHCP, how we got to internet because the Cisco integrator configured our network and another genius setup Apache on the end of the world.
Then come Microsoft with their “Click here to install the product, click Next, now click Finish. Congratulations, you just installed the product.” All of sudden everyone with admin credentials could be the local genius… With the years, the fact that most of MS products worked out of the box spoiled the IT world, big time. Never mind that implementation of new service requires:
a. Understanding of the concept
b. Reading and understanding the product
c. Toughly testing before implementation
d. Keep up with the changes related to all of the above
Because many people simply skip most or all of the above, the alternative is to blame Microsoft for the our own failures. Just read Internet. I am ready to take any bet that two editions ahead from Server 2008, there will be no more GUI. Everything will be based on PowerShell. Why? Because IT professional will either have to earn the title “Professional” by preparing itself or… sits behind the Professional’s back and go “Wow man, you are good!”
Back to OCS. Have you ever thought why Policom CX700 is so “great”? One reason - you cannot screw with it. You can unbox it, you can connect it, you can make a call - that’s about it. The key word here is - “No thinking is required”. I am not saying this in a bad since - indeed Microsoft and Polycom did a good job “ironing” another wrinkle of our brains. You don’t have to know the product - just put it there and it will work. And… be prepared to pay the price for it.
Snom product is different story. It come as affordable alternative for fully functional OCS endpoint well under $100 sitting on an entry clerk’s desk that makes $16,000 per year. Need proof - come by Georgia Military College in Milledgeville, Georgia. We are the first educational institution in USA to have 100% OCS R2 Enterprise Voice and Exchange Unified Messaging. Went live on 27 of April this year. Seven campuses in different cities, countless normalization and routing rules etc. Only the executives are equipped with CX700, the rest are happily working with… Snom 300.
Now, based on Mike’s blog, we do not exist :-). With so many “hurdles”, I should have been fired, GMC should have begged Polycom to save the business operations and the case should be closed. Instead, due to the success of the project, I am now “Associated VP of Telecommunications and Networking” instead of Network Administrator. Unlike Mike, I did my home work well before implementation. Snom have very well done WIKI site where everything is documented. Because I actually read and understood the product, I have full control over my environment. I can send any firmware update to my Snom environment with a click (huh, no TFTP indeed), I can re-provision a phone to different user with our in house web interface provisioning solution for 10 seconds etc. This is not because the Snom ticketing system liked my email, but because I did understand how the product worked. I also went ahead and federated with Snom, so I can be in touch with the dev. team which never refused to chat and provide insights and understanding when I stumble during my quest of understanding the product. In my native country, Bulgaria, to wait someone else to solve your problems is the biggest embarrassment a man could experience…
Here are some numbers:
Total EV users - 350
Endpoints:
Polycom CX700 - 45
Snom 300 - 305
TCO - $65,000
ROI - 11.8 months
Savings per year - $98,000
If you are interested of more details, we have open federation. Feel free to IM me at any time: dragomir @ gmc.cc.ga.us
Jamie: The CX300 does not really provide an alternative to the SNOM OCS phones, because it is a USB phone that requires the user to have a computer. Snom phones are likely to be used when you need common-use phones or you need to provide phones to users who don’t have PCs (and you have a PBX).
Mike: Do you know if the most recent SNOM firmware still has the problems you referenced in your article? It sounds like your engagement occured in the summer-fall timeframe. What firmware release did you revert back to?
Peter,
The firmware we currently have deployed isn’t an official build. We’re currently using “snom300-SIP snapshot_branch_8_2_2009_10_27_22_00_04_snom 4415″. The original firmware was 18983 and we’ve gone through quite a few other revisions to get to this last one. The currently deployed firmware still has the NR problem, though with less frequency than other builds we’ve used.
We’re still working with SNOM to resolve the issue and will update this post when we get a fix.
Mike,
snom300-OCS-snapshot_branch_8_2_2009_11_16_22_00_03_snom-SIP-f.bin resolves the NR issue. You might want to try this if you have not done so yet. Also, for my big suprise, 820 now offers presence and contact list on the display.
I personaly think 8xx series nice but… kind of off market segment. We need well under $100 endpoint for the entry clerk that makes 16,000 a year and Tanjay for the executives.
Drago
Hello,
I would tend to think that hurdle #1 could have clearly been known by you. It seems a bit unfair to blame snom for this. (although I think it would be nice to be able order the firmware version you want too…;-)
#2 Hurdle I would think if you are doing a roll-out you would test this first so you know the provisioning you need to do. This is part of your testing phase–that would be my thought.
Last straw–If a non-beta firmware has a major connection issue then that is a fair one…
The “OCS looses it’s cool factor” would lead me to believe that possibly this customer didn’t really fit OCS even without the snom “bumps”? Possibly a slightly square peg in round hole? Perhaps a more “traditional” IP PBX may have been a better fit?
Just some of my humble thoughts,
Matt
So Mike, have you been in touch with this guy named “Drago”? Aside from his rude post it seems like he isnt experiencing the same problems you are. For the sake of the community that is reading your blog, could you give us an idea of what he is talking about and why his experience differs from yours?
Best,
Andrew
First and foremost, I apologize in the delay of this response. I’m just circling back after several resources from the customer, Convergent and snom have worked on the problem. Currently the NR issue seems to be resolved, we worked with so many custom and generally unreleased firmware revisions that it’s difficult to nail down which one did the trick.
@Drago: the engineer that was handling the issue throughout the fall and winter has suggested that the firmware you’ve referred to sounds like it’s of the timeline a firmware used started to show effectiveness. Due to the extreme problems that previous firmware updates had caused, testing was staged on fewer phones and over a longer period of time. The issue was intermittent, so it took some time for the customer to feel comfortable that firmware had fixed the problem. Sometime in January the customer did feel comfortable enough to say that the NR issue is no longer a problem.
@Andrew: I can’t speak for Drago’s deployment, but if I were to guess it would be that his was a TCP deployment while ours was TLS. If his phones aren’t registering directly with OCS, then he wouldn’t experience the same NR issue. His response didn’t read like he was having the same issue, but if he was it was either limited in scope, his environment is not made up of heavy phone users, had better luck with firmware provided to him, or one of many other possibilities. We’re very happy that he had a good experience with his Snom deployment, I didn’t blog on this because we wanted people to gather their pitchforks and torches to storm Snom’s headquarters. It was a lesson learned.
What soured us the most was that the product was sold as a solution and in fact it ended up as an extended beta. It took many months to get a very real problem fixed for our customer while working directly with Snom. The elongated, tumultuous, support story should be the main take away from our experience.
@Matt: My statement about the “cool factor” could have easily be rewritten to “adoptability” if that makes my point clearer. The technology works, we’ve deployed it multiple times across multiple markets, and it IS cool. I can’t think of a more simple or correct word to describe OCS; wrap telephony with presence, messaging, and various point-to-point and public conferencing capabilities, then multiply that with federation and remote access—if my math is correct, that equals cool. Our client didn’t choose OCS solely for its telephony capability.