| Oracle® Communication and Mobility Server Administrator's Guide Release 10.1.3 Part Number E10292-02 |
|
|
View PDF |
| Oracle® Communication and Mobility Server Administrator's Guide Release 10.1.3 Part Number E10292-02 |
|
|
View PDF |
This chapter provides an introduction to the Oracle Communication and Mobility Server in the following sections:
This release of Oracle Communication and Mobility Server includes enhancements and new features. To read about new and improved features, see the following link:
http://www.oracle.com/technology/products/ocms/otn_front.htm.
The Session Initiation Protocol (SIP) is a signaling protocol for initiating, modifying, and terminating interactive communication sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. A 3GPP signaling protocol, SIP is a permanent element of the IMS architecture and is widely used for Voice over IP. Similar to HTTP, SIP is addressing neutral, with addresses expressed as URIs, telephone numbers, or addresses similar to e-mail.
Session Initiation Protocol is:
Lightweight, with only six methods
Transport-independent, as it can be used with UDP, TCP, and other transport protocols
Text-based, allowing for low overhead
Capable of handling user mobility, by registering and updating current user locations enabling delivery of messages to the correct address
Specifically designed to work with the Internet
See also:
For more information on SIP, see the following URLs:SIP is distinguished by the following features:
Cooperative and future compatible—SIP establishes session connectivity among users, including registering and locating users. However, SIP does not define the content of a session, such that SIP can be used to establish any type of a number of sessions. Other protocols can be used to define various sessions established using SIP, including protocols that do not yet exist.
End system intelligence—SIP Servers route requests to users by examining request URIs Via headers, rather than processing data in the message body. The User Agents at either end of the system are responsible for addressing messages, such that SIP pushes intelligence to the end system. Once a session is established, end systems communicate without the help of the SIP Servers. The near statelessness of SIP Servers makes SIP a very efficient protocol.
Interoperability—SIP extensions are designed to be modular, such that their use is individually negotiated between user agents. Negotiating the use of extensions guarantees interoperability among SIP user agents in the network.
Scalability—Stateless SIP Servers are kept at the core of the network, while any stateful servers are kept at the periphery, near the end systems. By keeping stateless servers at the point of network stress, SIP networks are very scalable.
SIP reuses Internet components that are used by other Internet applications, such as elements of HTTP and SMTP. SIP both integrates and delivers services to the current, actual location of the user. SIP applications integrate well with existing Internet applications such as Web browsing, e-mail, video-conferencing, voice calls, instant messaging, and so on.
The following features make SIP an ideal choice as a platform for service creation:
Based on HTTP—SIP uses a familiar text-based request/response model, and using a similar format for encoding protocol messages.
Uses URLS for addressing—SIP uses URLs or e-mail addresses for addressing, enabling flexible redirection of messages.
SMTP-like routing—SIP messages are routed very similarly to e-mail messages.
Instant messaging—SIP is good for delivering instant messages. SIP also features a protocol for user Presence information, and a registrar server for tracking a user's current location and online status. The combination of capable instant message delivery and up-to-date management of Presence information makes SIP an ideal platform for instant messaging.
Forward compatible—SIP re-purposes existing infrastructure to provide new services, for example, using a VoIP infrastructure to provide online gaming.
Easy to develop—The process of developing SIP Servlet applications is very similar to the process of developing HTTP Servlet applications. SIP messages are human readable, and SIP services can be developed without any specialized knowledge.
Reuses applications—Simple SIP applications can be combined to provide complex services.
Oracle Communication and Mobility Server (OCMS) is a carrier-grade SIP application environment for the development, 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 developed and 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 out-of-the-box, including a Presence Server, a combination Proxy and Registrar server, and a SIP message routing 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 is distinguished by its standards-based, high performance 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:
Development and Testing—OCMS provides Java APIs enabling fast development of SIP applications. A SIP client and client Web Services APIs are provided for testing the SIP platform from end to end. Diameter APIs are provided to enable charging and profile lookup in the IP Multimedia Subsystem.
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. The administrator console enables managing the SIP servlet life cycle, and ensuring that users who access a URL are permitted to do so.
Authentication and Security—User, role, and policy data can be stored on an Oracle TimesTen database, 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—For logging and monitoring SIP applications, the OCMS provides Log4J.
Oracle Communication and Mobility Server architecture is composed of three layers:
The Proxy layer includes a load balancer and the OCMS Edge Proxy Server. The load balancer provides a unique public address to which SIP requests are sent. Upon arrival, the load balancer distributes SIP requests either to the OCMS Edge Proxy Server, or directly to an OCMS SIP Server.
The SIP-unaware load balancer distributes requests to OCMS nodes based on the capacity and 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.
Most load balancers, however, are not SIP-aware, meaning that they are unaware of the content of the traffic they forward, such as the sender and recipient. The OCMS Edge Proxy provides a SIP-aware front end to a typical load balancer, proxying SIP requests to a particular OCMS SIP Server. The Edge Proxy thus 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 performant 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.
The Data layer is typically composed of a highly available, high performance in-memory 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.
There are two types of OCMS deployments:
For more information on configuring highly available OCMS deployments, see Chapter 3, "Deployment Topologies".
The OCMS single node deployment runs on a single instance of OC4J application server. The application server's SIP Servlet container hosts a home-grown SIP Servlet application or combination SIP and HTTP Servlet application. A single node deployment is not highly available, and is therefore suited for development, testing, and low-volume deployments.
A basic cluster is a configuration appropriate for small and medium scale deployments, consisting of a number of SIP Application Server instances with session state replicated among all nodes. Each SIP Application Server instance runs on a separate physical node. By increasing the number of nodes, a basic cluster provides scalability and availability. In the event of a failed node, another node takes over, minimizing downtime. A clustered OCMS deployment is easily scalable, such that adding additional nodes enables OCMS to handle a greater number of transactions.
SIP Servlet session data is replicated among nodes. This is useful in the event of a failure, where a designated node takes over the session data of the failed node.
Figure 1-2 Oracle Communication and Mobility Server Clustered Deployment
This section discusses the OCMS deployment types:
OCMS is the SIP Application Server component of a 3GPP IP Multimedia Subsystem, or IMS network. An IMS network is a Next Generation Networking architecture for telecom operators providing multimedia services. IMS is an open, standards-based architecture that runs over IP, and implements a VoIP solution using SIP as the main signalling protocol. The network supports both existing packet- and circuit-switched systems as well as current and future services such as SIP applications and, presumably, any other IP-based services that exist or have yet to be developed. By using standardized, open IP protocols, IMS aims to provide seamless roaming among mobile, public WiFi and private networks for a wide range of services and devices. IMS is designed to enable operators to control and track services, allowing for time-, packet-, and service-based charging.
The IMS architecture is composed of SIP proxies known as Call/Session Control Functions, or CSCFs, and a Home Subscriber Server, or HSS. The main components of an IMS network are:
Proxy Call/Session Control Function (P-CSCF)—The P-CSCF is the first point of contact into the IMS network, forwarding all SIP requests from subscribers to the network regardless of their destination.
Interrogating Call/Session Control Function (I-CSCF)—The I-CSCF matches incoming subscriber requests with the correct S-CSCF using data from the Home Subscriber Server (HSS). During registration, the I-CSCF assigns subscribers to an S-CSCF.
Serving Call/Session Control Function (S-CSCF)—As its name suggests, the S-CSCF provides services to subscribers following registration of subscribers to an S-CSCF. The S-CSCF handles both incoming and outgoing sessions associated with a particular subscriber.
SIP Application Server (OCMS)—The SIP Application Server hosts SIP applications and services within the IMS network. OCMS provides a cluster of managed SIP Servlet Containers that run OCMS SIP Servlet applications such as Presence or home-grown applications.
Home Subscriber Server (HSS)—The HSS stores information linking subscribers and their profiles with their associated S-CSCF nodes. The HSS also stores information regarding services accessible to any given subscriber, and where subscribers can be reached.
The IMS network can be divided into three planes, namely the service or application plane, the control or signalling plane, and the transport or user plane. OCMS is located in the application plane, as shown in Figure 1-4.
Figure 1-4 The Three Planes of the IMS Network
As illustrated by Figure 1-4, the IMS network uses SIP signalling to accomplish the following:
Handling a variety of network traffic
Authorizing subscribers and managing sessions
Managing calls
Providing services to subscribers
Managing charging and billing
Services typically provided by an IMS network include:
Caller ID services
Call waiting, call holding, call forwarding, call transfer
Call blocking services
Push to talk
Lawful interception
Announcement services
Conference call services
Voicemail, text-to-speech, speech-to-text
Location based services
SMS, MMS
Presence information, instant messaging
When used in the context of an IMS network, OCMS acts as the service layer within the IMS network, hosting SIP applications that provide services to end users. The OCMS Edge Proxy distributes incoming SIP requests to OCMS nodes, assigning each request to a particular node. Each OCMS node handles incoming SIP requests and outgoing SIP responses. Outgoing responses return to the correct Edge Proxy, which sends SIP traffic to the IMS core network. The IMS core network, in turn, sends responses back to the end users.
Figure 1-5 OCMS as Part of an IMS Network
Another way to deploy OCMS is in place of a vanilla SIP network. In this scenario, OCMS comprises the SIP network itself. As shown in Figure 1-6, is composed of three main layers:
Proxy layer—Including a SIP-unaware load balancer and one or more Edge Proxy servers.
Application layer—Including one or more OCMS application servers running a SIP Servlet container. The SIP Servlet container manages SIP applications such as the OCMS Presence Server, Proxy/Registrar, Application Router, and so on. Other home-grown SIP and merged SIP/HTTP applications also run on the SIP Servlet container.
Data layer—Includes a replicated, in-memory database where user, authentication, and location data are stored and accessed. These data are used to register and authenticate users, as well as deliver SIP messages to the correct destination.
Figure 1-6 OCMS Deployed as a SIP Network
When deployed as a SIP network, OCMS has much the same functionality as a full-scale IMS network, but on a smaller scale and at a lesser cost. Deploying OCMS as a SIP network enables the following:
Handling SIP traffic originating from a variety of clients, including PCs, PSTN phones, SIP-enabled mobile phones.
Proxying incoming SIP messages to OCMS application servers, and other SIP enabled nodes such as media servers and other SIP proxies
Managing user or session connections to specific application servers in a clustered OCMS environment
Registering user data and location, storing user profiles
Routing SIP messages through a chain of applications, and ensuring that messages arrive at the correct destination
Registering, storing, and retrieving user presence information
Figure 1-7 illustrates the logical system components of OCMS:
Figure 1-7 Oracle Communication and Mobility Server
The OCMS components are as follows:
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-8 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-10 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-12 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. Registration data is stored in an Oracle TimesTen In-Memory Database (Oracle TimesTen) database. A given subscriber might connect to OCMS using a client at home or work, for example. 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, audio and video capability, and so on.
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
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.
As illustrated in Figure 1-14, 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-15 How the Presence Server Works
Suppose a user's presence information has changed. 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. For more information on configuring the Application Router, see "Configuring 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-16 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-17). 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-17). Otherwise, the Application Router routes the SIP request to uri.3, and so on.
Figure 1-17 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.
Diameter is used for charging and profile lookup (Home Subscriber Server) in the IMS.
The Diameter protocol provides the following features:
Connection and session management
Reliable delivery of attribute value pairs (AVPs)
Agent support for proxy, redirect, and relay servers
APIs for developing applications such as user authentication, configuration of permissions, and basic accounting services
Oracle's Diameter component includes the following IMS interfaces:
The Sh interface operates between the SIP Application Server and the HSS network elements in the IMS. The Sh interface enables:
Downloading and updating user data
Requesting and sending notifications when changes are made to user data
Diameter provides online and offline interfaces for online billing or charging, called Ro and Rf, respectively.
Ro is used for charging services in real-time (as the service occurs). Based on the IETF Credit Control Application (RFC 4006), the Ro interface uses the Credit-Control command (CCR/CCA).
Rf is used to transfer charging data that has no affect on services being rendered in real-time. The Rf interface is based on the accounting functionality of the IETF-diameter base (RFC 3588). Rf uses the accounting command (ACR/ACA).
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 an Oracle TimesTen database, 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 an Oracle TimesTen database or 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.
