I attended the International Avaya Users Group Converge2014 in Dallas, Texas last week. This has been an annual event for me for many years and despite the non-stop days and nearly sleepless nights, it’s something I look forward to very much. Not only do I get a chance to stand before like-minded people and pontificate on subjects I pretend to be an expert in (this year I presented three sessions), but I learn a tremendous amount from the sessions I attend as a student. Truth be told, in some cases it’s more of a relearning experience, because I often need to hear something a few times before it finally sinks in.
This year I plan on doing something a little different and capture these light bulbs and gems of wisdom in writing. Now, when I forget – which I will – I know where to look to kick-start my memory cells.
Tim Kaye has to be one of the smartest people at Avaya and this year I attended three of his sessions. This man has forgotten more about telephony than I will ever hope to know and I never leave his presence without learning something of great importance.
For a number of years I have spoken about the idea of usage separation when it comes to session border controllers. By this I mean putting trunks on one SBC and users on another. This isn’t something that I recommend in every situation, but there are times when it makes sense to isolate different forms of connectivity. For instance, guaranteeing the availability of SIP trunks to a medium or large contact center may take precedence over providing remote workers with mobile SIP connectivity. In this case, I would recommend trunks on one SBC and users on another. In fact, I may even recommend different makes, models, and configurations of SBCs to meet the unique needs of each connection – perhaps high availability AudioCodes, Sonus, or Acme for the trunks and standard availability Avaya for the users.
In one of Tim’s sessions, he took it even further and recommended that different Session Managers be used in a similar manner. Remember, a Session Manager is both a SIP routing engine and a SIP registrar and it may make sense to dedicate different Session Managers to each function type. This will, of course, lead to a larger number of boxes or virtual instances to administer, but it protects your trunks from being overloaded with user traffic and vice versa. Additionally, it gives you greater flexibility in turning up or down signaling groups when processor overload becomes a concern.
Tim also told the audience how Session Managers should never be connected to C-LANs. Instead, Communication Manager Processor Ethernet should be used. This greatly improves reliability, reduces administrative complexity, simplifies signaling call flows, and eliminates C-LAN bottlenecks associated with IPSI connections. So, although a Session Manager to C-LAN connection is possible, Avaya strongly recommends that you use Processor Ethernet whenever possible.
He then went deep into the Split Registration Prevention Feature (SRPF), but that’s a subject worthy of an entire article. Look for something from me on that sometime in the near future.
In another session, I leaned how the University of Washington implemented SIP and some of the lessons they took away from the experience. While they restated some of the concepts that Tim presented, the two speakers gave the audience real-life examples of the right and wrong ways of moving to SIP. Among the gems of wisdom I walked away with were:
- The Communication Manager Notification Sync feature is a must. This forces CM to upload changes to System Manager as soon as they have been made.
- Get current. The later the versions of CM and Session Manager, the better your chances are of succeeding. SIP is evolving quickly and you need to make sure that you are taking advantage of the improvements that Avaya continues to make in SIP stacks, applications, servers, and endpoints.
- If you are using Lync, pay attention to the domain name you choose. Lync is heavily dependent on domain name while it has never been as big a deal with Avaya.
- Use sub-domains off the root for specific trunk routing in signaling groups — for example, tg1.mycompany.com.
- Learn how to use the new Global Search feature in System Manager. It will make user administration much easier.
- TraceSM is your friend. This is especially true with its new ability to trace Personal Profile Manager (PPM) flows. For more information on PPM, please see my article, Understanding Avaya’s Personal Profile Manager (PPM).
It was a long conference and I learned more than the just the above, but I will stop here for now. However, I will continue to write about additional lessons learned in future articles in the hope that I won’t have to relearn them next year…or the year after.