SSOA – SIP Service Oriented Architecture TM – SIP Service Oriented Architecture TM ......

SSOA – SIP ServiceOriented ArchitectureTM

Cloud and large enterprise communications and collaboration infrastructure

eBook | July 2012

SSOA – SIP Service Oriented ArchitectureTM

Cloud and large enterprise communications and collaboration infrastructure

eBook | 2012

These materials are proprietary information of eZuce. These materials may not be used for any unauthorized purpose, reproduced or distributed to third parties for any reason without the express written permission of eZuce.

© eZuce 2012

3 eZuce SSOA | eBook | July 2012

4 Introducing SSOA

7 Key SSOA Design Objectives

9 SIP Session Management

11 Enterprise Instant Messaging and Social Networking

14 Using MongoDB for More than Transaction Data

15 Session Routing Using DNS

17 Optimizing Voice and Video Quality

18 An Order of Magnitude Easier to Use

20 Curing the BYOD-Headache

21 Re-Use of Legacy Devices

23 Maximum Security

24 SSOA Provides Measurable Cost Reductions

26 SSOA Use Cases

29 Top 8 Deployment Best Practices

32 CaaS: Cloud Deployment and Virtualization

38 Service Assurance, Monitoring and Provisioning

40 Business Process and Application Integration

41 Summary - An Industry in Transition

Table of Content


This eBook introduces eZuce’s SIP Service Orient-ed Architecture (SSOA). SSOA is a ‘carrier-class’ system that offers the demanding global enter-prise a modern built-for-the-cloud and highly scalable and resilient communications, colla-boration and social networking infrastructure de-signed with native Session Initiation Protocol (SIP) and Extensible Messaging and Presence Protocol (XMPP) at its core. Built for the cloud as a lean and highly desirable software application, SSOA breaks free from legacy middleware and other bloated architectures of the past.

A Service Oriented Architecture enables the design of flexible software systems with system compo-nents that can interoperate as independent ser-vices and be provisioned automatically and via Web services. By extending Service Oriented Ar-chitecture (SOA) concepts to SIP and real-time communications, and by leveraging Web services interfaces for provisioning and communication between components, eZuce’s SSOA brings an in-novative, carrier-class, and ‘built for the cloud’ approach to communications systems design with significantly lower operating cost.

Introducing your new enter-prise virtualized communi-cations system. Sounds easy? Now it is!

Introducing SSOA

SSOA introduces an IT based software solution that communications enables an enterprise’s IT infra-structure, eliminates hardware dependency, and offers a groundbreaking order-of-magnitude re-duction in complexity and operating costs. SSOA addresses the need for scale, resiliency, operating practice, and functionality for the enterprise mar-ket, on premises or in the cloud. Global and geo-redundant clusters are deployed and provisioned with ease, with low complexity and cost, as SSOA is built assuming a modern cloud infrastructure from the ground up.

• It requires up to six times fewer hosts as com-pared to solutions from Cisco, Avaya, or Microsoft

• It is architected as a lean software solution with minimum resource footprint

• It is unique in offering seamless global redun-dancy and failover

• It auto-installs in just hours from bare metal into a full cluster using physical or virtual hardware

• It is centrally managed and provisioned for in-dustry-leading simplicity of administration

• It automatically reconfigures in case of failure• It leverages standard IT tools for service assur-

ance, service management and troubleshooting


SSOA offers attractive hosting options to carriers and system integrators for the delivery of fully outsourced and managed services out of a private cloud to large enterprise customers. SSOA is oper-ated in a lean,cost-effective, reusable production environment that is not vendor-specific, leverag-ing standard IT tools for service assurance (inven-tory, fault, performance, events, and alarms), service quality management, provisioning, and troubleshooting and diagnostics.

SSOA is leading the transition away from legacy systems, typically a PBX, to a new software-based IT application. By leveraging SSOA, eZuce’s openUC breaks from the pack and offers a true IT appli-cation, running on a Linux software stack and a scalable high performance NoSQL database; and it requires no specialized skills or staff to operate. By following typical IT best practices, the SSOA approach to a communications system just makes sense to IT organizations.

Traditional legacy and first generation IP PBX systems have very different scalability and redun-dancy characteristics, and the enormous level of complexity of such legacy systems makes them costly to own and maintain and undesirable for a

Unified Presence

Unified Messaging

Enterprise Instant Messaging (EIM)

Conferencing

Mobility

Rich user profiles

Social relationships

Activity streams

Dialtone

openUC

Figure1: Components of an openUC system. Carrier class virtualized communications for cloud and enterprise deployment.

modern IT environment. When we say ‘standards compliant’ we mean it: SSOA is truly interoper-able with the widest range of third party systems and devices. After all, SSOA is software-only, le-veraging the fast growing ecosystem of third party components. SSOA is fundamentally different in its basic concepts from the architecture of typical legacy communications and PBX systems.

SSOA allows enterprises to easily build a global, fully-redundant system at the highest standard and lowest cost. Performance, resiliency, and scale are combined with ease of installation and administration to render the most flexible of IT so-lutions. SSOA combines critical technologies such as SIP and XMPP to provide a presence-based user experience, efficient, flexible session routing, load-sharing, load-balancing, seamless redundancy, global extension mobility, best in class ease of use, and unprecedented management and operat-ing efficiency.


Built for large enterprise, SSOA offers a software-based communications and collaboration solution, integrated into a company’s existing IT infrastruc-ture. It provides a proven, rock-solid dialtone platform, along with

• Unified Presence• Mobility• Unified Messaging• Rich user profiles• Enterprise Instant Messaging (EIM)• Social relationships• Conferencing• Activity streams

and many other services at an industry leading to-tal cost of ownership (TCO), allowing an enterprise to transition successfully into the post-PBX era.

SSOA is carrier class and redefines the industry’s legendary five nine reliability and how it can be accomplished, putting it in the context of an IT application. While reliability is as important as ever, a Service Oriented Architecture tackles this challenge in a very different way compared to a legacy PBX design. Instead of building a very resil-ient vendor-specific box with hardened hardware

Figure 2: Lean production environment. Standard operating environment based on IT best practices for the post-PBX era.

Ass

uran

ce

openUC virtual cluster

Self-service portal

NOC

Billing &Ticketing

IaaS infrastructure and cloud operating system

Prov

isio

ning

Serv

ice

Man

agem

ent

Trou

ble

shoo

ting

&

Dia

gnos

tic

and a hot-standby for redundancy, SSOA leverages SOA and Infrastructure as a Service (IaaS) con-cepts, creating a load-sharing and distributed ar-chitecture that can tolerate server outages with-out impacting users or causing downtime.

The bottom line: eZuce’s openUC is based on SSOA and is architecturally superior to older, more tra-ditional designs such as Avaya Aura and Cisco Call-Manager that started as a PBX and have grown in complexity over many years of development. SSOA provides an open and lean alternative to Microsoft Lync that’s easier to operate and integrate with an enterprise’s diverse application environment. SSOA injects unprecedented simplicity, flexibility and scale at significantly lower cost as compared to legacy PBX communications systems. In an envi-ronment where the value of an IT solution is mea-sured in operating cost and end-user satisfaction, SSOA comes out on top every time.


The development of SSOA has centered from the start around IT managers’ key design needs:

1 TopologyInstead of a PBX system connected to the net-work, embedding SIP and XMPP session manage-ment and message routing into the network cre-ates a load-sharing and self-healing distributed infrastructure, capable of controlling real-time communications as part of the infrastructure. In other words, the architecture leverages these pro-tocols as they were designed to be used. Instead of using typical Back-to-Back User Agent (B2BUA) designs, it uses a native SIP stateless proxy based design, laid out as resilient SIP and XMPP message routers in the network.

2 ComplexityThere’s a significant reduction in overall system complexity for a much simpler system that is easy and cost-effective to administer, without compro-mising critical functionality. SSOA disaggregates features into individual components running as in-dependent applications. These independent com-ponents can easily be virtualized as they commu-nicate over SIP, XMPP, or Web Services with each other. Additionally, to maintain system simplicity,

Key SSOA Design Objectives

SSOA introduces a single Web-based configuration and management application for centralized pro-visioning and assurance, eliminating all the legacy element managers and manager-of-manager’s hi-erarchy seen in many older systems.

