UCStrategies on SBCs

UCStrategies on SBCs

By Stephen Leaden October 24, 2013 Leave a Comment
AA Industry Buzz graphic
UCStrategies on SBCs by Stephen Leaden

In this Industry Buzz podcast, the UCStrategies team discusses session border controllers and gateways. Steve Leaden is the moderator, and is joined by Phil Edholm, Bill MacKayJon Arnold, and Dr. Joseph Williams.

Loading media...

Transcript for UCStrategies on SBCs

Steve Leaden: Hi everyone, this is Steve Leaden from UCStrategies and the UCStrategies team. I will be hosting this week’s call, and the topic is all about session border controllers and gateways. It’s a very, very interesting topic because it’s actually a necessary requirement on the gateway side. Gateways have now been used for years to interface to legacy PRI trunks, analog devices, other kinds of digital technology, as well as legacy systems. Gateways have actually been around for quite awhile in the voice over IP and UCC space and now session border controllers have entered the space; have actually been around for several years now in the carrier side, but have now begun to infiltrate and gain exposure in the enterprise side of the market.

Session border controllers in particular are interesting because they are the main driver behind interfacing with SIP trunking. Now the carriers in general have provided session border controllers at the carrier level. But our colleagues at Gartner Group, about 24 months ago, put together an article and highly recommended to the enterprise user community to go ahead and get their own, and highly recommended obtaining their own session border controllers. Now we call them enterprise SBCs or ESBCs for short, simply because you want to ensure that you’ve got all of the controls and firewalling and call control and filtering and quality of service policies around interfacing into your environment.

So it is a very, very interesting topic; it’s a necessary topic, in my opinion. I would like to bring Phil Edholm in on this and talk about a survey that he just reviewed and found some very interesting data. Phil, maybe you can share with the team and the group and the listeners that as well why we need a session border controller.

Phil Edholm: In the old days of voice over IP, and I guess we would say that about a technology that is basically about 10 years old, maybe a little bit older... what you had to have was a gateway between your voice over IP network and the TDM. It actually took the packets, terminates them, took the data out of the packets, if necessary, did a codec conversion to G729 or G711 or whatever it was and then interfaced to the traditional PSTN via the T1. So that’s been the traditional PSTN gateway we’ve had over the years.

But what SIP brought was the concept that you could actually have a SIP trunk from a carrier where rather than interfacing using TDM technology or interfacing using voice over IP on an IP network with the SIP signaling methodologies. So one of the things that happened there is you now can go directly from a SIP interface on your premise equipment to a service provider who has a SIP trunk. And the promise, of course, was that these things would be openly interoperable and you could just plug together and select them. And it turns out that in many cases that’s true.

So what is interesting is that Infonetics actually did some studies/surveys earlier this year. One of the things that was very interesting was they asked about how people were connecting to SIP trunks. And what they actually identified was that it actually was around between 30 and 35 percent of the enterprises were actually using some form of SBC on the premises side on the SIP trunks. The vast majority, 58 percent for example, were just relying on the SIP capability that came with their PBX to go directly to the carrier’s SIP trunk. And obviously if you are willing to open a pinhole in your firewall with the IP address of your carrier and you assume that the carrier is protecting that IP address and you are not opening yourself up to viruses and malware coming in through that IP address, you can just do that.

So one of the questions, I think, that is very interesting for us to start with is, why do you want an SBC? Why is an SBC important on that SIP trunk? I will start off by saying I think there are four reasons. The first reason is interoperability. One of the things about SIP is, SIP is one of those standards that there are a number of points in the standard where the actual choice of an element of the standard has been left up to the implementer. And the net result is that often you can have two totally SIP compliant implementations that in fact will not actually interoperate. Or you have to choose within one of them, certain parameters based on whatever other side they are talking to. Now a number of the vendors certify their PBXs with certain carriers. But one of the big advantages of an SBC is most of the SBC vendors have a long list of essentially interoperability certifications and testing, so both on the premise equipment side, Avaya, Cisco, Microsoft Lync, but also on the carrier side with all the carriers. So that’s the first reason.

The second reason is security. The SBC provides a much more heightened level of security, assuring that other types of traffic are not coming in disguised as voice. One of the things you will see is that vendors are extending this now to policy, and this especially becomes true when you have different types of traffic where you can actually determine, is this person entitled to do a video conference.

