|Attention: DocWiki has reached EOL and will be decommissioned January 25, 2019.|
VXML Server: Session Does Not Contain Call Information
Session Does Not Contain Call Information
|Problem Summary||This is a rare error message that is displayed after end session request error. In this situation, VXML Server has completed its process of ending a session, however the Call Server has not completed its process for ending the session when a new HTTP request is received referencing that session. This would yield a legitimate session from the Call Server’s standpoint but an invalid session by VXML Server’s standpoint.|
|Error Message||SERVER ERROR: The session is not associated with a Server Configuration.|
|Possible Cause||The situations where this would be encountered are identical to those listed in the previous error condition except the timing of the second request would occur after the standard end of call process taken by VXML Server completed but before the Call Server actually removed the session. The timing for this situation is actually tighter than the previous situation and therefore would occur even more rarely. While there is a chance that this could occur under standard call volume, it would more likely occur only under extreme load to the network, operating system, or network.
Severity: The severity for this error is very low because there is no effect on the caller since this occurs after the call is complete. Additionally, the situations in which this can occur during normal operation are extremely rare.
|Recommended Action||For the first situation, the developer must ensure that their end of call events do not have the possibility of taking longer to execute than the H.323 Service’s fetch timeout VoiceXML property. Another possible solution, if the end of call event is a Java class would be to execute the class in a separately spawned thread. As long as the end of call class completed its execution before the session invalidation delay specified in the conf/global_conf.xml of the installation directory, there would be no risk of the class referring to data within the session after it was invalidated.
For the second situation, it may be an indication of excessive network, operating system, or Call Server load. For the network, perform diagnostics to ensure proper operation. For the operating system, check the CPU and memory utilization to ensure they are not maxed out. And for the Call Server, check the configuration to ensure the HTTP request queue is not too small (for example, on Apache Tomcat, the acceptcount setting can be configured in the conf/server.xml configuration file). Finally, the administrator may decide to direct less load on the system.
The administrator may also choose to ignore these issues if they occur rarely since there is no bad consequences for the call session that encounters this error.
|Associated CDETS #||None.|