3 Global A distributed system that seamlessly load-shares at the transaction level allows for robust scale and redundancy. Today’s enterprises require supreme extension mobility, and no one wants to deal with the usual branch-prefix-based addressing any-more. SSOA solves this problem with a global ad-dress space with all user credentials, permissions, aliases and registration information available to all participating session management systems at all times. To sustain scalability and overall sim-plicity of the architecture, you can’t have a cen-tralized database that’s in the transaction path, where it can be a bottleneck and single point of failure. Instead, we introduced an innovative distributed data replication mechanism based on MongoDB that is ‘eventually consistent’, always available, and fast.

4 DistributedBecause communications is a real-time applica-tion and in order to allow distributed environ-ments to be configured as one global, centrally managed system, it’s important to strictly sepa-rate media from SIP and XMPP signaling. Why? Separation offers key advantages:• Server failures do not interrupt sessions or calls• There is no limit on the maximum number of

concurrent sessions• Sessions are codec agnostic and can be voice,

video, or other media streams• And local media that stays in a local geography

even when the session manager servers are cen-tralized

• With better voice and video quality due to lower latency and jitter

5 StandardsFor unified presence and Enterprise Instant Mes-saging (EIM), IT managers need a standards-based and widely used protocol that allows for the best possible interoperability. XMPP is the protocol of choice for SSOA, allowing native federation with systems such as Google Talk, Cisco CallManager Presence & IM, Facebook chat, Microsoft (via an XMPP gateway), and many Jabber-based enter-


prise systems. SSOA provides for tight integration between SIP session management and XMPP pres-ence and IM, allowing unified presence to be ex-changed with clients that use the XMPP protocol.

SSOA is a design methodology that combines SIP Session Management with XMPP Extensible Mes-saging and Presence Protocol, taking this concept significantly beyond basic SIP and XMPP session routing to include extension mobility, branch re-siliency, seamless load-sharing among a large number of peer nodes, seamless redundancy and server failover, trunk failover, unified presence, and enterprise instant messaging. In addition, SSOA enables federation between systems and organi-zations, with significantly simplified management using Web services based centralized manage-ment. The model and its plugin infrastructure ac-commodates all the system components, including third party devices such as phones and gateways, delivering a pure plug and play experience. An SSOA system provides the flexibility to be deployed as distributed or centralized as needed, creating one large system that provides cohesive and centrally managed communications services with global user mobility. SIP and XMPP session management be-come a service in the network like IP routing itself.

UC x Virtualized x IT

= UC cubed


SIP Session Management

SSOA transforms traditional SIP call routing of-fered by legacy IP PBX systems into a resilient and self-healing network service. Branch survivability, scale and resiliency take on an entirely new di-mension as Session Management is distributed us-ing a large number of load-sharing nodes in a flat global topology.

Consider IP routing itself, where a network of IP routers provide packet routing along different routes and in a self-healing configuration where, if a router fails, then another one can take its place and re-route traffic dynamically. SSOA es-tablishes a distributed SIP Session Management and routing capability in the network, very simi-lar to IP routing itself, having any independent SIP proxy node offer SIP Session Management ser-vice in a flat hierarchy, forming a self-healing in-frastructure.

The eZuce openUC SIP Session Manager based on the SSOA architecture represents the most pow-erful and elegant implementation in the industry. No other product renders the SIP proxy server session or call stateless, enabling seamless load-sharing even across large geographic distances, without the usual complexity and without causing

excessive network traffic between nodes when synchronizing state information.

A stateless proxy infrastructure for SIP Session Management is made possible by the separa-tion of session routing from the line state pres-ence functionality, which represents session or call state. The choice of XMPP as the main pro-tocol and mechanism for unified presence helps facilitate this architecture. SIP based session routing can now operate as a call stateless pro-cess holding only transaction state, while all call state (such as the line state of a phone or user) is confined to the unified presence infrastructure, called Session State Sever (SSS) in SSOA.

Figure 3: Global load-sharing cluster leads to up to 80% reduction in required hardware. Key differentiator of SSOA separates trans-action processing from session state.

Distributed Data Management

Proxy

Invite

Register

Subscribe

Notify

RegistrarSession State (SSS)

Transactions Session and Line State


Figure 4: SSOA architecture configured as a global load-sharing and fully redundant cluster with global user mobility, global address space with uniform dialplan, seamless failover in case of failure, global trunk failover and least cost routing, and a distributed database based on MongoDB for highest performance at lowest cost. Service assurance and management follows established IT best practices.

Global cluster with DNS based load sharing and seamless failover

Global address space, uniform dialplan, least-cost routing, and user roaming

Globally distributed high-performancedatabase using sharding

IT best practices for operations and management leveraging standard tools

Global cluster:

Over

80%reductionin hardware

Terminal

ServerDatabase


Enterprise Instant Messaging and Social Networking

Communications and collaboration have changed forever in the last few years. Unified presence introduces an entirely new user experience, al-lowing improved and more personal interactions that make an organization more productive even beyond the boundaries of the enterprise itself. Unified presence represents a user’s ability or willingness to communicate; it consists of the ag-gregation of different types of presence such as

available away

free to chat extended away on the phone privacy

in a meeting blocked

do not disturb offline

invisible location

In addition, to meet the needs of organizations, you can add custom states such as ‘in court’ or ‘with a client’ to make presence more personal and relevant to end users’ real-world practices. Knowing a user’s presence before trying to com-

tion and contact Information needs to be shared with all applications an enterprise uses for social networking, communication and collaboration.

2 RelationshipsThe second is a model of the user’s social relation-ships, aka the social graph. The user’s buddy list in a chat client typically represents these rela-tionships and once established these relationships can be extended to followers of the user’s activity stream, friends displayed on a profile, and other uses. The user only has to maintain one social graph that is then shared throughout all enter-prise applications.

3 PresenceThe third is information about the user’s unified presence that can be made available to all appli-cations that display user information, including email, calendar, document management, CRM, and communication and collaboration systems.

A user’s profile, social graph, and unified presence can be made available for application integration in many different ways. Typically, each applica-tion establishes its own user profile which then gets stored in the application’s database backend.

municate significantly improves the experience on both sides and allows each party to choose the appropriate means of communications. In today’s always-on, mobile and social world it allows users to communicate more efficiently and flexibly.

In addition, Enterprise Instant Messaging (EIM) makes it easy to meet the growing need of users for multichannel communication. For instance, a conversation that starts in chat can be escalated to voice or video with a single click. The impor-tance of chat is often underestimated until it is made available, especially within large, distrib-uted organizations.

Presence is also the enabling technology for enter-prise social networking. Three basic capabilities are required as a foundation for Enterprise Social Networks (ESNs).

1 User profileThe first is a user’s profile which, in addition to the usual fields, has to be extensible and include customizable information that can be adapted to the enterprises’ needs. Users only want to main-tain one single profile, so profile information starting with the user’s avatar to his or her loca-


This then requires complicated and costly bi-directional sync protocols to keep such profiles synchronized. SSOA introduces a new methodology for profile integration. A user’s profile information is stored in MongoDB and each application con-nects directly into the distributed MongoDB layer and thereby avoids the need for complicated sync mechanisms. Because MongoDB is a NoSQL data-base, extensions of the data set are easily possible without having to change a schema.

Social graphs are represented by XMPP in the form of a user’s roster or buddy list. XMPP enables in-stant federation, a feature still absent in other enterprise social networking solutions, and it

Figure 5: SSOA introduces a new innovative concept for user profile, social graph, and unified presence sharing and integration. Instead of storing user pro-file and relationship data per application in the ap-plication’s database backend, openUC moved such user data into its shared and extensible NoSQL data store. Each application can directly access such data in real-time for both read and write on a global ba-sis, thereby eliminating the need for complicated application layer bi-directional sync capabilities.

User profiles stored in NoSQL DB for read/write access by all appli-cations eliminates bi-directional sync.

Relationships, or user’s social graph originates from the user’s roster and can be shared.

Unified presence makes applica-tions social; easy integration into any application.

E-MailCalendar

CRM

Distributed Data ManagementMongoDB

Distributed openUC cluster

Contact Center

Document Management


comes with all the sophisticated and mature secu-rity available for XMPP. XMPP is the only available and widely used standard protocol to share user relationship information with other applications and between organizations.