The third is related to the interoperability but is around the concept of being able to have multiple carriers. So if you have just one connection to one carrier for one SIP trunk, you now have two disadvantages. The first is that you don’t have redundancy necessarily, if that carrier has a problem and an impact that you will lose your trunk access. The second is that you can’t do easy pricing arbitrage. So a number of customers want to have multiple connections to multiple carriers. And you can actually accommodate that in SBC. And some of the vendors are actually building new and interesting capabilities to manage an arbitrage between those vendors dependent upon rates and where things are going.

And then the final reason is that the SBC is a tether point for those IP communications where you can provide other services like recording unlawful intercept and those kinds of issues. I think one of the things that is very important is a lot of people are actually putting in SIP without using SBCs and I think they are doing that because a lot of times they are told “you do not really need it, you can just put it in, you don’t have to spend that money.” But you have to realize that if you are not implementing an SBC you are opening yourself up to some potential issues. But you are also missing some of the capabilities and opportunities that SIP brings you in terms of redundancy, multiplicity, recording, et cetera. So that’s some of the thought process about why do you need these.  

Steve Leaden: So Phil, there’s another subtopic also as to why session border controllers are needed. And that topic would be session management. SBCs have an underlying feature set that allows them to create routing and dial plan capabilities to legacy PBXs. So in essence as you are migrating toward a full UCC environment and if you are a larger customer with multiple sites or have acquired other companies through mergers and acquisitions, M&A’s, the session management feature has this underlying compatibility add-in feature set that is difficult at times to see. Any comments about that?

Phil Edholm: Absolutely, and that’s one I left off because there are other ways – obviously session management is something you can implement, as is recording. You can either implement it in the SBC or you can implement it externally. For example, a Avaya Aura has a session management layer. Often the newer PBXs, when you go to a SIP implementation in this call control part of your core to your UC system, they will have a session management layer there. And the reason they do that is they want to be able to look at all the SIP signaling traffic because that way they can basically maintain SIP continuity between the core and the SIP devices so they don’t change state on their own. But you are absolutely right. I think this again comes back to the kind of combined with that interoperability. If you have got different PBXs, especially if they are TDM, maybe you brought a SIP implementation to them and you want to bring those together, you can use an SBC to bring together the multiple vendors to get interoperability. And then you can use the session management layer to actually manage for example your dial plan and dial plan normalizations.

So I mean, it really does – there are a number of functions that potentially have value there. And as you look at it as an organization, I think you need to look at each one of those points. That is a great additional point, Steve.

Steve Leaden: Thanks Phil. So Bill MacKay, I know there are a couple of topics that you are thinking about, including interfacing with the contact center and the necessity for a session border controller as well as E911 compliance. Can you share some thoughts around that?

Bill MacKay: Yes, thanks Steve. And actually Phil mentioned one of the key components from a contact center perspective and that wraps around security and the need for a session border controller or SBC to be able to deliver security. And one of the key concerns that a contact center would have is the virtualization where they may have a significant number of remote or at-home workers, and an SBC actually delivers the type of security particularly when it comes to being able to take advantage of audio and video conferencing. Or perhaps it’s instant messaging or a multimedia collaboration. And being able to control that type of traffic when you have a number of remote workers is absolutely key. And that’s where a session border controller can be extremely useful.

You think of some of the other touch points where a contact center may be perhaps processing orders, being able to as I mentioned looking after video chat, et cetera. It is a lot of traffic to be able to manage. And to do that in a secure manner is extremely important. From a 911 perspective there can be some other impact as well because there may be a need of being able to perhaps identify emergency calls and how they get handled. There may be a way of being able to exempt them from the mission control policy, for example. There may be a need to be able to route calls to the proper peace app. Again where you are supporting remote workers, obviously it does no good at all to have an emergency responder show up at a corporate head office when your remote worker may be several states away and looking for some assistance. So having the appropriate routing set up in an SBC can absolutely be an integral part of an emergency response. So just a couple of things I think from a contact perspective.

Steve Leaden: That’s great. Let me add a footnote to your comment, Bill. Great points, thank you. We have run across several clients, especially on the data side saying, “why isn’t a firewall just good enough?” But even pre to that the other comment comes in, “why do I even need an SBC or any kind of firewall for SIP trunking?” And so the first rule is that SIP trunking is a data driven technology. And it has all the exposure that the internet and any kind of data driven network has in terms of DoS, DDoS, and other kinds of security risks. So it kind of starts there. But interestingly, an SBC provides SIP-specific overload conditions, RTP traffic in sync with the SIP signaling as Phil had mentioned earlier, tracking session state and providing uninterrupted service and scaling to hundreds even thousands of real-time sessions that need to be managed from the voice or video or other kind of media. And then finally solving the interoperability issues that run across with SIP carriers. So any other thoughts around that, Bill, relative to security like again, a firewall is just not good enough?

