The State of
Session Border Control

Early on in the world of IP Communications, it became evident that VoIP (define - news - alert) calls were going to have trouble getting through firewalls and moving across and to differing networks and devices (e.g. SIP and H.323). This led to the first Session Border Controllers, or SBCs. SBCs have evolved since then to include functions other than simple border control, protocol and media interworking, signaling/media validation and SIP-aware NAT [Network Address Translation] traversal. Security and management functions became important, such as access control, call detail recording, Quality of Service [QoS] control, network topology hiding, and so forth. With the approach of IMS [IP Multimedia Subsystem] and fixed-mobile convergence (FMC), SBCs are evolving once more to meet the challenge.

For example, at the recent GSM World Congress in Barcelona, Acme Packet (news - alert) demonstrated IMS and an IMS-compliant decomposed session border controller (SBC) and how their Net-Net SBCs will work in a FMC solution, providing security, service reach maximization, service assurance, revenue and profit protection and regulatory compliance — for IP interactive communications over fixed or wireless IP networks.

Acme Packet’s SBC can be ordered as a ‘decomposed’ SBC solution; their Net- Net Session Controller (SC) and Net- Net Border Gateway (BG) are software configurations that decompose session border control into separate signaling and media control systems for SIP sessions and are supported on both the Net-Net 4000 and 9000 series hardware platforms. Both the Net-Net SC and BG are ETSI TISPAN and 3GPP IMS compliant and deliver the Interconnect- Border Gateway Function (I-BGF) and Interconnect-Border Control Function (I-BCF) elements for interconnect networks and Proxy-Call Session Control Function (P-CSCF), Core Border Gateway Function (C-BGF) and Service-based Policy Decision Function (SPDF) elements for access networks.

SBCs are considered such an important network element that larger companies have acquired some SBC vendors. Emergent Network Solutions is now the Emergent Network Solutions group at Stratus Technologies in Maynard, Massachusetts. Emergent was attractive to Stratus, a well-known maker of fault tolerant computing platforms, since Stratus has a strategic business initiative involving VoIP, IMS, service mediation and fixed-mobile convergence (FMC), all of which rely to a great extent on SBC functionality.

Netrake, another venerable SBC vendor, was acquired by AudioCodes. AudioCodes’ VP of Marketing for the SBC Business Line, Menachem Honig, says, “AudioCodes recently acquired Netrake, a company that has focused on SBCs and security gateways for several years now. AudioCodes sees SBCs as a type of product complementary to its product lines. Until recently AudioCodes has focused on the connectivity between the PSTN and VoIP networks, but now we’re seeing a lot of VoIP ‘islands’ forming both on the operator and enterprise side, so the connectivity between such networks is not so simple. From Layer 2 and up vendors and networks are using different schemes, so you need something that can guarantee the traversal between networks and through firewalls. Up to Layer 7, the networks are not necessarily signaling with the same protocol. Even the networks are using the same protocol, there can be slight differences, and you have to bridge between them. Accomplishing this is one of the traditional functions of an SBC. Now that the world is moving away from the PSTN to IP-to-IP voice networks, AudioCodes decided it should play a role in this game. Thus, the SBC is a very natural component or network element to have in our product portfolio.”

“If we ignore IMS for a moment,” says Honig, “and simply focus on a pure VoIP network, we will definitely find SBCs at the network edge, associated with the access functions and the hosting of residential services. SBCs are also in the core, where they are used to peer between two VoIP network operators.”

“There is no doubt about the future of session border controllers,” says Honig. “As long as VoIP exists, SBC functionality will be necessary.”

“IMS has presented us with innovation as to how to compose the network,” says Honig. “We think that we can easily move the needed IMS functionality into the SBC and then the SBC will play a role on the IMS networks as well. Both the functionalities of an SBC and a security gateway are going to merge into one AudioCodes product in 2007. As for IMS, we’ll have one device with all this functionality of both devices on one platform and it will be optimized for IMS. With IMS you can compose a network differently, in which case the functionality of the SBC will be partitioned in a different way in the network. Still, we think our SBCs are flexible enough to provide a lot of functionality that is defined in the IMS architecture. This new device will work in conjunction with residential voice services, hosting VoIP, and in the core it will support trunk peering to other network operators.”

