SIP Service Oriented Architecture

Transcription

1 SSOA SSOA SIP Service Oriented Architecture White Paper

2 Intoducing your new enterprise communications system. Sounds easy? Now it is! SSOA SIP Service Oriented Architecture White Paper This architecture white paper introduces the ezuce SIP Service Oriented Architecture (SSOA), a native Session Initiation Protocol (SIP) architecture for a modern, and highly scalable and resilient communications infrastructure. SSOA is based on a distributed network of SIP proxy servers, a model very similar to how the Internet Engineering Task Force (IETF) originally envisioned the SIP standard to be implemented, and enhanced with critical elements to provide efficient and flexible call routing, load-sharing and seamless redundancy, extension mobility, easeof-use, and unprecedented management and operating efficiency. openuc SSOA is fundamentally different in its basic concepts as compared to the architecture of typical legacy PBX systems and first generation IP phone systems. Legacy and first generation PBX systems were not designed as native SIP systems, but instead SIP capabilities were added later to an already existing design. This resulted in systems whereby SIP is primarily used as a message transport protocol alongside other proprietary IP protocols such as Nortel Unistim and Cisco Skinny, and in addition to TDM transport still available in hybrid systems. Communication features for the most part remained implemented in a legacy feature server, a new term for an old PBX, and not using the SIP standard. Therefore, such legacy systems have very different scalability and redundancy characteristics, and the enormous level of complexity of such legacy hybrid systems makes them costly to own and maintain and undesirable for a modern IT environment. 2 SIP Service Oriented Architecture White Paper

3 Key SSOA Design Objectives In developing SSOA the following key design objectives were at the center of consideration: SSOA also redefines telephony s five nine reliability and how it can be accomplished and puts it in the context of an IT application. While reliability is as important as ever, a Service Oriented Architecture tackles this problem in a very different way as compared to a legacy (IP) PBX design. Instead of building a very resilient vendor specific box with hardened hardware and a hot-standby for redundancy, SSOA leverages SOA concepts creating a load-sharing and distributed architecture that can tolerate server outages without causing downtime. SSOA is designed as a Service Oriented Architecture extended to SIP and real-time communications, leveraging Web Services interfaces for all communication between components. Because of this innovative new approach to communications systems design, SSOA injects unprecedented simplicity, flexibility and scale at significantly lower cost as compared to legacy PBX communications systems. 1. Instead of an (IP) PBX system connected to the network, we wanted to embed SIP session management and routing into the network, thereby creating a load-sharing and selfhealing distributed infrastructure capable of controlling realtime communications as part of the infrastructure. That ruled out using Back-to-Back User Agent (B2BUA) designs and instead asked for a native SIP proxy based design, laid out as a resilient SIP message router in the network. 2. We needed a significant reduction in overall system complexity in order to achieve our goal of creating a much simpler system that is easy and cost-effective to administer without compromising critical functionality. Therefore, SSOA disaggregates features into individual components or services that run as independent applications. These independent components or services communicate over SIP with the rest of the system. Additionally, to maintain system simplicity SSOA introduces a single Web based configuration and management application, eliminating all the legacy element managers and manager of manager s hierarchy seen in many legacy systems. SIP Service Oriented Architecture White Paper 3

4 3. For scale and redundancy we needed a distributed system that could seamlessly load-share at the transaction level. The requirement for ultimate extension mobility without requiring the usual branch prefix based addressing required a global address space with all user credentials, permissions, aliases and registration information available to all participating call control systems at all times. To sustain scalability and overall simplicity of the architecture, we could not rely on a centralized database to be in the transaction path as a bottle neck and single point of failure, but instead introduced an innovative distributed data replication 1 mechanism based on a NoSQL data store that is eventually consistent, always available, and fast. 4. Because communications is a real-time application and in order to allow distributed environments to be configured as one global, centrally managed system we needed to strictly separate media from SIP signaling. This offers key advantages: a) server failures do not interrupt calls, b) no limitation on the maximum number of concurrent calls, c) codec agnostic call servers with end points solely responsible to negotiate the codec used, d) WAN bandwidth savings with local media that stays in a local geography even if the call servers are centralized, and e) better voice and video quality due to lower latency and jitter. 5. For unified presence and Instant Messaging (IM) the requirement was for a standard based and widely used protocol that allows for the widest possible interoperability and federation between systems and organizations. For SSOA we chose XMPP as the protocol of choice allowing native federation with systems such as Google Talk, Cisco CallManager presence & IM, and many Jabber based enterprise systems in use today. SSOA provides for a tight integration between SIP session management and XMPP presence and IM, allowing unified presence to be exchanged with clients that use the XMPP protocol, but also with clients that use the SIP/SIMPLE protocol for presence and IM. SSOA is a SIP Session Manager based design that takes this concept significantly beyond just SIP call routing to include extension mobility, branch resiliency, seamless load-sharing among a large number of peer nodes, seamless redundancy and server failover, trunk failover, unified presence and instant messaging. In addition, SSOA enables federation between systems and organizations, and a significantly simplified management using Web Services based centralized management with a modeling and plugin infrastructure that accommodates all the system components, including third party devices such as phones and gateways delivering a pure plug n play experience. An SSOA system provides the flexibility to be deployed as distributed or centralized as required for a particular customer, creating one large system that provides cohesive and centrally managed communications services. SIP call control becomes a service in the network like IP routing itself. 1 Refer to 4 SIP Service Oriented Architecture White Paper

