Get ready for the future: How to make enterprise UC networks flexible, agile, secure and reliable

Editor's Notes

• #3: This presentation is informed by the interactions between Oracle Communications and its customers around the world. We engage with some very forward-thinking communications architects and engineers responsible for planning and building the networks of Fortune-ranked enterprises. We’ve noted common challenges faced by these organizations and have been fortunate to be able to offer some very effective solutions. I’d like to share these challenges and solutions with you. First, you’ll notice my topic focuses on making UC networks secure, reliable and flexible. These are challenges we hear frequently from customers and are born out by market data. A 2015 Infonetics survey indicates the top two barriers to UC adoption are cost and security at 38% each. This shouldn’t be surprising, because a 2015 Communications Fraud Control Association (CFCA) survey estimates about $3.5 Billion in global losses to corporate IP-PBX and unified communications system service theft. The need for flexibility is born out by the fact our enterprise communications environments are becoming only more diverse as they evolve. Enterprises are embracing public and private cloud deployment models at 21 and 26%, respectively, according to Infonetics. And the environments are increasingly multivendor, with the ascendancy of Microsoft as a UC vendor providing evidence of this trend. In 5 short years since introducing Lync, Microsoft has taken 34% of the UC market in 3Q15 (Infonetics) and has number one license share for on-prem UC deployments. Reliability has always been a cornerstone requirement for communications networks. We don’t see this changing. Flexibility, reliability and security are the three key attributes customers seek as they evolve their communications networks. Now, I’ll spend the rest of the presentation talking about how to attain these attributes as communications networks and services evolve toward the future.
• #4: To project future requirements, we must start by assessing our contemporary networks because most enterprises only expand their communications capabilities, they rarely retire them. The diagram illustrates a typical enterprise network with contact center systems, video conferencing equipment, PBX and UC systems. These disparate systems are interconnected with each other and with a session border controller for access to the PSTN and service provider networks. Obviously, this is a very complex network with many trunk connections to manage. It gets even more complex when we account for the number of vendors involved. It’s not uncommon for enterprises to have a half dozen or more different suppliers. Common challenges customers encounter are managing the dial plans across these systems, normalizing the SIP protocols used by each vendor’s gear and optimizing routing across the network. As I mentioned, most enterprises will add more capabilities to the network they have today. The cloud is a big area of growth. Infonetics projects the UCaaS market will exceed $12B by 2018. Enterprises may also begin using communications functions that are embedded in SaaS applications, for example in contact center and sales force automation applications. Mobile UC has been slow to adopt but may gain traction. WebRTC may find its way into consumer applications that are accessed by employees at work, or business applications. Finally, enterprises are improving customer experience by adding more channels to their contact centers. So, we have more services delivered by more providers through more technologies and deployment models. How do we enable this kind of evolution while maintaining security and reliability?
• #5: The first key objective is to establish a flexible and agile network architecture. We need to accommodate multiple dial plans, normalize the protocols used by different vendors and easily control the routing on these complex networks. But flexibility and agility are the enemies of security and reliability. The more vendors we use to build our network, the more services we subscribe to, the more elements we deploy, typically makes it harder to enforce consistent security policies and ensure reliable operations. Because there are more vulnerabilities and more complexity. In addition, when things break, troubleshooting becomes more difficult. So, we need an architecture that enables us to achieve all these things at once.
• #7: What do we have to work with? Well, the architectures offered by the incumbent UC vendors don’t provide a lot of help. Their architectures operate as silos. They operate very well when expanding within their product line. But, they don’t typically cooperate when it comes to bridging these silos and interoperating with each other.
• #8: Our solution is to build a layered architecture that enables enterprises to easily scale and add capabilities without fear of obsolescence. At the same time, this architecture dramatically simplifies the network, strengthens security and enables rapid troubleshooting. The real time communications edge layer controls network access and security. It provides interoperability between the enterprise and third party cloud services. The session control layer centrally controls the flow of sessions between edge and application as well as between different applications. It enforces enterprise policies as sessions traverse the network, and provides interoperability across diverse multivendor UC systems and applications. The application layer is where the UC systems, contact center applications and CEBP services live. It’s important to note, applications don’t interact directly with each other. Instead they communicate through the session control layer, which normalizes and provides interoperability services for the applications. The management layer includes a rich set of management tools, including monitoring and troubleshooting for the real-time session delivery network and systems for network element management. As we’ve already discussed, the existing applications aren’t going to be retired tomorrow. They live on. So, then the rest of the architecture needs to be vendor neutral to provide the interoperability and flexibility we need to evolve the network for the future. Of course, this is where Oracle solutions enter the picture.
• #9: Oracle offers products for each layer in this architecture that are designed to complement and facilitate interoperability across existing applications. But they do much more than that. This architecture can dramatically simplify a multivendor network, improving reliability. It also strengthens network security. At the edge layer, we offer our market leading SBCs. In the core or session control layer, we offer a session manager that we call the Oracle Enterprise Communications Broker. In the management layer, we offer a vendor-neutral monitoring and troubleshooting tool we call the Enterprise Operations Monitor. These three products are designed to enable interoperability across UC and contact center applications while making the entire network easier to manage and control. They strengthen security and improve network reliability.
• #10: This slide helps to illustrate the role each product plays in making an enterprise communications network more flexible, secure and reliable. You may already be familiar with Oracle E-SBCs. They are well recognized for their ability to manipulate SIP messages to achieve interoperability between networks. They are also the strongest defense against communications threats and include features to recover from network and equipment failures without impacting services. The Oracle Enterprise Communications Broker, or ECB, is our session manager. It normalizes SIP messages and dial plans implemented on disparate UC systems. It enforces policies, including policies to strengthen security, ensure compliance and reduce fraud. And because ECB is designed for the network core, it’s built to route sessions around failures and ensure high availability. The Oracle Enterprise Operations Monitor is our network-wide monitoring and troubleshooting tool. It’s designed to monitor SIP and RTP traffic in real time, detect trouble before it starts to affect service and enable rapid troubleshooting. Because EOM monitors all the messages flowing through the network, it’s perfectly positioned for analyzing the traffic and detecting fraud.
• #11: This diagram illustrates how the architecture would be deployed in the same network that we looked at in the earlier slide. Notice the network topology is dramatically simpler because all traffic flows through the ECB, which interconnects the various network elements. This reduces the number of peer connections in an 7 node network from 21 to just 7. ECB normalizes the SIP protocols and dial plans used by each element so that there are no interoperability issues. It is the central traffic cop in the network, enabling it to optimize network routing and improve overall network reliability. And it enforces policies for security and compliance. The yellow dots on the E-SBC and ECB indicate probe functions that are embedded in each device. These probes monitor SIP and RTP packets and forward data about network operation to the Enterprise Operations Monitor. Probes can be deployed as standalone devices, too, which enables EOM to monitor an network segment. Using EOM, we get an end-to-end view of each session, something a management tool provided by a UC vendor can’t provide. This end-to-end view enables EOM to quickly analyze and isolate problems. Thus improving network reliability. Finally, we have the E-SBC deployed at the network edge. It secures the border between the enterprise and outside networks and ensures reliable access to CSP services.
• #12: This case study illustrates how the Oracle SIP Enablement architecture helped a major pharmaceutical company transition from Cisco Unified Communication Manager to Microsoft Skype for Business and adopt SIP trunking services from its carrier. The firm is based in Europe but has major offices in the US and other countries. They needed to normalize the dial plans used in the different systems – SfB uses E.164 and the Cisco CM used a local dialing convention – and ensure reliable routing over their WAN. They implemented the layered architecture to help simplify their network and make it more flexible. They used the ECB’s call forking capabilities to transition incoming calls from Cisco hardphone to the Skype for Business client at the pace of each user. The CDRs produced by ECB enabled the customer to implement a charge-back system. The customer realized a significant improvement in MTTR by using EOM. Of course, the E-SBC provides a secure connection to the carrier network.
• #13: Here are the key takeaways from this presentation: If there is change in your network’s future, get ready now, by 1) investing in a UC-vendor-neutral architecture that makes your network more flexible and agile and 2) building security, reliability and flexibility into each element in the architecture.
• #14: The solutions I’ve described are part of the Oracle Communications Infrastructure product family, which are being demonstrated in our booth. They are part of a four-pillar product portfolio deisgned to power business transformation. I urge you to stop by the booth and check them out.