| Oracle® Communication and Mobility Server Developer's Guide Release 10.1.3 Part Number E10293-02 |
|
|
View PDF |
| Oracle® Communication and Mobility Server Developer's Guide Release 10.1.3 Part Number E10293-02 |
|
|
View PDF |
This chapter describes programming guidelines for SIP Servlet applications in the following sections:
For an application to take full advantage of OCMS as a JSR 116 SIP Servlet Application platform, observe the following recommendations.
For stateful applications, that is applications that save state in SipSessions or SipApplicationSessions, to be highly available in a SIP Application Server cluster, the sip.xml as well as the web.xml file must contain the <distributable> element. Marking applications as distributable will make sure that the application and session state is replicated to cluster nodes that will be able to resume execution of the session in the event of a failure of a cluster node.
There are performance implications related to how session state is replicated in a distributable environment. Replication is triggered each time there is a setAttribute() call on the session object, so large numbers of such calls in a servlet may impact performance.
For OC4J there are additional requirements if the application is packaged as an Enterprise Archive. See the Oracle Communication and Mobility Server Administration Guide for details.
All data that must persist for a session must be stored in the SIP Application Session explicitly and must be serializable.
As a corollary, to the previous recommendation, avoid using static variables in an application, instead use standard J2EE mechanisms such as EJB or database storage to achieve persistent storage of data that can be made available to another cluster node in the event of a failure.
All blocking calls as part of the invocation of a SIP Servlet application should be avoided. Blocking calls include Synchronous Remote procedure calls and synchronous database calls.
Remember to invalidate the SipApplicationSession in order to free up memory as soon as possible when the application has finished. For individual SIP Sessions, you should invalidate them as soon as they are finished as well. Make sure there are no active SIP Sessions when you invalidate a SIP Application Session as the owned SIP Sessions will be invalidated as well.
Monitor the memory usage for the data you want to store in session objects. Make sure there is sufficient memory for the number of sessions created before the sessions time out.
Objects that are stored in the session objects will not be released until the session times out (or is invalidated). If you hold any shared resources that have to be explicitly released to the pool before they can be reused (such as a JDBC connection), then these resources may never be returned to the pool properly and can never be reused.
Use the available mechanisms to create an event driven model for your application instead of creating threads to perform work outside of the activation model for the containers.
For B2BUA Applications, use the createRequest that clones the relevant fields of the original request:
SipFactory.createRequest(SipServletRequest origRequest, boolean sameCallId)
It will clone the request with the following modifications:
The From header field of the new request has a new tag chosen by the container.
The To header field of the new request has no tag.
The Call-ID will be new (or duplicated in sameCallId is true)
The Record-Route and Via header fields are not copied. The container will add its own Via header field to the request when it is actually sent outside the application server.
For non-REGISTER requests, the Contact header field is not copied but is populated by the container