Unified presence can be integrated with other applications easily using different mechanisms. An XMPP client, either native or Web based, has instant real-time access to a user’s presence. In addition, presence is available via Web Services (REST) interfaces and also Web Socket APIs. In this way the user’s unified presence can be integrated with other social business applications and tools such as for document management and sharing, collaboration, and social Intranet services to form a cohesive, real-time user experience.

Clients(Browser, Android, iPhone)

Web Server (http, BOSH, Web Sockets)

SIP Proxy SIP ProxyChannelServer

ChannelServer

XMPPServer

Session Cache

Replication XMPPServer

Distributed Data Management

MongoDB

PubsubService

PubsubService

SIP Server XMPP Server XMPP Server SIP Server

Figure 6: SSOA architecture depicting XMPP based redundant and load-sharing message routing with unified presence. Distributed and redundant back-end database based on MongoDB combined with highly efficient cache and state replication between cluster nodes assures maximum performance and carrier class reliability.

BOSH BOSH


Using MongoDB for More than Transaction Data

SSOA uses MongoDB to persistently store all user profile and transaction data in a distributed way.

While MongoDB’s stellar performance is critical to SSOA, its main benefit for SSOA is the horizon-tal sharding that’s part of its architecture, which allows horizontal scaling across several nodes. This is called for when you have nodes around the globe and the data needs to be made available to all nodes locally and in a consistent manner.

Horizontal sharding allows the SSOA cluster to operate globally, without a geographic distance limit, and without a requirement for a central-ized database cluster.

Each SSOA node runs its own instance of Mongo DB, which optimizes trans-action performance and assures data availability at all times.

Replication of data with other nodes happens au-tomatically in the background and at the database layer, relieving the SSOA application from imple-menting complex techniques to synchronize its data with other nodes in the cluster.

MongoDB already holds the user’s credentials re-quired to authenticate transactions, so it was an obvious move to use this data store for the entire user profile. User profile synchronization between different applications used to be a significant problem, requiring advanced bi-directional data synchronization solutions. Moving all of the user’s profile data into MongoDB allows applications to directly access the data, thereby eliminating this need for bi-directional sync. The result is signifi-cantly lower cost for application integration.

MongoDB also holds all client registration data and makes it available to all session manager nodes. This allows for seamless failover at the transaction layer and without requiring clients to re-register in a failure case. The effect to the user is complete-ly seamless failover at a regional or global level. Many session manager nodes can participate in such a globally redundant cluster, which allows en-terprises to easily build a robust communications backbone that spans the entire enterprise.

Document-oriented storageJSON-style documents with dynamic schemas offer simplicity and power.

Full Index SupportIndex on any attribute, just like you’re used to.

Replication & High AvailabilityMirror across LANs and WANs for scale and peace of mind.

Auto-ShardingScale horizontally without compromising functionality.

QueryingRich, document-based queries.

Fast In-Place UpdatesAtomic modifiers for contention-free performance.

Map / ReduceFlexible aggregation and data processing.

GridFSStore files of any size without complicating your stack.


Session Routing Using DNS

SSOA fully leverages the DNS infrastructure for domain based routing decisions, load-sharing dis-tribution and failover redundancy. This strategy removes a lot of complexity from the SSOA system and enables a tight integration with the rest of the network and IT infrastructure. Traditional sys-tems typically rely on a heartbeat polling mecha-nism for redundant systems to stay in touch. If the heartbeat fails, the surviving system knows that its peer has disappeared and takes appropri-ate action to wake up from hot standby mode and become the active server.

With SSOA, redundancy is not hot standby but fully load-sharing and dynamic. Failover happens at the transaction level, fully controlled by DNS.

No heartbeat mechanism is required and all participating systems are ac-tive all the time.

When an end device initiates a session, a DNS ser-vice record (DNS SRV) lookup is performed. DNS returns one of several possible servers that could handle the request. The DNS response can be made location-specific to control traffic and load distri-bution. The end device then initiates the transac-

tion with the first server it received from DNS. If it cannot reach that server the end device retries au-tomatically and instantly using an alternate server. This retry transaction is instantaneous, happening at the UDP/TCP/TLS transport layer, and therefore it is fully transparent to the user.

The DNS mechanism is not only used to load-share among participating session managers, but the same mechanism is also used to locate services that are part of the SSOA system, such as the unified messaging or conferencing services. This enables centralization, transparent load-sharing, and redundancy for all services, including fast di-saster recovery.

SSOA’s domain-based session routing mechanism based on DNS allows for excellent mobility char-acteristics with optimal flexibility for the ad-ministrator to define a dialplan against a global address space, allowing for numeric and non-nu-meric user IDs and user aliases.

In spite of this global addressing capability, ad-ministration remains easily centralized. In a multi-location installation, there is still only one SIP and XMPP domain for the entire enter-

prise and cluster: typically the main domain of the company. A user can register a phone in any location and all authorization decisions can be made for any service in any location, because the credentials and permissions information is glob-ally available, stored in MongoDB. The universal mobility requirement demands that a user can register anywhere and therefore the user’s reg-istration needs to be replicated everywhere. The SSOA design calls for all critical data required at the transaction level, such as credentials, per-missions, registrations, and aliases, to be stored in MongoDB with horizontal sharding (automated global replication) built directly into the data-base layer. The result is a truly global system with unlimited user mobility and roaming.

Cisco CallManager, in contrast, does not leverage DNS for high-availability failover of devices, but instead statically configures alternate registra-tion servers directly into the phones, a scheme inherited from the days of telephony. In case of a primary registration server outage the phone has to detect the failure and then re-register with an alternate server, causing up to a minute of down-time. The phone also has to constantly send keep-alive packets to the server so that it can detect


Figure 7: Redundant load-sharing SSOA session manager operation showing the DNS infrastruc-ture. DNS priority determines server selection down to the local level and allows fine-grained control and resource allocation.

register

register

invite

Load Balancing

a server outage, which causes additional network traffic and server load. Load balancing between servers then is accomplished at the configuration level, statically storing different lists of possible registrar host names into phones. All of this rep-resents a significant disadvantage to a dynami-cally load sharing SSOA system.

Provisioning

DNS Server

Replication

CDR DB

eZuce openUC eZuce openUC


Optimizing Voice and Video Quality

Voice over IP (VoIP) is not tolerant of packet loss. Even 1% packet loss can significantly degrade a VoIP call using a G.711 codec and other more compress-ing codecs can tolerate even less packet loss. The G.729 codec requires packet loss far less than 1 per-cent to avoid audible errors and ideally there should be no packet loss for VoIP. Jitter has a similar de-grading effect on audio quality. Most VoIP endpoint devices have jitter buffers to compensate for net-work jitter. Jitter buffers, used to compensate for varying delay, further add to the total end-to-end delay, and are usually only effective on delay varia-tions less than 100 ms. Packet loss and jitter must therefore be minimized via proper QoS handling and traffic priorization in the network at both the switching and routing level.

An SSOA system offers the best possible voice and video quality because there is strict separation of SIP and XMPP signaling from the media path. The voice or video codec used for any given session is dynamically negotiated at connection set up be-tween the participating endpoints. The session manager does not impose any restrictions on what codec the end systems can use. Once the call is set up, media traverses the LAN and is routed peer-to-peer and not through the session manager server.

The call server, therefore, is not a single point of failure for media and also is not a bottleneck lim-iting the maximum number of concurrent sessions. Any number of supported concurrent sessions, voice or video, is allowable, limited only by the available bandwidth in the underlying network.

Peer-to-peer media routing also reduces delay and jitter, the two most important parameters when it comes to voice or video quality.

High Definition (HD) voice or video is supported as permitted by the end systems. The administrator can set certain codec selection policies based on available bandwidth or other parameters. High defi-nition audio makes a real difference when it comes to user experience. Users experiencing it for the first time are typically very impressed by its clar-ity and quality, and they unanimously state that HD audio improves audibility.

Client-specific media, such as screen sharing, Web conferencing, and white-boarding is possible as a client-side-only implementation. The SSOA server is media agnostic and can easily interoperate with any number of third party clients that implement such specific capabilities.

A lot has been talked around the industry about the Microsoft codecs RTAudio and RTVideo. There is no evidence that these codecs are better than all the other codecs that were standardized, which leaves us with the conclusion that these Microsoft codecs serve only one purpose: To fortify the walls around Microsoft’s walled garden.