Bill MacKay: Well, there is no question a firewall just isn’t good enough. You need to be able to ensure that the traffic that is being moved back and forth across the network is the traffic that should be. There was actually some interesting dialogue yesterday at the Illinois Institute of Advanced Technologies. They were talking about organized denial of service and organized attacks. And they made a very valid point— that the good guys have to be everywhere. The bad guys only have to be in a specific area. And if they are able to exploit a vulnerability in a network, it could very easily bring your network to its knees by having the wrong kind of traffic coming across your network. So being able to protect your endpoints and ensure that the traffic that is intended is actually getting there, is an incredible feature of having a session border controller set up properly.

Steve Leaden: Yes. So to your exact point, the idea of having a firewall in place on the data network side, why wouldn’t you have some type of security device or mechanism as well as the other enhancements that an SBC provides very specific to SIP trunking? So thanks, Bill, I appreciate your thoughts there.

Jon Arnold, session border controllers are multimedia and I know you have that UC hat, and maybe you can share some of your thoughts about what you are seeing in the market and what are maybe some of the trends. Just one example within the last year, Avaya bought Sipera Networks. They were strictly an SBC provider. They got into the game. Cisco has owned the Cisco CUBE for quite a while. Siemens has had their own SBC for over 24 months. So Jon, your thoughts here.

Jon Arnold: Thanks, Steve. And yes, I really want to build on a few things Phil in particular was saying earlier. SBCs have kind of taken a similar evolutionary path on one level to the media gateways, which is really their predecessor. But they have taken a different path now that IP coms has been a lot more ubiquitous, but also more understood for what it can and cannot do. So to Phil’s earlier comments, the media gateway has always played that kind of vital role at the edge to be the go-between for translating back and forth from legacy to IP. And with IP starting to become the dominant mode, and yes carriers were the first to go down this path but now enterprises are following, when you get to the ultimate destination which is an all-IP network, there is no need for media gateway, because you don’t have to do any transcoding. You don’t have to do any translation between network types. If it is all IP, the network doesn’t really need that role anymore.

So SBCs kind of came into the market really with the eye to the eventual end game which is all IP. And in that environment, you need that SBC at the edge to protect, when you are handing off traffic from one IP network to another IP network; the whole issue there is that protecting the network. You control what comes in, what goes out, and initially there was a lot of pushback from the media gateway vendors because this is a threat to their business. And when the Acmes of the world came on the scene and said no, this is a standalone solution, media gateways can’t do this job, they can’t be just tacked on to a router or firewall to play this part, that created a lot of disruption in the marketplace. And in the end I think Acme was proven right by view of the takeout that they had by Oracle. And I think that says a lot about where this space is going.

I have not seen too many segments of this market where one vendor has come out and truly dominated and owned the space the way Acme has. So they are a bit of a one-off that way. But it shows you when you do it, you get the nice exit. But the thing is, when you become that big and dominant one of the reasons why they allowed themselves to be sold and one of the reasons why so many vendors have gotten into this game is because they had a target on their back. They were so big and dominant that everybody wanted to take them down and enter this market. But I have to credit Acme with doing a lot to really develop the awareness and adoption of SBCs, because a lot of people, as Phil said earlier, don’t see a need, that there are workarounds where you could get by without it. But anyone who has got certainly an IMS-centric environment knows that this is a key network piece.

And it is really – it’s a question of whether you believe it or not. But I think enough people do, and you can see it from the evidence of all the new vendors who have jumped in. And this is what I wanted to get to here. The move for enterprise now, and that’s where we are talking about the magic quadrant stuff from Gartner, all these companies are jumping into enterprise and ESBC because IP usage has reached a critical mass now where enterprises need to use this equipment. There was a very early player in the space called Jasomi. I would not expect many people here to know it. I’ve followed this space from day one and they were actually kind of – they were pretty prescient because they were the first kind of come out with an all-software based SBC that was targeted specifically at the enterprise network.

The Acmes of the world in the early days were only carrier focused, so they built large scale deployments that no enterprise could afford or need. So Gesome was early to market and they exited pretty fast, actually. But I think they were a sign of what is to come because now that is what everything is going towards now with this ESBC. In addition to what you see on the magic quadrant (you have) the usual suspects there but even companies like AudioCodes all have some flavor of an SBC or an ESBC. They are doing this, of course, to protect their gateway business because if they don’t, it’s going to go away. And more importantly they are trying to move up the value chain.

