Transcript for NET’s Talbot Harty Discusses Next Member of UX Family
Jim Burton: Welcome to UCStrategies Executive Insights, I’m Jim Burton and I’m joined today and again by Talbot Harty, Chief Development Officer at NET. One of the things I observed at Microsoft’s Worldwide Partner Conference a few weeks ago was that now these devices that have been known as gateways and the UX2000 being one of them, are now being called “SBAs,” survivable branch appliances. Microsoft has gone out and discovered that the branch office needed different services than necessarily was being available or offered by them and their partners in the past. So they came out with this device and I’m here today to talk to Talbot about how they’ve evolved the UX series into an SBA. Talbot, can you explain what this new class of product is all about? What does it do? Where is it used? And what features and functionality does it deliver to the customer?
Talbot Harty: Sure. The SBA supports Microsoft Lync for Unified Communications and it’s a survivable branch appliance that provides mediation and interoperability for the remote branch offices, as you have the Lync solution consolidated into core data centers.
Jim: I remember when I was here last time and we were talking about the UX2000, you really made a big deal about how it was a whole new architecture and while it sounded very good and it was scalable and it was all of these things, it was kind of like – “Oh great, it’s just another generation of gateway” as far as I was concerned. So how does that new architecture play into the fact that you now have this device also structured to be an SBA? What is the difference, and what I’d really like to understand is what would it have looked like if you would have just taken your old product and just added to it – compared to re-building or designing a product from scratch to fit this whole new market opportunity?
Talbot: That’s a great question. So in fact, that’s what most of our competitors have done, is taken their existing product architectures for their VoIP media gateways and added to it. And they really come from a couple of different architectural formats – there’s a format that has kind of a DSP-driven media gateway functionality at its core with a bolt-on server module. And then there is the other platform that takes what is basically a PC server and slaps in a communication card in there and then puts software into having the PC software control that card. We also have products that fit into those camps and the challenge was what the SBA was going to require now and what it was going to require going forward as we look at the different types of sessions that we were going to need to provide interop and functionality for – we recognize that now was a good time to start with a clean slate, and build an architecture from the ground up that would truly support the SBA requirements as a hardened integrated appliance.
Jim: Our goal is to help educate the end user and how to make an intelligent UCStrategy decision. The other thing that we work and pride ourselves in is to be vendor neutral and very objective. So I’m going to ask you a series of questions here to give you an opportunity to explain to our audience things that they should be looking at when they are looking for an SBA. I also want to be sensitive to the fact that I have good friends that work for your competitors and I don’t want to say anything that would be derogatory towards them and I know you will honor that so I’ve got a list of areas that I would like you to talk about and again, just giving guidance to our enterprise customers of things they should consider and think about and potentially ask when they are looking at an SBA.
Jim: So let’s just start off with, in comments that you have made before is that it’s a truly integrated appliance, so what are the issues around that and what are the things people should be looking for?
Talbot: So there’s a few things that customers should be looking for when it comes to looking at this, an SBA as a hardened enterprise class appliance. One of them is an IP switching core and this is the fundamental issue here is that at the heart of the SBA there is an IP switch that front-ends the rest of the solution behind it, and in some cases protects it and in other cases just makes sure that the front end creates a single entrance into the system for configuration and management and processing. So that IP switching core being the heart of the system is one element that they should look at and one way you can tell, and one question to ask would be how many Ethernet ports do I need to hook to this device, as an appliance? In the cases where you have architectures that have two separate systems inside the same box, the answer for that will be two. It will always be two because they have two, they are two fundamentally different systems, they need two fundamentally different Ethernet addresses and they have to be set up that way. In ours, it’s a single system, it’s a true single appliance and you need one Ethernet port and one Ethernet address to drive that. It will support a variety of Ethernet ports but you will only need that one Ethernet port to identify it as a system.
The second I would say the question is, what does the configuration and management UI look like? Is it one interface to set up the media gateway and something else to set up the Microsoft SBA server environment? Or is it an integrated single management UI with single configuration that controls both aspects of the SBA? And those are the two things that would identify it as a hardened integrated appliance.
Jim: Good. So the next thing on my list is the basic architecture in the upstream, how you’ve simplified that for cost effective migration? And I think the important part of that, and one that I would like you to speak about is – we know that these devices are being used for certain things today and we know that in the future they are going to be asked to do a lot more and the one that always comes to mind to me and the big challenging one is people’s upscale to video, which seems to be on everybody’s mind today. So could you address that particular area?
Talbot: Sure. The products, the SBA products that are out there today, don’t all support the concept of an upstream architecture. Where they are actually taking in the trunks and then behind it lives the existing PBX infrastructure that is being migrated away from and the Lync environment that is being migrated too. NET has a history of designing products that support that upstream architecture model. In a typical media gateway scenario is the media gateway is hanging off the PBX and the PBX has the T1-E1 trunks coming into it and in the case of some of the deployments that were are seeing today where we’ve got SIP trunking going on, those SIP trunks are going into the IP PBX and then the media gateway is hanging off the side and then the Lync environment is hanging over there.
So there are two fundamental things that I think are really important about supporting migration. One is being able to put the box in this upstream model because what you are doing when you do that is you are making the migration very, very seamless and transparent as we move users and user groups and sites over. And we can literally move a single Lync user at a time over and with the implementation of our active directory capability, where we can actually leverage Microsoft’s active directory functionality – it doesn’t require any configuration or changes or call route changes on the gateway or the existing environments to migrate people to Lync. Once that client gets registered in an active directory as a Lync user, the gateway is intelligent enough to start routing those calls over to that environment as opposed to the PBX. That makes this painless, it makes it seamless and it means that you can cut down dramatically the call re-routing configurations of the environments as you are moving people from one environment to the next.
So that’s an element of that upstream model and then you have the trunk issue that you need to be able to deal with and that comes in two forms. A common form that people are moving to today is SIP trunking which requires a session border controller capability and we have an integrated session border controller capability in the box but the key to that is that SIP trunks can only talk to a single device, whether that be an SBC, whether it be the Microsoft mediation server, whether it be an integrated session mediation platform like ours with integrated SBC functionality, but it can only talk to one box. And having that integrated SBC in our box allows us to be able to take in those trunks and then route the calls to the appropriate environment as opposed to routing all your calls through your PBX and then over to Lync, or routing them all through Lync and then sending the ones that you don’t have in Lync over to the PBX of the IP PBX environment.
So that integrated SBC is a core element of the upstream model and the second one is something that we’ve been doing for quite some time, which is called a TDM cross connect architecture. With our TDM cross connect architecture, we’ve actually virtualized that transition so you don’t lose visibility to the channel when it changes transport media. And secondly what happens is because a lot of these boxes that are architected to simply take whatever they are getting, whether it came from IP or whether it came from TDM, dump it on the DSP and get the opposite of it coming out the other side, when you need to do things like IP to IP or TDM to TDM, in these boxes that are forced to convert based on the nature of the way they are architected, they have to hairpin that call back through and basically double hop it – so they take the call, let’s say it comes in on a SIP trunk but it’s going to an IP device – maybe a SIP phone or something like that. They’ve got to take it in, they’ve got to convert it to TDM, then they’ve got to convert and send it back, convert it back to IP and then send it to the end point. In that case, we’ve added latency in call, audio quality degradation and so forth. The TDM cross connect is the same issue. If I’m taking in a TDM from a TDM trunk, a call - and I want to send it to a TDM device or an analog device, I need to take that, convert it to IP, drop it back, send it back through the box to get reconverted to TDM and then sent on to the analog device and that, again, call quality, degradation, latency, all that stuff gets injected into that call.
With our products, and the TDM cross connect capability, we can take that inherent, natively and keep it as a TDM flow all the way to the end point. So that upstream architecture, there is a lot to it; there’s the integrated SBC, there’s the TDM cross connect architecture, there’s the active directory integration for seamless migration and those three areas in there are the core things that allow you to confidently use an upstream model when you are deploying Lync.
Jim: Thank you. The next question is on enterprise class security. One of the things that happened when I was at the Microsoft Worldwide Partner Conference – they had a presentation and in that presentation they had a quote from Miercom congratulating NET on the quality product they had. So can you take this into the security issues?
Talbot: Right and there are some here. I mean again, without that integrated section border controller, in order to support remote users you would literally have to punch holes – a ton of holes in the firewall to get that traffic through into the SBA. We come back to the two elements that I think are key here. One is an IP switching core which we talked about earlier when we talked about the integrated appliance so we have that heart of the system being an IP switch, a high performance, high processing capability switch with an integrated hardware based firewall. And this is important – why do you need that? If you are doing a software based firewall capability in the system, then you are going to have performance degradation and scenarios where you see denial of service attacks and so forth on the box. And the performance is going to degrade dramatically. One of the reasons we got that Miercom secure certification was because of the fundamental architecture of the box, its ability to do the high, 35 million packets per second processing capability, that could literally take any denial of service attack, throw away those packets and continue to function and support the calls that were going on there.
That enterprise class security, the ability for the box to live in the DMZ and support an environment with NAT Traversal and the things that prevent you from having to poke a million holes in your firewall to support remote users and connectivity outside of the enterprise LAN, that is critical and that’s the reason why we got that certification.
Jim: Congratulations. So the last one on my list is talking about the reliable capacity in performance and I know you’ve touched on a couple of these things before, but let’s go into this in a little more detail.
Talbot: For the SBA there are two areas that we really need to look at when it comes to capacity, call capacity and performance characteristics of an SBA. One is the size of the server module that is going to support the Microsoft SBA code and the second is the inherent encryption processing capabilities of the mediation platform itself.
In the case of the server module, and one of the things that we are seeing in some of the specifications that are posted by competitors is there are assumptions there about how the box is going to be supporting the end user community. And in particular, one of the ones that hit the performance of the box the hardest is something called media bypass and what media bypass does is, it offloads the media processing off the gateway and basically, the box is just supporting the signaling to hook up the two end points to talk to one another and then all the media just flows directly between the end points. There’s no burden put on the mediation device itself. And in that scenario, where media bypass is turned on, you can see call capacities in the hundreds supported by some of these boxes. However, there’s a fundamental problem that we have with the assumption about media bypass being on in the branch office and that assumption is that everybody lives on the LAN all the time. Media bypass is not a good solution when you have remote workers that are coming into that office, connecting into it or people that aren’t on the LAN that are consuming services off of that SBA.
And so what happens and what you can expect to see, is the performance capabilities of that SBA will change dramatically when you have media bypass off.
Jim: To what levels would that…
Talbot: Some of the ones we’ve seen based on the specs that are posted, are as much as 90% decrease in call capacity with media, supported on the mediation platform versus media bypass being on. I mean it’s a pretty significant and dramatic issue because it’s the difference between doing the work and not doing the work. And if you assume that you are not doing the work you can support a lot more calls. What we’ve done in our specs, is assume that we are doing the work so we assume that we are doing those chores all the time, that we are handling the media, that we are handling remote users, hanging off that office and those are the basis of our call capacity statistics. That’s something that should be looked at very closely for the people that are trying to design and size the deployments that they are putting in place.
The second item, which has to do with things like SRTP encryption and the way we are handling encrypted sessions, SRTP encryption turned on may have a dramatic impact on the processing capabilities of the mediation platform itself. This is another example where we assume that it’s on with our specs and others do not. So if we are going to truly encrypt end-to-end with SRTP, then you can expect to see 20% to 50% degradation on some of the competitor’s boxes with them having to do the encryption chores. A unique aspect of UX is we are providing a dedicated hardware-based encryption capability in the product to ensure that we can support SRTP at full call capacity.
And again, if we think about audio, and voice being the low bar as we are getting into what we are going to have to do going forward with mediation appliances, now is the time to start with the next generation platform because this is only going to go up from here, right? Video is going to be immensely more taxing on the box than voice as we look at transcoding chores and interoperability and the other things that get put on that SBA module or other transcoding chores that we need to do or other high fidelity codecs that need to be supported in the mediation platform itself.
So recognizing that, if you are kind of hitting the wall where you are right now and you are saying, “Well it works well in this condition as long as you don’t turn this on or you don’t use this type of encryption, you’ll get some call capacity, but if you turn these things on – call capacity is going to degrade,” then where does that leave you when you roll out your enterprise network and you need new functionality, new operability chores and so forth and new capabilities out of the platform? Recognizing that we were going to have large enterprise customers that really wanted to roll out a network they could grow with for years and with UC, we just started from scratch to build something that was going to support this growth and migration to unified communications.
Jim: One of the things, that in fairness – and I’m not in a position to hear all the feedback from the field but I’ve not heard people saying that their products are hitting the wall yet that they’ve bought, and so I kind of wonder about that. Is it because these products are not necessarily deployed widely or is it because they are in labs being evaluated and maybe not hitting some of the real issues that they may face when they are deployed?
Talbot: I think that we are in the early days of unified communications and the adoption of Microsoft Lync and there’s just a lot of stuff going on but a lot of stuff is pilot, or contained deployment, if you will as opposed to a full scale rollout – especially for these large customers. So I would say, in environments where you have a smaller or medium size business, you are starting off on a pilot, you may not see these issues initially. Right? And you may not see, you may not really be thinking about the security issues because you haven’t been under a denial of service attack for example. Or you may not be thinking about the call capacity issues because you are dealing with a smaller pilot, you don’t have a lot of users on it, maybe those users are all contained within the LAN and you are running in a media bypass mode and you aren’t using encryption. So in those cases, you may not expose these issues but as we talk to our customers and their intent for what they want to do when they are fully deploying and the types of networks that they want to build and the types of chores that they want this box to be able to support – at the end of the day, those become fundamentally important issues when you get into a full production rollout.
Jim: Talbot, I was at the Worldwide Conference as I mentioned earlier and I was at the NET booth and I saw a new box there that was called the UX1000. Could you explain what that’s all about?
Talbot: Yes, so the 1000 is the next in line of the UX product family and it’s designed for smaller branch offices that don’t need the high capacity and high performance capabilities of the UX2000. One of the things that we are doing that’s unique with this UX product line is we are building everything on a common architecture with fundamentally the same code base for all UX products whether they scale up or down in this solution. And the reason that we are doing that is to give the customers that are deploying enterprise networks a common solution to configure and manage and rollout in their large enterprise deployments. So that’s a unique capability and it’s part of the fundamental strategy for the UX architecture. But the capacity of that box is scaled to 1000, it’s scaled down to meet the right price points and the right capacity needs of smaller branch offices.
Jim: In what kind of time frame will this product be available?
Talbot: We are going to be introducing our pilot program for key partners and customers this fall, and these devices will go into the labs and pilot environments to be trialed and then at the end of the year we will be releasing the initial versions of the UX1000.
Jim: I’m sure you can’t tell me who those partners are that are trying it but can you give me an idea of what kind of companies they are – multi-location? International? Large, thousands of deployments? Something to give a sense of who are the people that are actually looking at this because clearly they are only looking at it because they are interested in buying it – they are not interested in being a lab for you.
Talbot: The answer to your question is yes to all of the above. Multi nationals with large enterprise networks and looking at thousands of seats and hundreds of sites and again, we are very, very focused on enterprise class Lync and that’s what we are designing these products for so both the partners that are implementing for those types of customers and some of the customers themselves will be participating in our pilot.
Jim: Talbot, given the price sensitivity of media gateways, why did you come out with the more expensive version – the 2000 before the 1000?
Talbot: That’s a good question. Our feeling was, if you look at where the adoption of Microsoft Lync is at and how the pilots are coming and the momentum that is picking up, the 2000 was the right product to start the UX platform on – getting all the capacity and the performance and everything we needed for the higher end SBA solution in there – to prove out the enterprise class capability of the product. And do that before there is widespread adoption and the market really takes off which we expect to happen. And so we thought it made sense to get that whole architecture done and come out with the 2000 and then go downstream with the 1000 to hit the more price-sensitive and lower capacity solution.
Jim: But aren’t you finding that you are at competitive disadvantages because your competitors already have products available for customers today?
Talbot: Well they do, but they are different products. And they may be more price competitive for a pilot scenario but certainly not more price competitive for a large scale rollout when you look at the time for a project of a large enterprise to roll out, the 1000 will be here well within the timeframe to be able to support those customers as they are rolling out their solution. And what they can count on, with the 1000 – that it is based on the exact same software and architectural solution of the 2000. So what we’re seeing with our customers is they typically start out with a pilot and they go to their initial large sites that they are doing to roll that out. And then from there they will fan out their deployments to cover all the different countries and smaller sites and branch offices and so forth. So I think we got it right – I think we are meeting the needs for where they want to start and they just need to know that the 1000 will be there when they get into large scale deployment of their smaller branch offices.
Jim: This has been very helpful, there was a lot of information you provided and quite frankly what I was also hoping for is that we could summarize this so you could have the individual questions that you think would be appropriate for our audience to ask as they are doing their due diligence and as they are developing their UC strategy.
Talbot: Okay, let’s start with the integrated appliance and I think an important question for them to ask is how many user interfaces am I going to have to deal with for configuration and management of the solution? And is it two separate systems inside of one box or is it truly one system?
Next is, is the SBA designed to support the upstream model regardless of transport type? Whether it’s IP-to-IP or TDM-to-TDM or anything to anything else? And how effectively can it support migration when we are moving users from one environment to the other?
The next thing obviously, enterprise class security is a critical item. I think one way to look at the SBA, is it’s moving from what was a gateway world to an appliance where we have this thing that is core to the solution. It’s core to the network solution for supporting real time communications and therefore, it needs to be secure.
Lastly, dig deep into the numbers, dig deep into the call capacity numbers and understand if you are going to need encryption requirements, what does it do to the box? If you are going to need a support for remote workers – and you actually need the mediation appliance to handle media, what does it do to the call capacity of the box?
And that’s it – those four elements from there. There is a litany of feature level interop and that’s what we do all day long and we’ve done for years and there will be an always be an endless flow of new requirements to get something to work with something else. And those things are all doable, in comparison to the fundamentals that your architecture can support. And having an architecture that can support the future of unified communications is what I think people want to be thinking about when they are building out these enterprise UC networks.
Jim: Well Talbot, thank you and to our audience, as you all know we at UCStrategies have been focusing on SBAs for quite some time. Dave Michels did a vendor neutral report on SBAs back around the beginning of the year. And it’s something that each vendor had an opportunity to edit and review to make sure we were accurately reporting what they had to offer. We’ll put a link to that on our site and we’ll of course continue to talk to others about SBAs and their deployments because it is an important part of an investment people make in their UC strategies. Again, Talbot, thank you very much.
Talbot: Thank you Jim.