|
|
Welcome to Oracle Communications Converged Application Server Release 4.0! Oracle Communications Converged Application Server integrates SIP Servlet 1.1 technology with Java EE5 (JEE5) and other leading Internet standards to provide a reliable framework for developing highly available, scalable, and secure telecommunications applications. Oracle Communications Converged Application Server’s seamless integration of disparate, heterogeneous platforms and applications enables your network to leverage existing software investments and share the enterprise-class services and data that are crucial to building next-generation telephony applications.
The following sections describe some of the new features and changes made in Oracle Communications Converged Application Server Release 4.0:
This section describes new features and functionality introduced in Oracle Communications Converged Application Server.
Oracle Communications Converged Application Server is deployed on the core Oracle WebLogic Server 10g Release 3 product, which introduces many key features such as an improved Administration Console, fast and flexible deployment model, new diagnostic capabilities, and EJB 3.0 support. See What's New in WebLogic Server in the Oracle WebLogic Server 10g Release 3 documentation.
Supporting files for Oracle Communications Converged Application Server are now stored in a WLSS_HOME directory within the BEA home directory (for example, c:\bea\wlcserver_10.3). This is separate from the required Oracle WebLogic Server 10g Release 3 files, which are stored in the WL_HOME directory (for example, c:\bea\wlserver_10.3).
The revised documentation distinguishes between the WLSS_HOME and WL_HOME directories when appropriate.
Oracle Communications Converged Application Server provides a robust SIP container that is compliant with the SIP Servlet 1.1 specification (JSR 289). The SIP Servlet 1.1 specification introduces many new features compared to the 1.0 specification, including:
See the SIP Servlet v1.1 specification for a complete guide to the new SIP Servlet API and container functionality. See Porting Existing Applications to Oracle Communications Converged Application Server in Developing SIP Applications for details about backward compatibility and porting existing v1.0 SIP Servlets.
In addition to the metadata annotations described in the SIP Servlet 1.1 specification, Oracle Communications Converged Application Server supports a subset of annotations from JSR 250 and JSR 154 for deployment and resource injection. The supported annotations are described in Table 1-1 and Table 1-2.
Declares the security role to use for executing the SIP Servlet. This annotation functions in the same manner as the
run-as deployment descriptor element. See
JSR 250.
|
|
Declares security roles used by the application. See
JSR 250.
|
|
Identifies a single initialization method to be called after a dependency injection. The specified method is called before the class is made available. See
JSR 250.
|
|
Identifies a method to be called when the container is removing the application. See
JSR 250.
|
Declares a reference to a resource in a class, method, or field. This enables you to inject the
SipFactory, TimerService, and SipSessionUtil objects. See
JSR 250.
|
|
Declares multiple @Resource annotations. See
JSR 250.
|
|
Declares a reference to an EJB component. This annotation functions in the same manner as the
ejb-ref or ejb-local-ref deployment descriptor elements. See
JSR 154.
|
|
Declares a reference to a Web Service. This annotation functions in the same manner as the
resource-reference deployment descriptor element. See
JSR 154.
|
See also the SIP Servlet 1.1 specification for information about the new SIP Servlet-related annotations supported in this release, such as:
In order to improve compliance with RFC 3265, Oracle Communications Converged Application Server now permits applications to receive unsolicited NOTIFY messages and correlate them with a subscription. Prior to this release, Oracle Communications Converged Application Server would reject an unsolicited NOTIFY message with a 481 Subscription does not exist message.
Oracle Communications Converged Application Server meets the requirements for obtaining and using Globally-Routable User Agent URIs (GRUU) as described in the latest draft-ietf-sip-gruu-15: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP).
Oracle Communications Converged Application Server uses the new SNMP implementation provided by Oracle WebLogic Server 10g Release 3. In order to configure SNMP, you must create a dedicated Server SNMP agent for each engine and SIP data tier server (and optionally, the Administration Server) in your domain.
Oracle Communications Converged Application Server does not automatically increment the SNMP port number if the port is already in use. Instead, you must ensure that each agent is configured with a unique port number. In addition, the -DWLSS.SNMPAgentPort Java option cannot be used to override the SNMP agent configuration.
See Configuring SNMP in the Operations Guide.
The diagnostic monitors and diagnostic actions provided in Oracle Communications Converged Application Server are now prefixed with occas/. For example, the WebLogic SIP Server 3.1 Sip_Servlet_Before_Service monitor is now named occas/Sip_Servlet_Before_Service. You must update any existing diagnostic configuration files or applications that reference the non-prefixed names before they can work with Oracle Communications Converged Application Server.
See Using the WebLogic Server Diagnostic Framework (WLDF) in the Operations Guide.
Oracle Communications Converged Application Server example applications are no longer installed by default. To install the example applications, perform a custom installation and select the examples from the product component list.
When installed, Oracle Communications Converged Application Server examples are placed in the WLSS_HOME/samples directory (for example, ~/bea/wlcserver_10.3/samples/sipserver/examples).
A dedicated examples domain template is not included in this release. Instead, create a basic single-server domain using the sipserverdomain.jar template, then build and deploy individual example applications as needed.
See the Installation Guide for information about installing the examples and configuring a new domain. See the examples documentation installed at WLSS_HOME/samples/sipserver/examples/src/index.html for information about building and running the examples.
This section summarizes key new features and functionality that were introduced in the previous releases, WebLogic SIP Server 3.0 and 3.1.
WebLogic SIP Server now integrates with the Weblogic Diagnostic Framework (WLDF) to provide improved data collection and logging, watches and notifications, diagnostic image capture, and code instrumentation. See Using the WebLogic Diagnostic Framework (WLDF) in the Operations Guide.
WebLogic SIP Server 3.1 honors the rport parameter described in
RFC 3581 for symmetric response routing. When a message is received that has the rport parameter, the server responds using the remote UDP port number from which the message was received, rather than the port number specified in the Via header. You can also configure WebLogic SIP Server to automatically add the rport parameter to Via headers when acting as a UAC. See
enable-rport in the Configuration Reference Manual.
WebLogic SIP Server 3.1 now enables you to configure the exact domain(s) for which the server is responsible. Domain alias configuration avoids potential proxy problems and clarifies the domain handling support for a given server installation. See domain-alias-name in the Configuration Reference Manual.
You can now monitor the behavior of WebLogic SIP Server network channels (sip, sips, diameter, diameters, and diameter-sctp channels) using the Administration Console. To monitor SIP and Diameter channels:
WebLogic SIP Server channels display statistics only for the Connections, Messages Received, Messages Sent, Bytes Received, and Bytes Sent attributes.
WebLogic SIP Server uses encoded URIs to identify the call states and application sessions associated with a message. When an application is undeployed or upgraded to a new version, incoming requests may have encoded URIs that specify “stale” or nonexistent call or session IDs. In WebLogic SIP Server 3.1, you can configure the action that the server takes when it encounters stale session data in a request. See stale-session-handling in the Configuration Reference Manual.
WebLogic SIP Server may add one or more SIP headers and parameters to existing SIP messages in order to support various features. You must ensure that all network functions allow these headers and parameters to pass unchanged to SIP Server instances. Alternately, Session Border Control functions may archive and restore this information as necessary.
Table 1-3 and Table 1-4 describe the information that WebLogic SIP Server may add to SIP messages.
(New in Version 3.1.) Records the local address on which an incoming request was received by a stateless proxy. This header is required for handling the stateless proxy use case with
rport support.
|
|
(New in Version 3.1.) Records the local port on which an incoming request was received by a stateless proxy. This header is required for handling the stateless proxy use case with
rport support.
|
|
WebLogic SIP Server can be installed in a geographically-redundant configuration for customers who have multiple, regional data centers, and require continuing operation even after a catastrophic site failure. The geographically-redundant configuration enables multiple Weblogic SIP Server installations (complete with engine and SIP data tier clusters) to replicate call state transactions between one another. Administrators can then choose to redirect all network traffic to the secondary, replicated site to minimize lost calls if they determine that a regional site has failed. See Configuring Geographically- Redundant Installations in Configuring and Managing WebLogic SIP Server.
In addition to the Diameter Sh protocol provider introduced in WebLogic SIP Server 2.2, version 3.0 includes new providers for the Ro and Rf protocols. The base Diameter protocol implementation is also now available for developers who want to implement additional Diameter applications. See the following links in Developing Applications with WebLogic SIP Server for more information:
The engine tier now caches a portion of the SIP call state data available in SIP data tier replicas. When used in combination with a SIP-aware load balancer, the cache increases the performance of accessing call state data. See Enabling the Engine Tier Cache in Configuring and Managing WebLogic SIP Server.
WebLogic SIP Server 3.0 enables you to store long-lived call state data in an Oracle RDBMS in order to conserve RAM. The SIP data tier persists a call state’s data to the RDBMS after the call dialog has been established, and retrieves or deletes the persisted call state data as necessary to modify or remove the call state. Oracle also provides an API for application designers to provide “hints” as to when the SIP data tier should persist call state data. See Storing Call State Data in an RDBMS in Configuring and Managing WebLogic SIP Server.
WebLogic SIP Server can be licensed in a “real time” configuration, which uses the JRockit deterministic garbage collector to greatly improve latency performance for SIP transactions. To enable this garbage collector, see Using JRockit Deterministic Garbage Collection in the Configuration Guide.
WebLogic SIP Server 3.0 introduces application upgrade support for converged SIP/HTTP applications. Application upgrade support now closely models the upgrade support available in WebLogic Server 9.2, and provides for a SIP “administration channel” that can be used to securely testing applications in a production environment. See Upgrading Deployed SIP Applications in the Operations Guide.
| Note: | As part of the new upgrade functionality, SipApplicationRuntimeMBean is now deprecated for obtaining information about the application name and version string. Use ApplicationRuntimeMBean instead. |
WebLogic SIP Server supports the SCTP transport protocol on certain operating systems for Diameter network traffic. See Configuring Diameter Client Nodes and Relay Agents in Configuring Network Resources.
WebLogic SIP Server 3.0 now supports DNS for resolving the transport, IP address and port number of a proxy required to send a SIP message as described in RFC 3263. DNS may also used when routing responses in order to resolve the IP address and port number of a destination. Prior to version 3.0, DNS resolution had to be performed by the individual UA or proxy application.
See Enabling DNS Support in Configuring Network Resources.
WebLogic SIP Server supports IPv6 for external network interfaces as described in RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. To use IPv6, your underlying operating system must support the protocol, and you must configure IPv6 network channels on all engine tier server nodes. See IPv4 and IPv6 in Configuring Network Resources.
The Administrator can optionally configure the contents of the Server header that WebLogic SIP Server inserts into SIP message bodies. The entire header contents can be omitted to reduce the message size for wireless networks, or it can be set to an arbitrary string value. Prior to version 3.0, the header was always populated with the name and version of the WebLogic SIP Server instance. See server-header and server-header-value in the Configuration Reference Manual.
WebLogic SIP Server provides flexible configuration parameters and APIs for controlling whether generated SIP messages use compact or long header forms. Header form rules can be set at three different levels:
sipserver.xml file. See
use-header-form in the Configuration Reference Manual.WlssSipServletMessage interface provides the setUseHeaderForm method to specify long or compact headers for a given SIP message. See
Using Compact and Long Header Formats for SIP Messages in Developing Applications.SipServletMessage interface provides the setHeader method to set a given header name a specific value. See the JSR 116 JavaDoc for SipServletMessage.
WlssSipServletResponse.setUseHeaderForm can be used in combination with SipServletMessage.setHeader and the container-level configuration to customize header formats. See
Using Compact and Long Header Formats for SIP Messages in Developing Applications for information about how the different settings interact with one another.
WebLogic SIP Server extends the javax.servlet.sip.TelURL interface with the com.bea.wcp.sip.WlssTelURI interface. The extended interface enables applications to resolve Tel URLs present in the user portion of a SIP URI. The API parses a Tel URL into a domain name using the standard suffix, e164.arpa, as described in RFC 3761. It then performs a DNS NAPTR record lookup to produce an ENUM NAPTR record set.
For example, for a Tel URL domain name of 4.3.2.1.5.5.5.5.1.4.1.e164.arpa, the API performs a DNS lookup to retrieve an ENUM NAPTR record set similar to:
$ORIGIN 4.3.2.1.5.5.5.5.1.4.1.e164.arpa
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!"
IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!"
Methods in the WlssTelURI interface return either the full ENUM record set, an array of SIP URIs present in the record set, or only the highest-precedence SIP URI present in the record set. See com.bea.wcp.sip.WlssTelURI in the JavaDoc.
WebLogic SIP Server 3.0 supports deployment of applications in SAR file format. The SAR file is similar in format to WAR files, and can contain deployment descriptor information for both HTTP and SIP Servlets. SAR files need not include a weblogic.xml deployment descriptor.
WebLogic SIP Server includes a public profile service API, com.bea.wcp.sip.profile.API, that you can use to create profile provider implementations. A profile provider performs the work of accessing XML documents from a data repository using a defined protocol. Deployed SIP Servlets and other applications need not understand the underlying protocol or the data repository in which the document is stored; they simply reference profile data using a custom URL using the provider API, and WebLogic SIP Server delegates the request processing to the correct provider. See
Developing Custom Profile Providers in Developing Applications with WebLogic SIP Server.
WebLogic SIP Server includes a new connection pooling mechanism to minimize unnecessary communication with a Session Border Control (SBC) function or Serving Call Session Control Function (S-CSCF). The server multiplexes a fixed pool of connections to a configured SBC or S-CSCF instead of repeatedly terminating and recreating connections during operation. See connection-reuse-pool in the Configuration Reference Manual.
WebLogic SIP Server meets the requirements for obtaining and using Globally-Routable User Agent URIs (GRUU) as described in draft-ietf-sip-gruu-10: Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP).
To specify a GRUU for WebLogic SIP Server to use when acting as a network element, see globally-routable-uri in the Configuration Reference Manual.
|