Rejected Calls

Symptoms

Looking at the Control Center you may notice a lot of Rejected Calls.

Here is a common error that can be seen in the logfiles: FATAL_E 2009-06-18 15:27:34:816 [VoiceObjects.OBConnector.Servlet ] [] [ ] [] [] [] [] [] []: Initial request held parameter dialogID=' [Your full OVAP ID here] '!

Cause

The message itself is caused by a URL reaching the instance with a dialogID which is not or not longer fitting to a call handled by this instance.

There can be a few different possibilities for why this error is occurring.

1. An Exit object is inheriting the Event Handling item to handle disconnect events from somewhere in the application.
   You will see that usually a new rejected call is shown in the Control Center after a call has just ended.
2. Load balancer - in these cases you should find other messages with this dialogID in another instance showing that the call timed out.
3. A Dialog Exit happened within VoiceObjects application but the Media Platform continues to send requests.
4. Caching issue - where the speech platform mixes up dialog IDs from cached VXML pages

Resolution

The resolution depends on the cause. As items 1. and 2. in the above list are the most common ones, please check first:

1. Exit Object Event Handling

Here you can check if there is an exit object which causes this issue: This can be done by creating a trace file from a typical call. In case the call ends with an exit object please open the exit object and check on the exit type. The described behavior can happen if the exit type is disconnect or default (as the service default is also disconnect).
Check if there is any disconnect event handler in the VXML of this object (usually the last VXML in the trace file).
If there is such a handler and the please deactivate event handling inheritance in the event handling section of the exit object. This will prevent the event handler to be in the VXML of the exit object - and the call is ended properly without spawning another request to VoiceObjects.

2. Load Balancer

A load balancer can be set up to handle sessions or to balance each request. In addition it is possible to use the load balancer only for the first request from the media platform to VoiceObjects and route every following request directly from the media platform to the respective VoiceObjects instance.
In case all requests are using the load balancer and the load balancer does not handle the sessions correctly, it can happen that the call is load balanced to another VoiceObjects instance - and thus gets lost. The old call will run into a timeout in VoiceObjects and the new instance will reject the call as it already has a dialogID which is unknown to this instance.
To resolve this make either the load balancer aware of sessions or configure your system to only use the load balancer for the initial step of a call.

All Other Issues

You may do a SQL select on Infostore to gain more insight about the rejected requests:

 SELECT 
  DLG_ID, DAY_ID, MINUTE_ID, DLG_CALL_DUR_MS,SRV_INST_NAME 
  FROM VOLDDLGSTS 
  where DLG_ID in ('...','...')

This SELECT will deliver the call-start timestamp and the dialog duration as well as the name of the VO Server instance that processed the call. This should give you a first overview over what happens.

For further troubleshooting it would be helpful to turn on URL logging. To enable the URL log please change the log setting URLLogger from WARN to DEBUG on all instances. This is described in detail in the Troubleshooting instructions -> Additional log settings in the online help on our Developer Portal