SIP Session Manager Tricks from IAUG CONVERGE 2014

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.

Related article: Live from #Converge2014: Pierre-Paul Allard Keynote Address on Avaya’s Transformation Journey

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.

Converge 2014

Tim Kaye has to be one of the smartest people at Avaya and this year I attended three of his sessions.  This man will forget more about telephony than I will ever 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,
  • 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.

* * *

This article originally appeared on SIP Adventures and is reprinted with permission.

Related Articles:

Don’t Let SIP Endpoints be Your Achilles Heel

I was out East last week (I grew up in Arizona and we call everything on the right side of the map “out East”), where I worked with a large university and hospital on their move to SIP.

They aren’t starting from scratch and have implemented some SIP, but for the most part they are still predominantly TDM throughout their campuses and medical facilities.

They needed schooling on SIP trunks, users, SBCs…the works.

Security is a concern for every institution, but it’s especially important in research and medical facilities.

Preserving the integrity of their communications systems is extremely important, but so is providing access to those who need to use it.  At the same time, keeping out prying, unauthorized eyes is absolutely crucial.

So, not only did I meet with the traditional telecom people, but I spoke with the folks whose jobs revolve around keeping everything safe.

You reap what you sow…

A few years ago, I read a research brief from the Aberdeen Group that detailed their work with 299 companies on securing Unified Communications. I learned a lot from the study, but one thing clearly stood out to me:

The time spent with security solutions on the front-end led to the ability to launch greater functionality with fewer debates, challenges, and workarounds as Unified Communications were launched throughout the enterprise to all employees, including remote employees and brand offices.

In other words, if you build security into your environment from the very start, it becomes easy to roll out new applications. If IT trusts the strength of the platform, they don’t fear every new request for additional functionality.

This means that security must be provided from the inside out. You start with the core of the communications system and work your way towards the edges. In this way, you strengthen every access point to ensure that there are no weak spots.

Protect the core

At the core are your physical servers, gateways, and networking devices.

It goes without saying that they must be physically secured and if possible, logically isolated from the rest of your network. A hacker or malicious individual can do a great deal of damage by gaining access to an unprotected network port or console connection.

Keep your core communications equipment behind locked doors and limit the number of people who can change it.

SIP supports a number of built-in security checks and it’s important that you choose a vendor that implements them.  For example, every SIP message should be authenticated.

This means that before your SIP server blindly accepts that Andrew Prokop is trying to send an INVITE message, make him prove that he is who he says he is. (I dig into this subject in Proving it With SIP Authentication).

Related article:  How to Manage Network Risk and Security with Session Border Controllers

Protect the data that runs on your network. Encrypt SIP signaling with TLS and media with SRTP.

I teach a SIP class where I show how easy it is to use Wireshark to capture and play media streams. You don’t want the wrong people listening to your company’s phone calls or voice mails, do you?

Still, there are times when encryption is not possible.

For instance, no SIP carrier supports TLS or SRTP. You must decrypt on the egress and encrypt on the ingress. However, since this data travels to and from the carrier on an already secure MPLS connection, the risk of a security breach is extremely small.

Typically, carrier-facing encryption and decryption are done by an SBC. This makes it essential that the network between the SBC and MPLS edge router is inaccessible to attack or tampering.

Don’t Let SIP Endpoints be Your Achilles Heel

Encryption needs to extend to the endpoints, as well. This is especially true for endpoints that access your communications system over the Internet.

Whether it’s a physical device such as a SIP phone, or a soft client that runs on a PC or mobile device, make sure it supports TLS and SRTP. Also, make sure that your network policies are such that they do not allow unencrypted communications.

The next thing you need to examine are your password and access policies. Don’t let the weak link in your security chain be an easily guessed four-digit password.  I am constantly finding companies that allow a user’s telephone extension to be his or her password. I’ve also seen just as many “1234” passwords out there. This has to stop for clients both inside and outside your network.

When my company moved to SIP, we immediately forced every user to adopt eight-digit passwords. We also instituted a policy that prohibited easily-guessed passwords.

Next, we deployed software that aged passwords after so many days and didn’t allow the same passwords to be reused. In essence, we created communications password polices that mimicked what we were already doing with our domain passwords.

We also enabled rules on our SBC that detected malicious activity and stopped it from occurring.

Specifically, our SBC will disable an extension after a set number of failed login attempts. An alarm is raised and we require an administrator to re-enable that extension. This prevents people from hacking into our system by either manually or programmatically guessing at a password until they eventually get in.

One more edge-protection technique that can be applied is two-factor authentication.

Two-factor authentication forces you to “register” devices against specific resources. Perhaps you’ve already encountered this through online banking. Every time you access your bank’s website from a new device, you are required to answer your pre-defined security questions (“What is the name of your first pet?”).

The Avaya SBC supports two-factor authentication by only allowing SIP access from authorized devices.

So, even though you know Andrew Prokop’s user ID and password, you need to be on Andrew’s iPhone or iPad to log in. Add this to strong passwords and password hacking detection and you’ve got an extremely secure network edge that is very difficult to compromise.

If You Build It…

I would like to end with a little more from the Aberdeen study.

This paragraph sums up how building security into all aspects of Unified Communications fosters a more robust adoption rate.  Rolling out UC on an already secure platform significantly increases its ability to succeed within the workplace.

Although security and freedom are often seen as counterbalancing tradeoffs, Aberdeen research suggests that the opposite is true for Unified Communications and that security can actually lead to more opportunities for end-users. As an example, organizations were asked about their use of instant messaging, mobile wikis, and micro-blogging within their workplace. 70% of organization with a security solution used these short messaging capabilities on a regular basis, which nearly tripled the adoption by all other organizations.

Enough said.

*  *  *

This article originally appeared on SIP Adventures and is reprinted with permission.