I think Acme proved that you can become an integral kind of hub to what goes on in the networks when you start using these multimedia multichannel modes. And that is where UC comes into play, because if any enterprise is going to deploy it effectively, especially when you start getting into video, where you have to cross enterprise networks from one to another, the missing pieces can be addressed by SBC provided it is built for that. Most SBCs have tended to be voice centric but if you are going to do the whole package like what an Acme is doing or what a Sonus is doing, then you have got some interesting possibilities to support the whole UC package. And I think this is becoming really important. I think we mentioned earlier, Bill, to the remote workers, whether it’s contact center or the office, you have got to support all of these real-time modes across all these network environments.

And the enterprises are realizing that UC is going to be a big enabler for this. But at the same time it creates those vulnerabilities with all of those public internet access points and premise-based access points that come in through the phones. But now with video through the video endpoints, through the smartphones, through the tablets, if they are not managed right they can create all kinds of vulnerabilities for threats to come into the network and create all those denial of service attacks, et cetera. So I think there is a lot to be said for the role that SBCs can play. And now that we are seeing this attention and traction on the enterprise side I think it is an important space that we as a group here at UCStrategies probably need to tell a stronger story to show that with enterprises if you really want to do full UC this is a pretty important piece of the puzzle, I think, to do it in a really safe and secure and scalable way. So I will leave it at that and happy to jump in afterwards.

Steve Leaden: Thanks Jon. Just a couple of follow-up thoughts here. You mentioned Acme Packet, you mentioned Sonus, obviously these are bigger players in the carrier space. We’ve seen within the last 12 months now GENBAND, the former Nortel carrier side entity now enter into the SBC market, too. And they are making a big play as well. Any thoughts there?

Jon Arnold: Yes. GENBAND, they went through a series of name changes and mergers. But a lot of these companies have come into the space by acquisition. When a lot of the tier two SBC players fell by the wayside they were picked up for next to nothing. That’s how Sipera ended up with Avaya, et cetera. All these vendors have needed to get partners because they have realized that either you partner with Acme for SBC, or you figure out a way to do it yourself and retain control over your customer. And that’s what’s motivated all of these vendors to acquire SBC pieces or for companies like Metaswitch to develop them on their own.

They all see that if the SBC gets to be too big with too many features it has a kind of leverage of its own within the network. And that’s why the Avaya’s and Cisco’s of the world have their own, because they don’t want to lose that control. I should also mention, too, by the way, early on in this market there was a lot of concern about the firewall guys trying to get into this space and kind of discredit what Acme was doing. And there was an early entry called Kagoor Networks, an Israeli company that had a very strong solution. And they were acquired by Juniper. And if any company ever had a chance to integrate an SBC with existing network element, Juniper was kind of a test case for that. And they failed. And ever since then it kind of validated the model that Acme pioneered of having SBC as a standalone solution.

But I want to just quickly mention something that Phil brought up earlier, WebRTC. What is starting to happen is everything is getting to be virtualized. This is a big trend that’s really going to drive where this stuff is going. And this idea of virtualization of all the SBC functionality, we are going to see more and more of it. And that’s actually a reason why Acme was acquired by Oracle. Because eventually the carriers are going to virtualize and host just about every piece that an enterprise network is going to need. And with Acme in the picture Oracle is much better positioned to produce and deliver a true end-to-end virtualized cloud based environment and eliminate a lot of a need for any form of on-prem infrastructure for the enterprise networks.

Steve Leaden: Wow, huge statements, thank you, Jon. Just one other closing thought with you. You mentioned obviously the media gateway companies starting to get erosion as we move into this full IP endgame. Any thoughts and predictions on what that date is, so to speak or what that timeline is?

Jon Arnold: I think it’s still a long ways off. Because it’s smaller scale, there are a lot more enterprises that have to go down this road. I think some of this might tie in when the incumbent telcos formally can move away and shut down their legacy networks. I think that’s going to have a role to play there. But something else that is going to move it along faster, too, is I think the mobile space. And I know we have touched on that a little bit here already. But mobile SBC support is going to be really important. Eventually, I don’t want to sound too bleak, but if the desk phone goes away altogether, the mobile phone is probably going to be the main mode of telephony in the enterprise space. And when that happens, SBC will have to adapt – and it can. But we are still a ways off from that happening on an across the board scale. I think we’ve got many years left for that to go. And that’s what the gateway vendors are sure hoping for, because that’s their business.  

