McDewey

TAPI structures TAPI messages CTI Message Actions No change LINE_DEVSPECIFIC hDevice = hCall-1 dwCallbackInstance = 0 dwParam1 = SLDSMT_CALL_TONE_CHANGED dwParam2 = CTONE_ZIPZIP dwParam3 = CZIPZIP_CMCREQUIRED CallToneChangedEvent, CH = C1, Tone = ZipZip, Feature = FACCMC, FACRequired = False, CMCRequired = True Party A does a lineDial() with the FAC in the dial string LINECALLINFO (hCall-1) hLine = A dwCallID = T1 dwOrigin = OUTBOUND dwReason = DIRECT dwCallerID = A dwCalledID = B dwConnectedID = NP dwRedirectionID = NP dwRedirectionID = NP LINE_CALLSTATE hDevice = hCall-1 dwCallbackInstance = 0 dwParam1 = PROCEEDING dwParam2 = 0 dwParam3 = 0 LINE_CALLINFO hDevice = hCall-1 dwCallbackInstance = 0 dwParam1 = CALLEDID dwParam2 = 0 dwParam3 = 0 CallStateChangedEvent, CH = C1, State = Proceeding, Cause = CauseNoError, Reason = Direct, Calling = A, Called = B, OrigCalled = B, LR = NP Party A does a lineDial() with the CMC in the dial string and Party B accepts the call No change LINE_CALLSTATE hDevice = hCall-1 dwCallbackInstance = 0 dwParam1 = RINGBACK dwParam2 = 0 dwParam3 = 0 CallStateChangedEvent, CH = C1, State = Ringback, Cause = CauseNoError, Reason = Direct, Calling = A, Called = B, OrigCalled = B, LR = NP Timeout Waiting for FAC or Invalid FAC The following table describes the message sequences for the Forced Authorization and Client Matter Code scenario of timeout waiting for FAC or invalid FAC entered. Here, Party A is Idle and Party B requires an FAC. Cisco Unified TAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 767 Message Sequence Charts Timeout Waiting for FAC or Invalid FAC