Google has gone an entirely different way and in-stead of creating a set of proprietary codecs pro-tected by licenses and patents, Google released its codecs into open source with a free lifetime patent grant. It is the Google codecs that are now built into all the browsers and it will be the Google codecs that have the potential of changing our industry. SSOA and openUC are embracing Google’s model.


An Order of Magnitude Easier to Use

Ease of use and cost of administration are a di-rect function of the complexity of the system be-ing used, and its inherent need to be configured, managed and maintained. Legacy PBX systems grew complex over many years, with many different components melded together as new functionality was added, either as new components or layered on top of an existing component. The system as a whole was never redesigned from the ground up. Little has changed in the UC industry over the last decade.

The result of this ‘building on top of older systems’ was that administrators were left to cope with multiple element managers to manage individual components. Typically each element or component offered by a legacy vendor has its own architecture and history, was developed by a completely differ-ent team, or resulted from earlier technology ac-quisitions. They might run on different operating systems, require different middleware stacks, have independent database requirements, and drive dif-ferent operating needs. They all come with their individual management interface – an element manager. As complexity grew the need for a manag-er of managers arose, offering yet another admin-istration interface that only covers a small subset

of the manageable functionality of the underlying components. Only highly trained experts can han-dle such systems, which drives cost up and prevents end users from becoming self-sufficient for moves, adds, and changes. Sounds familiar?

SSOA does away with all of this complexity.

You can rebuild and restore a complete global cluster with 100,000 users in an afternoon. If a node fails you can replace the hard-ware or spin up a new virtual machine and restore its entire con figuration in-cluding the operating system, database, firewall, middleware, application and all application data in less than an hour.

Increasing capacity for conferencing or unified messaging is equally easy. Simply spin up a new machine using an identical image used for all nodes or components of an SSOA system and ask the con-figuration and management system to create a new node with the desired role. The rest happens auto-matically.

An SSOA system is centrally managed and there are no element managers. Each component • is based on the same software stack• runs on the same operating system and • uses the same middleware.

In addition: • All operating tasks are fully integrated into the

centralized configuration and management system. • A cohesive Web Services API is offered to third

party applications, enabling seamless business process integration for provisioning and assur-ance.

• Installation, configuration and management of cluster nodes is fully automated, including centralized backup & restore, disaster recov-ery, and log collection into snapshots for easy trouble shooting.

Configuration of a complex and global system has never been easier. SSOA removes all the usual complexity, automates all common administra-tive tasks, and gives back scarce IT resources to handle more strategic tasks.


Figure 8: Comparison of a global Cisco CallManager deployment with an alternative configuration based on SSOA and openUC. Building one global cluster as compared to four regional clusters reduces the required hardware from 30 serves to 5 hosts, an 80% savings. With SSOA and openUC licensing is much sim-pler, the system can run in the cloud, requires fewer administrative staff, and SSOA is an open and interoperable system.


Curing the BYOD-Headache

BYOD, or Bring Your Own Device, is the trend that cannot be stopped. It gives employees more choice and reduces cost for the enterprise. But it also puts IT departments on alert trying to put solutions in place and develop policies to cope with this new set of requirements. SSOA by definition is not a vertically integrated solution, but designed to support a wide variety of end user clients and de-vices. eZuce’s openUC which is based on SSOA can easily develop into the cornerstone infrastructure required to underpin a successful BYOD strategy in your enterprise.

A system based on SSOA is software-only, with no dependencies on hardware or any particular de-vice. As a standards based and open infrastructure, SSOA is specifically engineered to accommodate the growing variety of clients for voice, video, screen sharing, Web conferencing, chat, and enter-prise social media, both on mobile devices such as smartphones and tablets, softphone clients, as well as desk phones from different vendors. Even SIP devices such as desk phones from legacy vendors such as Cisco and Avaya/Nortel work within an open SSOA system, often with only minor limitations.

As native real-time communication for a wide range of applications finds its way into browsers and mobile applications starting in 2012, openUC and SSOA are right there to make the most of this new innovation and diversity.

By leveraging the SSOA methodology, eZuce’s openUC is among the very first server-side SIP / XMPP applications to support Web Socket trans-port, a critical capability when it comes to ac-commodating new browser-based and mobile applications developed to leverage HTML5 and Google’s WebRTC.

Increasingly application and business process inte-gration hinges on accommodating Web-based client integrations, and SSOA has already proven to offer unique capabilities and unprecedented simplicity when it comes to such projects, significantly de-creasing costs to build and maintain these integra-tions.

Figure 9: eZuce integrated multi-platform client with support for Windows, Mac OSX, and Linux for a presence based and immersive user experience.


Re-Use of Legacy Devices

A significant percentage of total system cost is sunk into devices, typically desk phones. The in-vestment in such devices often exceeds 50% of the total procurement cost and is therefore a ma-jor contributing factor to vendor lock-in.

Today’s knowledge workers require an impres-sive array of devices starting with a laptop and a smartphone. Tablets increasingly are also be-coming part of the business line-up. And in spite of the trend to more mobile clients, softphone applications, and BYOD, most deployments still require desk phones. The desk phone, however, is increasingly under pressure as it ranks lowest when it comes to cost / value tradeoffs in most organizations. A desk phone remains tied to your desk and its single application is to make and re-ceive calls. Compare this with tablets, put into a cradle on your desk, and offering a variety of

applications including video with a brilliant and large display at very reasonable cost, especially as compared to an executive desk phone. Sinking more costs into limited-use desk phones is defi-nitely not an option for many organizations.

It’s not surprising then that many organizations would like to extend the life of existing devices. This desire often postpones decisions to renew the underlying infrastructure and transition away from PBX type system to an IT application, even though large operating cost savings and improved user experience are well understood. There’s no need to put off modernizing the infrastructure just because you want to get more life out of legacy phones. What you need is a modern infra-structure that takes on board legacy desk phones and other legacy hardware, extending their life, while allowing your organization to move forward with a modern software-based communications infrastructure.

In spite of strong claims to be standards-compli-ant made by legacy vendors, many CIOs’ experi-ence has been that devices from such legacy vendors are lacking in many critical areas. Using SSOA, we’re able to overcome several of these

Figure 10: Salesforce.com integration illustrates the power and simplicity of Web based application and business process integration. Instead of using the Salesforce.com provided SDK with its set of lim-itations, we built our own integrated client on the basis of HTML5. Now it works not only on Windows but also on Mac and Linux.


Nortel 1100 and 1200 Series IP Phones:The number of Nortel Series 1100 and 1200 IP phones deployed is significantly smaller compared to Cisco IP phones as the transition to IP and SIP progressed much slower on the Avaya / Nortel side. As with Cisco IP phones, the Nortel phone’s SIP compliance is not up to the standard. openUC accommodates these phones with plug & play con-figuration and most features supported. A detailed application note is available on ezuce.com that describes deployment use cases in detail.

Other legacy vendors’ devices can be supported as well. Please ask eZuce for further informa-tion and compatibility as well as a list of sup-ported and certified devices. openUC also sup-ports a wide range of third party SIP devices from vendors who only sell devices and no call server products. These devices are typically much bet-ter when it comes to SIP standard compliance as they get tested much more rigorously by vendors. eZuce has established support relationships with many of these vendors to offer an end-to-end sup-ported solution.

limitations and enable legacy phones to truly be part of a flexible, full-featured contemporary ar-chitecture. Below are two typical examples:

Cisco IP Phones:In order to support Cisco IP phones with SIP firm-ware, SSOA incorporates a Cisco compatibility layer. These phones are supported with plug & play configuration management. Deficiencies in the phone’s SIP signaling are repaired server side so that a high degree of compatibility is accom-plished. Cisco CallManager does not support DNS based load-sharing and redundancy, and there-fore openUC implements specific measures to al-low these phones to operate in high-availability mode connected to an SSOA cluster. Replacing Cisco CallManager with openUC, retaining the Cis-co IP phones is a good deal, especially for larger organizations. Actual scenarios have shown an up to 80% reduction in required hardware combined with significantly lower operating and mainte-nance cost by doing so.

openUC

