The Evolution of Session Management: Part 2The Evolution of Session Management: Part 2

Without some sort of session management architecture (or at least a plan for an architecture), moving to UC will be very painful and costly.

In my last post I promised to talk about some of the key functional areas that a SIP session management solution should cover. You probably know that these functional areas are evolving as session management itself evolves. In general, however, one can break session management down into two "uber" functional areas:

1. Session and policy management
2. Brokering sessions between different applications

Session and Policy Management
I explained policy management at a high level in my previous post. This concept is often linked to a specific feature--namely, call admission control. Enterprises are asking for call admission control or, in session management parlance, Session Admission Control (SAC) that not only enforces policy but does so in the context of the underlying network fabric. This can be done in two ways: by provisioning static bandwidth or session caps; or via dynamic session caps based on true, real-time bandwidth availability. This capability allows enterprises to intelligently manage sessions started by remote workers, branch offices or other bandwidth-constrained areas.

While SAC functionality is common in many PBXs, enterprises too often find that they are unable to apply policy to ALL sessions from one centrally managed point. For example, imagine that a company has two PBXs purchased from different vendors and deployed in separate locations. To set a single enterprise-wide SAC, the administrator must change settings in both PBXs individually and, in each case, they must know the administrative platform for that particular PBX. In our two-PBX scenario this admittedly may seem trivial. However, in a typical real-world situation an enterprise never has just two PBXs. With tens or even hundreds of PBXs, purchased from myriad vendors, scattered throughout a worldwide network, the level of complexity we're talking about increases exponentially.

Application Integration
The other area of session management is application integration, specifically enabling a single enterprise-wide point of communications control. In essence, enterprises have multiple line-of-business applications (Oracle, Microsoft, SAP, etc.) and multiple communication-services servers (Avaya, Microsoft, Siemens, etc.). Linking the line-of-business application to the communication servers is the crux of the second functional area. Enterprises are looking for a middleware API layer that spans the entire enterprise communications network and provides an interworking and routing logic point between applications. This middleware layer would allow enterprise developers and IT departments to integrate their communications systems without spending endless hours on complex and tedious activities.

For example, consider a business that is using Oracle in its North American Region and SAP in its EMEA region. The company’s PBXs form another layer underneath the line-of-business applications. Getting SAP to speak to each of these PBXs and getting Oracle to speak to each PBX would require significant, and complicated, development work. Equally as important, the initial integration effort doesn’t take into account any subsequent new releases or upgrades on either the PBX or the application side.

Ok, so why is this all important?

Well, many companies today are moving to SIP trunking and unified communications and without some sort of session management architecture (or at least a plan for an architecture), moving to UC will be very painful and costly. So investing some time in thinking through an architecture that enables session management is well worth it.

In my next post I’ll explore a different aspect of voice architectures--security.