| Oracle® Communication and Mobility Server Administrator's Guide 10g Release 3 (10.1.3) Part Number E12656-01 |
|
|
View PDF |
| Oracle® Communication and Mobility Server Administrator's Guide 10g Release 3 (10.1.3) Part Number E12656-01 |
|
|
View PDF |
This chapter provides an introduction to the Oracle Communication and Mobility Server (OCMS) in the following sections:
This release of Oracle Communication and Mobility Server 10.1.3.4 includes the following enhancements and new features:
Oracle Database is now the main, supported database for OCMS subscriber persistence. Oracle TimesTen is no longer included with OCMS 10.1.3.4.
To read about new and improved features, see the following link:
http://www.oracle.com/technology/products/ocms/otn_front.htm.
See also "Supported Protocols, RFCs, and Standards".
OCMS 10.1.3.4 supports TLS as a network connectivity option.
The OCMS SIP Servlet Container support TLS in two modes, one in which the SIP container acts as a TLS server and another where you configure the SIP Servlet Container to provide mutual TLS, where the container not only provides its server certificate but also requires a client certificate.
The User Dispatcher enables the Presence and XDMS applications to scale. The User Dispatcher is a proxy that dispatches SIP, HTTP, and XCAP (over HTTP) requests to their appropriate destinations on a consistent basis.
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
The following improvements have been made to the Web Services APIs:
ParlayX 2.1 Presence Web Services API fully supported including asynchronous Web services. For more information see, Chapter 9, "OCMS Parlay X Presence Web Services".
A new API created for the SIP-based ParlayX 2.1 Messaging Web Services API. For more information see Chapter 10, "OCMS Parlay X Multimedia Messaging Web Services".
A new API for Contact Management API. This is a JAVA utility API that helps managing users contact list and presence rules. For more detail, refer to the javadoc that comes with the installation of OCMS. The javadoc is located at $ORACLE_ HOME/sdp/api-docs/sdpcontactmanagement-10.1.3.4.0-javadoc.zip
Oracle Communication and Mobility Server (OCMS) is a carrier-grade SIP application environment for the deployment, and management of SIP applications. Built on a standard Java2 Enterprise Edition (J2EE) platform, OCMS is a flexible, scalable environment enabling easy integration of SIP applications and services.
Among the applications that may be deployed on SIP platforms:
Voice and video telephony, including call management services such as call forwarding and call barring
Publication of and subscription to user presence information, such as online/offline status, notifications, permission to access a user's status, and so on
Instant messaging
Push to Talk applications, including Push-to-Talk over Cellular (PoC)
OCMS provides standard SIP applications, including a Presence Server, a combination Proxy and Registrar server, and a SIP Server. An integral part of any SIP platform, these applications are automatically installed to the OCMS platform, reducing development resources and time to go live.
OCMS provides a standards-based Presence Server which provides SIMPLE compliant Presence and event notification features. The OCMS Presence Server is robust enough to support carriers with a heavy load of subscribers, while still being a viable solution for ISVs, system integrators, and enterprises requiring an integration platform and an enterprise Presence Server.
OCMS provides the following functionality:
Deployment—SIP Servlet applications are easily packaged and deployed on Oracle Application Server acting as a SIP servlet container.
Configuration and Management—The Oracle Application Server administrator console enables managing SIP applications as well as the SIP server and its components.
Authentication and Security—User, role, and policy data can be stored on an external RADIUS database, or in Oracle Identity Management, enabling OCMS to authenticate connecting users against this data. OCMS secures SIP traffic through digest-based authentication as specified in RFC 3261. In addition, trusted hosts can be configured using p-asserted identity headers.
Logging and Monitoring—OCMS enables monitoring of the deployed SIP applications through comprehensive logging functions as well as metrics exposed as JMX Mbeans.
Oracle Communication and Mobility Server architecture is composed of three layers:
The Proxy layer includes an IP load balancer and the OCMS Edge Proxy Server. The IP load balancer provides a unique public address to which SIP requests are sent. The IP load balancer distributes SIP requests either to the OCMS Edge Proxy Server or directly to an OCMS SIP Server.
The IP load balancer is not SIP-aware - it is unaware of the content of the traffic it forwards, such as the sender and recipient. The IP load balancer distributes requests to OCMS nodes based on the availability of individual servers. This is essential in a clustered environment, particularly in the event of a node failure. If a node fails, the load balancer redistributes traffic to the remaining nodes until the failure is corrected.
The OCMS Edge Proxy is a SIP load balancer, proxying SIP requests to a particular OCMS SIP Server. The Edge Proxy forms logical pathways between sessions and SIP servers, such that SIP traffic sent from a particular session is always handled by the same server. As the number of SIP clients increases, additional Edge Proxy servers can be added, providing highly scalable and efficient handling of SIP clients.
The Application layer is typically composed of a cluster of OCMS SIP Server nodes. The Application layer provides SIP clients with low response time and high throughput when handling SIP requests. As the Application layer handles a greater number of transactions, it can be scaled up by adding additional OCMS SIP Server nodes. To achieve high availability of session data, replication of session data can be enabled so that sessions survive a failover.
The Data layer is typically composed of a highly available, high performance database for the storage and retrieval of user, authentication, authorization, and location data. This data is replicated among all nodes. Similarly, SIP Servlet session data is replicated among nodes. In the event of a node failure, another node takes over the session data of the failed node.
Figure 1-2 illustrates the logical system components of OCMS:
Figure 1-2 Oracle Communication and Mobility Server
The OCMS components are as follows:
User Dispatcher (described in Scalable Presence Deployments with User Dispatcher)
Servlets are dynamic applications that run on a web server using the J2EE platform. Like the HTTP Servlet API, the SIP Servlet API (JSR116) extends the functionality of the Java Servlet to receive SIP requests and generate SIP responses, regardless of the underlying network. A SIP application consists of one or more SIP Servlets which, along with a deployment descriptor, are packaged and deployed on a J2EE SIP Servlet Container.
Although they are similar, the SIP Servlet differs from the HTTP Servlet as follows:
SIP applications include intelligent request routing and the ability to proxy requests as required, even to multiple destinations.
SIP is a peer-to-peer protocol, with endpoints that can typically initiate and respond to SIP requests.
SIP Servlet applications may be registered so as to be invoked in response to particular events.
Unlike the HTTP Servlet, the SIP Servlet is asynchronous. This means that when receiving a SIP request, a SIP Servlet application can initiate another action, return control to the SIP Servlet container, and respond to the request at a later time.
A SIP Servlet application is often composed of more than one SIP Servlet.
As SIP and HTTP servlets are based on the same generic Servlet specification, both types of servlets can be easily converged into one application. An application composed of both SIP and HTTP servlets can therefore handle both SIP and HTTP traffic.
Figure 1-3 SIP Servlet Model versus HTTP Servlet Model
Typical SIP-based applications include:
Telephony over IP, with the following features:
Speed dial
Wake-up call service
Call forwarding service
Click-to-call
Emergency call service
Video calls
Push to talk
Instant messaging
Presence information service
Network gaming
A SIP Servlet Container extends the J2EE Application Server, providing a runtime environment for SIP applications, including services such as security, concurrency, life cycle management, transaction, deployment, and other services. A JSR116-compliant SIP Servlet Container provides network services for sending and receiving SIP requests and responses using a combination of transport protocols, IP addresses, and port numbers to listen for incoming SIP traffic.
The OCMS SIP Servlet Container can be installed on an existing instance of Oracle Application Server, running in OC4J. Alternatively, the OCMS SIP Servlet Container can run on its own stand-alone instance of OC4J.
The typical OCMS SIP Servlet Container is composed of an Oracle Application Server instance with OC4J as its J2EE container, and Oracle Process Manager and Notification Server (OPMN) to monitor the server. OCMS currently supports high availability deployments in this configuration only.
Figure 1-5 The SIP Servlet Container on Oracle Application Server
The SIP Servlet Container is configured upon server startup. Once a SIP Servlet application is deployed to the SIP Servlet Container, its deployment descriptor is used to configure its servlets and create a servlet context. The SIP application's listeners and servlets are instantiated, and the servlets are initialized with the servlet configurations.
When the SIP Servlet Container receives an initial incoming request, it processes a set of rules in order to send the request to the correct SIP Servlet. Once the request arrives at the SIP Servlet, the Servlet must either proxy the request to a new destination, dispatch it to another Servlet, or send a response.
The Edge Proxy server provides the following functionality:
Acts as a load balancer for initial incoming SIP requests
Provides SIP Server affinity and failover for subsequent SIP requests in a session
Manages the health of the OCMS application servers in a cluster by dynamically constructing a routing table of OCMS application servers
The Edge Proxy distributes incoming SIP traffic among OCMS SIP application servers when used between a SIP-unaware load balancer and an OCMS cluster. A standalone Java application running on its own server, the Edge Proxy establishes an affinity between the client and SIP Application Server for the duration of the session. This means that the same OCMS SIP Application Server always handles traffic from a particular client for the duration of the session, creating a path between the client and server.
Multiple Edge Proxy Servers can be deployed in a highly available environment. In this scenario, a load balancer distributes incoming traffic among the Edge Proxy Servers. Together, the Edge Proxy Servers can handle a greater load of subscribers connecting to the cluster of OCMS SIP Application Servers.
Figure 1-7 illustrates how the use of two Edge Proxy Servers reduces the load of SIP connections in a clustered OCMS environment. A third-party load balancer provides a single virtual IP address to which clients may address requests, and distributes SIP requests to the Edge Proxy Servers. Edge Proxy Servers can be duplicated to enable high availability—if one Edge Proxy fails, the other Edge Proxy takes over the workload of the failed node. When scaling up OCMS Server nodes, it may be necessary to add additional Edge Proxy Servers to the topology in order to handle the additional connections being established in the system.
The OCMS Proxy Registrar combines the functionality of a SIP Proxy Server and Registrar. Its main tasks include:
Registering subscribers. The Proxy Registrar registers a subscriber's address and maps it to the actual address of the subscriber's terminal. The Proxy Registrar stores subscriber contact information in the Location Service data store, and uses this data to create paths between the SIP Application Server and the subscriber.
Proxying requests onward. Upon receiving SIP requests, the Proxy Registrar finds the current contact information of the subscriber using the Location Lookup Service or ENUM (TElephone NUmber Mapping) Service. The Proxy Registrar replaces the request destination URI with the current, correct SIP address as returned by one of the lookup services, and proxies the request to this destination.
The Location Lookup Service stores registration information for all subscribers, as defined by RFC3261. This information is used by the Proxy Registrar to reach subscribers at the right client at any time. For example, a subscriber can connect to OCMS using a client at home or work
Registration data is stored in an Oracle database. The Proxy Registrar uses the Location Service to look up the subscriber's actual, current contact information and proxy requests to that URI. The Proxy Registrar thus creates a direct, reusable connection between the user and the node. The Proxy Registrar uses this connection to route subsequent requests to the correct destination. The client, meanwhile, must regularly refresh its state so as to keep the Location Service data current.
If an incoming SIP request destination URI includes a telephone URI, the Proxy Registrar must translate the telephone number to a SIP address, using an ENUM (TElephone NUmber Mapping) service. OCMS provides an ENUM Service which uses a configured DNS server to look up the telephone number and translate it into a SIP address. The ENUM Service replaces the telephone number destination URI with the translated SIP address and proxies the request to its destination.
The main tasks of the ENUM Lookup Services are as follows:
Convert the telephone destination in an incoming request URI into a host name. For example:
$ORIGIN 2.4.2.4.5.5.5.5.1.4.1.e164.arpa.
Look up the converted host name in the configured DNS server. The DNS server returns a matching SIP address based on its search for the phone number.
IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:4242@555telco.example.com!"
Replace the telephone number URI with a properly formatted SIP address.
Proxy the request to the SIP address.
OCMS includes its own Presence Server, based on the following: RFCs 2778, 3265, 3856, 3857, 3858, 3859, 3863, 3903, as well as OMA Presence Enabler 1.0. The OCMS Presence Server handles registration, storage, and retrieval of presence information.
Presence describes a user's availability and willingness to communicate. The Presence Server can signal whether users are on- or offline and whether they are idle or available. The Presence Server enables users publish their contact details such as instant messaging handle, mobile phone number, and audio and video capability.
A number of roles are defined in the context of Presence:
Presentity—A Presentity is a user entity that provides presence information to the Presence Server. A presentity can have a number of PUAs, such as a computer at work, a computer at home, and a mobile device.
Presence User Agent (PUA)—A device that provides presence information, such as an instant messaging application (Oracle Communicator), or a mobile device. A PUA provides presentity information to the Presence Server.
Watcher—Requests presence or watcher information from the Presence Server. The two types of watchers include the fetcher and subscriber.
The Presence Server does the following:
Composites event state into a presence document for a presentity
Accepts SUBSCRIBE requests from watchers to create subscriptions to a given presentity's presence data
Acts as a notifier, generating NOTIFY requests to notify subscribers of the state of their subscribed presentity
As illustrated in Figure 1-9, presentity Alice has three Presence User Agents (PUAs). A client running on any of these PUAs publishes Alice's presence to the OCMS Presence Server. Meanwhile, watchers Bob and Cathy want to subscribe to Alice's presence information.
Bob and Cathy each run a client that sends the Presence Server a SUBSCRIBE request for Alice's presence. The Presence Server consults Alice's presence policy document in order to determine if Bob and Cathy are permitted to subscribe to his presence. If they are, then the Presence server sends a NOTIFY message containing information about Alice's current presence state. Whenever Alice's presence state changes, the Presence Server sends a NOTIFY message to Bob and Cathy's clients informing them of the change
The following example illustrates how the Presence Server manages presence information.
Figure 1-10 How the Presence Server Works
A user's presence information can change. For example, the user might be using a different PUA, such as a mobile device or a laptop, or the user may be idle or away. The following describes how the Presence Server handles this change in data:
The presentity uploads a policy document that specifies the information to which each watcher is entitled. For example, a user might only want particular watchers to see whether or not she is online.
Each PUA sends the new presence information to the Presence Server and issues a SIP PUBLISH request. The presence information is sent in the form of a presence document.
The Presence Server receives the presence documents and merges the data into a single document using a composition policy that specifies rules regarding merging presence documents.
The unified document is filtered using the privacy policy uploaded to the Presence Server by the presentity (see step 1). This filtering removes any details that the presentity does not want to provide to a given watcher.
The Presence Server sends the watcher a NOTIFY request containing the presence document.
OCMS Application Router is a SIP application that routes incoming SIP requests to the correct application. The Application Router routes requests by placing route headers in each SIP request it processes. A number of route headers can be placed in a request, each representing a different destination URI. The SIP request is either sent through the chain of destination URIs, or proxied to a new URI upon arriving at its first destination.
The Application Router typically routes SIP requests to the Proxy Registrar or the Presence Server, respectively. Any number of additional application URIs can be configured in the Application Router.
The Application Router operates in two modes: standard and incremental.
The Application Router embeds any number of destination URIs, or routes, in the headers of incoming SIP requests. The SIP request follows this chain of URIs until the request is consumed. The order of URIs is determined by the incremented alias assigned to each route (uri.1, uri.2, and so on).
Figure 1-11 The Application Router in Standard mode
The Application Router incrementally embeds each route within the incoming SIP request, along with a route back to the Application Router. The SIP request is sent to the first destination, and then returns to the Application Router. The Application Router examines the SIP request's destination URI, which results in one of two possible outcomes:
If the destination URI has been changed by the application to which the request was sent, the Application Router proxies the SIP request to the new URI.
If the destination URI has not changed, the Application Router embeds the second route in the header of the SIP request and sends it on its way. Again, the SIP request arrives at the second destination, whereupon it returns to the Application Router. The Application Router must, once again, decide whether to proxy the SIP request to a new URI or embed the third route in the header of the SIP request.
For example, as shown in the following illustration, the Application Router embeds within a SIP request destinations uri.1, uri.2, and uri.3. The SIP request goes first to uri.1. If application 1 changes the destination URI of the SIP request, the Application Router routes the request to the new URI, or application x (see Figure 1-12). Otherwise, the Application Router routes the request to the next URI configured in the route header, namely uri.2.
Here again, application 2 may change the destination URI of the SIP request, in which case the SIP request continues on to application y (see Figure 1-12). Otherwise, the Application Router routes the SIP request to uri.3, and so on.
Figure 1-12 The Application Router in Incremental Mode
The Application Router can be used in conjunction with a call screening application, for example. In this scenario, the Application Router runs in standard mode with two destination URIs configured in the route header: one to the call screening application and one to the OCMS Proxy Registrar.
An incoming SIP request is intercepted by the Application Router, which embeds both the call screening application URI and the Proxy Registrar URI in the route header of the SIP request. The SIP request continues on to the call screening application, which determines whether or not to put through the request for a call to a given user.
If the call screening application accepts the call, the SIP request continues on to the Proxy Registrar, which forwards the request to the correct destination.
If the call screening application rejects the call, it responds with a "403 Forbidden" error message for example, stopping the SIP request and breaking the routing chain.
The Application Router can be used in the context of a call forwarding application. A call forwarding application typically forwards calls by modifying the SIP request destination URI. For example, a call forwarding application might change the destination URI to the URI of a voice mail server.
This is accomplished by using the Application Router in incremental mode to intercept and proxy the SIP requests. SIP requests are sent to the Application Router, which forwards the requests to the call forwarding application and places a return route to itself in the header of the SIP request. The call forwarding application determines whether or not to send the SIP request to the voice mail server and consequently modifies the SIP request destination URI. As the SIP request destination URI has changed, the SIP request returns to the Application Router, which proxies the SIP request to the destination determined by the call forwarding application.
Suppose the SIP request returns to the Application Router, but the call forwarding application has not changed its destination URI. In this case, the Application Router sends the SIP request to the next application as configured in the Application Router settings.
The OCMS subscriber data services stores user authentication data, user, role, and policy data, as well as user location data. In a scaled, highly available configuration, the shared database enables all OCMS SIP application servers to access stored data.
The following data is stored:
Authentication and authorization data provide the primary framework through which access control is configured for the OCMS. Authentication and authorization data can be stored on a RADIUS server, or on Oracle Identity Management.
The User database stores private subscriber IDs used for subscriber authentication. The Proxy Registrar authenticates users by mapping private subscriber IDs stored in the user database to public subscriber addresses in SIP requests and responses. User data is stored on Oracle Identity Management.
The Logging service is used to log and monitor system events and SIP traffic. Logs can be used to audit and debug the system.