Figure 11: Re-using Cisco and Nortel phones with openUC can lead to significant cost savings, easing the transition from a legacy system to a software solution.


Maximum Security

With BYOD and social communications trends come new concerns over security for IT profes-sionals, now tasked with managing a multitude of outside devices and external touch points. The SSOA methodology lets you deal with these secu-rity concerns, offering comprehensive security at various layers of the system, as expected from a system designed for large enterprise and cloud deployments:

1 Secure connections At the connection layer, SSOA systems are de-signed with secure connections using encrypted signaling over TLS for both the SIP and XMPP pro-tocols. Media can be encrypted end-to-end using SRTP dependent on the end point’s capabilities. Instant Messaging (IM) and presence exchanges run over encrypted TLS. Web based clients con-nect via HTTPS over secured connections that re-quire authentication.

2 Authentication All external calls are challenged and require proper authentication and authorization. SIP passwords are auto-generated to comply with strict password security policies, and kept sepa-rate from all other passwords in the system.

3 Policy User credentials management can be integrated within the enterprise directory service, either Active Directory (AD) or other LDAP based direc-tory. Established enterprise password policies ap-ply and user and credentials management remains centralized.

4 Certificates Cluster nodes are connected to the centralized management system via secured connections. Certificate administration and deployment is au-tomated for ease of use. Each node auto-deploys an iptables based firewall for secure and con-trolled access to the services it provides.

5 Border security For maximum security SSOA interoperates with Session Border Controllers (SBC) from a variety of vendors, including ACME Packet, Cisco, and Ingate. Deploying an SBC allows for deep packet inspection to prevent attacks from the outside, including Denial of Service (DoS) attacks. For re-mote workers VPN connections are an option, but not necessarily required relying on security pro-vide by the SBC combined with encrypted connec-tions for both signaling and media.

SSOA is ready for directory based enterprise single sign-on mechanisms and technologies, including Kerberos and two factor authentication systems, including support for multiple LDAP domains.

As the world of end-user behaviors grows ever more complex, SSOA grows with the challenges, maintaining robust security against existing and emerging threats, for greater IT peace of mind and efficacy in preventing security breaches.


SSOA Provides Measurable Cost Reductions

For every mission-critical IT application, operat-ing cost is highly important. Especially when an application is moved into an elastic cloud operat-ing environment, operating costs are exposed in a very visible way as the compute environment is now standardized. Below is a list of measures we have taken with SSOA to impact operating cost and drive to an industry leading low level.

1 Lean softwareHomogenous and lean software stack: Everything runs on the same stack. Same operating system, same database, same middleware, and the same admin UI. For SSOA and openUC we chose a free Linux stack, with a free database, and free mid-dleware. Creating a lean and agile application is easy for a solution built for the cloud from the be-ginning.

2 Single imageInstallation simplicity: Everything installs from the same image or virtual ‘CD’. No matter wheth-er you install a session manager node, a unified messaging server, a conferencing server, an in-stant messaging and presence server, or any other server or service in the system, there is only one image and everything, including the operating

system, fits on a single DVD. This allows complete standardization in a cloud or virtual setup with only one image to maintain. Now installation com-pletes in a matter of minutes, every time.

3 One managerOne management system: No managers of manag-ers or other complicated and bloated operations and support systems (OSS). We created one cen-tralized administration, configuration, provision-ing, and service assurance application capable of managing an entire global cluster and for every service provided. It’s that simple.

4 GlobalGlobal redundancy: The number of hosts you need for a global deployment matters; it is measured in operating expense. Instead of having to build a complete cluster with an individual DB backend for every region, we engineered a system that goes global from the beginning and with ease. One single global cluster with full geo-redundancy provides seamless failover. This gives you peace of mind even for the largest installations and it re-quires up to six times fewer hosts as compared to other solutions.


7 One licenseSimplified licensing: You likely know the drill when you change the configuration of a legacy system or users move, and you end up with licensing in-compatibilities. That can be a real nightmare. Therefore, we abandoned all that complexity and moved to a simple and global per user licens-ing scheme, all features included. Now users can roam globally without running into trouble.

8 Hardware agnosticStandard hardware: SSOA systems run on com-pletely standard hardware to the point where eZuce doesn’t sell any hardware at all to support openUC. No servers, no phones, no gateways, no SBCs – just software. Isn’t that the way an IT ap-plication is supposed to work? We still don’t un-derstand why legacy PBX providers have such a different view of the world.

9 VirtualIaaS and virtualization: You can run almost any-thing in a virtual environment, even software from an old PBX. However, that does not make it ef-fective or efficient. We have built a solution that fully leverages the advantages of virtual and IaaS environments, allowing elastic scalability globally.

SSOA is a real Communications as a Service (CaaS) solution for the enterprise.

10 Global scaleScale: Maybe the single most important factor for cost reduction is to give IT organizations the abil-ity to centralize operations into one data center and then deliver communications services to all your locations and branch offices. The reduction and concentration of PSTN access lines alone re-sults in ROI of typically less than one year as com-pared to old systems. Add to that operating effi-ciency and the savings really add up.

11 On demandOn-demand pricing: Communications as a Service (CaaS) is here to stay and more and more large organizations would like to consume communica-tions services on demand. Easier said than done. eZuce has made it happen by adhering to an SSOA design with openUC. By allowing customers to virtualize and outsource everything and consume communications as a service at a cost per user and per month, or just outsource datacenter opera-tions, or everything in between.

5 IT systemIT best practices: We know you need backups and a DR policy that works. We therefore provide one single button to press to create a backup of an en-tire global cluster with all its nodes, services and device configuration into one archive. Restoring such a cluster is equally simple. Instead of up to three months of planning and work to rebuild a cluster, we can do that in a matter of hours from the OS up. Using virtual hardware, restoration time after a fatal failure is extremely fast and fully automated. No fumbling around with thick manuals.

6 Standard assuranceService Assurance, monitoring and reporting: Op-erating cost is driven by what it takes to know what is going on with your system. We chose stan-dard tools widely used for most other IT applica-tions and likely already part of your IT operations center. Now you get all the data where you need it and your existing staff is already trained using these tools.


SSOA Use Cases

In our experience with customers we have seen many applications for our SSOA-based openUC platform which deliver an order of magnitude reduction in complexity and administration. The flexibility of the platform resulting from the SSOA architecture enables a variety of uses, some of which are outlined here.

1 Centralized deployment of all com-munications services into a datacenter:Centralization follows a trend established by most IT organizations as a major cost-saving strategy. Deploying a system based on SSOA principles into a regional, national, or global flat topology typi-cally represents today’s best IT practices. Hub-and-spoke topology establishes an enterprise wide communications backbone, based on SIP and XMPP, from where regional offices are served over the corporate IP network. The data center can be located on customer premises, at a regional host-ing provider, or be provided via an elastic cloud. Centralization improves productivity, allowing for closer cooperation and an agile and social busi-ness experience as colleagues in multiple regional offices share groups and collaborate in a pres-ence-enabled environment.

2 Centralized with branch office sur-vivability:In spite of the trend towards centralization and hosted or managed services, branch office re-quirements have to be met. Communication services have to be resilient to survive WAN net-work outages and power failures, and ensure that emergencies can be handled at all times. Addi-tional branch requirements depend on IP network topology, available bandwidth, and local service needs. Basic media services might have to be lo-cal to the branch to either make them available when WAN data connectivity fails or save on WAN bandwidth. Unified Messaging (UM), conferenc-ing, contact center, and enterprise instant mes-saging and presence are likely centralized with an option for redundancy.

3 Cloud based and offering a managed service via an outsourcing partner:Cloud offerings are clearly the new trend with a pay-as-you-go subscription pricing model. For large enterprise it’s private cloud services of-fered by an outsourcing partner such as a large system integrator (SI) or carrier, fully managed and priced per user per month. SSOA uniquely al-lows cost effective private cloud services to be

built and operated. Operating cost clearly is the driving factor in the provider’s business case in order to both offer a competitive service and also retain sufficient operating margin. SSOA of-fers many advantages as a cloud infrastructure, including low resource footprint, automated provisioning, flexible service assurance and man-agement, and the ability to build global clusters. Instead of a vendor specific stack for operations such as Cisco HCS, openUC is embedded into standard IT tools and operating practices.

