Skip navigation.

Release Notes

The WebLogic SIP Server 2.0.1 Release Notes includes the following sections:

Licensing WebLogic SIP Server 2.0.1 for Production Use

WebLogic SIP Server 2.0.1 uses two separate license files to provide basic functionality:

  1. A BEA WebLogic Server license, defined in license.bea, enables you to use WebLogic Server 8.1 SP4.
  2. A SIP container license, defined in sip-license.xml, enables you to use the SIP container with WebLogic Server 8.1 SP4 to deploy and manage SIP applications.

All default installations of WebLogic SIP Server 2.0.1 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.1, 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:

  1. Install WebLogic SIP Server 2.0.1 into a new BEA home directory (for example, c:\beawls) as described in Installing WebLogic SIP Server.
  2. Make a backup copy of the evaluation licenses that were installed with WebLogic SIP Server 2.0.1:
    cd c:\beawls
    copy license.bea license.bea.backup
    copy sip-license.xml sip-license.xml.backup
  3. Change the IP address of your existing WebLogic Server 8.1 license (license.bea file) to match the IP address of the WebLogic SIP Server machine. Use the BEA eLicense system at http://elicense.bea.com to change the IP address.
  4. Copy the license.bea file that you updated with eLicense into the BEA home directory for WebLogic SIP Server 2.0.1. For example:
    copy c:\bea814\license.bea c:\beawls
  5. Copy the production WebLogic SIP Server license that you purchased in the WebLogic SIP Server BEA home directory:
    copy c:\downloads\sip-license.xml c:\beawls 
  6. Restart WebLogic SIP Server to use the production licenses.

Third-Party Licenses

SIP Servlet Engine uses the following products:

For license information for these products, see the following files and URL:

  1. For license information for dom4j, see the legal/dom4j-license.html after decompressing the archive file.
  2. For license information for SNMPTrapAppender, see the legal/snmpTrapAppender-LICENSE.TXT after decompressing the archive file.
  3. JUG is distributed by LGPL. JUG can be downloaded from the following site.
    http://www.doomdark.org/doomdark/proj/jug/
  4. Acknowledgment (Apache Software Foundation)
    "This product includes software developed by the Apache Software Foundation (http://www.apache.org/)."

Deprecated Features

WebLogic SIP Server 2.0.1 is a restricted release of a BEA product and is subject to change in future releases. The following features are specifically called out as being deprecated in WebLogic SIP Server 2.0.1:

Known Problems and Limitations

web.xml Required for SIP Applications

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.

Compatibility with the SIP Servlet API

WebLogic SIP Server 2.0.1 does not support the following functions described in the "SIP Servlet API (Version 1.0):"

  1. The Application Composition
    WebLogic SIP Server does not deliver an initial request properly when it matches multiple SIP servlets. In this case, it delivers the request only to any single SIP servlet.
  2. Retrieving HTTP sessions
    WebLogic SIP Server can not return HTTP sessions using the SipApplicationSession.getSessions() method. This method returns SIP sessions only. Note that HTTP sessions can be registered explicitly in your application.
  3. Support for the .sar file
    The SIP Servlet API defines the .sar file as a format for containing an SIP application, but the .sar extension can not be specified. Deploy the .sar file contents as a .war file instead. For more information, see
    Interaction between Servlet Contexts.

100rel is Not Supported

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 is Not Supported

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.

Unsupported J2EE Tags

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.

Forking SUBSCRIBE Requests is Not Supported

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.

Virtual Hosting is Not Supported

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.

Limitations with Servlet.init() and Servlet.destroy()

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():

  1. When SipServletRequest.send() is executed, the message is sent after the J2EE container has completely started.
  2. Because SipServletRequest.send() does not actually send the request, an exception of the SipServletRequest.send() can not be caught.
  3. You cannot write code similar to the sample code shown below, which verifies the response of the request sent by SipServletRequest.send() before proceeding to the next process:
           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:

  1. Startup
  2. Shutdown
  3. Restart

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.

Limitations on Communication via TCP on Windows Platforms

On Windows platforms, communication via TCP does not operate properly. Use only UDP as a transport protocol.