Monitoring CTI RPs/Ports from multiple applications - autoAccept status changing when instance goes down

[stephan.steiner]

I have to make one of my applications HA capable. So, in order not to lose anything when an instance goes down, I use shared data structures and keep my CTI RPs and Ports monitored by two applications. That works fine, both instances get the calls. However, when the first instance I started goes down, the second one notes an 

CiscoAddrAutoAcceptStatusChangedEv

telling me AutoAccept is no longer active (one for every CTI RP and CTI Port my apps are listening to). Is there a way to prevent that? What other options would you recommend? CTI ports are only used to transfer calls, but the RPs they take in calls, I need both instances connected to them. 

@edit: so I changed my app to react on these events, and simply set the autoAccept state again. While all my commands are accepted, I then still don't get any calls. I do get call events still, so I know my app is still alive, but without autoaccept, calls don't get to my app and so it's dead in the water

[dstaudt]

Sounds to me like something might be flaky with the JTAPI implementation (either client or CUCM side).  The docs don't really cover the expected behaviour when multiple apps are monitoring the same port, but my personal expectation would be that you _wouldn't_ receive those events for the app/provider that is still up.  This may be a bug or limitation in JTAPI where it's confused about which instance to send the events to..?

One workaround might be to avoid relying on the CTI/Route port autoaccept feature, and do the accepting 'manually', i.e. handle the incoming call event and issue the accept() in your code - this would allow your secondary app to not accept calls at all all unless it goes 'active' which might save a bit of processing.

Certainly if you need/want autoaccept to work, I would encourage you to open a DevNet Developer Support ticket so we can look at the detailed logs and figure out what's going on.  However, IMHO the likelihood we can find a mechanism to change the current behaviour seems small, and we would probably end up needing to open/create/deploy a fix to resolve...

[stephan.steiner]

Case filed.

Trying to accept calls manually was my first workaround attempt. Haven't quite gotten around to doing it yet.. do you know which event I'd get before the accept? I've always set autoAccept first thing when working with CTI Ports / RPs going back to my CUCM 4 days. Is it catching 

handleCiscoCallCtlConnOfferedEv

then calling 

(CiscoConnection)ev.getConnection().accept()

Sounds about right to me but I haven't tested it yet.

[dstaudt]

Yep, that should be it

[stephan.steiner]

and it worked fine. I'm not bothering to set autoAnswer again on the second instance for the moment while I await what developer support has to say on my case.