4 Hybrid cloud complementing on-premises installation with elastic cloud resources:Additional compute resources can be required for different reasons and are typically triggered by specific operating activities. For instance dur-ing major system upgrades, system expansions, cluster reconfigurations, or geographic consoli-dations, the administrator greatly benefits from the temporary availability of elastic compute resources. Disaster Recovery (DR) procedures are often another reason for hybrid clouds. SSOA seamlessly bridges between physical and virtual resources and allows an on-demand allocation. Cluster reconfigurations for operations such a


Figure 12: Centralized SSOA deployment with a redundant load-sharing datacenter. Centralized trunks with branch offices to offer local PSTN connectivity to enable emergency calling at all times

re-balancing load, extending capacity for certain services and re-distributions of service roles to individual hosts can all be done dynamically and using an automated provisioning process.

5 Migration strategy away from a leg-acy PBX system:Different migration strategies have been tried and successfully implemented. In all cases interoper-ability with the legacy system during the transi-tion is critically important. Such interoperability is accomplished either using TDM circuits or SIP, dependent on the capabilities of the old system. Two migration strategies stick out in our experi-ence: a) start with branch offices, one at a time and migrate to a new dialtone platform, or b) mi-grate centralized services first such as voicemail or conferencing and then continue with branch of-fices and different locations. We have shown that it’s possible to provide a transparent user expe-

Main data center

Branch 1

openUCcluster

openUCcluster

SIP Trunk

PSTN PSTNMPLS

Branch 2

Branch only requires phones and optional gateways. Local gateways can be preferred route or fall-back route and used for emergency calls.

Branch 3

Geo-redundant deployment


rience during the transition for services such as voicemail access and message waiting indicators, which are the critical issues for end users.

6 Deployment of specific point appli-cations:openUC can serve as an enterprise conferencing, enterprise instant messaging, or unified messag-ing solution in conjunction with an existing sys-tem. In this configuration, openUC does not re-place the main dialtone platform, but augments its functionality and user experience. Specific ex-amples include an openUC based unified messag-ing system replacing Cisco Unity and connected to Cisco CallManager, a replacement of Nortel Call-Pilot and connected to a Nortel CS1000 system, addition of enterprise instant messaging (EIM) to an existing PBX, adding dialtone to a Microsoft OCS or Lync deployment that is used for IM only, or providing remote worker connectivity into an existing system for a mobile workforce. Such de-ployments tend to be an excellent starting point in larger enterprise, proving the openUC solution from an operations perspective and to get ready for an enterprise wide deployment.

7 Standalone serving a campus or building:Standalone on-premises deployments are still very common. It is fascinating to see that four (4) seven foot racks of PBX equipment can be re-placed with two 1U servers. Especially since the Nortel bankruptcy we have gained a lot of pro-ficiency replacing legacy CS1000 systems with openUC. Such a transition can create consider-able savings that materialize in saved rack space, power, and cooling, administrative cost, and licensing and support / maintenance cost with the vendor. ROI in typically less than one year is the norm including the replacement of old TDM phones.


Top 8 Deployment Best Practices

In building the eZuce openUC solution using the SSOA architecture, and across several years of managing SSOA deployments, we have developed an extensive and proven set of best practices. This top eight list can help you guide your SSOA deployment, avoid common pitfalls, and maxi-mize the properties of resource efficiency, global scale, and failover redundancy in a lean and agile environment.

1An SSOA-based system consists of one or several hosts or nodes and each can take on one or sev-eral specific roles as they are defined in the sys-tem. These hosts or nodes can be geographically distributed, but they remain centrally managed. Geographic distribution can mean a deployment into regional or global data centers each serving regional offices, or it can mean a topology with a single headquarter location and many survivable branch locations. The centralized configuration and management service provides all configura-tion information to all hosts or nodes and to all devices such as phones with a single Web based administrator interface. Service assurance is based on well-established IT tools such as open-NMS and many others.

2SSOA allows deploying global clusters and there’s no geographic distance limit between distributed systems. There is also no hierarchy between par-ticipating systems: all systems are equal in their ability to authenticate users, register devices and clients, apply permissions, and route sessions. Therefore, each system can take over from any other system in a load-sharing configuration at the transaction level.

3Distributed session routing can be deployed in-dependent of the way connectivity to the PSTN is established. Gateways to the PSTN can be de-ployed anywhere with a connection to the cor-porate network. Failover between gateways and trunks can happen globally or regionally. Least cost routing is implemented in the routing logic. To establish local branch survivability and guar-antee the ability to place emergency calls at all times, it is typically necessary to co-locate local call control with a PSTN gateway with a direct connection to the PSTN, thereby guaranteeing branch survivability in the event of wide area net-work failures.


5Session routing redundancy is seamless between load-sharing systems. Since all client registra-tion information is available to all participating systems, and because media does not traverse the session manager server, when a server fails, another one will take over immediately without causing any noticeable interruption of service to the user and without dropping the call.

6Media redundancy is provided for media services. If more than one instance of a particular media service is created in a cluster, then this service can load-share even across a large geographic distance. For example, several unified messag-ing services can co-exist, sharing a common stor-age backend for voicemail messages. This stor-age backend can be allocated in a high-available storage system or in the cloud using Amazon S3, GridFS, or other cloud storage services.

4Media is routed peer-to-peer. This is the single most important concept of the SSOA architecture at the session routing level. The session manager systems are media agnostic and can set up any session for which the participating end points can negotiate a media format and codec acceptable to all devices. Media streams do not flow through a session manager server, but are routed over the data network on the shortest path between the end point devices. In a distributed architecture, this makes a significant difference, as parties lo-cated in the same office communicate directly on the LAN while being able to use a remote session manager for call control.

7Enterprise Instant Messaging (EIM) and presence services can be clustered, across more than one XMPP server. Session state and server cache in-formation is replicated between participating instances. A common database backend based on MongoDB replicates required datasets.

8The IP network between all locations must be a routed network without Network Address Trans-lation (NAT) between systems. Sufficient band-width and voice QoS handling must be available and be properly configured to assure good and consistent call quality. Voice VLANs are also rec-ommended to increase system reliability and ease of management.


Figure 13 shows the progression from a legacy infrastructure to an IT application with the basic topology of an SSOA based system. A core of load-balancing SIP proxy servers act as Session Managers and call servers. Additional services connect to the Session Manager infrastructure using the SIP/XMPP protocols.

SessionManager

Mobility

ContactCenter

Provisioning

EnterpriseInstant

Messaging

Conferencing

Unified Messaging

ServiceAssurance

Virtual Communications, software and cloud IT solutionTelephony & Unified Communications

Two decades of development

Digital PBX’s

BasicCommunication,telephony wiring,

TDM

Voice over IP(VoIP)

NetworkConsolidation,

IP

Phones IP Telephony


CaaS: Cloud Deployment and Virtualization

Communications as a Service (CaaS) is on the rise. Gartner predicts that the global managed services market will grow at a 25% rate year over year, five times faster than the overall IT market. Industry analysts agree: in the near future, a significant percentage of enterprises will buy Information and Communications Technology (ICT) from the cloud as a service. As enterprise applications move into the cloud, the runtime environment is standardized and operating cost differences be-tween applications become clearly measurable and visible.

Cloud environments impose a new set of require-ments on the architecture and design of software applications if they are to profit from this new way of building data center infrastructure. Legacy applications can be force-fit into a standardized cloud environment; however, operating efficien-cies are not so easily reached. Lean and agile soft-ware solutions built for a standardized cloud envi-ronment are needed to fully realize the efficiency promise of the cloud.

Here are some of the key attributes of a cloud op-timized software solution you should look for:

1 Independent of the cloud controller and hypervisor: There are many different vendors who offer cloud controllers or cloud operating systems. Virtualiza-tion technology can also be sourced from different providers. The application must run on any virtu-alization technology and in any cloud environment

2 Hardware-agnosticAn application or its vendor should not dictate the hardware used to build the cloud environment. The whole point of a standardized (cloud) com-pute environment is that many different applica-tions can share a common infrastructure

3 Lean software architectureTo achieve minimum resource footprint and high runtime performance, the architecture needs to break with legacy middleware and other old archi-tectures and adopt a lean software stack throughout

4 Standardized runtime environmentAll application components, including components of a cluster, must run on an identical image with the same operating system, the same middleware, and the same database requirements