Steve Leaden: And to your exact point, we’re starting to see a lot of interest from the enterprise users on desktop replacements with mobile devices especially with some of the newer G.722 codec that will be coming out on the mobile side in the near future. So very interesting. Thanks, Jon.

Phil Edholm: Steve, this is Phil, just one additional comment. We’ve talked a bit about why Avaya went into the SBC space. One strong reason was that the SBC role was growing in the overall UC system. Early on we talked about things like reporting, and those kinds of functions, and essentially what happened was that the SBC role was getting larger. In fact, what you saw was SBC vendors actually getting into the session manager functionality. So, as a vendor of the UC system, what I saw was this other vendor developing a larger and larger role.

One of the other things that’s really important about the SBC discussion is that when you start to have a discussion about SBCs, it’s not just driven by the telecom people. You all of a sudden have your security people asking why you want to open a pinhole in the firewall, and what are you going to do through that pinhole? Then at that point you all of a sudden realize it’s a very different discussion than we normally have in telecom. They are going to talk about things that you haven’t heard before. They’re going to talk about how you’re going to manage viruses, how you’re going to manage different kinds of security constraints, what are you going to do?

One of the things that becomes very important in the SBC is to ensure that you have a partner who can go with you to the security organization and have that discussion. So it’s very different kinds of people; very different kinds of discussions.

Steve Leaden: You know what? You are absolutely right. I mentioned this procurement that we are involved in with this client that we actually developed an SBC RFP around, with a lot of technical statements. And sure enough, exactly, the security folks got involved and are deep in the water with us. They want to tear it apart. They want to evaluate it. They want to understand it. Because they know it is going to be a touch point on the network for sure. Exactly, Phil.

Let me bring Joseph Williams into the conversation here. So Joseph, I know that you have worked a lot with the carriers over the years. And you have seen this carrier ecosystem. And obviously session border controllers have been around quite a while on the carrier side. What are you seeing in this space, and what are you seeing from a positioning point of view? And what are your thoughts about even some of these SBC players being certified with the carriers?

Joseph Williams: One point I will make which hasn’t been brought up yet, if you have a UC product and you discover you left something out, it turns out SBCs are a really good place to engineer that feature back in. So SBCs have more value than just acting as a security boundary. They actually can do functional things which are very useful. Now most vendors like Microsoft with Lync would rather have the product provide the functionality. But in the event, again, if they left something out or if it turns out to be difficult to engineer, oftentimes you can get the SBC vendor to solve that problem for you. And so that works in both directions because the telcos can do the same thing. The telco’s infrastructure may not be set up for what the UC product needs to do, and then they will look to the SBC vendor to provide that functionality.

Having said that, my experience is the telcos want to certify everything to their network. They want to certify it not only in terms of quality but in terms of how it is going to integrate with their IMS core and everything. And if you approach a telco with a solution that uses an SBC that is not certified, you are probably looking at as many as six months to a year to go through the certification process. It requires a lot of work to coordinate with the SBC vendors and with the telco to understand what that ecosystem needs to look like. And as it often turns out with enough advance notice, I mean, if you are clever about how you do the engineering, you can actually start to negotiate with the telco, discover that you have got a problem, you can discover what their SBC ecosystem looks like, and then in the old days at any rate when Acme was independent, Acme might just build in the engineering for you if there was enough value in it.

So it’s really an interesting relationship but the telcos typically don’t do the engineering of the SBCs themselves. They rely on the vendors. And so they tend to be very specific about what they will accept on their network. So take caution. Make sure that your UC strategy, particularly that which is going to impact either a telco hosted cloud or an enterprise solution they are offering matches what they have got, and by market. The other big mistake that you can make is you think you are OK because Vodaphone Germany looks one way, well, it does not look that way in Spain. So you have to pay attention to what they have in each specific market.

Steve Leaden: Yes, totally, I totally agree Joseph, thanks. Any other comments from the UCStrategies team?

Phil Edholm: Steve, I think we touched very briefly on virtualization. I think that’s a really important topic that we should spend a little bit more time on.

Steve Leaden: Yes, go right ahead, Phil, please. Hot topic.

Phil Edholm: SBCs essentially started out, as many technologies do, with hardware accelerators, because you don’t have the capacity to do it in the core processor, and there are limitations in how fast a processor can do things. So initially you build a system that has specialized hardware, a specialized environment. That was really the start of both firewalls and SBCs. But then over time, what happened is the processors, because of Moore’s law, became more and more powerful, and you saw them moving from these specialized bespoke hardware environments to just standardized appliances that were COTS servers.

