Common Problems

Issue	What to do
Incorrect processing of call in following scenario:	Issue: An inbound call with certain DID (DNIS) comes from Media Gateway to SIP Server and directly forwarded to GVP. GVP is represented by a Trunk DN in SIP Server, meaning SIP Server won't generate DN related TEvent on it. After caller's interaction with GVP is finished, GVP transfers the call to a Routing Point at SIP Server Time of call processing in GVP is higher than ~30 sec. Resolution: Configure a TrunkGroup DN that points to GVP, instead of the Trunk DN. This will result in generating Tevents on the Trunk Group, which will ensure proper completion of call create transaction in this scenario. Increase the timeout to the length of time to wait for the event before failing the call create transaction. By default it's 30 seconds. If in the scenario described here, the call spends more than 30 seconds on GVP, call create transaction would fail. To increase the timeout, set option "cti-transaction-timeout" in section "gts" in the ORS application to the desired value in seconds. This option can have a maximum value of 600 (10 minutes).
Unexpected crash after some period of time ORS stops creating sessions	The most common cause for this problem is that sessions are not ending.  In Orchestration, a session ends by transition to a <final> element.  Orchestration sessions can be started in a number of ways and have a number of purposes.  For sessions that are based around voice interactions, it should be made certain that the session ends.  This is typically done by detecting the event interaction.deleted and then transitioning to a <final>.  For projects built with Composer, this can be easily done by adding an exception handler to the default Entry point.
Internal communication delays	In cases where there are unexpected delays within the SCXML application execution, the cause may be unneccessary attempts to resolve 'localhost' through DNS.  Internal thread communication employs this hostname.  Check the /etc/hosts file to determine if localhost is defined as 127.0.0.1, for example for ipv4.
ORS occasionally fails to fetch document with error "Recv failure: Connection reset by peer" if idle time between calls exceeds web server Connection Timeout	This was observed on a RedHat installation of ORS where it was discovered that TCP_KEEPALIVE was turned off on ORS sockets. ORS attempts to re-use existing connections but when TCP_KEEPALIVE is disabled, libcurl fails to detect when TCP connections are disconnected. TCP_KEEPALIVE can be forcibly enabled by loading libkeepalive.so via LD_PRELOAD (add path of libkeepalive.so to LD_PRELOAD environment variable) prior to starting ORS.