John Smolucha, VP of Product Marketing at ENEA (news - alert) (http://www.enea.com), says: “There was a feeling early on in VoIP that everyone in the industry would settle on the same two or three voice codecs, and not a whole lot of interworking and transcoding would be necessary. As it turns out, more and more interworking and transcoding has been necessary to maintain the interoperability of networks and network devices, and SBCs fill the bill.” “The ‘Session Border Controller’ term caught on because it’s a pretty accurate description of what they do,” says Smolucha.

“Ultimately, at the end of the day, without session border controllers, IP networks aren’t secure,” says Smolucha. “Carriers must be in a position so that they’re confident they can safely exchange traffic to access networks, and they’ll be able to do that while hiding the topology of their network, especially when it comes to carrier-to-carrier peering. A lot of what the rapid acceleration of VoIP that we’ve seen is all about moving across carrier-to-carrier networks. If you look at what what’s happening with the companies that are building SBCs, what would you say you see there? Are the companies going public? Are they getting bigger or smaller? Many are getting acquired by big companies, and you don’t do an acquisition unless you’re convinced it’s a strategic move.”

“As for ourselves,” muses Smolucha, “we’re probably the most important software company you’ve never heard of. We’ve been around for about 40 years. We’re a public company headquartered in Sweden, with 500+ employees globally. The interesting thing about us is that our software technology is powering about 250 million mobile handsets — 2G and 3G — half of the world’s 3G base stations, satellite gateways, media gateways, session border controllers, and more. Being that we don’t make devices, we help our customers make better devices. We don’t get the public recognition that really should go with what we do. The company had its origins building real-time operating systems for Ericsson, which is still one of our best customers after more than 30 years. We also work with names such as Nokia, Motorola, Sony Ericsson, Agere, Alcatel, Samsung and more. Our focus is really network software. When I say ‘network’, if you think of whatever you have in the palm of your hand as a mobile handset, being the termination or delivery point for that, then we’re also into mobile handsets.”

“ENEA is interesting is that we’re one of the only companies I’m aware of that has a software platform and IP infrastructure that works equally well in mobile handsets or in high-end carriergrade telecom equipment,” says Smolucha.

“One basic function that SBCs fulfill is carrier-to-carrier network peering,” says Smolucha. “As VoIP rolls out a bit more and the movement continues to try to achieve a coalesced IP network, session border controllers are still required to provide all of that interoperability to allow carriers to peer into each others’ networks, but now with security and quality of service [QoS]. I don’t see that moving into routers, since routers aren’t really ‘stateful’, they can’t perform all of the key mediation functions and quality of service, transcoding and authorization. I don’t see it being entirely integrated back into softswitches either, because a softswitch is only stateful at the core, not necessarily at the edge, which is where the security and quality of service mediation and traffic normalization happens. A softswitch can provide some of signaling and some media routing, but it can’t do all of the real-time IP routing.”

“So, in the cases of carrier-to-enterprise and carrier-to-carrier peering, says Smolucha, “SBCs will stay around for a while. Also, if you look at that market from who’s out there and who’s playing in it, the companies that are building SBCs tend to be specialized — the Acme Packets, MERAs, Netrakes, NexTones and Newports and the Sonuses. I haven’t seen the big guys such as Nortel and Ericsson take on session border control as a strategy part of their product portfolios. In 2003 to 2004 timeframe, I recall there was a flood of venture capital money into that market, something on the order of $240-$250 million in funding. Having raised VC money on my own, I know that VCs don’t put money into technologies or companies unless they’re hoping to get a 10X return on their investment in a three-to-five year window. So somebody was expecting a $2.4 billion return with a good hunk of profitability.”

“As carriers and operators send out RFPs, what are they asking for?” asks Smolucha. “If you believe guys like Frost & Sullivan and the other analysts that spend all of their time focused on this space, then there is a huge carrier demand for session border controllers, or at least SBC functionality, and it’s not going away, especially with the dramatic increase over the last few years in real-time multimedia IP communications, which typically are based on SIP, H.323 or MGCP protocols. Multimedia content really must flow between IP networks, carrier-to-carrier networks, or services that go from carrier-to-access networks be they enterprise or residential. What else but a session border controller could provide such functionality?”

“Still, as we talk to our customers about convergence and migration to IMS networks,” says Smolucha, “one of the things we see are folks asking themselves, ‘How do I get to carrier-grade availability? How can I improve the engineering efficiency of my product development team, reduce the cost of ownership of this technology and build stuff that’s going to last longer than three or four years in the network?’ So we’ve still got some work to do.”

The Hidden SBC

(news - alert) Rod Hodgman VP of Marketing for Covergence (http://www.covergence.com), says, “Many of the current SBC features are going to move into other network elements. That’s beginning to happen today. SBCs will have to evolve to address not the connectivity issues that they deal with today, but higher-level application issues instead posed by customers — both providers and carriers deploying IMS as well as enterprises. You can categorize these around a broad class of issues related to making a service ‘business grade’. The biggest market for a business grade service is of course businesses in the enterprise marketplace. Most service providers, other than the consumer VoIP pure plays, desperately want to attract and retain business customers because they can sell them higher value services and incremental services. But if you look at traditional SBCs today and how they stack up, in terms of several business-related categories, you can see that traditional SBCs are somewhat limited.”

“For example, the security that SBCs provide today is essentially unusable,” says Hodgman, “They don’t provide the signaling or media security encryption necessary to pass security muster or the monitoring, logging, and alerting necessary to pass the compliance team. If you look at SBCs’ ability to help service providers provision real-time services that go beyond VoIP, such as instant messaging, presence and other capabilities, SBCs do nothing — they’re ‘silent’ on that topic. Then there’s SBCs’ lackluster ability to manage diverse endpoints in terms of handling registration and registration ‘floods’ and in terms of addressing the interoperability issues that we’ll have at the edge because enterprises are going to use differing vendor handsets, softphones, Office Communicator clients, mobile devices, and so forth. In such an environment interoperability is not at all assured and needs to be addressed.”

“Then there’s the whole area of management tools,” says Hodgman. “Networks are becoming really complicated and they require high-level applications layer tools to debug and faultisolate problems on the network and ensure that the service doesn’t get degraded by these faults.”

“SBCs solved the first generation of problems,” says Hodgman. “You couldn’t make a VoIP call because it couldn’t traverse the network firewalls. To that we added some things necessary for service providers, such as call admission control and media transcoding, basic authentication. Many SBCs have some features you’d expect of them such as protocol and media interworking, session routing, admission control and policing, auality monitoring and enforcement, signaling security, network address translation (NAT), authentication, authorization, and accounting (AAA), media transcoding and call detail recording, Network Topology Hiding. SBCs will increasingly move onto things such as blades that will be in routers and other network elements. SBCs will be involved with open source software and pretty widely available as we move through 2007. What’s left to do with SBCs has nothing to do with connectivity issues, it really involves the harder, more interesting issues at the Application layer of how to provide a single point of policy-based control for real-time services and applications based on the SIP protocol.”

“SBCs will need to shift focus to solving application-level security, control and management issues,” says Hodgman. “Basic connectivity will migrate into network elements.”

Hodgman elaborates: “This is why we developed the Eclipse, which not only has basic SBC features but also advanced application level security features, such as application-level security, cryptographic authentication, DOS attack protection, signaling encryption, media encryption, signaling and media validation, intrusion prevention, virus scanning, malicious URL filtering. The Eclipse also has advanced management and control features, such as application- aware session routing, web services management/control, distributed signaling/ media processing, independent policy decision functions and much more.”

Another SBC-in-the-machinery scenario is playing out over at Tekelec (news - alert) (http://www.tekelec.com) Sara Hughes, Director of Product Management for the P6000 VoIP Application Server at Tekelec, says: “From the standpoint of the switching realm — I’m in the switching business unit — we have three products in this area and I’m the director of product management for one of those products. For my product and one other, we’ve integrated SBC functionality. My product interfaces with CPE [Customer Premise Equipment] devices as well as SIP gateways, so we use my integrated session border controller in the Tekelec 6000 to interface not only CPE devices and control firewall traversal, NAT and PAT and all that, but also to handle peering to other SIP gateways and SIP functions in the network.”

“The forward thinking of this is that we’re debating whether we should sell the SBC part as a standalone device as well,” says Hughes. “For the time being, the SBC is fully integrated with the product and is controlled by the product, which does yield a lot of benefits associated with an integrated platform. Not all of our competitors have that, and it does definitely give us an ‘edge’ that our customers see.”

“One of our products actually does connect to a 3rd-party session border controller,” says Hughes, “because the basic functionality that some customers need, such as session control, firewall traversal, and those sorts of functions, are needed and yet they didn’t need a very expensive platform to do that. And so we found a very inexpensive solution. In fact, you’ll find that a lot of routers and devices are implementing that approach, so SBCs are a kind of basic functionality, almost like having a photocopy machine in an office. Our other two products have SBC NAT traversal functionality integrated in them. My product takes SBC functionality to the point where it makes the implementation and deployment phases for our customers more seamless. In doing that, we’ve created a single solution. Both provisioning and billing is integrated. The control of that device is integrated, too. Statistics monitoring, and all of those types of functions are also fully integrated with the platform.”

“If you go with a standalone SBC,” says Hughes, “provisioning is separate; you’ve got another vendor to deal with, and the billing must traverse devices. You also have to deal with not only the integration of provisioning, but integrating the SIP call flow and any other protocol call flows between devices.”

Meet the Universal Convergence Gateway (UCG)

Reef Point’s Universal Convergence Gateway is the industry’s first fixedmobile convergence gateway product to publicly demonstrate security for multivendor mobile IMS networks and to concurrently provide security for mobile IMS and landline (or ‘fixed’) IMS networks. The Reef Point UCG was also the first gateway to publicly demonstrate IMS fixed- line and mobile network security and IMS Proxy-Call Session Control Function integrated in a single chassis system.

Aaron Sipper, Director of Product Marketing for Reef Point Systems (news - alert) (http://www.reefpoint.com), says, “Obviously, the network is changing. It’s changing for a number of reasons, but mainly because the applications being pushed over the network are not just voice anymore. They’re voice, data and video. Carriers are looking to deliver these things over a unified platform, or unified network, if you will. I think that VoIP has done a great service to the industry by paving the way in terms of showing how you can take something that wasn’t necessarily and IP applications and have it run over IP. For that process to occur, a lot of things in the industry had to change. IP has become as a protocol suite. More and more applications appear and they have more and more capabilities. If you look at SIP alone, for instance, when it first appeared it was a simple session setup and teardown protocol; it is agnostic to specific applications and so it’s suited to IMS.”

“New networks are trying to deploy services that encompass all media,” says Sipper. “When I say ‘all media’ I’m not just referring to multimedia, I mean all media: tech services, voice, data and video services that could be uniquely deployed on their own or they can be mixed in a number of ways. These services will be pushed over any network — any means the customer can use to access the services has to be available as a means to deliver those applications. It’s no longer suitable to just have networks built specifically for a particular application or setup accessing technology.”

“What Reef Point sees in the market is that there is a requirement now for a new kind of border element that must exist in the network,” says Sipper. “An SBC is definitely a border element. Session border controllers are purposebuilt devices that were really built for fixed-line VoIP signaling mediation for peering and access. They’re used in a number ways in such things as access applications, everything from VoIP services that you have at home or in the office to peering. Most of the traffic for voice today is obviously peering traffic or LD [Long Distance] so SBCs were designed to fix problems associated with two carriers or networks attempting to peer on a VoIP level, and really to handle signaling mediation — specifically, two separate domains can talk to each other without any problems, even if one domain is based on H.323 and the other is based on SIP.”

“Our Universal Convergence Gateways [UCG], on the other hand, are built to provide security, quality of service [QoS] and policy enforcement,” says Sipper. “In particular, they’re designed not just for voice but for any application you want to push over it. The UCG is built for what’s really occurring in the industry, and that’s the fixed-mobile convergence [FMC] order that’s occurring. So, whether a carrier is fixed line, cable, or a mobile operator really doesn’t matter. There’s almost always a mobile component to the strategies of carriers and network operators, and because of this, borders are definitely changing.”

Sipper continues: “If you look at the SBC architecture foundation, as I said before, it started out as a mediation device for signaling. Most VoIP networking and devices of the past used the H.323-based control protocol. As the benefits of SIP became more apparent, carriers looked to evolve the network to SIP, but they had to maintain interoperability with the networks that actually were generating revenue at the time, and those were running H.323. It’s still true to some extent today. The solution to this was the development a product that could translate between SIP and H.323, the SBC. The architecture is really based on back-to-back user agents and it’s very software-centric, because SBCs are designed by nature to terminate a SIP session, understand or parse through the meaning of that session, and then regenerate or ‘re-originate’ another session as need be. So, with an SBC you have to terminate, parse, and then re-originate.”

“Obviously, over time, SBCs evolved to accommodate firewall traversal on the access side,” says Sipper, “so if you’re deploying VoIP services on the edge, and you had a network access translation function sitting at the residence or in the enterprise, you needed a way to perform a conversion there, and so SBCs were a prime candidate to do that, because they could act as a proxy, they had back-to-back user agent functionality, and by tacking on some additional capabilities SBCs could get VoIP traffic could actually get around firewalls by handling NAT [Net Address Translation]. As the world moved forward, NAT was one of the first introductions to security measures. The SBC industry at that point realized that there are other functions that the SBC could provide, things such as topology hiding, SIP Denial of Service [DoS] protection and to some extent, VoIP bandwidth management. They realized that, because the SBC is an endpoint user agent, they could actually glean what’s really going on — for example, ‘Since I [the SBC] am really parsing the SIP message, I can detect a malformed SIP message that someone can use in an attack on me, to take control of the servers or do something to assist them. Furthermore, since I can already see the SDP session descriptor, I can make some decisions on what to do with that flow. Shall I route it to a specific path, such as a voice or IP trunk for least cost?’ So, security built into SBCs is designed for voice specifically and SIP, and centers on policy decisions. Typically, there’s a requirement with some SBCs that if you want to control the media you have to use a separate, external media-firewall to handle RTP sessions. Not all SBCs are like that, of course, some of them do include a media component, but usually it’s a separate function.”

“SBCs, therefore, are really good at VoIP network peering applications,” says Sipper. “At two VoIP borders — it really doesn’t matter whose borders they are — you really need an SBC to ensure the interoperability of the networks and to provide some measure of security in terms of topology hiding and potentially doing some authentication functions. More importantly, there’s other functionality that comes along with SBCs, such as doing number translation for ENUM (“Electronic Numbering”) that’s required at the border.”

“Now that IMS is appearing, many vendors are focusing on TISPAN,” says Sipper. “specifically the TISPAN as it addresses wireline players, and since many tend to be entrenched in the wireline space, it makes sense. SBCs are really positioned for VoIP fixed-line access and peering roles in the IMS network. So, vendors are starting to evolve their platforms to do more with it, along the lines of what they’ve done before, but now in an IMS context, so it includes such things as SIP protocol enhancement and as well as other protocols such as DIAMETER that’s necessary to work with other IMS network components.”

“Our universal convergence gateway, or UCG, starts life a bit differently than an SBC,” says Sipper. “We have a legacy too, just like the SBCs. The UCG actually started out as a security gateway. From a security gateway perspective, one looks at borders a bit differently than an SBC does. First off, the type of functions that are needed deal with private networking, authentication, separating traffic, routing, packet switching, doing NAT — I’m not referring to firewall traversal yet, but just NAT, mapping one IP address to another from an enterprise or VPN perspective — and being able to mark flows and provide some measure of QoS, being able to do firewalls and filtering packets using deep packet inspection to examine the flows, providing intrusion detection and protection capabilities, and also encryptions. As a secure gateway product, we developed this generically. We said, ‘Okay, there’s media coming in. It could be anything, because it’s encapsulated in IP. Given that, how do you safeguard that traffic and/or the network and in so doing, what are the functions we need to build into the system?’ And so we did. The architecture is really based on network processors, FPGAs [Field-Programmable Gate Arrays] and ASICs [Application-Specific Integrated Circuits], that must handle all types of IP applications at wire speed.”

“Why so? Their model of handling packets is completely different than SBCs,” says Sipper. “Everything must be processed at wire speed, and to do that, you can’t afford to terminate sessions. In other words, you can’t terminate a flow, look at it, and then decide to ship it out somewhere once you know what to do with it. Doing that causes too much delay and too many performance losses. Plus you have different protocols that aren’t necessarily suitable for termination. You can’t say, ‘Well, I’m going to terminate this type of session, parse it, look at it, then send it on its merry way.’ You have to be able to look at all flows in a real-time, singular fashion. What UCGs do in general is to use deep packet inspection technology that examines the packets as they move through the system, and affects change as the packet streams traverse the box. Hence the hardware focus of the UCG concept.”

“Over time, the UCG evolved to include things such as firewalls, NAT and you began to see more access-side specialization of functionality,” says Sipper. “UCGs can handle SIP DoS, ALG, additional encryption methods, IP application bandwidth management and offer flexible policy control.”

“UCGs are designed from the ground up for IP security, QoS, and policy enforcement and they operate on both signaling and media flows,” says Sipper. “From an IMS perspective, they’re focused on FMC access security, QoS, and policy enforcement for 3GPP, 3GPP2, TISPAN, and PacketCablebased networks. We expect that UCGs will be a major player in the IMS era.”

SBCs and IMS: Made for each other?

Over at NexTone (news - alert) (http://www.nextone.com) VP of Product Marketing Nick Turner says, “Many people wonder how SBCs will work an IMS network. Will they be absorbed? Packaged? Minimized in value? I think the clear answer from the field perspective is quite to the contrary. IMS is an ideal architecture if not framework for building networks and creating applications. But everyone is discovering that the real world is somewhat more complicated than what IMS’ creators anticipated in its design. The world is messy and has lots of complexity, and more and more the primary role of SBCs is to ‘nomalize’ that complexity into something that the core IMS networks can handle. IMS networks need to be fast, lightweight and inexpensive, so it’s important that the SBCs take away all of the complexity from the core.”

“SBCs are still important when it comes to certain kinds of network carrier- to-carrier peering, particularly dealing with H.323 which will be around for a while,” says Turner. “There are specific business rules involved in carrier peering which need to be observed or handled by an SBC on behalf of an IMS network.”

“For peering involving an enterprise, there are a different set of problems and complexities,” says Turner. “There’s the likelihood of more variances or difficulties of the IP realm. Then there are private IP addresses, public NAT devices, overlapping IPs, VLANs, ‘realms’, and all sorts of other nuances and complexities that softswitches and IMS networks don’t have the ‘plumbing’ to handle. An SBCs job is to take care of and normalize these things into something it can understand and relate to, in addition to the commonly understood security aspects that we all know and love about SBCs.”

“What differentiates NexTone is that we decided to go down the computing platform path from its inception,” says Turner. “We’re inherently portable to AdvancedTCA [ATCA] form factor computing platforms for high-end telecom applications. If you look at any major Tier-1 or mobile operator, they’re looking at moving generically from a telecoms hardware ‘kit’ network to more of an IT-based platform, and ATCA was the common denominator. NextTone equipment is Intel-based, our boards can slot into ATCA chassis slots as and when needed.”

“Bottom line, we see that SBCs were conceived of as a security device at the network boundary,” says Turner. “That role will persist. As we see more and more production environments we start to understand that architectures or I guess frameworks such as IMS need more, they need help in dealing with all of the complexity that the real world has. Take 3GPP as an example. Many of the 3GPP assumptions and what the devices and network will look like just aren’t real. Enterprises find themselves with IP PBXs from vendors that sometimes deviate slightly from established standards and the enterprise may want to preserve some private address space. 3GPP wasn’t designed for that, so you need something at the network boundary to provide the adaptation.”

As IMS gets going, people will be able to roam in a fixed-mobile communications environment from the desktop to WiFi to cellular or WiMAX with their services intact, the ‘boundary’ of the enterprise disappears. One would think that SBC functionality has to appear at every endpoint in the system, since the “edge” of the network will be everywhere.

“It may commoditize to that level over time,” replies Turner, “but at the moment we see the need to ‘repackage’ SBCs to fit the right space. So carriers for network trunking need fewer but very large implementations. As you head toward the enterprise there are more possible sites and the hardware form factor tends to be smaller. We fully expect such repackaging to be necessary to be a competent vendor in this space. Again, since we’re Intel-based we’re easily portable in all those dimensions.”

Whatever we call them — Session Border Controllers, Universal Convergence Gateways, or what-not — a certain group of features and functions associated with SBCs will not just persist in the future IMS network world, but will both flourish and be of immense importance.