This can be the case when
1) a call is over but the application continue processing (like for DB cleanup or other similar tasks).
2) Basically, based on how customer built their application, they need to account for the fact that
it might run longer after the call is over at which point the ports and media channels are released
and can be re-used by the system. In this case, they are but when it comes to triggering the application,
there is no more sessions available for it since the other one is still running.

Recommended Action

1) It could be that there are some stuck sessions in the system, due to which sessions are
not getting released for the new calls. To confirm this, check the application tasks in RTR reports
to see if there are any sessions stuck for a long duration.

Also, there could be following deadlock exceptions in the logs, due to a deadlock situation
while executing step :StepHost which is called while executing some custom Java Method in the IVR script.

In the above case, the script is stuck inside customer-defined code which is not returning the control back to UCCX. As such, the task will hang there and the application session and the task instance will never be released.

The customer should investigate their code to figure out why they are blocking.

Correct the script and try out the calls.

2) If the number of sessions are not sufficient to handle the incoming calls, then the new calls will get
abandoned. Try increasing the number of sessions and see if this resolves the issue.