This chapter describes known problems and associated solutions for the Communications Server software. If a summary statement does not specify a particular platform, the problem applies to all platforms. This information is organized into the following sections:
Communications Server instances starts up even if it cannot bind to a SIP or SIPS port.
Ensure that ports are free before starting server instance(s). Check the log files (server.log) to ensure that there have not been any SIP container errors or exceptions during the startup.
For details on how to view log files, see TBDlink.
You can use a preinstalled JDK instead of the default version for the installation by using the ––javahome option. Communications Server, by default, uses the JDK version from as-install/jdk.
The AS_JAVA variable in the asenv.conf file always points to as-install/jdk. If you want to use a different JDK version, update the asenv.conf file manually and changed the value of AS_JAVA.
When JVM heap size is set to 3.5 GB, Communications Server instances fail and restart when they receive traffic.
Ensure that the maximum JVM heap size is set to 3.0 GB or less. For details on how to change the JVM heap size, see TBDlink
On Solaris platforms, Communications Server calculates CPU usage based on the number of available processors and the per-core CPU usage. However, Communications Server takes into account the static value of number of cores and not the number of cores that are used by the JVM.
Recalculate the CPU threshold values if you are not using all the cores in the machine.
If you log in as root with the Bourne shell (/bin/sh) and run asadmin commands, then log out of the console window, all the domain administration server (DAS), node agent, and instance processes are killed. This is because in the Bourne shell all child terminals inherit the TTY by default, so when the terminal is logged out, all child processes are killed too.
Before running any asadmin commands, do the following:
Log in to the server.
Change to K shell:
# exec /bin/ksh |
In K shell, run all the asadmin commands to bring up the DAS, node agents, and instances.
When you use asadmin commands related to converged load balancer, the domain status changes to “Restart required”, although it is not necessary to restart the domain. You can view the domain status with the asadmin list-domains command.
Domain restart is not required. Ignore the domain status.
If you modify the configuration of the converged load balancer on a target and you redeploy the applications on that target, the instance logs will show SEVERE messages.
These messages do not affect the functioning of the converged load balancer or the instances. Ignore these messages.
When you use a converged load balancer with a data-centric rules file that returns a complete URI for the BEKey parameter, he BEKey parameter in the Contact header is not correctly escaped. The “:” character is not correctly escaped as specified in RFC 3261.
No known solution.
This problem has been observed on systems running Linux with the environment variable, MALLOC_CHECK_, set to 2.
Set the environment variable, MALLOC_CHECK_ to 0. Run one of the following commands:
For Bourne shell:
MALLOC_CHECK_=0; export MALLOC_CHECK_ |
For bash shell:
export MALLOC_CHECK_=0 |
For csh, tcsh shell:
setenv MALLOC_CHECK_ 0 |
Installation fails on 64–bit systems that have 64–bit JDK because the installer tries to use the 64–bit JDK.
If you are installing Sun GlassFish Communications Server on a 64–bit system, download the 32–bit JDK and use it to install Sun GlassFish Communications Server on your 64–bit machine. You will need to use the following command: ./distribution_filename —javahome path to 32–bit JDK location
After installation, to ensure that Sun GlassFish Communications Server uses a 64–bit JDK, edit the value of the AS_JAVA variable in the asenv.conf file to point to the 64–bit JDK installation.
Communications Server throws Null pointer exception Realm is not configured when P-Asserted-Identity authentication is configured in sun-sip.xml.
Configure Realm using the trust-auth-realm-ref property in sun-sip.xml. See TBDlink for more information on setting this property.
The SIP container cannot handle a CANCEL request when a 100 response has been sent.
The application needs to send a provisional response (such as 1xx), so that the remote side is able to CANCEL the INVITE request.
The session expiration model of SIP sessions is different from the HTTP expiration time logic. In HTTP, the session is automatically extended, outside of the control of the application, whenever a new HTTP request is received in that HTTP session.
With SIP sessions, the application is in control over the duration of the SipApplicationSession (SAS), subject to approval by the SIP container. Applications can use the setExpires method to indicate when the SAS should expire. setExpires defines an expiration time relative to the moment the setExpires method is called. The container can modify, reject, or accept the duration indicated in setExpires. If the session is not invalidated, then the sessionExpired callback is performed at the time defined by setExpires . In this callback, the application can try to extend the duration of the SAS by invoking a new setExpires, again subject to modification, rejection, or acceptance by the container.
For this reason, converged applications that start out with the same expiration time of the SipApplicationSession (SAS) and on the HTTP session will notice that the SAS times out before the HTTP session if new requests were received on the HTTP session.
The best way to deal with the different expiration time handling of the SIP and the HTTP session is to start with a large enough SAS expiration time, which is the total time that the application session is expected to live (including several HTTP requests). The SAS lifetime could even be set to infinite, specifically if invalidateWhenReady semantics are used, in which case, the SipApplicationSession is invalidated when the last protocol child session becomes invalidated. The initial expiration time for the SAS can be configured in the deployment descriptor.
If the maximum total duration can be estimated in advance, no further code is needed, as it is then appropriate to invalidate both the Sip session and the HTTP session when the SAS expires. If the maximum duration cannot be estimated in advance, then the SipApplicationSession can be extended when it expires, as shown in the code snippet below.
In the SipApplicationSessionListener implementation, you can do something like this:
public void sessionExpired(SipApplicationSessionEvent sasEvent) { // check if the SAS needs to be extended first, if so: int granted = sasEvent.getApplicationSession().setExpires(2); if (granted <= 0) { System.out.println("extension rejected"); } else if (granted < 2) { System.out.println("extension granted with lower value " + granted); } // else allowed }
This is an intermittent issue. The SIP container intermittently responds with a 500 Server internal error message instead of a 481 Call/Transaction does not exist message when there is a race condition between the 200 for NOTIFY indicating that the session has been removed, and the SUBSCRIBE sent by the client when receiving that NOTIFY.
The client needs to the refresh SUBSCRIBE much before the subscription expires.
When it receives an INVITE request, Communications Server first acts as UAS, replies to this request with 1XX, and then proxies this INVITE request to another instance, which replies with 200 OK. The 1xx creates an internal virtual branch while the 200 message creates a real branch. Upon reception of 200 OK from B the internal virtual branch should be cancelled
This exception trace does not affect the functionality of the virtual proxy branch.
The getLastAccessedTime method of a SIP session does not provide accurate results.
Applications that need to keep accurate track of the lastAccessedTime must store it themselves into the SipApplicationSession.
synchronized (sas) { Long last = (Long) sas.getAttribute("myLastAccessedTime"); if (last == null) {last = 0}; // do something with the last one // and... // set the new one. sas.setAttribute("myLastAccessedTime", System.currentTimeMillis()); }
After a SIP listener configured for TCP and UDP requests is deleted, the listener remains active for a certain duration. UDP requests that are sent to the listener could receive a response from the listener.
No known solution. The SIP listener stops listening to UDP requests after a certain duration. This problem does not impact TCP requests.
Description
Communications Server throws exception when it receives a Contact header without “<>”. According to SIP RFC 3261, it is not mandatory to have the “<>” in the address. This could lead to interoperability problems with other SIP-compliant devices.
Solution
Use “<>” in the Contact header.
Communications Server throws exception at an invalid UUID value instead of returning a 400 Bad Request. The UUID value resides in the SIP contact header's sip.instance value
No known solution.
This problem is intermittently seen only on Windows. UDP messages are not received by Communications Server.
Set the following JVM option as follows, and restart Communications Server.
org.jvnet.glassfish.comms.disableUDPSourcePort=true