x
VoIP Systems

Juniper Kills Its Session Controllers

Juniper has discontinued the standalone session border controller (SBC) products it inherited when it acquired Kagoor Networks in March 2005, and has laid off staff in Israel as part of the process. (See Juniper to Acquire Kagoor.)

Juniper confirms its VoiceFlow range of SBCs are all now classified as "end of life," and that, as a result, 25 staff at its Herzelia, Israel, location have been laid off. Juniper describes the job losses as "very small... less than one percent of our [global] employee base," a spokeswoman says.

A Juniper spokeswoman says the company always had plans to integrate Kagoor's technology into existing products, and that "now is the right time to prioritize development in that direction to ensure we're well placed to deliver to customer requirements in the long term."

But while that platform integration was expected, some rival SBC vendors are surprised that Juniper has decided to exit the standalone SBC market so quickly.

According to Juniper's Website, the last order date for the VoiceFlow (VF) 1000 was June 30, while for the VF 3000 it is November 30 this year. Service providers using VoiceFlow SBCs, of which there are around 100, will be supported for five years after that date. (See Swisscom Deploys Kagoor's VoiceFlow, SingTel Picks Kagoor , Juniper Scores Kagoor Win, ISN Selects Kagoor's Controllers, BtNAccess Picks Kagoor, and Comwave Deploys Kagoor.)

The VF 3000 is a three unit-high SBC designed for edge and core session control functionality –- in essence, enabling the secure flow of traffic from one IP network to another. In the core, this would be from one service provider network to another, while at the edge it would help IP traffic, such as VOIP calls, traverse enterprise and residential firewalls. The VF 3000 was designed for networks with 1,000 or more concurrent VOIP calls.

The VF 1000 is an "entry-level" single unit-high SBC designed for network edge and enterprise network deployments, and was designed to handle up to 1,000 concurrent VOIP calls.

Juniper has also decided to discontinue the high-end VF 4000, designed for large networks that are handling 5,000 or more concurrent VOIP calls, though its absence from the end-of-life list suggests the product never made it into a carrier network.

Rivals believe Juniper has withdrawn too early from the standalone SBC market. "It's surprising Juniper didn't invest further in these products, as this is a growing market," says Kevin Mitchell, director of solutions marketing at Acme Packet Inc. (Nasdaq: APKT).

When Acme filed for an IPO in June this year, it reported a significant growth in revenues in the past few quarters, and cited figures from Infonetics Research Inc. that predicted the SBC market would grow from $86 million in 2005 to $613 million in 2009. (See Acme Packet Lines Up IPO.)

Mike Wilkinson, VP of marketing at Newport Networks plc (London: NNG), says he is surprised at the timing of the move given the current growth in the SBC market. He says Newport has already seen Juniper marketing an integrated edge router/SBC solution in the Asia/Pacific region, and notes that Cisco Systems Inc. (Nasdaq: CSCO) is also pushing the same integrated model. (See Cisco Integrates Session Control.)

