@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.

Best,
Andrew

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

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

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: 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?