By now, you know how much of a fan I am of Avaya’s SBC. Avaya really knocked it out of the park with SBC 6.2. This is the first major version of firmware developed after the acquisition of Sipera. And while I realize that most people think of Session Border Controllers for their SIP trunks, I still find this use-case to be the most boring. Remote workers and mobile devices are my favorite use-cases for SIP right now, provided by the SBC-AE license. I live it. I have One-X Communicator SIP, that happens to be installed on my home PC, I use Flare Experience for iPad (happens to be on my personal iPad) when I’m working from some other remote place (remote Arrow S3 Office, customer site, hotel, etc), and I use the new One-X Mobile SIP for iPhone (on my personal iPhone). All of these connect in through our Avaya SBC’s in either Bloomington, MN or in Allen, TX. The best part is that none of these personal devices need a VPN connection of any kind. IT departments LOVE this. It is definitely the most secure way to support BYOD. Secure the application, not the entire device. There’s no company data stored in the app at all and the SBC only let’s in that one application’s traffic (ie SIP Signaling and Bearer Path), not the entire device’s traffic.
But this isn’t a discussion about SBC’s. Let’s focus on the real world issues of rolling out these cool SIP-based clients to end-users. Until recently, you really had to be configured as a SIP user, with SIP endpoints in Communication Manager, for this to work. It seems logical right? That by itself is not a big deal. But it also means that if you also want a hard physical phone somewhere, it has to be a SIP phone as well. SIP signaling and H.323 signaling are totally different. If you tell CM that you a user has a SIP phone (such as an administered type of 9608SIP), but they attempt to register with an H.323 phone (such as a 4610), nothing will work right with that station. The really weird part is that it may work right for a little while, you may even be able to place and receive calls, but eventually the the screen will go funky and usability becomes a serious issue. The answer has been to make sure a SIP user only uses SIP endpoints and clients. The good news is that if you have 96XX’s and the 96X1’s deployed as H.323, they can easily be converted to SIP with a simple firmware update. But what about the 46XX series phones???
If your company is like mine, you still have a TON of those 46XX series IP Phones. These phones work great for H.323, but they don’t work well at all for SIP. This means if anyone wanted to use any SIP device or client, I’d have to buy them a new hard phone (preferably a 96X1 series phone), whether they really needed it or not. That was a hard pill to swallow. To be honest, this limited our rollout of SIP Mobility to our end-users. We’re not going to generically replace all the dial-tone oriented hard phones, just to give people access to SIP. There were some that didn’t need or want a hard phone anymore and just wanted to use the SIP clients (Flare Experience for iPad has been the most popular with our users), but most of them REALLY wanted to keep a physical hard phone on their desk. Well, then no SIP for you! That is, until now…
As of Avaya Aura 6.2 FP1 (which, for CM, is technically version 6.2.1, which with SP6, puts you at 02.0.823.0-20558), Avaya is now supporting and documenting the use of a dual registration of both SIP and H.323 endpoints to the same extension. You should know that not every feature has been fully tested using this dual registration concept, but most of the basic things have been working well for us. So, how do you do it? You still need to add a user to System Manager the same way you would any other SIP station. But instead of programming it with a SIP set type (ie such as 9611SIP), program it with the set type you would normally do (ie maybe 4610). In fact, if the station already exists, System Manager will tell you what set type the station is currently configured for. The big difference is that by using an H.323 set type, System Manager won’t automatically build the OPS station required in CM to get the SIP routing to work right. So, you need to go do that manually. To see how it’s set up, a system administrator can just look at one of their existing, real SIP phones, and use that as a guide. They can see the programming with “display off-premise station-mapping xxxx” where xxxx is one of your existing SIP stations. Then, just use “change off-premise station-mapping yyyy”, again, where yyyy is your new station, and add the required OPS programming. Keep in mind, this is just the station level programming. This assumes that the all the system-level administration has been done to make your Avaya Aura system is SIP-enabled. It’s not hard, but definitely out of the scope of this blog.
So, don’t get me wrong, I LOVE the 96X1 phones. And they are great SIP Phones. Really good stuff. And you’ll get a much more seamless and intended experience by keeping all of a single user’s devices the same type (ie SIP versus H.323). But for those end users that don’t need the features of the new 96X1 phones, this lets you get some more life from those old phones by simply adding SIP mobility on top of it!! If fact, here at Arrow SI, that’s what our plan is. We’ll slowly migrate our remote users off the VPN remote 46xx phones and replace them with 9608 SIP phones that will register through the SBC. But until that happens, they can still get the value and benefit from the other Avaya’s SIP clients, all while keeping their existing H.323 hard phones!!