Current communications architectures based on IMS/SIP treat all established sessions the same, which limits the ability to optimize the end user's experience based on available network capacity. As UC applications that utilize voice and especially video consume more network bandwidth, network resources should be allocated according to business value.
An emerging method for providing this flexibility is called dynamic session management, defined as the ability to prioritize, limit, and optimize communication sessions in real-time as the network becomes congested. Enterprises should look at supplementing their Network QoS and static call admission control (CAC) policies with dynamic session management.
Traditionally, a UC solution is unaware of network capacity. CAC is used to limit the utilization of network links by communications applications: A UC solution will have a predefined limit on the number of voice and video sessions that a link can handle, and a Wide Area Network will be designed to handle the predicted busy hour/minute of traffic. Because WAN bandwidth is deemed expensive, highly compressed voice and video codecs are typically used, which lowers the end user experience while putting a cap on the number of sessions that are carried. Even though the majority of the time, bandwidth is available for a high-quality end user experience, the pre-defined, static configuration of the network inhibits the use of the available bandwidth.
In a VoIP/SIP connection, once a voice/video session is established, the media is designed to flow peer to peer and the session is set. The codec type and all the other communication negotiations are done prior to session establishment. If the network runs out of bandwidth mid-session, then the communication will suffer either quality degradation or total drop of the call. Adaptive codecs were introduced to address this problem, and the network communicates to the session by the means of dropping packets and/or adding jitter.
The flaw in this model is the premise that all established sessions are equal and all must adapt in the same way. The business reality is that not all sessions are equal and that under network congestion, some sessions should get higher priority than others.
Figure 1. Current UC/SIP Deployment Architecture
Figure 1 illustrates a multi-vendor Unified Communications SIP deployment. The key components are:
1) SBC: Termination of SIP trunks to the PSTN
2) Session Manager: SIP proxy that manages the dial plan and session policy rules across platforms
3) Communications Services: Manage the communications to the endpoints/services that it supports; these services include:
a. Telephony: Provides the standard telephony and media for all hard- and some softphones
b. Contact Center: IVR, Routing, CTI/desktop, recording, reporting
c. Collaboration: Instant messaging, presence, unified messaging, file sharing
d. Conferencing: Audio, video (room and desktop), and web conferencing
4) End Users: In the office, home, mobile, and at third-party sites
This model works the majority of the time, but under high load, it falls apart. A few examples:
1) Large Conference Call: At the top of the hour, a large conference call starts and consumes all available voice sessions to a site. Contact Center calls cannot get to available agents, emergency calls cannot get out, and local customer calls get a fast busy.
2) Training Video: Marketing is launching a new product and wants to update the sales force on it and requires that everyone watch the 30-minute video. All video sessions are used up and a sales person that would like to show the video to a prospective client that is on-site has to wait.
3) Critical Issue: An overseas manufacturing plant is having production problems and needs to establish a HD video link back to HQ and to the R&D team. The bandwidth is not available due to other voice, video, and data sessions currently running.
4) Desktop Video: A team member wants to collaborate on a new idea with folks at 4 other sites, but is not permitted to do so because the organization does not allow desktop video, because IT cannot manage the bandwidth it may consume, and they worry that it may impact other applications--even though at this moment in time, there may be plenty of network capacity.
Next Page: The Solution: Dynamic Session Management
The Solution: Dynamic Session Management
A dynamic session manager would combine the features and functionality of both an SBC and a SIP Proxy. SBCs provide a Back to Back User Agent function and handle both the signaling and the media. Unlike a SIP Proxy, aka Session Manager, which is only involved in the session set-up, an SBC can be engaged during the entire session. Because high-bandwidth media is involved, an SBC is the right platform, with the session management applications and rules added on top.
Here's an example of how this could work in practice; an example policy rule could be: To a site that can support 300 G.729 (8 kbps) voice sessions, utilize G.722 (64 kbps) codec for the first 75 sessions, G.729 for the next 25 sessions, and if the number of concurrent voice sessions exceeds 100, then issue a SIP Re-Invite and take the existing G.722 sessions and make them G.729, so more sessions can be supported. At 280 sessions, stop allowing new conference call sessions and at 300, start dropping internal calls in order to continue to support new external customer calls.
This model requires that all media run through the SBC and not be peer to peer with the endpoints. That may seem like a departure from the ideal of IP communications, but it's actually how most IP communications work in real-world deployments. With modern collaboration, conferencing, and third-party communication systems, more than 90% of an enterprise's real time traffic ends up needing to be handled by some communications elements between the two peer endpoints. "Peer to peer" communications is actually a rarity in enterprise communications, and is likely to continue that way.
Having all media go through the SBC adds additional functionality, such as:
* Dynamic Session Management: Ability to change codecs and prioritize sessions, once the sessions have been established. One example is on a video conference, tearing down the video portion of the session but maintaining the audio portion of the session until enough network capacity comes back to enable the video again. Having the video totally go away can be less disruptive than having it freeze every 10 seconds while simultaneously hampering the voice communication.
* End-to-End Recording: As sessions go between different platforms, the SBC has the ability to record the voice/video as the communication is transferred and/or more people are added to the session.
* Real-time Usage Reporting: Especially with video traffic, it is not good enough to know how many sessions are currently active; one must also understand which codecs are being used and how much network capacity is being consumed, since there is a variation in bandwidth consumed based on the type/resolution of the video.
* Communication Proxy: Enable the SBC to add functionality to an end system that the current product does not offer, such as media injection to give a special ring for overseas calls or a request to video chat with the boss. There is a long list of options here, and this would help an organization to potentially utilize a SIP phone/client across multiple vendors' platforms.
* Application Awareness: Enabling UC sessions to take advantage of information and applications during the session, such as pressing 1 and asking Siri a question.
Figure 2 illustrates what this architecture would look like. The only change is that the Session Manager has been replaced with an SBC that both provides the session management and has all the voice and video media going through it. The architectural difference from IMS is that the session layer is media aware and sits between peer-peer communications using all real-time media. SBCs may not currently have all the functionality built in to provide this capability, but this is the next step in their evolution.
Figure 2. Future UC/SIP Deployment Architecture
As mobile carriers build out their VoLTE networks, they should consider this model too. In an emergency, when communication is critical, the functions of prioritizing, limiting, and optimizing sessions can ensure that more critical communication can get through. An example simple rule set under extremely high utilization could be: Drop all video immediately, terminate voice calls that are over 5 minutes that are not going to 911, with a 30-second warning tone, and force the most efficient codec on every session. During normal operations, the carrier could offer multiple tiers of service. The session management can dynamically offer the best possible level of service with the resources at hand, for a given tier of service.
Most organizations that I am working with currently are not allowing desktop video, and minimize video coming in over the Internet. As consumers utilize video more and video becomes critical to the success of enterprise collaboration, video will become a higher priority. As video consumes more of a network's capacity, the percentage allocation of traffic between voice, video, and data will need to be supplemented with dynamic session management. Not all sessions and applications are equal, and the network can only do so much with QoS and CAC.