Lean architecture with small resource footprint

Standardized runtime with single image

Free OS, middleware and database

Hardware agnostic

Independent of cloud controller and hypervisor

Standard tools for troubleshooting and

diagnostics

Standard tools for Service Assurance

Automated installation and provisioning with

Web Services API

Centralized management

Linux based

2

3

4 5

6

7

8

9

10

1

Figure 14: 10 fundamental reasons why SSOA represents a lean, cost effective, and cloud optimized architecture.


on the role of the node and sent to the host over the network

8 Centralized managementAll components of the application must be cen-trally managed, including automation for backup and restore for all connected devices and DR pro-cedures for an entire cluster

9 Linux based Linux offers an open and more versatile operating system environment for mission critical applica-tions. Linux first allows creating an open operating stack for assurance, troubleshooting and diagnos-tics with many available tools widely used in en-terprise IT and free

10 Free OS, middleware, and database Low cost means low cost for the entire system. Le-veraging an open source software stack represents the most reliable and cost effective choice avail-able in the industry

5 Troubleshooting and diagnosticsThe application needs to come with native and built-in powerful tools for troubleshooting and di-agnostics to minimize training required on a spe-cific application and to reduce labor required to maintain it

6 Standard service assuranceNo application must rely on vendor specific service assurance tools. For many years enterprises have built and operated IT infrastructure based on a highly sophisticated set of tools and the applica-tion must provide information into and leverage those open tools

7 Automated provisioningManaged services require end-user administrator self-provisioning and self-administration. A Web Services API with a high level of abstraction must be available for the integration of provisioning into existing workflows and applications for user and service management. A standardized environ-ment offers the unique opportunity to completely automate application deployment and provision-ing. An entire cluster must unfold automatically, installing nodes from an identical image, and all configuration should be centrally generated based

SSOA easily fulfills all the requirements stated above. SSOA can be deployed cost-effectively into a private cloud centralized in a data center and serving a large number of different regional loca-tions and buildings. A managed service can be of-fered to an end customer from such an environ-ment with ease and at very low operating cost.

Unlike the Cisco Hosted Collaboration Solution (HCS), which is limited to running on Cisco’s Uni-fied Computing System (UCS) hardware, an SSOA based solution is agnostic of the underlying hard-ware and can leverage any private or public cloud infrastructure.

An SSOA based system is also independent of the cloud operating system or cloud controller used to provide and operate elastic compute and stor-age resources. Many different cloud operating sys-tem solutions already exist and most of them are available in open source. openStack has gained significant traction with backing from Rackspace, Novell SuSE, Canonical (Ubuntu), HP, and recently Red Hat. Eucalyptus was one of the first solutions available and Amazon recently endorsed their re-verse-engineering of the Amazon AWS APIs. Citrix’s cloudStack is now available under the Apache 2.0


license and got contributed to the Apache Founda-tion. Zimory, a spin-out from Deutsche Telekom, is adopted by T-Systems for their cloud offering.

When it comes to virtualization technology, SSOA again offers choice and accommodates different environments. All the different cloud operating sys-tems can accommodate hypervisors from VMware, Oracle VM, XenServer (Citrix), or KVM (Red Hat).

At the application level, the first step towards successful deployment in an elastic cloud and on standardized virtual hardware is standardization of the environment from the operating system on up. SSOA relies on one single image to start from for every component; it’s built using an identi-cal operating system, database, middleware, and sy stem configuration for everything. This signifi-cantly simplifies otherwise complicated tasks.

The second step involves full automation of the setup, configuration, and management process for every node and every component in a system or cluster. SSOA uses CFEngine, a leading server con-figuration and management software, built deep into the architecture to completely automate all aspects of system installation and configuration

“Full production deployments exceeding 15,000 users per cluster in Amazon AWS have proven the viability of this approach and al-lowed for a clear demonstration of real and significant cost savings.”

down to the OS. For all the components that make up an SSOA system, CFEngine scripts control the automatic installation and configuration of these components on every node based on a pre-defined role assigned to that node. Installing or rebuild-ing a cluster becomes a very simple and fully au-tomated task and even procedures required for disaster recover (DR) become fast and intuitive. This also facilitates automatic reconfiguration of a cluster to re-balance load, extend capacity, configure service redundancy, re-allocate services to different hosts or locations, or establish a DR policy.

The third step required for cost-effective cloud deployments is a small resource footprint in terms of (primarily) the required number of CPU units and memory. The cost of cloud deployments de-pends on the number of hosts and the required resources for each host or component and SSOA minimizes this footprint to an industry-leading level. Lean and efficient middleware, distributed data management using MongoDB, as well as cach-ing and efficient communication between differ-ent parts of the application all contribute to an agile environment.


In actual customer deployments studied,

an eZuce openUC system based on SSOA shows significantly reduced re-source footprint per cluster node and in addition it requires up to 6x fewer hosts to build the cluster.

This particular result was obtained against an equivalent Cisco CallManager setup for four glob-ally distributed locations. The openUC deployment successfully reduced the 30 servers required for CM to only 5 hosts with eZuce openUC. Comparisons with equivalent systems from Avaya or Microsoft have produced similar results. The main factors that contribute to this reduction are:

• SSOA allows building one global cluster instead of several regional clusters,

• SSOA uses a built-in high-performance and dis-tributed database and therefore does not re-quire a separate large backend database cluster, and

• SSOA allows flexible distribution of services among hosts in a cluster, based solely on specific performance requirements, thereby reducing the number of hosts required.

Due to the homogenous software stack used to install every component, system administrators have maximum flexibility in partitioning the clus-ter for different services, further reducing the number of hosts required. The global SSOA cluster then allows users to roam globally without compli-cation or additional licensing cost.

SSOA fully supports Infrastructure as a Service (IaaS) setups such as Amazon Web Services (AWS) and similar offerings. Full production deployments exceeding 15’000 users per cluster in Amazon AWS have proven the viability of this approach, pro-viding a clear demonstration of real cost savings. Different configurations are possible including full and partial virtualization and hybrid private and public clouds. In addition, cloud storage services, such as Amazon S3, GridFS, or Red Hat’s Gluster file system can be used for persistent storage, making data available global to the cluster and enabling load-sharing redundancy at a global level for services such as unified messaging.

Since SSOA systems are built as homogenous sys-tems using an identical operating system, as well as the same lean middleware and database stacks for all components, virtualization is as easy as installing the system on a single physical host. Standardized images exist for different operating environments and it is possible to accommodate enterprise specific Linux distributions derived from Red Hat Enterprise, such as Amazon Linux.

As an increasing percentage of SSOA systems are virtualized direct integration of the SSOA cluster management system with cloud infrastructure management solutions will allow for the auto-mated turning up and down of virtual instances on demand. As a new and innovative concept, SSOA offers the possibility to realize elastic automated provisioning of compute resources to be used by a given cluster based on actual current load, there-by further reducing hosting cost.


Figure 15: SSOA cloud operating model for Infrastructure as a Service (IaaS), virtualization, service assurance, billing, and provisioning. SSOA is embedded into a standard IT operating environment, leveraging typical Network Operations Center (NOC) tools, many of them familiar to the IT staff and available in open source.

ProvisioningeZuce Web Services API

openUC Billing: Rating and billing

Service Assurance: Monitoring, reporting, inventory, events, and alarms

IaaS Operating System: Hardware abstraction and virtualization

VirtualizationHypervisor

Example open NMS tools

Customer self-service portal eZuce admin dashboard

End User Portal and App integration openUC Web Services API, eZuce user dashboard


Service Assurance, Monitoring and Provisioning

Few enterprises or even carriers and major sys-tem integrators (SIs) have the IT resources or expertise to build a service assurance, service monitoring, and provisioning infrastructure from scratch, especially not if this needs to be done separately for every vendor specific application.

Both Cisco and Microsoft gravitated to the solu-tion most obvious to large vendors: they built their own stack and packaged the solution into a fully-featured offering. Cisco Hosted Collabora-tion Solution (HCS) is all inclusive starting with Cisco UCS hardware to Cisco CallManager, Cisco Jabber, Cisco WebEx, Cisco provisioning, Cisco assurance (CUOM) and Cisco Service Manager (CUSM), creating a completely vendor and appli-cation specific operating environment..

