This document was generated from CDN thread
Created by: Christopher Nagel on 12-05-2010 03:42:25 PM
I am testing with CTI OS Java CIL 7.0.0, 09816 (latest release?) and OnButtonEnablement sets my Answer button enabled.
When I click it, the code that executes is:
Call rCall = m_ctiSession.getCurrentCall();
if( rCall != null ) rCall.Answer( new Arguments() );
Unfortunately, this doesn't answer the new call - it tries to re-answer the call I already have on hold.
It should "just work", no?
Chris
Subject: RE: New Message from Christopher Nagel in Computer Telephony Integration Ob
Replied by: David Lender on 12-05-2010 06:43:09 PM
When you receive the begin call for the new call, your handler should
set the currentcall to be the new call:
////////////////////////////////////////////////////////////////////////
///
public void OnCallBegin(Arguments rArguments)
{
if (IsMonitoredEvent(rArguments))
return;
m_appFrame.LogEvent("OnCallBegin", rArguments);
DisplayCallInfo(rArguments);
// Get a reference to the call object, reset as our default call
String sUID = rArguments.GetValueString(CTIOS_UNIQUEOBJECTID);
Call rCall = (Call) m_ctiSession.GetObjectFromObjectID(sUID);
m_ctiSession.SetCurrentCall(rCall);
// Dump the properties out to the Trace mechanism
m_log.Trace(Logger.TRACE_MASK_ALWAYS, rCall.DumpProperties());
} // OnCallBegin
However, with 7.0 you cannot handle multiple ACD lines. The only way
you can have a 2nd call when you have one call on hold is when you are
placing a consult call. There is no support for handling an inbound ACD
call when you have a call on hold.
Subject: RE: When is CurrentCall changed?
Replied by: Christopher Nagel on 13-05-2010 05:19:08 PM
David,
Thanks for your response. I used to do this, but stopped doing so for a couple reasons:
1-
Releasing a consult call did not automatically make the held call
current, so the button enablement would essentially disable all my
buttons, making the app appear as if there were no calls whatsoever
(forcing users to retrieve held call using hardphone).
2-
When a caller abandons a call after the first ring at the device, no
further enablement events are sent, so the buttons are stuck in
"Answer" mode - a Cisco release note said "jiggle the handset", but my
QA folks don't like that idea... I don't know how to generate a
SnapshotDeviceConf message, or to request a refreshing Enablement event.
Given a UI that does not display a grid of calls, do you see any way some
kind of complex state machine to address the possibilities implied here?
Thanks,
Chris
