Release Note [SIP Servlet Engine Version 3.0.0]

AP-00001 Problem about Compatibility with the SIP Servlet API

SIP Servlet Engine supports the "SIP Servlet API (Version 1.0)" as an SIP servlet engine, but now it does not support the following functions:

AP-00002 Problem that 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.

AP-00003 Problem that TLS is Not Supported

TLS does not operate as an SIP transport protocol, and the available transport protocols are only TCP and UDP. Therefore, 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 the <transport-guarantee>, an exception will be thrown.

AP-00006 Problem that the J2EE-related Tags are Not Supported

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.

AP-00010 Problem that Forking the 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.

AP-00011 Problem that 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.

AP-00013 Problem about Limitations on the Servlet.init() and Servlet.destroy()

SIP Servlet Engine 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 by the <load-on-startup> in the sip.xml, the following limitations apply to the Servlet.init():

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

When you use WebLogic Server as a J2EE container, during WebLogic Server startup applications may perform the following processes:

1. Startup
2. Shutdown
3. Restart

Therefore, the third limitation on the Servlet.init() also applies to the Servlet.destroy(). In this case, the init() affected by the 3. limitation 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 1. limitation is destroyed by the destroy() affected by the 3. limitation.

AP-00014 Problem about Limitations on Communication via TCP on Windows Platforms

When SIP Servlet Engine runs on a Windows platform, communication via TCP does not operate properly. Use only UDP as a transport protocol.

AP-00015 Problem about Limitations in a Clustered Environment

The clustering function through SIP session replication can be used in SSE V3.0 or later. But the following SIP applications does not support the clustering function.

AP-00016 Problem about Limitations When Upgrading from SSE 2.x

SSE V3.0 or later accesses database through the SPIs. You need to create a new WebLogic domain to use the SPIs because they are incompatible with the basic components in V2.x or earlier. And note that V2.x and V3.x can not be co-located on the same WebLogic.