The strategic question carriers and SIs have to answer is how to differentiate their hosting of-ferings if all players in the market offer the same solution with the same operating model. If the vendor itself then offers its own hosted solution, such as Microsoft Office 365, the question quickly turns into a competitive situation with the vendor and a conflict of interest.

We think there’s a better model. Instead of spending all your resources on operationaliz-ing two major vendors’ solutions and creating a me-too offering, carriers and SIs should focus on creating an open operating environment that can accommodate as many enterprise applications as possible. The concept of an Enterprise App Store is the natural progression for the IT industry as CIOs are looking to outsource not only operations of individual applications, but the integration of these applications into complete solutions. As social applications penetrate deeper into the enterprise, integration complexity and costs rise and with that the urge for CIOs to outsource this effort to a carrier or SI, capable to productize the integration. For the carrier and SI the producti-zation of the integration together with the selec-tion of supported applications represents a major opportunity for service differentiation.

SSOA is an open system and therefore naturally gravitates to an open operating environment. For service assurance, standard monitoring and re-porting applications are used to manage the SSOA system in the same way other IT applications are managed. As an example openNMS offers an FCAP based management solution that heavily lever-

ages SNMP. It includes discovery, inventory, fault and performance management, service manage-ment, as well as reporting, event filtering, and alarming. openNMS is open source and designed to manage the entire infrastructure from the net-work up to the compute infrastructure and the application layer. It is widely used by IT depart-ments and typically competes with commercial offerings such as HP OpenView and IBM Tivoli. vFabric Hyperic is another example of a more ap-plication oriented service assurance system from VMware that comes with an open source edition.

Service Management (SM) is based on RFCs 3611 and 6035 and the RTCP-XR protocol and met-rics for call quality. Enterprise network manag-ers need a more comprehensive approach to VoIP management. One of the foundations of such an approach is the IETF’s RFC 3611, the Real-Time Control Protocol Reporting Extensions (RTCP-XR). Published in November 2003, RTCP-XR is the first standardized protocol to provide a comprehensive set of VoIP-related performance metrics. RTCP-XR is designed to be implemented as a software agent in IP phones, gateways, and media servers. Many devices support RFC 3611 and RTCP-XR, in-cluding Polycom phones with the Polycom Produc-


tivity Suite, Audiocodes gateways, Counterpath softphones, Snom, and also phones from Cisco and Nortel. Different standard solutions exist to col-lect RTCP-XR information and generate reports, including Telchemy’s SQmediator.

Once the decision is taken in favor of an open operating environment, application integration becomes a lot easier. All applications can now be produced in the same operating environment and application integration is reduced to bringing specific functionality from one application into another. An excellent and high value example of this is communications enablement of applications using Web Services API.

Figure 16: Service quality measurement and re-porting are critical elements in a high-quality VoIP setup. Customers expect providers to answer questions regarding call quality with reliable data, collected in real-time and based on industry stan-dards that is interoperable with a wide range of devices.

openUCcluster

(call server)

NMS

Terminal

Networkswitch

Gateway

PSTN

Probe /Analyzer

Branch Office Teleworker

Internet

Clients

SNMP


Business Process and Application Integration

Business Process Integration (BPI) is about inte-grating applications for a better user experience, and it is also about integrating and simplifying the IT production process for service assurance, provi-sioning, and troubleshooting and diagnostics.

SSOA natively supports Web Services interfaces, which makes business process and application in-tegration easy. If you start out with a Computer Telephony Interface (CTI) on a legacy (IP) PBX, you will need complex and expensive add-on solu-tions to translate the functionality of the CTI in-terface into Web Services.

SSOA eliminates this step by natively supporting a comprehensive Web Services API.

Users want a combined experience where pres-ence based communications is not a standalone separate application but integrated with tools and applications used to conduct their business. They don’t want yet another place to log in or a new set of processes to learn. Any user accessible functionality created using SSOA does not live as a separate “SSOA” application that users must learn. Instead, the new functionalities, includ-ing presence and communications enablement,

are integrated with any existing applications on the end users’ desktops or mobile devices. For the administrator, too, SSOA was designed with-out a built-in user interface and focused on a Web Services API instead. This includes Web based user management capabilities, open social based gadget and portlet integration, application inte-gration using toolbars and add-ins, etc. Rather than offer yet another separate UI, SSOA com-munications enables other primary applications and business processes and allows for simplicity of use and administration on both the admin and end-user sides.

Enabling Social Business Social Business is a new term and trend that emerged from the evolution of early Intranet and document management solutions towards group collaboration, real-time and collaborative docu-ment editing, and the building of social project groups linked using social media. The most social aspect of Social Business is a user’s unified pres-ence and the ability to share presence with other users, combined with the power to communicate in real time using different media while collabo-rating. This is where unified communications in-teracts with Social Business. The SSOA architec-

ture for a unified communications solution was especially built to communications-enable Social Business applications. Combining SSOA-based uni-fied communications with Social Business creates new applications from existing ones, applications that now make it more efficient to collaborate and improved the user experience – thus a new market segment is born.

Presence ProfileSocialRelations

Communi-cations

E-Mail Calendar

ContactCenter

CRM DocumentManagem.


Summary - An Industry in Transition

This is the time when real-time communications and enterprise software meet. Forever there were two separate industries, one that provided telephony and the other that provided IT infra-structure. Two completely different channels formed called telephony VARs and interconnects on one side, and system integrators (SIs) on the other side. Their respective business models and skill sets could not be more different. In today’s enterprises these two worlds merged and the CIOs now own it all. With their IT background CIOs quickly realized the cost savings potential prom-ised by delivering real-time communications in-cluding dialtone out of the IT stack, but how to do it?

At the same time IT software ISVs started to re-alize that communications enablement of their respective software products represents signifi-cant value and potentially the most relevant key differentiator for their solutions going forward. Led by Microsoft the IT software industry started to rush towards absorption of the UC market into the enterprise software stack. Without a doubt this would not only significantly challenge the old UC industry, but likely eliminate it all together.

Unified Communications transitions from being an industry to becoming a feature in a larger context called En-terprise software.

We think SSOA and eZuce are ideally positioned for this transition. As the vertically integrated te-lephony business model breaks open, bring-your-own-device (BYOD) takes hold, Google succeeds with the integration of real-time media into the browser, IT assets move into the cloud, and CIOs get their way to producing real-time commu-nications out of their IT stack, SSOA is the right product at the right time. This transition is also a technical shift, but first and foremost it is a shift in business model and ‘how things get done’.

There are too many advantages moving real-time communications into the IT stack, not the least of which is cost. Communications enablement of IT applications will remain a key differentiator for any IT software solution as particularly presence brings applications to life and makes them social. The ability to communicate is so central to our human needs that once it is possible to initiate voice, video, Web and other forms of communica-

tion and conferencing from within the user’s cur-rent context and not using a completely separate application or device, there will be no way back.

SSOA allows replacing old PBXs and it provides communications enablement to the IT industry based on a lean highly desirable software archi-tecture. As an IT application SSOA lives in the same context as IT and clouds do. We speak the same language. Integration is easy. Cloud de-ployment and IT operating models come natural. Customers benefit from lower cost, carriers and system integrators finally have an easy solution to offer differentiated cloud based services, and end users get a modern experience that is open and fully supports BYOD.

SSOA is the better choice; it is the only open alterative to otherwise vendor specific silos.


Figure 17: Real-time communications gets absorbed into the IT stack and industry as a feature, thereby challenging and likely eliminating today’s UC industry as we know it.

Absorption through packaging

> Powerful practice known to work

> IT software industry much larger than UC

> Significant customer benefits

> Communications enablement

> Destroys the old industry

> Makes the VAR channel obsolete

“Sell knowledge” business modelFocus on services

IT Software Industry SI Channel

CRM / ERP

Intranet and social portals

Support

E-Mail / Calendar

Document Management

Communications

Directory Service

Cloud Infrastructure

eZuce, Inc.300 Brickstone Square, Suite 201Andover MA, 01810o. [email protected]

http://www.ezuce.com

SSOA – SIP Service Oriented Architecture TM – SIP Service Oriented Architecture TM ......

Documents

Transcript of SSOA – SIP Service Oriented Architecture TM – SIP Service Oriented Architecture TM ......