The WebLogic SIP Server 2.0.2 Release Notes includes the following sections:
WebLogic SIP Server 2.0.2 introduces the following features:
The following table summarizes the issues that have been resolved in WebLogic SIP Server 2.0.2.
| Change Request Number | Description |
|---|---|
| CR211125 | The product license file, sip-license.xml, was moved to the WebLogic SIP Server product directory (BEA_HOME/wlss202). |
| CR217316 | The code was modified so that SIP message Via, Contact, and Record-Route headers can be populated with the correct IP address on multihomed machines. See Setting Up Connectors. |
| CR218114 | WebLogic SIP Server generated an exception if an INVITE request contained a Route header having the server's IP address. The code was modified to remove the Route header and forward the request. |
| CR218136 | If a SIP request did not contain a Max-Forwards header, WebLogic SIP Server would throw a javax.servlet.sip.TooManyHopsException and respond with code 483. This behavior did not match the specified behavior, which is to decrement the Max-Forwards value by one of the header is present. The code was changed to match the specified behavior. |
| CR218285 | WebLogic SIP Server threw an exception if a From address contained a "<" or ">" symbol. The code was modified to address this problem. |
| CR218359 | The code was modified to support configurable SIP timers. See Configuring SIP Timers. |
| CR219912, CR221880 | WebLogic SIP Server did not observe the Record-Route header for BYE or ACK messages. Instead, BYE and ACK messages were sent using the Contact header, ignoring the record-route hierarchy. This problem was solved with a change to the code. |
| CR221952 | WebLogic SIP Server did not generate an error if it could not bind to a configured UDP port (for example, if the port was already in use). The code was modified to generate an appropriate message when the server cannot bind to a configured port. |
| CR224690 | To improve proxy performance, the code was modified to first use UDP with a fixed buffer size, and then switch to TCP only if the message size exceeds the MTU size. This code fix also improves compliance with the SIP specification, because responses that exceed the configured MTU size are no longer rejected, but are instead sent over UDP if the original Request was via UDP. |
| CR231206 | When forwarding messages having Route header values and a proxyTo() destination, WebLogic SIP Server forwaded to the proxyTo() destination rather than the first Route value. The code was changed to comply with the SIP specification; Route headers are now handled based on the transaction user in question and on whether a dialog is established. |
| CR231208 | WebLogic SIP Server could potentially proxy a CANCEL request if a SIP application failed to implement a doCancel() method but the doRequest() method proxied the CANCEL. The code was modified to ensure that CANCEL requests are not proxied even if the SIP application attempts to proxy them in doRequest(). |
| CR231821 | WebLogic SIP Server returned an ArrayIndexOutOfBounds exception when 0 bytes were read from a stream. This issue was resolved with a code fix. |
| CR231849 | WebLogic SIP Server 2.0.2 includes a "no-op" authentication provider, called the Identity Assertion Authenticator, that performs netiher group population nor user existence checking. You can configure this provider and use it with the Digest Identity Asserter provider when neither group population nor user existence checking is required, in order to save an additional round-trip connection to the LDAP server. See Configuring Digest Authentication for WebLogic SIP Server for more information. |
| CR231852 | Trusted hosts can now be configured in order to bypass authentication for listed host addresses. See Configuring Trusted Hosts. |
| CR231857 | A deadlock situation could occur when two messages were received by a B2BUA servlet at the same time and each leg tried to forward the response to the other leg. This issue was resolved with a code fix. |
| CR231887 | Weblogic SIP Server did not consider DNS names in Route headers when proxying requests; if a Route header contained a DNS name that resolved to the IP address of WebLogic SIP Server itself, the Route header was not removed when proxying the request to its destination. The code was changed to resolve the DNS name in the Route header and remove the header if the name resolved to the IP address of the server. WebLogic SIP Server caches the IP address to avoid repeated DNS lookups. |
The com.oki.sip.bea.wls81.security.WLSSecurityManagerFilter is no longer used. WebLogic SIP Server implicitly registers a com.bea.wcp.sip.security.WLSSecurityManagerFilter class to support trusted hosts. However, the XML configuration for trusted hosts is deprecated in this release and subject to change. See Configuring Trusted Hosts for more information.
WebLogic SIP Server 2.0.2 is a restricted release of a BEA product and is subject to change in future releases. The following features are specifically identified as being deprecated in WebLogic SIP Server 2.0.2:
WebLogic SIP Server 2.0.2 uses two separate license files to provide basic functionality:
All default installations of WebLogic SIP Server 2.0.2 include an evaluation license for both WebLogic Server 8.1 SP4 and the SIP container.
You can purchase a production upgrade license for WebLogic SIP Server 2.0.2, which includes a production-enabled sip-liense.xml file and requires that you own or purchase a separate BEA WebLogic Server 8.1 production license. To use the production version of WebLogic SIP Server, follow these steps to update and use an existing BEA WebLogic Server 8.1 production license and to install the purchased WebLogic SIP Server license:
cd c:\beawls copy license.bea license.bea.backup copy sip-license.xml sip-license.xml.backup
http://elicense.bea.com to change the IP address.copy c:\bea814\license.bea c:\beawls
copy c:\downloads\sip-license.xml c:\beawls
SIP Servlet Engine uses the following products:
For license information for these products, see the following files and URL:
The WEB-INF subdirectory of a SIP application must contain both a web.xml and sip.xml descriptor, even if your are deploying a pure SIP application. The web.xml descriptor must define a standard listener class used to manage the lifecycle of HTTP and SIP Servlet contexts. See Interaction between Servlet Contexts for more information.
WebLogic SIP Server 2.0.2 does not support the following functions described in the "SIP Servlet API (Version 1.0):"
The 100rel extension defined in RFC3262 does not operate. If the following information is specified in a message header,
Require: 100rel
A 420 error message is returned to this request.
TLS does not operate as an SIP transport protocol, and the only available transport protocols are TCP and UDP. Because of this, the <transport-guarantee> which is a child element of the <user-data-constraint> element is not supported. If any value other than NONE is specified in <transport-guarantee>, WebLogic SIP Server throws an exception.
This release does not support the <ejb-link> which is a child of the <ejb-ref> and <ejb-local-ref> elements. If the <ejb-link> is specified, the setting is ignored.
This release does not support the send-by parameter in the Via header defined in RFC3261. If the send-by parameter is specified, the setting is ignored.
This release does not support the SUBSCRIBE requests forked at proxies defined in RFC3265. SIP sessions are not generated properly for the SUBSCRIBE requests forked at proxies.
This release does not support virtual hosting. Use SIP applications on only one virtual host. When an SIP servlet is used on multiple virtual hosts, SIP messages may not be delivered properly to the servlet.
WebLogic SIP Server does not open the port for receiving SIP messages until the J2EE container has completely started. Therefore, if SIP servlets are simultaneously generated and initialized with <load-on-startup> in sip.xml, the following limitations apply to the Servlet.init():
public syncronized init() {
...
SipFactory factory = getFactory();
SipServletRequest req = factory.createRequest(...);
wait();
...
}
public synchronized doSuccessResponse(SipServletResponse res) {
notifyAll();
}
WebLogic Server startup applications may perform the following processes:
Therefore, the third limitation on Servlet.init() also applies to Servlet.destroy(). In this case, the init() affected by limitation 3 above sends only the request which the SipServletRequest.send() has attempted to send after WebLogic Server has started. The request which the SipServletRequest.send() has attempted to send in the init() affected by the limitation 1 is destroyed by the destroy() affected by limitation 3.