Wow. No one here can guarantee stability in your environment. That being said, I stay away from X.0 trains (e.g. 7.0). I had problems with 7.1(2) and noticed that the lag between updates was really short, which to me means that there were some stability issues. The 7.1(3) release has been pretty good thus far. I have not tested 7.1(5).
I recommend that you research the release notes and software defects. Keeping your particular deployment in mind. You also have to consider IOS releases, signaling protocols, UC applications, etc.
Finally, get a test environment if you can and a lower environment if it fits your company size. This will give you a method to test things out. Picking a software release is almost an art form since there is no black-and-white. You have to do the footwork, apply your institutional knowledge, and be disciplined enough to stick with what tests out well. Meaning, don't always listen to guys like me on what version you should use.
Another way to get my point across is that you should come up with the method for picking a good version. Way more valuable than a recommendation from an unknown person on what the best release is.
In regards to "lower environment". You may find some value in this link: http://www.netcraftsmen.net/resources/blogs/uclowerenvironment.html
Current recommendation from me is 7.1(3b)SU2. However, 7.1(5) just came out and I've not yet loaded it in my lab for testing. Reading the release notes, there doesn't APPEAR to be anything major updated but I haven't done a deep dive yet. However, stability depends on a number of factors including other applications in use (integrations), gateways, etc.
Absolutely. I didn't mean to disregard the value of popular opinion. It is always good to have an extra data point. Personally, I find that lack of consistency in software releases and the general lack of stability along with all of the various integration points somewhat daunting. The way we like to approach the software selection process is to first discount all of the non-starters. So, we typically skip the "dot zero" releases UNLESS the customer really, really needs it.
We then check the FCS timeline. I like to go to the software download side and capture the release dates for minor, maintenance, and service releases of a particular major line. I have tried to trend the release schedules since the 5.1 appliance model. What I found was that aside from a few "extreme cases" is that if a release lasts 30-45 days without have a "b" (e.g. 7.1.3b) or SU release then it is most likely free from major install or upgrade catastrophes and has a very good probability of passing internal lab validation. On my team, when a software rev makes it through the ol' historical scrutiny we call it a "candidate for review". This is where the fun starts. We start doing all of the things I touched on in my original reply.
If I was in a position where I could pick only one release and keep my commentary to myself, then I would pick 7.1(3b)SU2. If I was allowed just a little latitude for my big mouth, then I would echo Hailey's 7.1(5) may deserve a look. BUT, I would not seriously consider any release as a candidate for review/testing until it has been out at least 30 - 45 days.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...