An application acceleration vendors says it has solved a persistent problem with optimizing Session Initiation Protocol applications.
Radware claims that its latest application delivery controller (ADC), called SIP Director, is the first on the market to be fully SIP-aware. However, a rival supplier has poured cold water on the claim, arguing that it’s already quite feasible to optimize SIP.
ADCs are used to improve the performance of Web and IP-based applications over WANs and other networks, using techniques such as proxying, caching, load balancing and protocol optimization.
According to David Aviv, Radware’s VP of advanced services, SIP, which is used in VoIP, instant messaging and other communications applications to set up and control sessions, is a problem for standard ADCs because it is not your typical client-server app with persistent sessions.
“Most ADCs are designed for client-server applications and need persistency on each session,” he explained. “SIP decouples the control stream from the message stream, and the control plane is peer-to-peer so everything is exposed, such as IP addresses, which brings new security issues.”
He added, “The three tiers of SIP require three different solutions. The first is an application layer, for applications like voice mail or conference calling, another is the session controllers and gateways, and the third is the core IMS or SIP signalling. Each one has different issues. For instance, core authentication requires different things from call state persistence.”
Aviv said that SIP Director can also act as a carrier-grade VoIP bridge, proxy and gateway, bringing interoperability and transport conversion on both the core (which could be SIP or UDP, say), and call (TLS or TCP) sides.
He explained that while SIP signalling — as a real-time protocol — cannot be accelerated, an application’s content can, so you can still build SIP services that can be accelerated. In addition, he said, “the SIP control plane is ‘high touch’, so on top of the TCP proxy we can split the session across multiple SIP servers for better SLA and response time.”
However, F5 Networks’ UK technical director Owen Cole pointed out that his company has offered SIP capability in its BIG-IP ADCs for some time now, including the ability to distribute and balance SIP and RTP traffic, and perform health checks on the SIP devices themselves.
SIP is not at all difficult to deal with, he declared, adding: “The way SIP works is a challenge for a lot of people, because it looks like HTTP but it’s not HTTP. We introduced persistence for SIP four or five years ago, though.”
He said that in his view, the content of a SIP call shouldn’t go through the ADC in any case.
“The subscriptions to call managers and other devices would go through the ADC, but not the peer-to-peer traffic between devices,” he explained. “A real-time protocol is best run peer-to-peer as it needs the shortest network path.”
Cole was speaking as F5 announced its biggest ADC yet, in the chassis-based VIPRION system. It uses similar software to F5’s current BIG-IP models, but is designed to run as a clustered multi-processor device with up to four blades, each with four processor cores.
“We have seen market demand for greater throughput in a single system, instead of having three or four separate boxes,” he said. “The clustered multi-processor concept needs intelligent workload management, so it’s more than just a BIG-IP on a blade, but it gives linear performance growth.
Following Cisco‘s announcement earlier this week that it had updated its Application Control Engine (ACE) line of ADCs, F5 claimed that each VIPRION blade outperforms a top-of-the-line ACE by four to 10 times on application throughput and SSL processing.
