Q. I have an application which uses several CTI ports to transfer calls to one main CTI port which handles conferencing them all together. In the event of a conference failure, I would like to inform the user that a failure has occured in the form of playing audio to the user. After the transfer, the main CTI port answers and attempts a transfer. If there is a failure to conference, say due to lack of conference resources, there is no terminal connection for this call. Without a terminal connection, I can't retrieve RTP parameters to setup my RTP player. Do I have to perform another transfer of that same call to some dedicated CTI port or route point in order to establish a terminal connection (and thus have an RTP destination port and address) ??
A. I think another transfer is not needed. Request to refer https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/12_5_1/cucm_b_cisco-unified-jtapi-developers-guide-1251/cucm_b_cisco-unified-jtapi-developers-guide-1251_chapter_010.html#CUCM_TP_CDA2DC56_00
and Configuring CTI port for related information.
Are you doing blind transfer? In that case app will loose control of that call either call succeed or failed. First you create consult call and then complete the transfer, this will help you to keep control of call.
I figured out my problem.
There were no terminal observers set up to listen on the main CTI port (the one receiving the transferred calls.). I was only seeing call control events. I was not seeing RTP start/stop events. Once I set up the terminal observer, I started seeing RTP events, and now I am able to use the main CTI port to send RTP should a conference failure occur.