![]() ![]() ![]() ![]() ![]() ![]() |
The following table summarizes the issues that were resolved in WebLogic SIP Server 3.1 MP1. See also Table 2-2, “Problems Resolved in Version 3.1,” on page 2-9.
The code was modified to correct the above issues. Ensure that you enable Anonymous Admin Lookup by following these steps:
Also, note that WebLogic SIP Server instances ignore the SNMP port number specified on the SNMP configuration page. Servers use the default port 1610 to start the SNMP agent and, if this port is not available, the port number is incremented until an unused port is discovered. You can specify the starting port number using the
-DWLSS.SNMPPort= port_number startup argument. The server logs display the actual SNMP port on which the server is listening.
|
|
Because of the RFC3261 limitation described at
http://bugs.sipit.net/show_bug.cgi?id=706, transactions could remain in PROCEEDING state and the associated call states were never cleaned up. In certain conditions involving very high loads, this could lead to Out of Memory errors.
|
|
Using the
weblogic.Admin utility to look for the SipServletSnmpTrapRuntime bean caused the following error:
|
|
The WebLogic SIP Server
doAction API could cause unnecessary locking of call state data. For example application code such as:
WlssApplicationSession appSession =
causes the call state to be locked and unlocked once to obtain the application session ID, and then once again to perform the
doAction operation. To address this problem, the following new API was added:
To make use of the new API, replace application code that uses the above pattern with the following pattern:
sessions.doAction(confAppSessionId, new WlssAction() {
sessions.getApplicationSession(confAppSessionId);
|
|
This release improves server performance on Intel Quad Core processors when running in a non-replicated configuration. The code was modified to enable the database persistence flag by default, which in turn enables local serialization of call state data. This setting is ignored for replicated configurations.
|
The following table summarizes the issues that were resolved in WebLogic SIP Server 3.1.
When a SIP request was sent via application code, WebLogic SIP Server immediately started the transaction timer even though the actual message was queued for sending only after the application’s service method ended. If the application code (or the system load) caused a delay in exiting the service method, retransmissions for the request could appear in a shorter amount of time than the configured SIP timers would indicate. (In extreme cases, the application request and its retransmission would appear on the wire at nearly the same time.)
|
|
In previous versions,
setCharacterEncoding() did not throw an UnsupportedEncodingException . Existing Servlet code that called this method and used a catch claus for UnsupportedEncodingException had to be modified before recompiling for deployment to WebLogic SIP Server. This problem was addressed with a code fix.
|
|
While proxying an ACK message, if a
TooManyHopsException was thrown WebLogic SIP Server would attempt to send a response to the ACK. This caused the exception:
<Oct 17, 2006 1:50:18 PM PDT> <Error> <WLSS.Session> <BEA-331412> <Failed to respond 483 to too many hops request. java.lang.IllegalStateException: Cannot createResponse for ACK |
|
WebLogic SIP Server allowed you to deploy SIP applications with deployment descriptors that did not conform to their respective schemas. This could lead to exceptions or other unexpected behavior at runtime. The code was modified to reject application deployments when deployment descriptors do not conform to the schema.
|
|
When proxying a request over TCP, if an
IOException was raised, WebLogic SIP Server logged the exception but did not send a final response upstream. Because of this, a UAC would not know whether an invite request was proxied successfully. The code was modified to detect transport errors while proxying, and create and send a 503 error response upstream in response to such errors.
|
|
If a Servlet used the
load-on-startup deployment descriptor element to initialize the Servlet on startup (rather than on first request), and the init method created a new call state, WebLogic SIP Server would throw the following exception if any partition in the data tier was not yet online:
Unexpected exception com.bea.wcp.sip.engine.server.SetupException: [WLSS.Engine:330027]Failed to initialize "proxy" servlet class test.ProxyServlet java.lang.IllegalStateException: PartitionClient offline |
|
WebLogic SIP Server used a fixed overload duration of 30 seconds. This could cause poor performance and continual overload situations with periodic spikes in
wlss.transport work manager queue. The code was modified to set the initial overload duration to a much shorter 512 milliseconds, and then dynamically increase the duration if necessary in response to recurring overload conditions.
|
|
On Windows platforms, if you installed the WebLogic SIP Server product nested inside of other folders, the Administration Console extension could not load due to the length of the path being too long. To work around the problem, the following environment variable could be set before starting the Administration Server:
|
|
WebLogic SIP Server allowed SIP requests to access the retiring version of a deployed SIP application. This behavior was inconsistent with the base WebLogic Server application upgrade functionality, which disallows HTTP requests to a retiring application. For example, if you retired a converged SIP application, HTTP requests to the application would be rejected while SIP requests were permitted. The code was modified to be consistent with WebLogic Server behavior; the server now disallows SIP requests to a retiring application.
|
|
The server did not register SIP container runtime MBeans with the compatibility MBean server. This would lead to exceptions such as:
javax.servlet.ServletException: Unable to lookup type 'SipServletSnmpTrapRuntime' |
|
When using WebLogic SIP Server with geographically-redundant installations, each write to a secondary site would log an error message similar to:
|
|
WebLogic SIP Server provided no way to configure the timeout duration for SCTP connections. The code was modified to honor a custom channel property,
SctpConnectTimeoutMillis , to configure the property. See
Configuring Custom Timeout, MTU, and Other Properties in Configuring Network Resources.
|
|
WebLogic SIP Server would throw a
NullPointerException if an application used SipServletSnmpTrapRuntimeMBean to generate an SNMP trap outside of a do xxx method. The code was modified to allow trap generation outside of a do xxx method. Note, however, that traps generate outside of a do xxx method use the string “Non Sip-Servlet Scope Application” instead of a Servlet name.
|
|
The Diameter implementation used incorrect values (3 and 4) for the CHECK_BALANCE and PRICE_ENQUIRY values of the
Requested-Action AVP. The code was modified to use the correct values of 2 and 3, respectively, as described in
RFC4006.
|
|
The Diameter implementation did not allow for a Diameter application to receive and process ASR requests. This meant that Diameter applications could not add AVPs to the termination CCR or be notified when a session was finished. The code was modified so that if a
SessionListener is registered, the Diameter implementation passes ASR requests to the application listener for handling. In this case, it is the responsibility of the application to generate CCRs as well as send ASAs.
|
|
WebLogic SIP Server exhibited poor scalability performance on Sun Sparc Enterprise T2000 servers when using the JRockit JVM. These performance problems are addressed with a patch to
JRockit R27.3.1.
|
![]() ![]() ![]() |