So more and more they are just servers that are running in boxes. Now what’s happening is more and more of these kind of technologies move from being appliance technologies deployed individually on servers, to being virtualized. And really that’s where you see the technologies today. Essentially we’ve seen SBCs become virtualized. For example, just two weeks ago Sonus announced their software version of their complete product virtualized, to be able to deploy, for example, in VMware. So they now have an SBC that’s virtualized. So one of the things, as you are looking at SBCs that’s very important to understand is how that vendor’s virtualization strategy moves forward.

The other that’s important about virtualization is that it’s not just a short discussion. It’s which virtualization environment are you supporting. Are you supporting VMware? Are you supporting something else? And when you look at managing within that environment, how are you managing things like redundancy, survivability, the capability of movement, does it integrate with both an on-premise virtualized solution, often referred to as a private cloud, or a private cloud that’s off-premise or even into a public cloud.

So now it becomes very interesting because it used to be that this was a telecom solution put into a telecom rack when it was a gateway. And we went out and bought essentially an IP gateway, we ran an Ethernet connection, and we put it into a rack, and that was essentially our telecom equipment. But now the SBC is being virtualized, it’s not owned by the telecom people, it’s run by the virtualization environment, by the data center people. And so you actually have a very big change in terms of who’s managing, who’s operating these things. So you have to begin to think about all of these things as you bring these virtualized SBCs in.

Finally, I think there’s one other important consideration as we look at SBCs today, and that’s WebRTC. Of course SBCs started off essentially as voice platforms. And we begin to see them today as not just voice, but also video. But now, WebRTC is emerging. And WebRTC not only has a voice component and a video component, but it also has the data channel. So one of the things that is very important is, how is your SBC going to manage WebRTC because as your users start to use their browsers to go join WebRTC conferences, out on websites and your partners in the web, and other organizations, understanding where they’re going, understanding the resources they’re using, and understanding what the data channel is doing, is very important.

So you’re not only protecting yourself from security breaches, but this becomes very much a policy environment, of how do you manage policies in this new world? So a lot of things to think about as we think about SBCs going forward.

Steve Leaden: For sure. Thanks, Phil. And just one other thought around session border controllers, and that is that many of the manufacturers out there do offer all kinds of reporting capabilities for real-time statistics both on the data side including call volumes, minutes where the calls came from almost as a semi-replacement or adjunct to call accounting. So it’s quite interesting to see the depth and the breadth that session border controllers really offer.

One last thought before we close here, and that is that there is a third party company out there based out of Canada called Phybridge. And we have been looking at them quite a bit for our enterprise clients. They offer a third party solution as we migrate towards a full IP environment, to Jon Arnold’s points a little bit earlier in this conversation. And basically what they do is offer a reuse of category 3 cabling. And basically can offer you a SIP endpoint to replace an analog endpoint at a cost that is well below replacing that Cat3 with Cat5 cabling. And the other talking point is that they can actually reach out as much as 1,500 feet from that endpoint to the replacement to the closet, versus the standard 100 meter/300-foot distance limitation. So it’s a consideration as you’re, again, migrating your entire network.

So let me just wrap it up with these summary talking points. All of us at UCStrategies really believe that security is paramount in any enterprise and IP is inherently less secure and subject to IP-driven attacks. So again, SBCs can help with that.

A service provider SBC is simply not good enough. How can you control really the security policies of the carrier and ensure that your network is totally protected? And then to some of our colleagues’ earlier points about interoperability amongst multiple vendor environments, and the fact that SBCs and SIP trunking really starts with voice today but adding in UC components such as VPN and UC clients and audio and video conferencing are all components in mobility. And the one thing we have not really touched on here is that one of the biggest drivers here that is underlying in this entire conversation outside the technical aspect is the cost savings. And that is that SIP trunking in all the studies that we have done, saves annually a client...we have seen it as little as 20 percent annually up to even as much as 60 percent annually. And that’s for a fully redundant SIP trunking network with very high availability as well as over design in the build.

So it is a very, very important topic obviously, cost savings drives deployments, so that’s the starting point. But let’s not forget that if we don’t include session border controllers there will be risk. I want to thank everybody today for attending this important UCStrategies topic. And we will be back next week with another topic. Thanks for attending, all.


No Comments Yet.

To Leave a Comment, Please Login or Register

UC Alerts
UC Blogs
UC ROI Tool RSS Feeds