5 SIP Session Management SSOA transforms traditional SIP call routing offered by legacy IP PBX systems into a resilient and self-healing network service. Branch survivability, scale and resiliency take on an entirely new dimension as Session Management is distributed using a possibly large number of load-sharing nodes in a flat 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 establishes a distributed SIP Session Management and Routing capability in the network very similar to IP routing itself. Many different SIP proxy nodes offer SIP Session Management service in a flat hierarchy, forming a self-healing infrastructure. The ezuce openuc SIP Session Manager based on the SSOA architecture represents the most powerful and elegant implementation in the industry. No other product renders the SIP proxy servers call stateless, enabling seamless load-sharing even across large geographic distances and without the usual complexity and without causing excessive network traffic between nodes. A call stateless proxy infrastructure for SIP Session Management was made possible by the separation of call routing from the line state presence functionality. The choice of XMPP as the main protocol and mechanism for unified presence first facilitates such an architecture. SIP based call routing can now operate as a call stateless process 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. Fig. 1: Unified presence architecture, synchronizing line state presence (BLF) with unified XMPP based presence, allowing for SIP/SIMPLE or SIP/XMPP clients to be used simultaneously. SIP RLS: SIP Resource List Server (RFC 4662 & RFC 5367) Phone notifies RLS of line state used for BLF SIP Subscribe / notify RLS tells XMPP server the line state of the phone. XMPP aggregates this information into unified presence SIP RLS XMPP client plugin XMPP Server XMPP XMPP server communicates unified presence back to the RLS. This is used to sync presence info for clients that subscribe to unified presence using SIP/SIMPLE XMPP client SIP Service Oriented Architecture White Paper 5

6 Presence Based Communications Communications will never be the same again. Collaboration and communication based on unified presence introduces an entirely new user experience, allowing improved and more personal interactions that make an organization more productive even beyond the boundaries of the enterprise. Unified presence represents a user s ability or willingness to communicate and consists of the aggregation of different sources of presence such as on the phone, in a meeting, do not disturb, away, available, and other custom states such as in court, or with a client. Knowing a user s presence before communication is initiated significantly improves the experience on both sides and allows each party to choose the appropriate means of communications. Oftentimes communications is first initiated using chat and if convenient for both parties quickly escalated to voice or video. The importance of Instant Messaging (chat) is often underestimated until it is made available to an organization, especially if this organization is larger and distributed across different locations. The ability to form presence enabled contact (buddy) lists replaces the traditional phone book or speed dial list on a phone and enriches the user experiencing, thereby enabling a social business environment. A user s unified presence can be made available in many different ways including integration of presence information into a wide range of clients or other applications. Examples include: Call center agents can use their unified presence state to indicate their status on the contact center system. Now an agent can integrate the status as it exists in the contact center environment, like free, wrap-up, on break, etc., with other sources of presence information such as on the phone or in a meeting, or do not disturb. A 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 one single user profile. For workers using a particular enterprise application, such as a CRM or ERP system, unified presence can be integrated into such applications making them presence aware. The SSOA architecture, as a Web Services based infrastructure, offers simple Web Services interfaces for other business application to get access to unified presence and other unified communications related functions, thereby enabling easy and cost effective business process integration. 6 SIP Service Oriented Architecture White Paper

7 SSOA Deployment Scenarios Fig. 2: Centralized SSOA deployment with a redundant datacenter. Branch offices offer local PSTN connectivity to enable emergency calling at all times Centralized deployment of all communications services in a data center is following trends established by most Information Technology organizations. The data center approach can reside physically on customer premises, at regional hosting providers or provided via the Internet Cloud. In spite of the trend to centralization and hosted or managed services, branch office requirements have to be met. Telephony services have to be resilient to prevent WAN network outages, power failures and ensure that emergency calls can be handled at all times. Additional branch requirements depend on IP network topology, available bandwidth and local service needs. Basic media services, such as for call park & retrieve, group paging, autoattendant, and music on hold might have to be local to either make them available when WAN data connectivity fails or to save on WAN bandwidth. Unified Messaging (UM), conferencing, contact center and instant messaging and presence services are more likely centralized with an option for redundancy. One of the key advantages of the SSOA architecture is its ability to centralize unified communications services into a data center that can serve hundreds if not thousands of smaller offices. There are a lot of companies that operate businesses with a need for many local offices; including real-estate brokerages, insurance offices, banks and other financial services, restaurant franchises, logistics and shipping offices, and likely many others. In the past each small office had a small office legacy (IP) PBX, separately maintained and with its own connection to the public switched telephone network (PSTN). Centralization saves cost on the operating side and the consolidation of many local trunks can significantly lower phone bills. Centralization also improves productivity, allowing for closer cooperation and a social business experience sharing presence, forming groups, and allowing for collaboration. SIP Service Oriented Architecture White Paper 7

8 To cost-effectively deploy an SSOA system centralized in a customer s data center or for a large number of individual customers, possibly as a managed service and in a hosted (cloud) environment, virtualization technology becomes the key factor to contain cost. We believe that the market for cloud based or hosted unified communication solutions will separate and play out in two entirely different ways. At the low end of the market multi-tenant solutions will be offered by cloud hosters and provide the next generation cloud based services to a large number of small businesses. For mid-size to large enterprise customers a virtualized but dedicated solution will provide the necessary data privacy, security and flexibility required by larger companies. Such a larger enterprise deployment can run virtualized in a private cloud setup by the enterprise, or hosted using Infrastructure as a Service (IaaS) offerings such as Amazon Web Services (AWS). A virtualized but dedicated approach has many advantages for mid-size to large enterprises, including the ability to seamlessly integrate communications services into existing business applications and processes. SSOA was designed to fulfill the requirements of mid-size to large enterprises and excel at cost-effective deployments in a virtualized but customer dedicated setup. Since SSOA is built as a homogenous system using identical operating system, middle-ware and database stacks for all its components, virtualization is as easy as installing the system on a single physical host. Standard monitoring and reporting applications can be used to manage the SSOA system in the same way other IT applications are managed. Cloud Deployment and Virtualization Real-time applications, such as the components of the SSOA architecture that process voice and video streams, have historically been difficult to virtualize in environments without compromising voice or video quality under certain system load conditions. This is not an issue with the SSOA architecture, but solely relates to the real-time capabilities of the virtualization technology used. To alleviate this problem it is possible to run media processing applications on physical hardware while virtualizing the remaining components of the SSOA system. As the cloud model expands and accelerates penetration of the enterprise IT landscape we expect a higher and higher percentage of SSOA systems to be virtualized. Direct integration of the SSOA cluster management system with cloud infrastructure management solutions will allow for the automated turning up and down of virtual instances on demand. 8 SIP Service Oriented Architecture White Paper

9 Ease of use is a direct function of the complexity of the system being used, compared with its inherent need to be configured, managed and maintained. Legacy and first generation IP PBX systems grew complex over many years of development, which resulted in many different components melded together to provide all the required functionality. New functionality was added as either new components or layered on top of an existing component, while the system as a whole was never redesigned from the ground up. 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 such element or component offered by a legacy vendor has its own architecture and history, is developed by a completely different team, or often resulted from earlier technology acquisitions. Elements or components often run on different operating systems, require different middleware stacks, have independent database requirements, and drive different operating needs. They all come with their individual management interface an element manager. As complexity grew the need for a manager of managers arose, offering yet another administration interface that only covered a small subset of the manageable functionality of the underlying components. Only highly trained experts can handle such systems, which drives cost and prevents end users from becoming self-sufficient for moves, adds, and changes. SSOA 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. All operating tasks are fully integrated into the centralized configuration and management system and a cohesive Web Services API is offered to third party applications, enabling seamless business process integration. Ease of Use Explained SIP Service Oriented Architecture White Paper 9

10 Unified Presence and Unified Inbox Unified presence and a unified inbox for the user to consolidate receipt of all offline communications are two terms often discussed in conjunction with the user experience of a unified communications system. The SSOA architecture provides the technical underpinnings to realize a modern user experience that integrates capabilities of a typical phone with applications used for , calendar, collaboration and mobility. Unified presence in an SSOA system is defined as the aggregated presence for a user consisting of the user s Instant Messaging (IM) presence, the user s telephone line state presence (also called Busy Lamp Field (BLF) presence), as well as the status intelligence derived from the user s calendar. This allows for a comprehensive representation of the user s current activity as well as the user s availability and willingness to communicate, including on the phone, in a meeting as well as custom status messages. Unified presence is available and can be visualized in different ways. It is represented in the user s Instant Messaging (IM) client, can be made available in the user s client (such as Outlook 2010), is available on the user s smartphone mobile device, and can be accessed using Web Services interfaces for application and business process integration. A unified inbox is a similar concept used for offline messaging and communication such as , voic and fax images. The user experience projected by an SSOA system is focused on enabling the user to use the productivity or business tool that makes the most sense. In many cases integration of unified messaging onto the user s client makes the most sense, creating a unified inbox. The most basic implementation of the concept of a unified inbox is to forward incoming voic messages by with the message attached as a file. More advanced implementations provide for message waiting indication (MWI) notification back to the user s phone when messages are read combined with a set of additional tools and capabilities in the client to manage voic messages. SSOA provides a set of Web Services interfaces to integrate unified messaging into different applications used for , calendar and collaboration, in particular also Outlook Improved Voice and Video Quality SSOA offers the best possible voice and video quality given its strict separation of SIP signaling from the media path. The voice or video codec used for any given call is dynamically negotiated at connection setup between the participating endpoints and the call server does not impose any restrictions on what codec the end systems can use. Once the call is setup, media traverses the LAN and is routed peer-to-peer and not through the call server. The call server, therefore, is not a single point of failure for media and also is not a bottle neck that limits the maximum number of concurrent calls. Any number of supported concurrent calls, voice or video, is 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. 10 SIP Service Oriented Architecture White Paper

11 Basic Concepts and System Topology An SSOA system consists of a set of systems whereby each can take on one or several specific roles (refer to System Roles). These systems can be geographically distributed, but remain centrally managed. Geographic distribution can mean a deployment into regional data centers serving regional offices from a central location, or it can mean a topology with a headquarter location and survivable branch locations. There is a single master system that runs the configuration and management service, which itself is a system architected as a Service Oriented Architecture (SOA) Web application. A distributed system may be one or more servers; if more than one server, it may have local call routing redundancy by having multiple call control (i.e. proxy/registrar) services. Such a distributed system may be located in a branch, or a regional or backup data center. There is no geographic distance limit between distributed systems and there can be many distributed systems. There is no hierarchy between participating systems, and all systems are equal in their ability to authenticate users, register phones, apply permissions, and route calls. Therefore, each system can take over from another system in a load-sharing configuration at the transaction level (refer to Transaction versus Call State). A location with a legacy distributed system often includes its own PSTN interface; either a local PSTN gateway or a local SIP trunking interface to communicate with an Internet Telephony Service Provider (ITSP). With SSOA distributed call routing can be deployed independently of the way connectivity to the PSTN is established. Gateways to the PSTN can be deployed anywhere with a connection to the corporate network. To establish local branch survivability and guarantee the ability to place emergency calls at all times it is typically necessary to co-locate local call control with a PSTN gateway or direct connection to an ITSP in order to render the branch survivable in the event of wide area network failures. Media is routed peer-to-peer. This is the single most important concept of the SSOA architecture at the call routing level. The call server systems are media agnostic and can setup any call for which the participating end points can negotiate a media format and codec acceptable to all devices. Media streams do not flow through a call 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 located in the same office communicate directly on the LAN while they can use a remote call server for call control. Redundancy is seamless between load-sharing systems. Since all registration information is available to all participating systems and because media does not traverse the call 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 (refer to Transaction versus Call State). The IP network between all locations must be a routed network without any Network Address Translation (NAT) between systems. Sufficient bandwidth and voice QoS handling must be available to assure good and consistent call quality. Voice VLans are also recommended to increase system reliability and ease of management. SIP Service Oriented Architecture White Paper 11

12 All system configuration tasks are performed using the management and configuration system. The configuration and management service is not a single point of failure as this service is not required to be available for call routing to take place in the distributed systems once they are configured. The configuration and management service uses a database to store its configuration information. This database is only used by the configuration and management service and does not need to be available to other components. Once configured, a distributed system must be able to serve as a survivable branch solution and optionally perform all of the following services without contacting remote system components: Local phone registration and user authentication Intra-location station to station calls (calls between users located in that office) PSTN calling, including local emergency services using a local gateway In addition to call routing services, there is a requirement to allow for basic media services to be available locally. Such basic media services include: Auto-Attendant services Music on Hold Intra-location Group Paging Call Park & Retrieve (all park orbits are local to a location) Figure 3 shows the basic system topology. 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 protocol. Figure 3 shows a larger SSOA cluster where different services of the system run on individual server hardware. The core is formed by the redundant and load-sharing SIP Session Manager. Additional services are added as independent systems, centrally managed. 12 SIP Service Oriented Architecture White Paper

13 System Roles A system in the SSOA architecture can be dynamically configured to take on one or more specific roles. These roles are defined to simplify system partitioning and configuration and provide a powerful mechanism to individually distribute and scale specific system functions. This offers redundancy and scale where it is needed on a per component level. Roles defined in the system include: Call Server role: Session Manager component for call routing Unified Messaging role: Voic server Instant Messaging role: Instant messaging and presence service (XMPP) SIP trunking role: Integrated Session Border Controller (SBC) for SIP trunking Conferencing role: Conferencing server Contact Center role: ACD server Configuration and Management role: Management system The configuration and management server includes specific rules about how many systems of each role are allowed to be configured. Installing a new distributed system becomes very simple using roles. The system installation starts with the same image or CD used for all installations. During installation a setup wizard asks whether this is the first or an additional system being setup. If this is an additional distributed system, the administrator creates that system on the master server using the configuration and management web GUI. The new distributed system then only needs to know the host name of the master system and the password the master created to authenticate the new system. All configuration information necessary to configure the new system with the role(s) assigned to it is done automatically through the master configuration and management server. Component Architecture As a unique difference to regular unified communications systems architectures, SSOA is granular, modular and scalable down to the component level. All services provided by the system are implemented in native SIP, creating a component per service. Figure 4 illustrates how the components of an SSOA system are grouped into four major blocks: 1. Management, business process and application integration includes the administrative management system, and interfaces (APIs) used for business process and application integration, as well as user accessible features such as user Web portal and gadgets. 2. Telephony, mobility and video components represent the core of the real-time communications infrastructure, all based on the Session Initiation Protocol (SIP). 3. Instant Messaging and presence components provide enterprise IM services including chat, group chat, escalation to voice or video, user profiles, avatars, and federation with other IM systems, implemented based on the XMPP protocol. 4. IT integration and administrative automation covers all aspects of integration of an SSOA based system into an existing IT infrastructure for administration, monitoring and reporting. SIP Service Oriented Architecture White Paper 13

14 Device Mgml Admin Portal Unified Messaging Voice Features Security Cloud Mgmt User Portal Call Center Conferencing Redun dancy App Integration SOAP/ REST IVR FMC Monitoring Alarms Desktop Integration Gadgets Single sign-on Mobility Reports Contacts Video ezuce Communicator Upgrade Mgmt IM / Presence Group Chat Backup Restore Federation Profile / Avatar Trouble Shooting Installing a new distributed system becomes very simple using roles. The system installation starts with the same image or CD used for all installations. During installation a setup wizard asks whether this is the first or an additional system being setup. If this is an additional distributed system, the administrator creates that system on the master server using the configuration and management web GUI. The new distributed system then only needs to know the host name of the master system and the password the master created to authenticate the new system. All configuration information necessary to configure the new system with the role(s) assigned to it is done automatically through the master configuration and management server. Components among themselves communicate using the SIP or XMPP protocol. Each component is part of a role (see System Roles), and roles are established on servers using the configuration and management system. This allows creating a system for a smaller deployment with all servers and services running on one physical system, or a clustered system for a very large deployment with individual servers and services run on dedicated hardware, optionally redundant. Management, buisness process and application intehration Telephony, mobility and video service instant Messaging (IM) and Presence services IT integration and administrative automation Figure 4: Main components and functional blocks of a typical fully configured SSOA system. SSOA does not require a large feature server typically used in legacy (IP) PBX systems to provide telephony features. Instead each feature is implemented in native SIP creating independent components per feature. This has distinct advantages: Services can scale independently based on specific requirements. If more call park orbits are needed or the customer needs more conferencing ports, only these respective services need to be scaled. The SSOA architecture also makes redundancy a lot easier. Redundancy is accomplished on a per component level, instead of having to replicate state information of an entire feature server. 14 SIP Service Oriented Architecture White Paper

15 Session Routing using SSOA Initially when developing SSOA there were only two possible alternatives considered to be used as the basic principle for SIP session routing in a distributed environment: 1) Use a DNS domain name per location, combined with a domain alias to allow all locations to accept the same 'top level' domain name in addition to their location based domain name. 2) Introduce location semantics into the user part of the SIP addresses, essentially a traditional telephony solution with location prefix such as 3xxx for Boston, 4xxx for Berlin, etc. The domain-per-location approach was eliminated fairly early in the discussion because DNS configuration complexity and domain alias implementation for multiple services are of significant complexity as the system scales. This left us with adding structure to the user part of the SIP addresses. While this approach has a lot of advantages and is used in other systems, namely also in legacy (IP) PBX systems, we found there were a few significant limitations: 1) It would relegate ' style' SIP URI addresses (sip:[email protected]) to a second class status. The only really usable addresses would be the numeric telephone number with a location prefix assigned to a user (sip: @example.com). This felt like a step backward, and will create problems for deployments that prefer non-numeric user identities. 2) The approach has very poor mobility properties: A numeric address is permanently tied to a location. Moving a user from one location to another means changing the user s phone number. Registering a mobile user agent at a different location means that the call is really routed back to the user s 'home' location. It seems that this has bad properties when the network is partitioned, and probably causes other non-optimal routing decisions. 3) By putting structure into the user part we abandon (or at least put some limits on) the flexibility we would otherwise have to use different number lengths (not all extensions need to be the same size) and other nice qualities that result from the fact that the user part is just a token to be matched in the dialplan. In the final definition of the SSOA architecture a new innovative approach was developed that alleviates all the negative properties of the previous approaches discussed above and renders a fully scalable system with excellent mobility characteristics and optimal flexibility for the administrator to define a dialplan against a global address space allowing for numeric and non-numeric user Ids. With SSOA and in a multi-location installation there is only one SIP domain for the enterprise, the main domain of the company, and it is managed by the configuration and management server. Within that domain, there are many servers, each of which is associated with a location (the 'central' site is just another location that happens to co-host the configuration and management service). SIP Service Oriented Architecture White Paper 15

16 A location is defined as a set of systems (possibly just one) that share some services among themselves that are distinct from those at other locations. These services can include basic media services such as Auto Attendant, Call Park & Retrieve, Group Paging, and a typically PSTN interfaces (gateways and/or SIP Trunks). Some other services, such as Call Center (ACD) and Conferencing might be configured on the servers within a location, but are fundamentally global. The fact that they are running on the servers in a particular location is not important. A user can register a phone at any call server in any location and all authorization decisions can be made for any service in any location, because the credentials and permissions databases are uniformly replicated to all servers in all locations. One concern with global identities in our earlier discussion was the complexity of global replication of registrations. The universal mobility argument demands that a user can register anywhere, and therefore the user s registrations need to be replicated everywhere. To accomplish this a new replication strategy had to be developed for the (inmemory) databases that stores critical data required at the transaction level, such as credentials, permissions, registrations, and aliases. The replication mechanism has to support incremental changes to keep bandwidth requirements between locations minimal, it has to provide guaranteed delivery of data, and it has to scale to a large number of users, phones, and locations. Resilient and Reliable Data Replication SSOA relies on resilient, efficient and reliable data replication between distributed systems. Different data sets are used for specific functions of the system. Dynamic runtime data is contained in a clustered NoSQL database, and configuration data is stored in files that are replicated to the respective servers. The NoSQL database currently includes the following 9 datasets listed below. With the exception of #5: registration.xml all data sets are read-only and sent from the management and configuration server to the respective system. The registration dataset is updated at each distributed system as registrations occur, are renewed, or expire. Entries in the registration dataset are read-only as they are never updated, but expire and get renewed instead. Registration events have to be replicated between all participating systems in a multi-master configuration using the clustering capabilities of the NoSQL database as all systems have to rely on a current registration dataset for proper call routing. 1. alias.xml 4. permission.xml 7. userforward.xml 2. caller-alias.xml 5. registration.xml 8. userlocation.xml 3. credential.xml 6. subscription.xml 9. userstatic.xml Database access performance is important for the datasets in the NoSQL database as the local copy of this dataset is accessed for every transaction in the system. However, there is no real-time replication requirement and therefore the replication mechanism does not cause any blocking of transaction processing. Datasets in the NoSQL database, except for registration data, are only updated if the admin or the users make changes to the configuration that affects parameters stored in the dataset. The size of the dataset is small as compared to typical database applications, reaching only a few megabytes even for systems with upwards of 10,000 users. Additional dialplan information and other configuration data required for call routing decisions is created by the configuration and management system and replicated using file replication. These XML based dialplan information files are only updated when the admin changes the dialplan. Dial plans are universal and global, which is a unique property of SSOA. 16 SIP Service Oriented Architecture White Paper

17 The Importance of the DNS Service Register Configuration Server ezuce openuc Replication Load Balancing DNS Server ezuce openuc CDR DB Figure 5: Redundant load-sharing SSOA call server operation showing the DNS infrastructure. SSOA fully leverages the DNS infrastructure for domain based routing decisions, load distribution and load-sharing failover redundancy. This strategy removes a lot of complexity from the SSOA system. Traditional systems typically rely on a heartbeat polling mechanism for redundant systems to stay in touch. If the heartbeat fails the surviving system knows that its peer has disappeared and takes appropriate action to wake up from hot standby mode and become the active server. With SSOA redundancy is not hot standby but fully loadsharing and dynamic and it happens at the transaction level, fully controlled by DNS. No heartbeat mechanism is required and all participating systems are active all the time. When an end device initiates a call, a DNS service record (DNS SRV) lookup is performed. DNS returns one of several possible servers that could handle the request, where the DNS response can be made location specific to control traffic and load distribution. The end device then initiates the transaction with the first server it received from DNS, and if it cannot reach that server, the end device retries automatically and instantly using an alternate server. This retry transaction is instantaneous and happens at the UDP/TCP transport layer, and therefore it is fully transparent to the user. The DNS mechanism is not only used to load-share among participating call servers, the same mechanism is used to locate services that are part of the SSOA system, such as the unified messaging service, instant messaging service, conferencing service, music on hold, and other relevant services. This allows centralization of such services and enables transparent load-sharing and redundancy for such services. SIP Service Oriented Architecture White Paper 17

18 Transaction versus Call State Load-sharing redundancy and failover occur at the transaction level. Every call made can consist of many different transactions. Let s look at an example: a) The call is setup, b) the call is put on hold then retrieved, c) the call is parked then retrieved, d) the call is transferred, e) the call is transferred again, and finally e) the call is hung up. Each individual step is a transaction and all the different transactions make up one call. SSOA is unique in that is creates redundancy at the transaction level. This is not only significantly simpler and more efficient as compared to a legacy (IP) PBX system where every call server holds a lot of call state; it creates a much better user experience. When a server fails, the call does not go down. In addition, since all servers are active the system s call processing capacity scales essentially linearly as servers are added. Transaction based load-sharing allows leveraging the Domain Name System (DNS) infrastructure to distribute load among servers, to direct requests to preferred servers based on network topology and geography, and to allow for automatic failover. DNS based load distribution is significantly simpler than doing this based on logic included in the call server. Dialplan Management With the SSOA architecture the dialplan properties are global, offering full flexibility for extension number assignment and mobility, as well as for simple and uniform SIP URI dialing. The usual prefix based numbering plans required to address branch locations can still be implemented, but SSOA offers significantly better flexibility using a uniform dialplan. Every call server that is part of the SSOA system possesses the same registration information from the phones and locally stores all the user credentials and call permissions. A global dialplan is configured centrally that applies to all locations as administering a separate dialplan for every location would add significant administrative overhead. However, sometimes local differences have to be accommodated in the dialplan, especially if locations are spread internationally. Therefore, the global dialplan template can be modified for each location using location specific parameters. This particular area of internationalization is still subject to refinement. 1 As part of the dialplan management it is possible to use dynamic ENUM lookups to assist with or completely take over number translation. ENUM is the most prominent facility for telephone number mapping based on the E.164 Number Mapping (ENUM) standard. It uses special DNS record types to translate a telephone number into a Uniform Resource Identifier (SIP URI) or IP address that can be used in SIP communications. While public ENUM was the initial primary driver, ENUM is most successfully used for enterprise internal call routing using DNS. 1 Refer to RFC SIP Service Oriented Architecture White Paper

19 Integration with Enterprise Directory Services As an IT application, SSOA is designed to integrate with enterprise directory services including Microsoft Active Directory and other directory services that offer an LDAP interface. Ideally a unified communications system, similar to an / calendar system, would be self-managed and only fed by data contained in an enterprise directory for all user configuration and moves, adds, and changes. That would be possible if the schema used for the enterprise directory service included all the parameters necessary to configure the unified communications experience for a user. This is not the case in most environments. Therefore, SSOA allows two distinct functions as it integrates with the enterprise directory service: 1) Direct authentication using LDAP bind into the directory service provides single sign-on. Password changes are ubiquitous and take effect immediately. Revocations or other actions can be taken in the directory service. 2) Upload of complete contact information for a user, including business and home address, mobile, office, and work phone numbers, address, assistant s name, manager s name, office designation and others. In addition an avatar can be uploaded if available. Many directory services are read-only, including many Active Directory deployments. The reason is not that LDAP / AD cannot allow users to make changes to their profile and store these changes back in the directory service. The reason is that configuration of Access Control Lists (ACLs) and other mechanisms required for proper authentication and authorization are often complex and not well understood by system administrators. SSOA allows storing profile changes back into the directory service, but also allows other applications to synchronize their user database and profile data directly with the SSOA system. Public Safety and E911 Considerations SSOA based systems allow enterprises the flexibility to architect systems that centralize the deployment, share trunking, and create a single virtual communications environment like never before. But these capabilities challenge customers to fully understand and plan through the implications these can pose on emergency services notification. Two critical aspects have emerged: 1) When someone dials from the enterprise, will the Public Service Answering Point (PSAP) receive the correct building and in-building location information? 2) When someone dials from the enterprise, will in-building personnel be appropriately notified and alarmed so that they know about the incident and can direct first responders appropriately? Without the use of any special E911 capabilities, a user dialing 911 in an enterprise will pass the Automatic Number Identification (ANI) associated with the trunk they are using to the PSAP. SIP Service Oriented Architecture White Paper 19

20 ANI is basically the Caller ID of the line the user happens to be using for the call. The PSAP then taps into the Automatic Location Information (ALI) database using the ANI it received to obtain the location information, which will almost always correspond to the billing address for the trunk. The challenge with this setup is twofold: a) In a centralized deployment the billing address for the trunk is not likely to correspond with the address of where the incident occurred, and b) no in-building location information is included. SSOA provides different mechanisms to allow for a modern, flexible and safe emergency notification environment, including compliance with existing and emerging state and federal laws. a) Zone based E911 notification allows partitioning a large building into several zones. The ELIN (Emergency Location Information Identification) assigned to the zone by the enterprise admin then replaces the trunk s ANI passed to the PSAP. The location information that corresponds to this ELIN is the Emergency Response Location (ERL). It depicts the correct in-building location and is stored in the ALI database. The admin may break down the campus or enterprise area into several different ERLs that each can include a number of phones. b) Special call routing in the dialplan for emergency calls allows selection of dedicated gateways for such calls. This can be used to improve resiliency by e.g. using a local branch gateway as the first preference for emergency calls, and it can be used to make sure the call ends up in the appropriate emergency dispatch center for the location. c) Internal notification is provided using , SMS and XMPP based screen alerts. An alarm is logged and an SNMP trap is sent to a monitoring and reporting system that can provide for additional alarm escalation and logging. d) ESInet integration, the emerging SIP based next generation emergency services infrastructure, is possible by inserting location information (PIDF-LO) directly into the SIP messages sent to the PSAP. This is still a bit experimental but likely the future of an advanced public safety infrastructure. e) Auto-discovery of the actual location of an in-building device, in particular mobile DECT or WiFi connected devices is possible using an external auto-discovery solution. The SSOA system then interacts with this external auto-detection solution using Web Services interfaces to obtain the correct location information for a mobile device. Unified Messaging Service The Unified Messaging (UM) service is architected as an independent application, centrally managed as a component of the SSOA architecture. As a component with its own role, it can be instantiated on a common server together with other roles and components, or it can be run on a dedicated server. Very often there is a requirement to centralize unified messaging services in order to save operating expense. In this way one big unified messaging system can serve the entire enterprise for all remote locations. As unified messaging integrates into an existing and calendar system to provide a unified inbox user experience, colocation with that and calendar application often makes sense. The unified messaging (voic ) service itself is stateless on a call-bycall basis provided the voic message store is available to all components that need access to it. 20 SIP Service Oriented Architecture White Paper

21 Using the SSOA reliable data replication mechanism, the voic message store can be clustered among participating voic servers. This allows for load balancing between voic servers under normal operating conditions. Upon a server failure calls serviced by that server at the time of failure are lost, but the remaining voic servers can take over instantly and seamlessly. Dependent on hardware, a single unified messaging server typically scales to several hundred simultaneous calls or ports. With e.g. a capacity for 500 simultaneous calls or session, a single unified messaging server scales well beyond legacy voic systems that use TDM trunks to connect to the old PBX. A two server redundant setup doubles the capacity with the ability to add more servers as needed. Considering all the advantages and disadvantages of a centralized unified messaging service, it is believed that most of the larger deployments will rely on such a deployment topology. However, the SSOA architecture could accommodate location specific unified messaging services. The mailbox for each user is then associated with the instance of the voic service in the user s home location. The voic functions of forwarding and distribution lists are local to the instance of the unified messaging service and it is not possible to forward, distribute, or otherwise share voic messages between users on different instances of the unified messaging service. In addition, increased administrative overhead will be imposed managing decentralized unified messaging services with individual requirements for e.g. backup & restore of messages, as well as many servers integrating with a centrally located and calendar system. Integration with and calendaring services is done using Web Services interfaces. For instance the integration into Microsoft Outlook is done using an Outlook plugin. Messages are managed using Outlook, and messages can be heard using the Outlook integrated player. When a message is listened to in Outlook, it is marked read on the unified messaging server and the message waiting light (MWI) on the phone goes out. If the message is marked unread again in outlook the MWI light goes back on. If the message is deleted in Outlook, it is deleted on the UM server. The integration is based on Web Services transactions and agnostic to the backend system. That means that Outlook can be connected to Microsoft Exchange, Google Mail, Open- Xchange mail or some other server. Integration into other clients is equally simple using the same Web Services API. Conferencing Service Similar to the unified messaging service, the conferencing service is architected as an independent application. Each instance of a conference service must be located on a server in some location. There is a unique system role to assign conference service capabilities to a location and server. All conference bridge addresses (i.e. bridge number or SIP URI) are unique, so users in any location may use any conference server. The administrator assigns a specific conference service to be used for a user or group of users based on capacity, trunk availability and WAN bandwidth considerations. Each user can have one or several personal conference bridge(s) and each bridge is associated with a specific conferencing service. Capacity considerations for conferencing service are similar as compared to the unified messaging service. The conferencing server provides high-definition audio and in case a conference has mixed mode attendees using highdefinition and standard-definition audio, the conferencing bridge transcodes between the different codecs. Such transcoding is compute intensive and highly impacts overall system capacity. SIP Service Oriented Architecture White Paper 21

22 Instant Messaging and Presence Service The definition of Unified Communications in its most simple form is based on the integration of telephony with instant messaging and presence. The SSOA architecture unites a flexible SIP call routing service with Enterprise grade instant messaging based on the XMPP standard. The integration of the two allows for powerful new features such as seamless escalations from chat to calls, and group chat to conferencing. Unified presence is a direct consequence of this integration and is required for a modern user experience. The instant messaging and presence service offered by SSOA is highly scalable and offers all the relevant features required for enterprise deployment. Multi-vendor client interoperability is guaranteed given its adherence to the XMPP standard. Federation with other third party and at times proprietary Instant Messaging services are possible to the extent the other service s protocol definition is available. Server to server federation with other XMPP systems, such as Google Talk, is offered as a standard feature. In addition to Enterprise instant messaging and presence services, the SSOA IM service also extends functionality to mobile devices and smartphones, allowing mobile interactions with the system using the MyBuddy IM buddy. In this way it is possible to initiate calls, perform phone book lookups, manage conferences, and get notification of incoming voic messages and many other features normally only available at the office. Business Process and Application Integration SSOA natively supports Web Services interfaces, which makes business process and application integration easy. If you start out with a Computer Telephony Interface (CTI) on a legacy (IP) PBX, you will need complex and expensive add-on solutions to translate the functionality of the CTI interface into Web Services. SSOA eliminates this step by natively supporting a comprehensive Web Services API. SSOA was designed without a built-in user interface and focused on a Web Services API instead. Any user accessible functionality can then be made available through that interface. This includes Web based user management capabilities, open social based gadget and portlet integration, application integration using toolbars and add-ins, etc. SSOA communications-enables other applications and business processes, realizing that users want a combined experience where presence based communications is not a standalone separate application but integrated with tools and applications used to conduct their 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 document editing, and the building of social project groups linked using social media. The most social aspect of Social Business is a user s unified presence, the ability to share presence with other users, and combined with the power to communicate in real-time using different media while collaborating. This is where unified communications interacts with Social Business. The SSOA architecture for a unified communications solution was especially built to communications-enable Social Business applications. Combining SSOA based unified communications with Social Business creates a new application that makes it more convenient and efficient to collaborate and significantly improves the user experience thus a new market segment is born. 22 SIP Service Oriented Architecture White Paper

23 Summary SIP Services Oriented Architecture represents the state-of-the-art architecture for a scalable, highly-available, and modern unified communications system. It optimally uses available resources given its load-sharing redundancy, offers best possible audio and video quality, integrates all relevant modes of communications, and provides an attractive end user experience. SSOA is designed as a system that is easy to manage, avoiding any hierarchy between components with element managers and managers of managers. A cohesive web based administration interface allows centralized management of all components and powerful Web Services APIs allow for application and business process integration. SSOA is the new standard blue-print for how software based unified communications systems are built as an IT application. SSOA is the foundation of the ezuce openuc software communications system, and made available by ezuce in open source at SIPfoundry under the name sipxecs. Intoducing your new enterprise communications system. Sounds easy? Now it is! openuc SIP Service Oriented Architecture White Paper 23

24 Corporate Office ezuce, Inc. 8 Lorum Street. Newburyport, MA o [email protected]