The Avaya Session Border Controller

by David Lover | Arrow Systems Integration

It’s been a while since we’ve talked about the Avaya SBC. I thought it would be a good time for an update. First, the controlled introduction of 6.2 is now available. For those of you who have been in the Avaya world for a long time, it’s probably important to explain “Controlled Introduction”. In the old days, Controlled Introduction meant that you were basically doing a beta. It was an early preview of the final software that also involved testing the sales/services operational processes behind the scenes. Well, Controlled Introduction doesn’t mean that anymore. Now, Controlled Introduction really relates more to the available/tested features of the final version. And for those specific, fully supported, fully tested features, it is generally available for sale and purchase.

So, the trend is to now make sure that the applications that are creating the payload itself are encrypting that traffic. A secure web page is a great example of this. Web servers can be programmed with security certificates that encrypt it at the HTTP level, long before it hits the network. You see it as HTTPS or you’ll see a little lock on your web browser telling you that it is encrypted with SSL (Secure Socket Layer). In the world of Voice over IP, we do the same thing. We tell the phones themselves and the DSP resources (like a MedPro card) to encrypt the traffic before it even starts to think about the network.

So, for Avaya, this new SBC lets us get rid of the VPN remote phones that all use device-level IPSec. Granted, to do this with the SBC, it must be SIP based traffic. H.323 phones can’t come in via the SBC. These are two totally different signaling and bearer paths. But this means that the individual devices (like Avaya’s 96×1 and 96xx SIP phones) and softphones (like One-X Communicator, Flare Experience for iPad, and the One-X Mobile SIP clients) can connect to our internal infrastructure without creating the security risk associated with allowing VPN’d devices in.

Release 6.2 is a big deal. Besides the fact that it has been Avaya branded (remember this SBC was from their acquisition of Sipera), there are a series of mainstream SIP devices/clients that have been fully tested. This is where the “Controlled Introduction” part of the story comes in. In this first release, only the 96X1 phones (ie 9608, 9611, 9621, and 9641), One-X Communicator SIP for PC/Mac, and the Avaya Flare Experience for iPad (conferencing/video not yet supported). Again, these are the “supported” endpoints. On the one we have installed at Arrow SI, we have successfully connected these as well as 96xx (ie 9610, 9620, 9630, 9640). We’ve been playing with the One-X Mobile SIP for iOS, but I’ve found it to be a little flaky. But this client itself is actually in beta, so I’m not sure that it’s an SBC issue.

With this release, High Availability is also supported. This is actually the configuration we are running internally. I have 3 SBC servers. There are 2 redundant SBC’s, plus an EMS (Enterprise Management Server) that controls the HA functionality as well as the overall administration/configuration of the sbc’s themselves. If you only wanted a single SBC, it still uses the EMS, but it’s run embedded on the same server.

Avaya’s SBC tells a great story for a mobility solution. It fits beautifully with your BYOD strategy. There’s no need to VPN in the entire device. We simply enforce the encryption of the traffic of the ONE application on the device (ie the SIP client). If you bought the Sipera SBC, you REALLY need to check out this new version. As a guy who rolled out both the old Sipera version 4.0.5 and the new Avaya version 6.2, I can tell you it’s night and day better!!!

Share this article

The thoughts and opinions in these blogs belong to the individual blogger and do not necessarily represent the views or opinions of Arrow Systems Integration.