Jump to: navigation, search

Orchestration Server Troubleshooting

Common Problems

Issue What to do

Incorrect processing of call in following scenario:

Issue:

  1. An inbound call with certain DID (DNIS) comes from Media Gateway to SIP Server and directly forwarded to GVP.
  2. GVP is represented by a Trunk DN in SIP Server, meaning SIP Server won't generate DN related TEvent on it.
  3. After caller's interaction with GVP is finished, GVP transfers the call to a Routing Point at SIP Server
  4. Time of call processing in GVP is higher than ~30 sec.

Resolution:

  1. 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.
  2. 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 then 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. For example, this option could be set to 3600 (one hour).

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.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on September 22, 2017, at 10:51.