|
|
Welcome to BEA WebLogic SIP Server 3.1! WebLogic SIP Server™ integrates SIP Servlet technologies with J2EE 1.4 and 1.3 and other leading Internet standards to provide a reliable framework for developing highly available, scalable, and secure telecommunications applications. WebLogic SIP 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 the new features and changes made in the WebLogic Server 3.1 general release and in intermediate releases:
This section describes new features and functionality introduced in WebLogic SIP Server 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-1 and Table 1-2 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.
|
|
This section describes new features and functionality introduced in WebLogic SIP Server 3.0.
WebLogic SIP Server 3.0 is deployed on the core BEA WebLogic Server 9.2 product, which introduces many key features such as J2EE 1.4 compliance, improved systems management, and higher performance, scalability, and availability. See What's New in WebLogic Server 9.2 in the WebLogic Server 9.2 documentation.
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 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 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 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. BEA also provides an API for application designers to provide “hints” as to when the 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 used with the JRockit deterministic garbage collector to greatly improve latency performance for SIP transactions. To use WebLogic SIP Server with 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.
| Note: | The Windows XP IPv6 implementation does not support dual mode sockets, and cannot be used with any available JVMs to support IPv6. Using IPv6 with a network channel throws the following exception with either the Sun or JRockit JVMs: |
| Note: | Address family not supported by protocol family: bind. |
| Note: | For more information see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230761 |
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.
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.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.
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.
This section describes new features and functionality introduced in WebLogic SIP Server 2.2.
WebLogic SIP Server 2.2 now supports the following additional RFCs and specifications:
See Standards Alignment in the Technical Product Description for a full description of RFC compliance.
WebLogic SIP Server 2.2 introduces a variety of changes in order to comply better with the IMS Application Server specifications described in 3GPP 24.229 Rel 7.0.0:
orig parameter when creating new requests based on an identity specified in the top route header. WebLogic SIP Server provides a new com.bea.wcp.sip.util.TransportUtil class to help an application determine if a particular request was generated locally, so that the application can add the orig parameter if necessary. See the
WebLogic SIP Server JavaDoc.Request-Disposition, Accept-Contact, and Reject-Contact headers, which can be used by callers to define preferences for how a message should be processed. See
RFC 3840.P-Charging-Vector or P-Charging-Function-Address header is present in a given message, and automatically strips any such header if a message is proxied to an untrusted host. See
RFC 3455.sipserver.xml file includes a new element, route-header which you can use to statically define the S-CSCF route header to be added to new outgoing requests originated from the WebLogic SIP Server container. See
route-header in the Configuration Reference.WebLogic SIP Server implements the Diameter Sh interface as a Web Application that you can deploy to the server. Sh interface functions are implemented as a provider that transparently generates and responds to the Diameter command codes defined in the Sh application specification. A higher-level profile service API enables SIP Servlets to manage user profile data as an XML document using XML Document Object Model (DOM). WebLogic SIP Server supports converged SIP and Diameter applications. See Using the Profile Service API (Diameter Sh Interface) in Developing Applications with WebLogic SIP Server.
WebLogic SIP Server also provides a Diameter relay node application, which you can configure for use when connecting to an HSS. An HSS simulator application is included for development or testing purposes. See Configuring Diameter Sh Client Nodes and Relay Agents in Configuring Network Resources.
As described in
RFC 3311, the SIP UPDATE method enables a UAC to update the parameters of a session, such as the media streams or codecs used for communication. To fully support the behavior described in RFC 3311, WebLogic SIP Server now automatically generates a 500 response with a Retry-After header value if a deployed B2BUA receives an UPDATE request, relinquishes control (returns control from the service() method), and then subsequently receives another UPDATE. This change was made to comply with section 5.2 of RFC 3311, which requires a UAS to return a 500 response and Retry-After header if a second UPDATE is received before making a final response to a prior UPDATE.
RFC 3327 defines the extension header field, Path, which provides a mechanism for multiple SIP proxies to add themselves to a defined path between a UAC and registrar. The Path header functions similar to the SIP Record-Route header, but is defined outside of a Dialog.
WebLogic SIP Server provides API support to enable multiple proxy applications to add themselves to a Path header in a REGISTER request. A deployed registrar application could then manage and maintain the Path headers.
To provide this support, WebLogic SIP Server extends the javax.servlet.sip.Proxy interface with com.bea.wcp.sip.WlssProxy. The extended interface provides getter/setter methods for the AddToPath attribute, which determines whether proxyTo() operations automatically add a Path header to the proxied request. The interface also provides a method to retrieve the complete URI defined in the Path header for a request, so that the proxy can add arbitrary attributes to the header.
See the com.bea.wcp.sip.WlssProxy JavaDoc for more information.
Note that WebLogic SIP Server does not provide a method for a proxy application to push an arbitrary Path entry (as well as its own Path as supported in the extended API).
WebLogic SIP Server supports the SIP refer-to header and REFER method for applications that implement services such as unattended or attended call transfer, and third-party call control.
A “REFER” request can come within an existing dialog, or out of dialog. If REFER arrives out of a dialog, it starts a new dialog. WebLogic SIP Server creates an implicit subscription after the 202 Accepted response is sent, and the dialog remains active until the subscription expires. The subscription and original dialog are maintained until a subsequent NOTIFY or method explicitly terminates the subscription. The subscription for REFER can also be terminated with a SUBSCRIBE request sent with expiration = 0.
If a NOTIFY request doesn't find a REFER subscription it is rejected with a 481 status response.:
Because of the implicit subscription described above, WebLogic SIP Server maintains a SIP dialog after the REFER method is used even if a subsequent BYE message is sent. This behavior ensures that call transfer applications can re-establish the original session (via an INVITE) if the call transfer fails. See Section 2.4 Transfer - Unattended in http://tools.ietf.org/wg/sipping/draft-ietf-sipping-service-examples/draft-ietf-sipping-service-examples-09.txt for more information.
WebLogic SIP Server extends the JSR 116 SipServlet class to provide a convenience method for handling SIP REFER requests. To provide a handler your own SIP Servlet, extend com.bea.wcp.sip.WlssSipServlet and implement the doRefer() method. For example:
package myapp;
import javax.io.IOException;
import javax.servlet.ServletException;
import com.bea.wcp.sip.WlssSipServlet;
public class MyApp extends WlssSipServlet {protected void doRefer(SipServletRequest req)
throws ServletException, IOException {
// Respond to REFER method...
}
}
The authentication process for SIP requests having the P-Asserted-Identity header was changed to conform to the behavior described in 3GPP TS 24.229: IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). In version 2.2, if the SIP message contains a Privacy header with either an “id” or “user” value, the user is treated as being anonymous. Previously, only the “id” value was considered. See Configuring P-Asserted-Identity Assertion in Configuring Security.
WebLogic SIP Server 2.2 authentication behavior meets the requirements of 3GPP TS 24.229 except as follows:
auth-method configured in the login-config element of the application’s sip.xml descriptor. This is done instead of immediately returning a 403 Forbidden response.HttpServletRequest.isUserInRole() method to determine if a user is authorized to access a particular resource. If the user is not authorized, the application can construct a “fake” 2xx response to return to the UAC and mask the authorization failure.
WebLogic SIP Server now supports the X-3GPP-Asserted-Identity header for HTTP authentication as specified in
3GPP TS 33.222. Two new security providers, X3gppAssertedIdentityAsserter or X3gppAssertedIdentityStrictAsserter are available to enable and configure support. See
Configuring 3GPP HTTP Authentication Providers in Configuring Security.
WebLogic SIP Server now supports the development and deployment of converged applications that combine SIP protocol functionality with features from J2EE such as HTTP sessions, Enterprise JavaBeans (EJBs), and Java Message Service (JMS).
An extended API is provided to help you obtain SipApplicationSession objects and to create and associate HTTP sessions with SipApplicationSession objects.
An extended API is also provided to help non-SIP Servlets concurrently modify a SipApplicationSession object in a replicated environment. See
Developing Converged Applications in Developing Applications with WebLogic SIP Server. See also the converged application example installed with WebLogic SIP Server (wlss_home/samples/server/examples/src/convergence/readme.html).
You can upgrade a deployed SIP application to a different version without losing calls that the application is current processing. WebLogic SIP Server supports application upgrades by allowing two different versions of the same application to be deployed simultaneously. The server itself automatically routes new calls to the latest-deployed application version, while directing messages for already-established calls to the older application version. After a period of time, the new application version processes all SIP messages, while the older version processes no messages and can be safely undeployed. See Upgrading Deployed SIP Applications in the Operations Guide.
A new failover detection mechanism is provided to improve failover performance in the event that a data tier server process immediately fails, or the network connection between an engine and data tier server is physically compromised. See Improving Failover Performance for Physical Network Failures in Configuring and Managing WebLogic SIP Server.
WebLogic SIP Server now supports SIP applications that indirectly specify the content of the SIP message body (for example, using an HTTP URL). Content indirection is generally used move large message bodies out of the SIP signalling network, or to allow bandwidth-constrained applications to determine whether or not they should download the additional content. Instead of providing the content directly in the message, the message body contains only a link to the specified content and metadata that specifies the size and type of information to be retrieved.
To support content indirection, WebLogic SIP Server provides an API to enable SIP Servlets to easily determine whether or not a message uses content indirection. For messages that include indirect content, the API provides for easy retrieval of the content metadata. See Using Content Indirection in SIP Servlets in Developing Applications with WebLogic SIP Server. See also the draft specification for content indirection at http://tools.ietf.org/wg/sip/draft-ietf-sip-content-indirect-mech/draft-ietf-sip-content-indirect-mech-05.txt.
WebLogic SIP Server supports reliable provisional responses (defined in
http://www.ietf.org/rfc/rfc3262.txt). For a particular dialog there may be multiple reliable provisional responses at a given time. For this reason, the existing SipSession.createRequest() method in the SIP Servlet API is not sufficient for handling PRACK. Also, the basic doAck() method cannot be used for generating PRACK from the reliable provisional responses themselves.
Because of these issues, WebLogic SIP Server provides two alternatives for creating PRACK from the reliable provisional responses themselves:
WlssSipServletResponse.createPrack()—SIP Servlets can acknowledge a provisional response (and stop retransmissions of provisional responses) by creating a PRACK request using the com.bea.wcp.sip.WlssSipServletResponse.createPrack() method. This method returns a PRACK request having the RAck header sequence number of the response that is being acknowledged.SipServletResponse.createAck()—The implementation of the JSR116 SipServletResponse.createAck() method was modified to automatically return a PRACK request instead of an ACK request for provisional (non-2xx) responses.
See the WebLogic SIP Server
JavaDoc for com.bea.wcp.sip.WlssSipServletResponse.
WebLogic SIP Server provides limited support for modifying Contact header parameters, which is required by the 3GPP IMS specification. In version 2.2, applications can use the following SipServletMessage method call to return a Contact address object whose parameters can be modified:
SipServletMessage.getAddressHeader(“Contact”);
The object returned allows only limited modification of parameters in this release. Specifically, the object does not permit applications to add a URI user part to the Contact header, or to modify parameters that could influence the network interface that the SIP Container uses for transmitting messages.
In addition to the above change, the code was modified to allow a UAS to modify Contact header parameters for a 200 response to an OPTIONS request, as required in RFC 3261.
WebLogic SIP Server 2.2 introduces a number of new and revised example applications. Source and build files for the new examples are installed at WLSS_HOME\samples\server\examples\src, where WLSS_HOME is the directory in which you installed WebLogic SIP Server (for example, c:\bea\wlss220).
See the WLSS_HOME\samples\server\examples\src\index.html file for information about all examples installed with WebLogic SIP Server.
WebLogic SIP Server 2.2 introduces a new runtime MBean, SipServletSnmpTrapRuntimeMBean, that enables applications to easily generate SNMP traps. The WebLogic SIP Server MIB contains seven new OIDs that are reserved for traps generated by an application. See
Generating SNMP Traps from Application Code in Developing Applications with WebLogic SIP Server.
A new configuration element in sipserver.xml, default-servlet-name, enables you to specify a default SIP Servlet that the container calls for incoming initial requests when no other Servlet can be matched via servlet-mapping definitions in sip.xml. See
default-servlet-name in the Configuration Reference.
The default-servlet-name element cannot be modified using the Administration Console. You must modify this value directly in sipserver.xml using a text editor, and redeploy the sipserver/config Web Application to all engine tier servers, to use this feature. You can redeploy the config Web Application using either the Administration Console or the weblogic.Deployer utility. To redeploy from the Administration Console:
To redeploy using the weblogic.Deployer utility, enter a command to:
java java weblogic.Deployer -username weblogic -password weblogic -verbose
-targets config@BEA_ENGINE_TIER_CLUST -name sipserver -adminurl
t3://localhost:7001 -redeploy"
This section details features that were introduced between WebLogic SIP Server 2.1 and earlier versions. This section includes information about the following:
The architecture of WebLogic SIP Server 2.1 was dramatically improved to provide increased performance, higher availability, and flexibility in configuring available resources. The most visible change in architecture is in WebLogic SIP Server’s use of two separate clusters, referred to as the engine tier and data tier, that can be sized independently of one another to increase the call throughput or availability of an installation. (Development installations and small production installations can also use a single server instance as needed.) See Overview of the WebLogic SIP Server Architecture for more information about these changes.
| WARNING: | When you configure a domain with multiple engine and data tier servers, you must accurately synchronize all server system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly. See Configuring NTP for Accurate SIP Timers for more information. |
SIP Servlets developed for previous versions of WebLogic SIP Server must observe new coding practices and requirements in order to operate in the version 2.1 distributed environment:
doxxx method of a SIP Servlet is invoked by the SIP Servlet container, the container automatically locks the associated call state. If the doxxx method spawns additional threads or accesses a different call state, deadlock scenarios can occur.distributable tag, in order to deploy them to a cluster of engine tier WebLogic SIP Server instances. The distributable tag is not required and is ignored if you deploy to a single combined-tier (non-replicated) WebLogic SIP Server instance.These and other porting requirements are described in Requirements and Best Practices for WebLogic SIP Server Applications in Developing Applications with WebLogic SIP Server.
WebLogic SIP Server now supports the P-Asserted-Identity SIP header as described in RFC3325. See
Trusted Host Forwarding with P-Asserted-Identity in Configuring Security.
WebLogic SIP Server now supports Client-Cert authentication as well as BASIC and Digest authentication. See
Configuring Client-Cert-Based Authentication for SIP Applications in Configuring Security. Client-Cert authentication is disabled by default; the switch to enable is defined in ClusterMBean and ServerMBean.
WebLogic SIP Server 2.1 now includes an RDBMS (JDBC) Digest Identity Assertion provider as well as the LDAP provider included in previous versions. In addition, both the RDBMS and LDAP providers support reverse-encrypted passwords as well as clear-text and hashed password values. See Configuring Digest Authentication for more information.
The following sections describe changes in the way you configure and manage WebLogic SIP Server 2.1.
The configuration file used to define partitions and replicas in the data tier is now named datatier.xml. In addition, the main XML element defined in the file has changed to data-tier (formerly state-tier). The location of the data tier configuration file has also changed; both datatier.xml and statetier.xml are located in the DOMAIN_DIR/sipserver/config subdirectory, where DOMAIN_DIR is the root directory of the WebLogic SIP Server domain.
Load balancer addresses are no longer defined in the sipserver.xml configuration file. Instead, the load balancer address and port number must be defined in the External Listen Address and External Listen Port fields of a SIP channel on each engine tier server. See
Configuring Load Balancer Addresses in Configuring Network Resources.
When using queue- length-based overload protection controls, WebLogic SIP Server now monitors the sum of the lengths of the sip.transport.Default and sip.timer.Default execute queues, rather than only the length of sip.transport.Default. Also, the default overload configuration initiates overload protection when the combined queue size reaches 200 simultaneous requests, and releases overload control when the combined size falls to 150 simultaneous requests. See
overload in the Configuration Reference.
The schema for sipserver.xml has changed in WebLogic SIP Server. See the
Engine Tier Configuration Reference (sipserver.xml) in the Configuration Reference. Notable changes include:
In addition to schema changes, the location of sipserver.xml has changed in this release. The sipserver.xml is included as part of the sipserver enterprise application that implements the SIP container features of WebLogic SIP Server. See
Overview of WebLogic SIP Server Configuration and Management.
WebLogic SIP Server 2.1 no longer uses the (previously-deprecated) connector element in sipserver.xml for configuring network connections. Instead, all connections are defined using:
Multiple network channels can be defined to support multiple transport protocols or to configure multiple network interfaces on multi-homed server hardware. See the Managing WebLogic SIP Server Network Resources in Configuring Network Resources.
Access logging is no longer configured by defining a filter in the sipserver.xml configuration file. See
Enabling Access Logging in Developing Applications with WebLogic SIP Server for information about the new XML configuration elements.
In previous WebLogic SIP Server releases, if an application called the send() method within a SIP request method such as doInvite(), doAck(), doNotify(), and so forth, the SIP Servlet container immediately transmitted the send() call to the network. In WebLogic SIP Server 2.1, send() calls are instead buffered in the order in which they are called, and transmitted in order only after the control has returned to the SIP Servlet container.
| WARNING: | Applications must not wait or sleep after a call to send(), because the request or response is not transmitted until control returns to the SIP Servlet container. |
WebLogic SIP Server 2.0.2 introduced the following features:
weblogic.xml introduced support for mapping principal and role names to roles defined in sip.xml. See
Securing SIP Servlet Resources.
WebLogic SIP Server 2.0.1 was a restricted release of a BEA product and was subject to change in future releases. The following features were specifically called out as having been deprecated in WebLogic SIP Server 2.0.1:
sipserver.xml, in a future release of WebLogic SIP Server.sipserver.xml may not be used to configure SIP Servlet container features in future releases.
|