Ditech Networks Inc. (Nasdaq: DITC), Sonus Networks Inc. (Nasdaq: SONS), and Veraz Networks Inc. (Nasdaq: VRAZ) are also pushing an integrated SBC story. (See Ditech's Itsy Bitsy Jasomi Deal, Veraz Gets More Controlling, and Sonus Takes Session Control.)

But Wilkinson believes carriers want SBC functionality in a separate network element, and there's market research to back up his view. In the Heavy Reading report 'Session Management, IMS, and the Future of Session Border Controllers' published in April this year, a survey of carrier respondents found that 85% preferred SBCs to be separate network elements, while just 15 percent believed that integration into a router (4 percent), firewall (4 percent), or softswitch (7 percent) was the optimal approach. (See HR Eyes Session Mgt and Why Session Management Matters.)

It's not just customers and Israeli staff that are affected by Juniper's decision, as the VoiceFlow products were resold by a number of other vendors, including Siemens Communications Group , NEC Corp. (Tokyo: 6701), Lucent Technologies Inc. (NYSE: LU), and Fujitsu Ltd. (Tokyo: 6702; London: FUJ; OTC: FJTSY), as part of their VOIP systems. (See Siemens to Resell Kagoor Controllers, Siemens Unveils 21CN Partners, NEC Selects Kagoor, Kagoor Teams With NTT-ME, and Kagoor Gets Hot With Lucent.)

Juniper's decision comes during a period of brisk activity in the SBC sector, with Acme filing for its IPO, Netrake Corp. being acquired, and Newport struggling to make its mark in the Tier 1 carrier community. (See AudioCodes Takes Netrake and Newport Sinks & Shrinks .)

— Ray Le Maistre, International News Editor, Light Reading

Page 1 / 2   >   >>
alchemy 12/5/2012 | 3:48:36 AM
re: Juniper Kills Its Session Controllers Given the Cisco strategy of integrating the SBC function into the router, I don't see that Juniper had any choice but to mirror that strategy. In the Cisco case, I think it's an excellent strategy since it essentially mandates forklifting your routers and replacing them with models that support the integrated SBC function. If your business is to sell routers, that's the correct strategy.

In the Juniper case, it appears that they got practically no traction with their acquired SBC product. In short, they bought the wrong company. There is clearly enough market to support 2 SBC companies since most customers aren't going to want to forklift their Cisco routers. Juniper wasn't one of the 2. Time to cut their losses.
digits 12/5/2012 | 3:48:36 AM
re: Juniper Kills Its Session Controllers So, let's hear it from the floor... should session border control (SBC) capabilities be integrated into other network elements such as routers, softswitches and firewalls?

And should Juniper be hanging on longer, or even for the foreseeable future, with a standalone SBC product?
optodoofus 12/5/2012 | 3:48:35 AM
re: Juniper Kills Its Session Controllers Carriers like the integrated SBC-router story since it avoids the need for an extra box in the network, reducing capital costs and operations costs. What's not to like? Unfortunately, there are a few things not to like. First, if history is any predictor of the future, turning on SBC capabilities on a router will significantly reduce throughput. Ask any carrier who has turned advanced QOS or firewall capabilities on an edge router. (Router vendors have to manufacture a reason to upgrade all the router line cards, after all). Secondly, in an area where technology is moving very quickly (such as VOIP/IMS), tying the SBC functionality to the router code release will put a major burden on the carrier test facilities. Now, every time the carrier needs a new SBC feature, they have to certify a full router release, which is much more burdensome. Also, tying the SBC to the router will make it more difficult to churn out new SBC functionality as quickly as the carriers will likely demand it.

At first glance, integrated SBCs seem free. But when you look closer, that's just not the case.

optodoofus
chook0 12/5/2012 | 3:48:35 AM
re: Juniper Kills Its Session Controllers Depends whether that edge router came from Juniper or Cisco. Turning on features on Juniper boxes typically has minimal or no impact on line card performance. (Although in a couple of cases and with some features, it forces packets through a hardware bottleneck elsewhere in the box.)

--chook

optodoofus:
"First, if history is any predictor of the future, turning on SBC capabilities on a router will significantly reduce throughput. Ask any carrier who has turned advanced QOS or firewall capabilities on an edge router. "
fmc_man 12/5/2012 | 3:48:35 AM
re: Juniper Kills Its Session Controllers Market size questions aside, the requirements for "border functions" have changed.

New requirements as an IMS border / PDG for example include support for user awareness, services beyond voice, lots of encrypted sessions(IPSec), SIP, DPI, etc. all integrated on a high performance platform.

I think it makes sense that most of the original purposes of SBCs - secure, NNI VoIP protocol mediation for example - would be intergated into an edge router.

Then the question is can SBCs re-position themselves as security gateways, PDGs, etc. And to do that, they will need new platforms with new technologies, more horsepower, etc.
link 12/5/2012 | 3:48:34 AM
re: Juniper Kills Its Session Controllers It has never been clear to me what the real function of an SBC should be. Most seem to agree that there is security functions, others seem to throw in transcoding and other functions. These functions could be moved as adjuncts to existing devices for more efficiency and probably more simply and hence more securely.

The model of having a standalone SBC seems to be introducing an entire softswitch like capability between two softswitches that are trying to talk to eachother. Granted that the SBC would be purpose built for protecting the end points, it just seems like it's too much to ask for the intelligent security desk guy to actually know who to let in and not let in (especially when you consider how much you have to pay these guys if they are appoaching the intelligence of the resources that you are trying to protect). It probably works better if the security guy is told to look at badges and call the destination and let the destination decide who to admit or not. My question is, are there not standards yet that allow the gateway devices to talk to the softswitches in a secure manner to enable the typcial security desk model???

Isn't the general direction for end to end security require encryption? Doesn't that cut out the abilty of the middle man (SBC) to apply any intelligence? If we give the encryption keys to middle man, haven't we just opened up a bigger potential security breach?




Dredgie 12/5/2012 | 3:48:33 AM
re: Juniper Kills Its Session Controllers As the P-CSCF and SBC functions were merging, will this router/SBC element also include P-CSCF functionality?
slideruler 12/5/2012 | 3:48:33 AM
re: Juniper Kills Its Session Controllers chook -

The same holds true, depending on the Cisco router you're talking about...7200/7300 are primarily software driven engines, and definitely suck wind when additional features are turned on. C10K is pretty much a hardware engine, as are most of the feature sets of the 7600 series family, meaning that throughput will be impacted to a lesser degree.

In reality, though, look at the capacity of Kagoor's gear -- the "big box" was built for 5,000 sessions. Cutting this in half to account for the "marchitecture factor" leaves a pretty small platform capability.

At the end of the day, what the router guys are more than happy to sell you more routers as the feature/session count goes up. In this model, "SBC" is just another IOS/JUNOS feature set - just stack more routers!

Full Disclosure: Not affiliated with any router or SBC vendor.

SR.
fiberous 12/5/2012 | 3:48:28 AM
re: Juniper Kills Its Session Controllers Looks like there is a pattern here:

PBC's, CMTS was a dead duck even before
Juniper acquired it. So, they bought it for
a good sum and lined the pockets of all the
PBC's unworthy management team.
Kagoor's SBC was the same and
so did the Kagoor management make a bundle.

It is incredible to find such social service
of bailing out loosers after the telecom bubble
burst!
lightreceding 12/5/2012 | 3:48:24 AM
re: Juniper Kills Its Session Controllers it may seem like social service in retrospect but maybe the M&A team at Juniper just wasn't so good at picking. This could be part of the reason for the big turnover in management and the renewed focus on internal development.
Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE