Skip Headers

Oracle® Communication and Mobility Server Administrator's Guide 10g Release 3 (10.1.3) Part Number E12656-01 |
Home | Contents | Index | Contact Us

Previous | Next
| View PDF

# 2 Deployment Topologies

This chapter discusses OCMS deployment topologies in the following sections:

- "About Deployment Topologies"

- "Topology Components"

- "Supported OCMS Topologies"

- "Deploying OCMS as a Highly Available SIP Network"

- "Deploying OCMS as a Presence Server"

- "Deploying a Scalable Presence Deployment"

- "Deploying OCMS as an Instant Messaging Service"

- "Deploying an OCMS Testing Environment"

- "Configuration Recommendations"

## About Deployment Topologies

OCMS supports single-node and clustered, multi-node deployment topologies.

A single-node deployment consists of a single SIP Application Server instance. This deployment, which typically hosts SIP applications along with a database server, is appropriate for running a testing environment or a very small deployment of OCMS.

A SIP Application Server cluster is defined as a set of SIP Application Server instances that share state related to the applications. A cluster consists of one or more application server nodes, with each node running one instance of OCMS.

A highly available OCMS cluster provides the following:

- Replication of objects and values contained in a SIP Application Session.

- Database backed location service data.

- Load balancing of incoming requests across OCMS SIP application servers.

- Overload protection protects the server from malfunctioning in the event of overload and rejects traffic which cannot be handled properly.

- Transparent failover across applications within the cluster. If an instance of an application fails, it becomes unresponsive and the session can fail over to another instance of the application, on another node in a cluster.

Table 2-1 Additional Information

For more information on... | See:
--- | ---
OCMS installation | Oracle Communication and Mobility Server Installation Guide
Operating systems supported by highly available OCMS clusters | Oracle Communication and Mobility Server Certification Guide
Configuring a highly available clustered Oracle Application Server environment | The "Application Clustering" chapter in Containers for J2EE Configuration and Administration Guide. The "Active-Active Topologies" chapter in Oracle Application Server High Availability Guide.
Configuring highly available OCMS topologies | Chapter 5, "Configuring High Availability" in this guide

## Topology Components

Components of a highly available topology include the following:

- Third-Party Load Balancer

- Edge Proxy Nodes

- SIP Application Servers

- Aggregation Proxy

- Proxy Registrar

- User Dispatcher

### Third-Party Load Balancer

A third-party load balancer balances the load of incoming traffic among the Edge Proxy nodes. It also deflects failed Edge Proxy nodes and redirects traffic to other Edge Proxy nodes.

### Edge Proxy Nodes

The Edge Proxy nodes form sticky connections between clients and servers for the duration of the session, creating a path between a client and server and sending SIP traffic over that path. The Edge Proxy nodes balance the load of SIP traffic among the SIP Application Servers.

Both Edge Proxy Servers are configured with a virtual IP address. Each Edge Proxy node detects failed SIP Application Server nodes and fails over to the remaining SIP Application Server nodes.

### SIP Application Servers

The SIP Application Servers are all linked to each Edge Proxy node. The SIP Application Servers are linked to each other through OPMN. The OCMS SIP state on each computer is replicated to the other two nodes. If one SIP Application Server node fails, another node takes over, using the replicated state of the failed node.

For more information on replicating states among OAS instances and configuring clustering, see "Setting Up a Highly Available Cluster of OCMS Nodes".

### Aggregation Proxy

The Aggregation Proxy authorizes Web Service calls and authenticates XCAP traffic. The Aggregation Proxy then proxies this traffic to the Parlay X Web Service and XDMS. This is an optional component.

### Proxy Registrar

The OCMS Proxy Registrar combines the functionality of a SIP Proxy Server and Registrar. Its main tasks include registering subscribers, looking up subscriber locations, and proxying requests onward. The Proxy Registrar stores user location and registration data on the Oracle database. This is an optional component.

For more information, see "Proxy Registrar".

### User Dispatcher

The User Dispatcher enables the Presence and XDMS applications to scale. The User Dispatcher is a proxy that dispatches SIP and XCAP (over HTTP) requests to their appropriate destinations on a consistent basis.

#### Presence Dispatching

Because the Presence application maintains the states for all users in the deployment, the User Dispatcher enables scaling (distribution) of the Presence application. The User Dispatcher supports request dispatching to the following Presence sub-applications, which use the SIP and XCAP (over HTTP) protocols:

- Presence server

- Presence XDMS

- Shared XDMS

## Supported OCMS Topologies

Supported topologies include:

- Deploying OCMS as a Highly Available SIP Network

- Deploying OCMS as a Presence Server

- Deploying OCMS as an Instant Messaging Service

- Deploying an OCMS Testing Environment

Note:

Only the Oracle Application Server installation mode supports high availability. For more information, refer to the Oracle Communication and Mobility Server Installation Guide.

## Deploying OCMS as a Highly Available SIP Network

When deployed as a highly available SIP network, OCMS can be used to implement a basic VoIP system, enabling voice and video calls. This topology (illustrated in Figure 2-1) includes the following:

- A hardware load balancer

- A cluster of Edge Proxy Servers

- A cluster of two SIP Application Servers, each running a SIP Servlet Container

- Replicated databases, including user data, authentication data, and user location information

Figure 2-1 OCMS as a Highly Available SIP Network

Description of "Figure 2-1 OCMS as a Highly Available SIP Network"

This topology provides a highly available SIP network capable of handling millions of users. Each SIP Application Server must run an Oracle database and Proxy Registrar application.

The SIP network topology includes hardware and software components described in Table 2-2.

Table 2-2 SIP Network Topology Hardware and Software Requirements

Hardware | Software | Installation TypeFoot 1
--- | --- | ---
Load balancer | N/A | N/A
Two computers with at least 4 GB of RAM and a dual 2.8 Ghz CPU | Edge Proxy | Custom installation
Two computers with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 Oracle database Proxy Registrar Application | Typical installation

Footnote 1 Refer to the OCMS Installation Guide for more information.

Load Balancer

A load balancer or DNS round-robin algorithm balances the load of incoming traffic among the Edge Proxy nodes. Using the DNS round-robin algorithm requires all clients to implement DNS lookup.

See also:

"Topology Components" for a description of the components used in this topology.

## Deploying OCMS as a Presence Server

OCMS can be deployed as a Presence Server. The Presence Server topology is deployed on two nodes: one running the Presence Server and the other running the Aggregation Proxy and XDMS. This topology (illustrated in Figure 2-2) can be implemented within an IMS network to provide Presence functionality.

The Presence Server topology includes the following:

- One SIP Application Server node with the Presence Server

- One SIP Application Server node with an XDMS and an Aggregation Proxy

Figure 2-2 Presence Server Topology

Description of "Figure 2-2 Presence Server Topology"

The Presence Server topology includes hardware and software components described in Table 2-3.

Table 2-3 Presence Server Topology Hardware and Software Requirements

Hardware | Software | Installation TypeFoot 1
--- | --- | ---
One computer with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 Presence Server | Typical installation
One computer with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 XDMS Aggregation Proxy Oracle database 10.2.0.3 or 11.1.0.7 (required for the Aggregation Proxy). | Typical installation

Footnote 1 Refer to the OCMS Installation Guide for more information.

XDMS

Manual post-installation configuration is required for the XDMS, involving configuring Presence as an XDMS. For more information, refer to the OCMS Installation Guide.

See also:

See "Topology Components" for a description of the components used in this topology.

## Deploying a Scalable Presence Deployment

This section describes the recommended and supported deployment topology for a large scale Presence Solution requiring Presence, XDMS, and User Dispatcher. It illustrates the typical flows from a multi-node perspective.

To scale across multiple nodes, the User Dispatcher component dispatches all traffic targeting a particular Presentity to the same Presence Server instance.

### Presence Cluster

A Presence Cluster is defined as a set of Presence Nodes connected after one or more Load Balancers. The Presence Cluster is responsible for processing incoming subscribe and publish requests made towards the presence event-package and of course for sending out notify's whenever appropriate. The Presence Cluster will also accept and processing subscribe requests for the presence.winfo event-package.The Presence Cluster will interact with the XDM Cluster in order to obtain information needed to complete its responsibilities. The information queried of the XDM Cluster is user's presence-rules and pidf-manipulation documents.

The Presence Cluster is layered into the following three distinct tiers:

- The load-balancing layer, responsible for dispatching incoming traffic to the User Dispatchers. The load balancers are stateless and do not understand SIP as a protocol.

- The user-dispatching layer, responsible for dispatching traffic based on user information. A user is assigned to a particular Presence Server instance and all traffic destined to that user will be dispatched to the same Presence Server instance. Even though each User Dispatcher is stateless and does not share state with the other User Dispatchers, they still need to have the same view of the Presence Server tier.

- The bottom layer is where the Presence Server instances reside. Each instance is separated from the others and does not share any state with any other instances. The purpose of the Presence Server tier is to serve incoming SUBSCRIBE and PUBLISH requests destined to the presence event-package as well as servicing subscriptions to the presence.winfo event-package.

The Presence Cluster consists of the following physical nodes:

- The Load Balancer, such as an F5.

- The Presence Node, which consists of the following components:

  - User Dispatcher

  - Presence Server

### XDM Cluster

The XDM cluster is defined as a set of XDM Nodes connected after one or more Load Balancers. The XDM cluster processes all XDM related traffic, that is, SIP subscribe traffic towards the ua-profile event-package and XCAP traffic. As such, it deals with everything that has to do with manipulating XML documents. The XDM Cluster uses a database for actual storage of the XML documents but note that the database, and potentially its cluster, is not part of the XDM Cluster.

The XDM cluster consists of the following layers:

- The load-balancing tier, responsible for dispatching both SIP and XCAP traffic to the next layer. For XCAP traffic the next tier is the Aggregation Proxy but for SIP, the traffic goes directly to the User Dispatcher layer.

- Aggregation Proxy layer – authenticates incoming traffic and upon successful authentication it forwards the requests to the User Dispatcher layer. All XCAP traffic for external traffic goes through the Aggregation Proxy layer. Internal traffic, however, will not go through the Aggregation Proxy but rather directly to the User Dispatchers.

- User Dispatcher layer – from a SIP perspective it carries out the exact same duties and functions as in the Presence Cluster (it is the same kind of traffic after all). The main difference in the XDM Cluster compared to the presence one is that in the XDM Cluster the User Dispatchers will also have to handle XCAP traffic. However, the XCAP traffic is treated in the exact same way as SIP and the purpose of the User Dispatcher for XCAP traffic is the same as for SIP: to extract user information based on the request and then dispatch it to the correct XDMS instance.

- The XDM Server layer has the same function as the Presence Servers in the Presence Cluster. The XDMS instances serve incoming SUBSCRIBE requests for the event-package ua-profile and will whenever appropriate send out NOTIFY messages to all registered subscribers. Note that the XDMS does not accept PUBLISH requests and updating the state of the Resources (which are XML documents) is through XCAP operations. An XDM Client can manipulate the documents managed by an XDMS by issuing appropriate XCAP operations. A successful XCAP operation may alter the content of a document whereby the XDMS would send out NOTIFY messages to the subscriber of that document to inform them about the change. Whenever the XDMS needs to get an XML document it queries the next layer, the database layer.

- The Database tier physically stores the XML documents managed by the XDMS. This tier guarantees high-availability and scalability so that if one of the nodes in the database layer fails, documents that resided on that node will still be accessible to the XDMS without any loss of data or service.

The XDM Cluster consists of the following physical nodes:

- The Load Balancer, such as an F5.

- The XDM Node, which consists of the following components:

  - Aggregation Proxy

  - User Dispatcher

  - The XDM Server (XDMS)

- The database.

### Presence Node

The Presence Node is the main component in the Presence Cluster and is responsible for dispatching the incoming traffic to the correct Presence Server instance and of course servicing users with presence information. The User Dispatcher serves the same purpose both in a single node deployment and in a multi-node deployment. That is, its purpose is to dispatch incoming traffic to a particular PS instance and if this instance is running on the same physical node or not is of no relevance to the User Dispatcher. The User Dispatcher identifies a particular node by its full address, that is, the IP address and port, and has no concept of local instances.

A Presence Node will always have a User Dispatcher deployed that serves as the main entrance into the node itself. Typically, the User Dispatchers listen to port 5060 and the other Presence Servers on that node listen on other ports. In this way, a single node will appear as one Presence Server to clients but is in fact multiple instances running behind the User Dispatcher. Each of the components deployed on the Presence Node is executing in their own separate Java Virtual Machine. That is, the User Dispatcher and the Presence Server instances execute in their own OC4J and SIP containers. The reason for this is to be able to utilize all the available memory on that machine.

### XDM Node

The XDM Node always has an Aggregation Proxy deployed that typically listens on port 80 for XCAP traffic. The Aggregation Proxy authenticates incoming traffic and upon successful authentication forwards the request to the User Dispatcher. As with the Presence Node, the XDM Node will also have a User Dispatcher deployed (usually on port 5060) and for SIP traffic there is no difference between the XDM and Presence Nodes. The difference between the two types of nodes is that the User Dispatcher will also dispatch XCAP traffic. As it does with SIP, it extracts the user id out of the request and, based on that, maps the request to a particular XDMS instance to which it forwards the request.

There will be a number of XDMS instances deployed to which the User Dispatcher dispatches both SIP and XCAP traffic. Just as in the case of the Presence Server instances on the Presence Node, each XDMS instance is not aware of the others and executes in isolation.

The Aggregation Proxy and User Dispatcher are deployed onto the same OC4J container and use the same Java Virtual Machine.

### Complete Presence and XDM Cluster

Figure 2-3 shows a complete Presence and XDM cluster with all necessary components. This figure also illustrates that the two clusters, Presence and XDM, are treated as two separate clusters and the way into those two networks for initial traffic is always through their respective Load Balancers. Even the Presence Servers will actually go through the Load Balancer of the XDM Cluster when setting up subscriptions. However, once a subscription has been established the subsequent requests will not go through the Load Balancer but rather directly to the XDMS instance hosting the subscription. All nodes in the XDM Cluster are directly accessible from the Presence Cluster.

Figure 2-3 Presence and XDM Nodes

Description of "Figure 2-3 Presence and XDM Nodes"

## Deploying OCMS as an Instant Messaging Service

The OCMS Instant Messaging topology is a highly available, topology that enables messaging, including instant messaging client applications. Figure 2-4 illustrates a sample topology consisting of six nodes in three clusters. The IM topology comprises a four-node SIP network topology and a two-node Presence Server topology, with the addition of the Application Router. The Application Router routes SIP requests to either the Proxy Registrar or the Presence Server, enabling registering and retrieving user contact and location data, as well as handling all aspects of Presence publication and notification. The Aggregation Proxy on either SIP Application Server node is used to authenticate subscriber access to presence documents stored on the XDMS. This topology provides the server-side functionality behind instant messaging client applications.

Figure 2-4 Instant Messaging Service Topology

Description of "Figure 2-4 Instant Messaging Service Topology"

This topology includes hardware and software components described in Table 2-4.

Table 2-4 Topology Hardware and Software Requirements

Hardware | Software | Installation TypeFoot 1
--- | --- | ---
Load balancer | N/A | N/A
Two computers with at least 4 GB of RAM and a dual 2.8 Ghz CPU | Edge Proxy | Custom installation
Two computers with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 Oracle Database Aggregation Proxy Application Router Proxy Registrar | Typical installation
One computer with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 Presence Server | Typical installation
One computer with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 XDMS | Typical installation

Footnote 1 Refer to the OCMS Installation Guide for more information.

For more information about scaling this hybrid topology, see "Deploying OCMS as a Highly Available SIP Network" and "Deploying OCMS as a Presence Server".

See also:

"Topology Components" for a description of the components used in this topology.

## Deploying an OCMS Testing Environment

An OCMS testing environment is deployed on a single SIP application server node. A single-node OCMS topology is appropriate for testing, demonstrations, and small enterprises.

Note:

Because the testing environment is deployed on a single node, it cannot provide high availability.

Figure 2-5 illustrates a single-node deployment which includes a Proxy Registrar.

Figure 2-5 Single Node Deployment

Description of "Figure 2-5 Single Node Deployment"

Figure 2-6 illustrates a single-node deployment with Proxy Registrar, Presence, Aggregation Proxy, XDMS, and Application Router.

Figure 2-6 Single Node Deployment with Presence

Description of "Figure 2-6 Single Node Deployment with Presence"

The single node topology includes hardware and software components described in Table 2-5.

Table 2-5 Single Node Topology Hardware and Software Requirements

Hardware | Software | Installation TypeFoot 1
--- | --- | ---
One computer with at least 4 GB of RAM and a dual 2.8 Ghz CPU | OAS 10.1.3.4 Oracle database Proxy Registrar | Typical installation
| If deployment includes Presence: Presence application Aggregation Proxy | Typical installation

Footnote 1 Refer to the OCMS Installation Guide for more information.

See also:

"Topology Components" for a description of the components used in this topology.

## Configuration Recommendations

The following is recommended for most topologies:

- Use TCP as the transport protocol. SIP clients use UDP or TCP to transport SIP messages. If there is a concern about exceeding UDP MTU size limits, TCP should be used. The preference for TCP can be enforced by adding NAPTR and SRV records to the DNS indicating that TCP is the preferred protocol. Make sure that clients connecting to OCMS fully support NAPTR and SRV records.

- Run the OCMS SIP Server in the default Record-Route mode. The best way for clients to handle NAT/FW in the network is to establish a TCP connection to the server upon registration, and reuse this connection for all incoming and outgoing SIP traffic. This requires the client to have an `outboundproxy` setting that points to the Proxy Registrar, and that the Proxy Registrar is configured to use `record-route`.