Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager Release 7.1(2)
Appendix A Message Sequence Charts
Downloads: This chapterpdf (PDF - 1.99MB) The complete bookPDF (PDF - 9.51MB) | Feedback

Message Sequence Charts

Table Of Contents

Message Sequence Charts

Shared Line Support

AddressInService/AddressOutofService Events

Incoming Call to Shared Address

Outgoing Call from Shared Address

Shared Address Calling Itself

Transfer and Direct Transfer

DirectTransfer/Arbitrary Transfer Scenario

Direct Transfer/Arbitrary Transfer—Page 2

Consult Transfer

Conference and Join

Join/Arbitrary Conference

Consult Conference

Join Across Lines with Enhancements

Barge and Privacy

Barge

CBarge

Privacy

CallSelect and UnSelect

Dynamic CTIPort Registration Per Call

Media Termination at Route Point

Redirect Set OriginalCalledID

Single Step Transfer

Modifying Calling Number

AutoAccept for CTIPort and RoutePoint

Forced Authorization and Customer Matter Codes

Super Provider Message Flow

SuperProvider and Change Notification Enhancements Use Cases

QSIG Path Replacement

Device State Server

Partition Support

Using getPartition() API

Using getAddress (String number, String partition)

Park DN

Partition Change

JTAPI Partition Support

Hairpin Support

QoS Support

JTAPI QoS

TLS Security

SRTP Key Material

Device and Line Restriction

SIP Support

SIP REPLACE

SIP REFER

IN-Dialog REFER Scenario

OutOfDialog Refer

SIP 3XX Redirection

Unicode Support

Backward Compatibility Enhancements

Half Duplex Media

Recording and Monitoring

Intercom

Do Not Disturb

DND-R

Secure Conferencing

JTAPI Cisco Unified IP 7931G Phone Interaction

Locale Infrastructure Development Scenarios

Calling Party Normalization

Click to Conference

Call Pickup

selectRoute() with Calling Search Space and Feature Priority

Extension Mobility Login Username

Calling Party IP Address

CiscoJtapiProperties

IPv6 Support

Provider Open Scenario

Calling Party IP Address scenarios:

RTP Addresses

CTI Port/Route Point Registration Scenarios

Advance Test Cases:

Direct Transfer Across Lines Use Cases

Connected Conference or Join Across Lines Use Cases - New Phones Behavior

Enhanced MWI Use Cases

Join Across Lines Enhancements

Swap or Cancel and Transfer or Conference Behavior Change

Drop Any Party Use Cases

Park Monitoring Support

Use Case 1: Park Monitoring States

Use case 2: Shared line scenario - Cisco Unified IP Phone Does Park

Use case 3: Shared Line Scenario - Cisco Unified IP Phone 7900 Series with SIP Does Park

Use Case 4: Use Case for Snap Shot Scenario

Use Case 5: Park DN is Monitored

Use case 6: Query Number of Parked Calls

Use case 7: Filter Enabling or Disabling

Use case 8: Filter Enabling or Disabling

Use case 9: Filter Enabling or Disabling

Use Case 10: Filter Enabling or Disabling

Additional Use Cases for Park Monitoring

Use Cases Related to DPark

Logical Partitioning Feature Use Cases

Shared Lines

Call Park Reversion with Shared Lines in Different Geographic Locations

ComponentUpdater Enhancement Use cases

IPv6 Support

Support for Cisco Unified IP Phone 6900 Series


Message Sequence Charts


This appendix contains the message sequence charts, which illustrate the message flows for the following scenarios:

Shared Line Support

Transfer and Direct Transfer

Conference and Join

Barge and Privacy

CallSelect and UnSelect

Dynamic CTIPort Registration Per Call

Media Termination at Route Point

Redirect Set OriginalCalledID

Single Step Transfer

Modifying Calling Number

AutoAccept for CTIPort and RoutePoint

Forced Authorization and Customer Matter Codes

Super Provider Message Flow

SuperProvider and Change Notification Enhancements Use Cases

QSIG Path Replacement

Device State Server

Partition Support

Hairpin Support

QoS Support

TLS Security

SRTP Key Material

Device and Line Restriction

SIP Support

SIP REPLACE

Unicode Support

Backward Compatibility Enhancements

Half Duplex Media

Recording and Monitoring

Intercom

Do Not Disturb

DND-R

Secure Conferencing

JTAPI Cisco Unified IP 7931G Phone Interaction

Locale Infrastructure Development Scenarios

Calling Party Normalization

Click to Conference

Call Pickup

selectRoute() with Calling Search Space and Feature Priority

Extension Mobility Login Username

Calling Party IP Address

CiscoJtapiProperties

IPv6 Support

Connected Conference or Join Across Lines Use Cases - New Phones Behavior

Enhanced MWI Use Cases

Join Across Lines Enhancements

Swap or Cancel and Transfer or Conference Behavior Change

Drop Any Party Use Cases

Park Monitoring Support

Logical Partitioning Feature Use Cases

ComponentUpdater Enhancement Use cases

IPv6 Support

Support for Cisco Unified IP Phone 6900 Series

Shared Line Support

The following diagrams illustrate the message flows for Shared Line support.

AddressInService/AddressOutofService Events

Incoming Call to Shared Address

Outgoing Call from Shared Address

Shared Address Calling Itself

Transfer and Direct Transfer

The following diagrams illustrate the message flows for Transfer and Direct Transfer.

DirectTransfer/Arbitrary Transfer Scenario

Direct Transfer/Arbitrary Transfer—Page 2

Consult Transfer

The message flow for Consult Transfer acts the same as the flow for Arbitrary Transfer.

Conference and Join

The following diagrams illustrate the message flows for Conference and Join.

Join/Arbitrary Conference

Join/Arbitrary Conference—Page 2

Consult Conference

The message flow for Consult Conference acts the same as the flow for Arbitrary Conference.

Join Across Lines with Enhancements

The message flows for Join Across Lines with Enhancements are described in following tables. A, C, D, E and F are addresses on different terminals. B1 and B2 are addresses on the same terminal, TermB.

Action
Events

Application conferences the two calls on B1and B2 by invoking GC1.conference(GC2) to chain two conference call.

Events to CallObserver of A,C and B1:

TermConnActiveEv TermB GC1

CallCtlTermConnTalkingEv TermB GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1

ConnConnectedEv Conference-2 GC1

CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv GC1

Ev.getAddedConnection will return connection for Conference-2

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2

Ev.getConferenceChain().getChainedConferenceCalls() will return GC1

Event for CallObserver at B2, D & E:

ConnDisconnectedEv B2 GC2 Cause=NORMAL

CallCtlConnDisconnectedEv B2 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

TermConnDroppedEv TermB GC2 Cause=NORMAL

CallCtlTermConnDroppedEv TermB GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC2

ConnConnectedEv Conference-1 GC2

CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2

Ev.getAddedConnection will return connection of Conference-1

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 & Conference-2

Ev.getConferenceChain().getChainedConferenceCalls() will return GC1 & GC2

Application invokes GC2.conference (GC1) to chain two conference calls.

Event for CallObserver at B2, D & E:

TermConnActiveEv TermB GC2

CallCtlTermConnTalkingEv TermB GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC2

ConnConnectedEv Conference-1 GC2

CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2

Ev.getAddedConnection will return connection for Conference-1

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1

Ev.getConferenceChain().getChainedConferenceCalls() will return GC2

Events for CallObservers at A, B1 & C:

ConnDisconnectedEv B1 GC1 Cause=NORMAL

CallCtlConnDisconnectedEv B1 GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

TermConnDroppedEv TermB GC1 Cause=NORMAL

CallCtlTermConnDroppedEv TermB GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1

ConnConnectedEv Conference-2 GC1

CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1

Ev.getAddedConnection will return connection for Conference-2

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2

Ev.getConferenceChain().getChainedConferenceCalls() will return GC1

A, B1, C are in conference-1 (GC1), B1,D, E are in conference-2 (GC2), B2, F, G are in conference-3 (GC-3)

Application completes conference at C by initiating GC1.conference(GC2, GC3) setting B1 as controller.

Event for CallObserver at A, B1 & C:

TermConnActiveEv TermB GC1

CallCtlTermConnTalkingEv TermB GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1

ConnConnectedEv Conference-2 GC1

CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1

Ev.getAddedConnection will return connection for Conference-2

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2

Ev.getConferenceChain().getChainedConferenceCalls() will return GC1

TermConnDroppedEv TermB GC2

CallCtlTermConnDroppedEv TermB GC2

ConnCreatedEv Conference-3 GC1

ConnConnectedEv Conference-3 GC1

CallCtlConnEstablishedEv Conference-3 GC1 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1

Ev.getAddedConnection will return connection for Conference-3

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 & Conference-3

Ev.getConferenceChain().getChainedConferenceCalls() will return GC2 & GC3

 

Event for CallObserver at B1,D & E:

ConnDisconnectedEv B1 GC2 Cause=NORMAL

CallCtlConnDisconnectedEv B1 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

TermConnDroppedEv TermB GC2 Cause=NORMAL

CallCtlTermConnDroppedEv TermB GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC2

ConnConnectedEv Conference-1 GC2

CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2

Ev.getAddedConnection will return connection for Conference-1

Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1-GC2

Ev.getConferenceChain().getChainedConferenceCalls() will return GC2

 

Event for CallObserver at B2, F & G:

ConnDisconnectedEv B2 GC3 Cause=NORMAL

CallCtlConnDisconnectedEv B2 GC3 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

TermConnDroppedEv TermB GC3 Cause=NORMAL

CallCtlTermConnDroppedEv TermB GC3 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC3

ConnConnectedEv Conference-1 GC3

CallCtlConnEstablishedEv Conference-1 GC3 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC3

Ev.getAddedConnection will return connection for Conference-1

Ev.getConferenceChain().getChainedConferenceConnections() will returnconnections of Conference-1

Ev.getConferenceChain().getChainedConferenceCalls() will return GC3


Action
Events

Application sets the requestor as B2 and calls GC2.conference(GC1) getControllerAddress() returns B2. getOriginalControllerAddress() returns B1.

A

CiscoConferenceStartEv
CallCtlTermConnTalkingEv TermB GC1
ConnCreatedEv D GC1
ConnConnectedEv D GC1
CallCtlTermConnDroppedEv TermB GC2
CiscoConferenceEndEv

B1

CallCtlTermConnHeldEv TermB GC1
CiscoConferenceStartEv
CallCtlTermConnTalkingEv TermB GC1
ConnCreatedEv D
ConnConnectedEv
CiscoConferenceEndEv

B2

ConnDisconnectedEv B GC2
CallCtlTermConnHeldEv TermB GC2

D

CallActiveEv GC2
ConnAlertingEv D GC2
ConnConnectedEv D GC2
CiscoConferenceStartEv
TermConnDroppedEv TermB GC2
CallActiveEv GC1
CiscoCallChangedEv
TermConnTalkingEv TermB GC1
TermConnDroppedEv TermD GC2
CallObservationEndedEv GC2
CiscoConferenceEndEv

If application uses B1 as request controller in the above setup getControllerAddress() returns B1. getOriginalControllerAddress() returns B1.

Events are same as above


Barge and Privacy

The following diagrams illustrate the message flows for Barge and Privacy.

Barge

CBarge

Privacy

CallSelect and UnSelect

The following diagram illustrates the message flows for CallSelect and UnSelect.

Dynamic CTIPort Registration Per Call

The following diagram illustrates the message flows for Dynamic CTIPort Registration per call.

Media Termination at Route Point

The following diagrams illustrate the message flows for Media Termination at Route Point.

Redirect Set OriginalCalledID

The following scenario illustrates the message flows for Redirect Set OriginalCalledID.

Scenario One

A, B, and C appear in an applications controlled list.

D is does not appear in the control list.

A calls B.

B redirects call to D with C as preferredOriginalCalledParty.

Application will see following events for parties A and B:

Meta Event Cause
Call
Event
Fields

META_CALL_ADDING_PARTY

Call 1

ConnCreatedEv for D
ConnConnectedEv for D
CallCtlConnEstablishedEv for D

CallingParty=A
CalledParty = B
LastRedirectedParty=C
CurrentCalledParty=D

META_CALL_REMOVE_PARTY

Call 1

ConnDisconnectedEv for B
CallCtlConnDisconnectedEv for B
TermConnDroppedEv for B
CallCtlTermConnDroppedEv for B
CallObservationEndedEv for B

CallingParty=A
CalledParty = B
LastRedirectedParty=C
CurrentCalledParty=D



Note The specified event group may not be in the same order and might change depending on where parties are present in the cluster, on the load, and other conditions.


Scenario Two

A, B, and C do not appear in the Control list, and

D is in the application control list.

A calls B.

B redirects the call to D with C as preferredOriginalCalledParty.

The application will see following events for party D:

Meta Event Cause
Call
Event
Fields

META_CALL_STARTING

Call1

CallActiveEv
ConnCreatedEv for D
ConnInProgressEv for D
CallCtlConnOfferedEv for D
ConnCreatedEv for A
CallCtlConnInitiatedEv for A

CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D

META_CALL_PROGRESS

Call1

ConnAlertingEv for D
CallCtlConnAlertingEv for D
TermConnCreatedEv for D
CallCtlTermConnRingingEv for D
ConnConnectedEv for A
CallCtlConnEstablishedEv for A

CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D

META_CALL_PROGRESS

Call

ConnConnectedEv for D
CallCtlConnEstablishedEv for D
TermConnActiveEv for D
CallCtlTermConnTalkingEv for D

CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D


.

Single Step Transfer

Addresses A, B, and C appear in the control list, and the call between A and B is then gets transferred to C with B as the transfer controller. Applications will see the following events:

Action
Address A (5001)
Terminal CTIP1
Address B (5002)
Terminal CTIP2
Address C (5003)
Terminal CTIP3

Call.transfer(string)

ConnCreatedEv 5003 Cause: CAUSE_NORMAL

ConnInProgressEv 5003 Cause: CAUSE_NORMAL

CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL

CallControlCause: CAUSE_TRANSFER

ConnAlertingEv 5003 Cause: CAUSE_NORMAL

CallCtlConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

NEW META EVENT__
META_CALL_REMOVING_PARTY

TermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL

CallCtlTermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

ConnDisconnectedEv 5002 Cause: CAUSE_NORMAL

CallCtlConnDisconnectedEv 5002 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

CallActiveEv Cause: CAUSE_NEW_CALL

ConnCreatedEv 5003 Cause: CAUSE_NORMAL

ConnInProgressEv 5003 Cause: CAUSE_NORMAL

CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

ConnCreatedEv 5001Cause: CAUSE_NORMAL

ConnConnectedEv 5001 Cause: CAUSE_NORMAL

CallCtlConnEstablishedEv 5001Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

Call.transfer(string)

(continued)

CiscoRTPInputStartedEv Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL

ConnConnectedEv 5003 CAUSE_NORMAL

CallCtlConnEstablishedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_UNKNOWN

CallObservationEndedEv Cause: CAUSE_NORMAL

ConnAlertingEv 5003 Cause: CAUSE_NORMALCallCtlConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

TermConnCreatedEv CTIP3

TermConnRingingEv CTIP3Cause: CAUSE_NORMAL

CallCtlTermConnRingingEvImpl CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

CiscoRTPInputStartedEv Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL

ConnConnectedEv 2004 Cause: CAUSE_NORMAL

CallCtlConnEstablishedEv 5003Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

Call.transfer(string)

(continued)

   

TermConnActiveEv CTIP3 Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

CiscoRTPInputStoppedEv Cause: CAUSE_NORMAL

CiscoRTPOutputStoppedEv Cause: CAUSE_NORMAL

ConnDisconnectedEv 5001 Cause: CAUSE_NORMAL

CallCtlConnDisconnectedEv 5001 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

TermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL

CallCtlTermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

ConnDisconnectedEv 5003 Cause: CAUSE_NORMAL

CallCtlConnDisconnectedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

META_UNKNOWN

CallInvalidEv [#32] Cause: CAUSE_NORMAL


Modifying Calling Number

The following scenario illustrates the message flows for Modifying Calling Number.

Scenario One

The application controls the device Route Point (RP) and registers RP .

A and B are PNO and appear within the Cisco Unified Communications Manager cluster.

A calls RP.

Call arrives at RP

Action
Event
Fields

Call Arrives at RP

RouteEvent

State = ROUTE
getCurrentRouteAddress () = RP
getCallingAddress () = A
getCallingTerminal () = SEPA
(Terminal associated with A)

Application invokes

selectRoute( routeselected[],
callingsearchspace,
modifiyingcallingnumber[] ) where
routeSelected[] = C
callingSearchSpace =
CiscoRouteSession.DEFAULT_SEARCH_SPACE

RouteUsedEvent

State = ROUTE_USED
getCallingAddress () = A
getCallingTerminal () = SEPA
(Terminal associated with A)
getRouteUsed () = C

Application invokes

endRoute (ERROR_NONE)

RouteEndEvent

State = ROUTE_END
getRouteAddress () = RP


Scenario Two

The application is controls A and B.

A calls RP, which selects Route call to B with modified calling number as M.

Action
Event
Fields

A calls RP, which is not in controlled list.

NEW META EVENT_________META_CALL_
STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_CALL_
PROGRESS
CallCtlConnDialingEv A

NEW META EVENT_________META_CALL_
PROGRESS
CallCtlConnEstablishedEv A
ConnCreatedEv RP
ConnInProgressEv RP
CallCtlConnOfferedEv RP

getCallingAddress() = A
getCalledAddress() =
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()=
getModifiedCallingAddress()=A
getModifiedCalledAddress() =

getCallingAddress() = A
getCalledAddress() =
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()=
getModifiedCallingAddress()=A
getModifiedCalledAddress() =

getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=A
getModifiedCalledAddress() =B

Another application controls the RP selectRoute to B with modifying calling number as M.

NEW META EVENT_________META_CALL_
ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B
ConnDisconnectedEv RP
CallCtlConnDisconnectedEv RP

NEW META EVENT_________META_CALL_
PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B TermConnRingingEv B
CallCtlTermConnRingingEv B

getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B


getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP

getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B

B answers the call.

ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv B
CallCtlTermConnTalkingEv B

getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B


AutoAccept for CTIPort and RoutePoint

Forced Authorization and Customer Matter Codes

Scenario One

The application controls A and B; B requires a forced authorization code (FAC) to extend the call.

Action
Event

A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult().

NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A

NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. FAC_REQUIRED

Application enters additional digits by using CiscoConnection.addToAddress.

NEW META EVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B

NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B
TermConnRingingEv B
CallCtlTermConnRingingEv B
ConnConnectedEv B
CallCtlConnEstablishedEv B

B answers the call.

TermConnActiveEv B


Scenario Two

The application controls A and B; B requires both an FAC and a CMC (client matter code) to extend the call.

Action
Event

A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult().

NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause:
CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A

NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. FAC_CMC_REQUIRED

Application enters FAC code digits with # termination by using CiscoConnection.addToAddress within the T302 timer.

NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. CMC_REQUIRED

Application enters CMC code digits with # terminated by using CiscoConnection.addToAddress within T302 timer.

NEW META EVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B

NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B
TermConnRingingEv B
CallCtlTermConnRingingEv B

B answers the call.

ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv B
CallCtlTermConnTalkingEv B


Scenario Three

The application controls A and B;

B requires a CMC, and the application enters an invalid code.

Action
Event

A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult().

NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause:
CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A

NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. CMC_REQUIRED

The application enters the incorrect CMC digits (# terminated) by using CiscoConnection.addToAddress within the T302 timer limit.

The application receives reorder tone.

NEW META EVENT_________META_CALL_PROGRESS
ConnFailedEv A
CallCtlConnFailedEv A getCiscoCause () =
CiscoCallEv.FAC_CMC

NEW META EVENT_________META_CALL_ENDING
TermConnDroppedEv
CallCtlTermConnDropped
ConnDisconnectedEv
CallCtlConnDisconnectedEv
CallInvalidEv
CallObservationEndedEv


Scenario Four

The application controls both A and B; A calls B; B redirects the call to C, which needs both an FAC and a CMC.

Action
Event

A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult().

NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL

NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A

NEW METAEVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B

NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv SEPB
TermConnRingingEv SEPB
CallCtlTermConnRingingEv SEPB
ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv SEPB
CallCtlTermConnTalkingEv SEPB

B issues a redirect request to C and passes an FAC and a CMC code.

NEW META EVENT_________META_CALL_REMOVING_PARTY
TermConnDroppedEv SEPB
CallCtlTermConnDroppedEv SEPB Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED
ConnDisconnectedEv B Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnDisconnectedEv B Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED

NEW META EVENT_________META_CALL_PROGRESS

ConnCreatedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED

NEW META EVENT_________META_CALL_PROGRESS
ConnInProgressEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED

NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv A Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED

NEW META EVENT_________META_CALL_PROGRESS
ConnConnectedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR
CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR


Scenario Five

Application controls the device Route Point (RP) and registers the RP.

A and B are PNO and within the Cisco Unified Communications Manager cluster.

Action
Event
Fields

Call arrives at RP

RouteEvent

State = ROUTE
getCurrentRouteAddress () = RP
getCallingAddress () = A
getCallingTerminal () = SEPA (Terminal associated with A)

Application invokes

selectRoute(routeselected[], callingsearchspace, modifiyingcallingnumber[], preferredOriginalCdNumber[], preferredOriginalCdOption[],
facCode[],
cmcCode[]) where
routeSelected[] = B
callingSearchSpace = CiscoRouteSession.DEFAULT_SEARCH_SPACE
modifyingCgNumber = null,
preferredOriginalCdNumber = null,
preferredOriginalCdOption = CiscoRouteSession.DONOT_RESET_ORIGINALCALLED,
facCode[] = "facCode for B"
cmcCode[] = "cmcCode for B"

RouteUsedEvent

State = ROUTE_USED
getCallingAddress () = A
getCallingTerminal () =
SEPA (Terminal associated with A)
getRouteUsed () = B

Application invokes

endRoute (ERROR_NONE)

RouteEndEvent

State = ROUTE_END
getRouteAddress () = RP


Super Provider Message Flow

The application tries to create Terminal for CTIPort1 that has Addresses 2000 and 2001. The following events get sent to the application.

No.
Action
Event

1

Application invokes CiscoProvider.CreateTerminal(CTIPort1)
where
CiscoProviderCapabilities.
canObserveAnyTerminal() returns TRUE.

JTAPI would return CiscoTerminal object and the following events get sent:

CiscoTermCreatedEv CTIPort1<---------------
CiscoAddrCreated 2000<------------------------
CiscoAddrCreated 2001<-------------------------

2

If the application already has a terminal where the 2001 address already exists, that is, 2001 is a SharedLine Address.

Now, the application invokes CiscoProvider.CreateTerminal(CTIPort1)

JTAPI would return CiscoTerminal object and the following events get sent

CiscoTermCreatedEv CTIPort1<----------------
CiscoAddrCreated 2000<------------------------
CiscoAddrAddedToTerminalEv 2001<--------

3

Application invokes

CiscoProvider.
CreateTerminal(CTIPortX)
where CTIPortX does not exist in Cisco Unified Communications Manager cluster.

JTAPI would throw an exception: InvalidArgumentException

4

Application invokes

CiscoProvider.
CreateTerminal(CTIPort1)
where
CiscoProviderCapabilities.canObserve
AnyTerminal() returns FALSE.

JTAPI would throw an exception: PrivilegeViolationException


SuperProvider and Change Notification Enhancements Use Cases

New events have been added to JTAPI, which will be sent to applications in order to handle new failover scenario and change notification. This enhances JTAPI to handle failover scenarios and the time required to shift between Superprovider and normal user modes.

Scenario One

Superprovider user opens provider and opens a few devices in Superprovider mode which are not in control list. From admin pages, Superprovider privilege is removed.

Application receives CiscoProviderCapabilityChangedEvent event. JTAPI sends CiscoTermRemovedEv all the devices which are opened / acquired and are not in the control list. JTAPI will send provider OOS to application, CiscoTermRemovedEv to devices not in control list and will reopen connection to CTI. When connect succeeds, JTAPI will send provider in service event to the application. Else, it will close the provider.

Scenario Two

Normal user opens provider and opens a few devices in control list. From admin pages, Superprovider privilege is added to the user.

Application receives CiscoProviderCapabilityChangedEvent event. User will now be able to acquire/open devices not in its control list.

Scenario Three

Normal user opens provider and opens a few park DNs. From admin pages, park DN monitor privilege is removed for the user.

Application receives CiscoProviderCapabilityChangedEvent event. JTAPI will cleanup all park DN addresses.

Scenario Four

Normal user opens provider. From admin pages, park DN monitor privilege is added for the user.

Application receives CiscoProviderCapabilityChangedEvent event. Application registers the park DN monitoring feature and is able to monitor park DN.

Scenario Five

Normal user opens provider. From admin pages, "modify calling party" privilege is removed for the user.

Application receives CiscoProviderCapabilityChangedEvent event. Application is not able to change the calling party number during redirect. JTAPI will throw error if application tries to do this.

Scenario Six

Normal user opens provider. From admin pages, "modify calling party" privilege is added for the user.

Application receives CiscoProviderCapabilityChangedEvent event. Application is able to change the calling party number in a call during redirect.

Scenario Seven

Superprovider user opens provider and acquires a device not in control list. From admin pages, the device is deleted.

Application receives CiscoTermRemovedEv event. Device is closed from JTAPI perspective.

QSIG Path Replacement

The following table shows the JTAPI events that are delivered to applications when calls between PBXs that are connected by Q.Signaling (QSIG) trunks are transferred and forwarded. This table also shows the events that are delivered to applications when the real-time path (RTP) is optimized by the QSIG Path Replacement feature.

Calls going out on a QSIG trunk may not have a connection for the far end if any translation pattern is changing the pattern. In other words, when the application sees two calls in the trombone case, B may not serve as the common connection on the calls.

No.
Action
Event

1

A registered with CM1, B is registered with CM2, and C registered with CM3.

A calls B (GC1); B transfers the call to C. The application is monitors C. The PR feature replaces the path after the call gets connected to C.

The same action applies to scenarios that involve call forward at B. (The called party transfers the call.)

These events get delivered to applications:

CallCtrlConnectionEstablishedEv A

CallCtrlConnectionDisConnectEv B

OpenLogicalChannelEvent if C is a CTI device (Dynamically registered CTIPorts and RP)

2

A registered with CM1, B registered with CM2, and C registered with CM3. B calls C; C answers; B transfers the call to A. A answers. The application is monitors only C. (The calling party transfers the call.)

In this case, both A are C represent called parties when transfer completes. After the call is answered, PR replaces the path. In this case, A and C represent IP phones; the display will be updated as a part of PR feature operation, that makes either A or C as calling.

JTAPI events:
GC1: CallCtlConnEstablishedEv A
GC1: CallCtlConnDisconnectedEv B

3

3. Trombone case: A registered to CM1, B registered to CM2, and C registered to CM1. A calls B (GC1); B answers and transfers the call to C (GC2). Path replacement connects A and C bypassing CM2. The application observes both A and C. (The called party transfers the call.)

For GC1 Call Observer:

GC1: CallCtlConnEstablishedEv C

GC1: CallCtlConnDisconnected B

Before the PR feature replaces the path, the application sees two calls: GC1 with connections to A and C (external) and GC2 with connections to C and A (external).

When the PR feature replaces the path, either GC1 changes GC2, or GC2 changes to GC1.

Assuming A's GCID changes from GC1 to GC2:

GC1: CiscoCallChangedEv (oldGCID=GC1,newGCID=GC2)

GC1: CallCtlConnDisconnected for A

GC1: CallCtlConnDisconnected for C

GC1: CallInValid

GC2: TermConnTalkingEvent for TerminalA cause= CAUSE_QSIG_PR

4

Trombone case: A registered to CM1, B registered to CM2, and C registered to CM1. B calls A and transfers the call to C. Path replacement connects A and C, bypassing CM2. Application observes both A and C. (The calling party transfers the call.)

Before the PR feature replaces the path, the application will see two calls: GC1 with connections to A and B (external) and GC2 with connections to C and B (external). In this case, the application will not see any transfer start events.

When PR feature replaces the path, it updates the display of A and C and path gets replaced, resulting in a GCID change. Assuming A's GCID is changed and made the calling party, the following JTAPI events occur:

GC1: CiscoCallChangedEv (GC1 to GC2)

GC1: CallCtlConnDisconnected for A

GC1: CallCtlConnDisconnected for C

GC1: CallInValid

GC2: ConnCreatedEv A

GC2: ConnConnectedEv A

GC2: TermConnTalkingEvent for TerminalA cause= CAUSE_QSIG_PR

5

A registered to CM1, B registered to CM2, and C registered to CM1. A calls B; B transfers the call to C. C answers and before path replacement completes, C invokes a feature (park, redirect, and so on).

Path replacement gets abandoned.

6

In some conditions, call processing ignores feature requests (redirect, park, transfer, and so on). This happens when a setup request is sent out, and the local CM is waiting for connect from the other end.

JTAPI:

Exception will be thrown from JTAPI for feature requests.

7

In some cases, the application could receive dead air when CM goes down when the PR feature is trying to switch the RTP path. This could happen to a previously connected call.

No events

JTAPI Apps: Hang up the call


Device State Server

Partition Support

Since the address hashing mechanism in JTAPI has changed, this feature is expected to have performance degradation in address lookup time and during load tests.

Using getPartition() API

The example given below illustrates how getPartition(), will be used by JTAPI and applications, to differentiate between addresses having same DN but belonging to different partitions.

Example A-1 Using getPartition() API

In this case, there are three addresses which belong to three different partitions: A(2001, P1), B(2001, P2) and C(2001, P3), where 2001 indicates DN and P1, P2, and P3 denote different partitions.

When JTAPI calls provider.getAddress("2001"), the provider object will return an array of three address objects containing A, B and C, since all of them have the same DN.

The application and JTAPI will distinguish between the three addresses by using the getPartition() method of the address object.

Using getAddress (String number, String partition)

Consider the example shown below to see how JTAPI will use the getAddress (String number, String partition) API to retrieve the address object corresponding to a particular DN and partition when there are multiple addresses with same DN and different partitions.

Example A-2 Using getAddress (String number, String partition)

In this case, there are three addresses which belong to three different partitions. Let us denote them by A(2001, P1), B(2001, P2) and C(2001, P3), where 2001, indicates DN and P1,P2,P3 denote different partitions.

When JTAPI calls provider.getAddress("2001", "P1"), the provider object will return the address object which has the same DN i.e. 2001 and the same partition info, that is P1-as provided in the API. In this case, the address object A will be returned to the application.

Scenario of Simple Call

Consider the following scenario where A calls B. A has DN 1000 and calls B which also has DN 1000. A belongs to partition P1 and B belongs to partition P2. The following diagram illustrates the various events and the results of API calls pertaining to this scenario, which are relevant to partition support feature.

Example A-3 Simple Call Scenario

Park DN

Park DNs are also treated as addresses in JTAPI. Hence, the same treatment given to normal DN is also given to park DN. The following message flow illustrates how an application will use park DN partition information in a call where park DNs are involved.

Example A-4 Park DN Scenario

When the application is monitoring park DN, it is possible to have the park DN to be the same as a regular DN (while both belong to different partitions).

In this case, C is a park DN having same DN value as A and B while belonging to a different partition.

A receives a call and parks the call at C. B unparks the call. While the call is parked, and unparked, CiscoProvCallParkEv is generated. The API

getParkingPartyPartition(), getParkedPartyPartition() and getParkPartyPartition() return the associated address objects as shown in the figure.

Partition Change

Partition attribute is similar to the DN attribute of an address. Hence, whenever the partition attribute changes, the address object has to be destroyed and recreated. When the partition information of an address is changed, JTAPI will be restarted during which the current address objects will be deleted and new address objects will be created, reflecting the changed partition information.

Example A-5 Change in Partition

When the partition information of an address is changed, the address object will be destroyed and a new address object will be created.

The new address object will have the new partition information.

In the example given, Address A's partition string was changed to P4. Hence, the current address object of A will be deleted and a new address object will be created.

A query on the old address object using A.getPartition() will retrieve "P1", while the same query on the new object will return "P4".

When the address partition changes, applications should query the address objects to update their partition information.

JTAPI Partition Support

The common assumption for all of the following use cases is that CTI provides partition information for all the lines which the JTAPI opens in the response message and JTAPI stores the partition information for every address it maintains.

S.No.
Pre-Condition
Scenario
Expected Behavior
Result

1

A and B are two addresses in the same cluster with same DN and different partitions (P1, P2) and in same cluster. A calls B. CSS of A has B's partition in it first.

Calls between addresses with same DN in different device but different partitions should go through.

Two address objects are created, one for A and one for B. All the appropriate call related events are delivered to both the addresses.

Call is established between A and B

2

A and B are two addresses with same DN in same device but different partitions (P1, P2) and in same cluster. A calls B. CSS of A has B's partition in it first.

Calls between addresses with same DN in same device but different partitions should go through.

Two address objects are created, one for A and one for B. All the appropriate call related events are delivered to both the addresses.

Call is established between A and B.

3

A, B, and C are three different addresses with different DN. (P1, P2, P3). A park DN is configured with same DN as C and different partition (P4).

A calls B. B parks the call. C unparks the call from a park DN which is same as C's DN.

JTAPI should allow C to unpark the call from park DN.

C is successfully able to unpark the call from park DN.

4

A, B, and C are three different addresses having the same DN and different partitions (P1, P2, P3). A park DN is configured with same DN but belonging to a different partition (P4)

A calls B, B parks call at park DN. C unparks the call.

JTAPI should allow C to unpark the call from park DN.

A is able to call B. B should be able to park the call at the park DN.

C should be able to pick up the call.

5

A, B, and C are three different addresses with same DN and different partitions (P1, P2, and P3)

JTAPI calls getPartitionAddress(DN of A).

Three address objects are returned each corresponding to A, B and C.

JTAPI maintains the address objects based on partition info and DN.

6

A and B are addresses with same DN but belong to different partitions (P1, P2).

Application calls getPartition() on the address objects of A and B.

 

Partition strings of the addresses are returned correctly.

7

A and B are two different addresses (different DNs) belonging to different partitions. A and B are in the control list of the same user. Provider open is completed and the lines are opened.

JTAPI supports old API to open lines when DN is different. There will be no change in behavior.

Lines A and B will be opened, but since they have different DN, user need not specify the partition info. DN alone is sufficient to open the lines, but users can also give partition info and both modes of opening lines will be supported by JTAPI.

Address objects for A and B are created successfully.

8

A is an address in the control list of user and is opened by the user. From the CM admin page the partition information of A is changed. The device is restarted after this.

Partition information of a DN is changed. JTAPI should reflect new partition information.

JTAPI will delete the current address object and create a new address object for A when it comes in service again. By querying the partition info of this address object, user should get changed partition info.

New partition information is reflected in the new address object.


Hairpin Support

S.No.
Pre-Condition
Use Case
Expected Behavior
Result

1

IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C. Gateway does not pass new party information to each other. There will be no transfer start and end events as transfer controller is not a controlled device.

A calls B via gateway. B transfers call to C via gateway. B completes the transfer and goes out of scenario. Now IP Phones A and C are connected

At A: It is connected to B.
A's type is CiscoAddress.Internal
B's type is CiscoAddress.External
At C: It is connected to B.
C's type is CiscoAddress.Internal
B's type is CiscoAddress.External

A and C are connected.

2

IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C. Gateway is able to pass new party information to each other.

A calls B via gateway. B transfers call to C via gateway. B completes the transfer and goes out of scenario. Now IP Phones A and C are connected.

At A: It is connected to C.
A's type is CiscoAddress.Internal
C's type is CiscoAddress.External
At C: It is connected to A.
C's type is CiscoAddress.Internal
A's type is CiscoAddress.External

A and C are connected.

3

IP Phones A and B are in same cluster, IP phone C is in another cluster. JTAPI observes A and B.

A calls B. B does a conference call to C via gateway. B completes the conference and all A,B and C are in conference.

At A and B, ConferenceCallStateChanged event has participantInfo with following types:
A: CiscoAddress.Internal
B: CiscoAddress.Internal
C: CiscoAddress.External

A, B and C are in conference call.

4

IP Phones A and B are in same cluster, IP phone C is in another cluster. JTAPI observes A,B and C.

A calls B. B does a conference call to C via gateway. B completes the conference and all A,B and C are in conference.

At A and B, ConferenceCallStateChanged event has participantInfo with following types:
A: CiscoAddress.Internal
B: CiscoAddress.Internal
C: CiscoAddress.External

A, B and C are in conference call.

5

IP Phones A, B, C are in same cluster, IP phone D is in another cluster. JTAPI observes A, B and C. Gateway is able to pass new party information to each other.

A calls B. B does a conference call to D via gateway. D transfers the call to C. B completes the conference and all A,B and C are in conference.

At A and B, ConferenceCallStateChanged event has participantInfo with following types:
A: CiscoAddress.Internal
B: CiscoAddress.Internal
C: CiscoAddress.External

A, B and C are in conference call.

6

IP Phones A, B, C are in same cluster, IP phone D is in another cluster. JTAPI observes A, B and C. Gateway does not pass new party information to each other.

A calls B. B does a conference call to D via gateway. D transfers the call to C. B completes the conference and all A,B and C are in conference.

At A and B, ConferenceCallStateChanged event has participantInfo with following types:
A: CiscoAddress.Internal
B: CiscoAddress.Internal
D: CiscoAddress.External

A, B and C are in conference call.

7

IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C.

A calls B via gateway. B redirects call to C. Now IP Phones A and C are connected.

At A: It is connected to C.
A's type is CiscoAddress.Internal
C's type is CiscoAddress.External
At C: It is connected to A.
C's type is CiscoAddress.Internal
A's type is CiscoAddress.External

A and C are connected.


QoS Support

Figure A-1 Call Flow Diagram for QoS Support

JTAPI QoS

For QoS to work in Windows, complete the following steps:


Step 1 Start Registry Editor (Regedt32.exe).

Step 2 Go to the following key:

HKEY_LOCAL_ MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\


Note The registry key is one path.


Step 3 On the Edit menu, click Add Value.

Step 4 Type DisableUserTOSSetting.

Step 5 Click REG_DWORD in the Data Type box.

Step 6 Click OK.

Step 7 Enter 0 in the prompt box.

Step 8 Quit the Registry Editor.

Step 9 Restart the computer.


For more information on this see http://support.microsoft.com/default.aspx?scid=kb;en-us;248611

Scenario
JTAPI Behavior

Application uses the JTAPI getPrecedenceValue() API to query for the new DSCP value, in CiscoRTPOutputStartedEvent.

JTAPI returns the DSCP value received from CTI in StartTransmissionEvent to the application.

Application uses the JTAPI getAppDSCPValue() API to query for the new DSCP value, when it gets ProviderInServiceEvent.

JTAPI returns the DSCP value received from CTI in ProviderOpenCompletedEvent to the application.


TLS Security

Message flow for updating certificate and establishing TLS certificate is illustrated in Figure A-2 and Figure A-3.

Figure A-2 CTI/API Security Approach

Figure A-3 CTI/API Security Approach (continued)

SRTP Key Material

If this feature is enabled, it is expected to degrade the performance of Cisco Unified JTAPI. Performance degradation is because of encrypted signaling between CTI and JTAPI and also because of encrypted media between end points.

Scenario One

Action
Event

App adds CallObserver on an Address 1 and initiates a call to address2 and involves in secure media conversation.

If user is authorized, then CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv contain key material.

CiscoRTPInputKeyEv
CiscoRTPInputStartedEv
CiscoRTPOutputKeyEv
CiscoRTPOutputStartedEv


Scenario Two

Action
Event

Application adds TerminalObserver by enabling snapshotEnabled filter. Device is already in a secure call and queries invokes CiscoTerminal.createSnapshot ()

CiscoTermSnapshotEv using which applications can query getCiscoMediaCallSecurity () to find out if a call is secured or not.


Scenario Three

Action
Response

Application does not have a TLS link and tries to register with secure media.
CiscoMediaTerminal.register (ipAddr, portNum, mediaCaps, algorithm)

PrivilegeViolationException is thrown to the application

Application has a secure media and registers CiscoMediaTerminal.register (ipAddr, portNum, mediaCaps, algorithm)

Request is successful


Device and Line Restriction

S.No
Scenario
Events

1

Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list. T1 and A3 is added into the restricted list. Application opens the provider

Application queries for is Restricted on T1,T2, T3

Application queries for is Restricted on Address A1, A2, A3


Application tries to addObserver and addCallObserver on T1,T2,T3, A1,A2,A3





CiscoTerminal.isRestricted() returns true for T1 and false for T2 and T3

CiscoAddress.isRestricted() returns true for A1, A3, false for A2.

CiscoAddress.getRestrictedAddrTerminals() on A1, A3 returns T1, T3 respectively, returns null for A2.

addObserver and addCallObserver fails for T1, A1, A3. For T3 observer is added, but no events are received on A3. For A2, application will be able to add observers successfully and events will be received

2

Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list.

Application opens the provider and adds observer on all terminals and addresses.

T1 and A2 are added to the restricted list.

T1 and L2 are removed from restricted list



CiscoTermRestrictedEv for T1 CiscoAddrRestrictedEv for L1
CiscoAddrRestrictedEv for A2 sent to providerObserver.

CiscoTermOutOfServiceEv for T1 CiscoAddrOutOfServiceEv for L1
CiscoAddrOutOfServiceEv for A2

CiscoTermActivatedEv for T1 and CiscoAddrActivatedEv for A1
CiscoAddrActivatedEv for A2 sent to providerObserver.
CiscoTermInServiceEv for T1and CiscoAddrInServiceEv for A1
CiscoAddrInServiceEv for A2 sent to terminal and address observers.

3

Application has Devices T1, T2, T3 whose lines are A1, A1, A2 in the control list. A1 is the shared line on T1 and T2

Application opens provider and adds observer on all terminals/addresses

T1 is added into the restricted list.



T1 is removed from the restricted list





Application will see CiscoTermRestrictedEv for T1 and CiscoAddrRestrictedOnTerminalEv which contains getAddress is L1 and getTerminal as T1. Application will also see CiscoTermOutOfServiceEv for T1 and CiscoAddrOutOfService for A1/T1

CiscoTermActivatedEv for T1
CiscoAddrActivatedEv for L1
CiscoTermInServiceEv for T1
CiscoAddrInServiceEv for A1/T1

4

Application has Devices T1, T2, T3 whose lines are A1, A1, A1 in the control list. A1 is the shared line on T1, T2 and T3

Application opens the provider and adds observer on all terminals and addresses

A1 on T1 is added to the
restricted list

A1 on T2 is added to the
restricted list

A1 on T3 is added to the
restricted list

A1 on T1 is removed from the restricted list

A1 on T2 is removed from the restricted list

A1 on T3 is removed from the restricted list






CiscoAddrRestrictedOnTerminalEv for A1/T1
CiscoAddrOutOfServiceEv for A1/T1

CiscoAddrRestrictedOnTerminalEv for A1/T2
CiscoAddrOutOfServiceEv for A1/T2

CiscoAddrRestrictedEv for A1
CiscoAddrOutOfServiceEv for A1/T3

CiscoAddrActivatedOnTerminalEv for A1/T1
CiscoAddrInServiceEv for A1/T1

CiscoAddrActivatedOnTerminalEv for A1/T2
CiscoAddrInServiceEv for A1/T2

CiscoAddrActivatedEv for A1
CiscoAddrInServiceEv for A1/T3

5

Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list.

Application opens the provider and adds observer on all terminals and addresses. A1 is involved in a call with party X.

A1 is added into the restricted list.

CiscoAddrRestrictedEv for A1
CiscoAddrOutOfServiceEv for A1

ConnDisconnectedEv CallCtlConnDisconnectedEv TermConnDroppedEv
CallCtlConnDroppedEv
CallInvalidEv


SIP Support

S.No
Scenario
Events

1

External SIP phone
(external@someserver.com) calls A, A is monitored by application.

Assuming external sip phone uses uri and not DN.

Event delivered to call observer on A

CallActiveEv
ConnCreatedEv A
ConnCreatedEv unknown

getCurrentCallingPartyInfo().geUrlInfo().getUser() returns external.

getCurrentCallingPartyInfo().geUrlInfo().getHost() returns someserver.com

getCurrentCallingPartyInfo().geUrlInfo().getUrlType() returns SIP_URL_TYPE

2

7970 runs SIP protocol with 2 max calls set. 3rd call comes in with GCID=GCID3

GCID3 CallActiveEv
GCID3 ConnCreatedEv A
GCID3 ConnFailedEv A
GCID3 callInvalidEv

3

7960 running SIP is included in the control list. Applications add callobserver on the terminal

Exception is thrown to addobserver exception. TerminalRestrictedEv will be delivered if the status changed.


SIP REPLACE

For the JTAPI events in the scenario described below, we have not shown Terminal events. It will be sent for all the observed Terminals as usual. Also events are shown with the assumption that only A, B, or C is observed; events would vary if combination of A, B, or C is observed.

SN
Scenario
Events at A
Events at B
Events at C

1.

REPLACE with INVITE a confirmed Dialog:

A (Dialog1) is in Call with B(Dialog2)(GC1). C sends INVITE with REPLACE Dialog2(GC2). After replace is completed, A(Dialog1) and C(Dialog3) are in the Call

GCID and CPIC with reason REPLACES, Cgpn=C, Cdpn=A, Ocdpn=A, Lrp=B

JTAPI Events:

CiscoCallChangedEv-(GC1-GC2) ConnDisconnectedEv -B-GC1 CallCtlConnDisconnected
Ev-B-GC1 ConnDisconnectedEv -A-GC1 CallCtlConnDisconnected
Ev-A-GC1 CallInvalid-GC1

CallActive-CG2 ConnCreatedEv -C-GC2 ConnConnectedEv -C-GC2 CallCtlConnEstablishedEv-C-CG2

ConnCreatedEv -A -GC2 ConnConnectedEv -A-GC2 CallCtlConnEstablishedEv-A-CG2

Cause =CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=C, Called=A, CurrentCalling=C, CurrentCalled=A, LastRedirecting=B

CSCE IDLE with reason REPLACES



JTAPI Events:

ConnDisconnectedEv -A -GC1 CallCtlConnDisconnected
Ev-A-GC1

ConnDisconnectedEv -B-GC1 CallCtlConnDisconnected
Ev-B-GC1

CallInvalidEv-GC1

CAUSE_NORMAL

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

NewCall/CSCE-Dialing/ CSCE-Connected with Cgpn=C, Cdpn=A, Ocdpn=B, Lrp=B

JTAPI Events:

CallActiveEv -GC2 ConnCreatedEv -C -GC2 ConnConnectedEv-C--GC2 CallCtlConnEstablishedEv
-C-GC2

ConnCreatedEv -A-GC2 ConnConnectedEv A--GC2 CallCtlConnEstablishedEv
-A--GC2

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES



JTAPI CallInfo:

Calling=C, Called=A, CurrentCalling=C, CurrentCalled=A, LastRedirecting=B

2.

REPLACE with INVITE an early Dialog:

A (Dailog1) is in Call with B(Dialog2)(GC1), B is ringing. C sends INVITE with REPLACE Dialog2(GC2). After replace completed, A(Dialog1) and C(Dialog3) in the Call

GCID and CPIC with reason REPLACES, Cgpn=C, Cdpn=A, Ocdpn=A, Lrp=B

JTAPI Events CiscoCallChangedEv-(GC1-GC2) ConnDisconnectedEv -B-GC1 CallCtlConnDisconnected
Ev-B-GC1 ConnDisconnectedEv -A-GC1 CallCtlConnDisconnected
Ev-A-GC1 CallInvalid-GC1

CallActive-CG2 ConnCreatedEv -C-GC2 ConnConnectedEv -C-GC2 CallCtlConnEstablishedEv-C-CG2

ConnCreatedEv -A -GC2 ConnConnectedEv -A-GC2 CallCtlConnEstablishedEv-A-CG2

Cause =CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=C, Called=A, CurrentCalling=C, CurrentCalled=A, LastRedirecting=B

CSCE-Idle with reason REPLACES

JTAPI Events:

ConnDisconnectedEv -A -GC1 CallCtlConnDisconnected
Ev-A-GC1

ConnDisconnectedEv -B-GC1 CallCtlConnDisconnected
Ev-B-GC1

CallInvalidEv-GC1

CAUSE_NORMAL

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

NewCall/CSCE-Dialing/CSCE-Connected, with Cgpn=C, Ccdpn=A, Ocdpn=A, Lrp=B

JTAPI Events:

CallActiveEv -GC2 ConnCreatedEv -C -GC2 ConnConnectedEv-C--GC2 CallCtlConnEstablishedEv-C-GC2

ConnCreatedEv -A-GC2 ConnConnectedEv A--GC2 CallCtlConnEstablishedEv-A--GC2

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=C, Called=A, CurrentCalling=C, CurrentCalled=A, LastRedirecting=B

3.

REPLACE with INVITE an early Dialog:

A (Dialog1) is in Call with B(Dialog2) (GC1), B is ringing. C sends invite with replace Dialog-X (GC2)

   

NewCall/CSCE_Dialing/ reason REPLACES CSCE-Disconnected with reason REPLACES

JTAPI Events:

CallActiveEv -GC2 ConnCreatedEv -C-GC2 ConnConnectedEv -C-GC2 CallCtlConnEstablishedEv-C--GC2

ConnFailedEv -C--GC2 ConnConnectedEv -C--GC2 CallCtlConnEstablishedEv-A--GC2

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=C, Called=, CurrentCalling=C, CurrentCalled=, LastRedirecting=

4.

REFER request with REPLACE Dialog:

When REPLACE Dialog is in a Cisco Unified Communications Manager Cluster.

A is in call with B(REFEREE) Dialog1, and Dialog2

A is in Call with C(REFER TO TARGET) Dialog3 and Dialog4

SIP-UA A send REFER B on Dialog1 to C with REPLACES Dialog3

TransferStartEv

CSCE-Idle at Dialog1 with reason TRANSFER and at Dialog3 with reason TRANSFER

TransferEndEv

JTAPI Event:

Regular TransferEvent

TransterStartEv

CPIC with reason TRANSFER and Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

TransferEndEv

JTAPI Event:

Regular TransferEvents

TransferStartEv

GCID with reason TRANSFER and Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

TransferEndEv

JTAPI Event:

Regular TransferEvents

5.

REFER request with REPLACE Dialog:

When REPLACE Dialog is outside Cisco Unified Communications Manager Cluster

SIP-UA A is in call with B, Dialog1 and Dialog2(GC1)

SIP-UA A is in call with SIP-UA C Dialog3

SIP-UA A sends REFER B on Dialog1 to SIP-UA C with REPLACES Dialog3

No Events

CPIC with reason REFER and Cgpn=B, Cdpn=C, Lrp=A OCdpn=B

JTAPI Events:

ConnDisconnectedEv -A-GC1 CallCtlConnDisconnectedEv-A-GC1

ConnCreatedEv - C -GC1 ConnConnectedEv -C-GC1 CallCtlConnEstablishedEv -C-GC1

Cause = CAUSE_NORMAL CiscoFeatureReason=REASON_REFER

JTAPI CallInfo:

Calling=A, Called=B, CurrentCalling=B, CurrentCalled=C, LastRedirecting=A

No Events

6.

REFER request with REPLACE Dialog:

When A is outside a Cisco Unified Communications Manager Cluster

SIP-UA A is in call with B, Dialog1 and Dialog2

SIP-UA A is in call with C Dialog3 and Dialog4

SIP-UA A sends REFER B on Dialog1 to C with REPLACES Dialog3

No Events

CPIC with reason REPLACES and Cgpn=B, Cdpn=C, Lrp=A, OCdpn=C

JTAPI Events:

ConnDisconnectedEv -A-GC1 CallCtlConnDisconnected
Ev-A-GC1

ConnCreatedEv - C- GC1 ConnConnectedEv -C -GC1 CallCtlConnEstablishedEv -C-GC1

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES






JTAPI CallInfo:

Calling=A, Called=B, CurrentCalling=B, CurrentCalled=C, LastRedirecting=A

GCID with reason REPLACES and Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

JTAPI Events:

CiscoCallChangedEv(GC2-GC1) ConnDisconnectedEv -A-GC2 CallCtlConnDisconnected
Ev-A-GC2

ConnDisconnectedEv -C-GC2 CallCtlConnDisconnected
Ev-C-GC2 CallInvalid-GC2

CallActive-CG1 ConnCreatedEv -B -GC1 ConnConnectedEv -B-GC1 CallCtlConnEstablishedEv-B-CG1

ConnCreatedEv -C-GC1 ConnConnectedEv -C-GC1 CallCtlConnEstablishedEv-C-CG1

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=A, Called=B, CurrentCalling=B, CurrentCalled=C, LastRedirecting=A

7.

REFER request with REPLACE Dialog:

When REPLACE Dialog is in a Cisco Unified Communications Manager Cluster.

A is in call with B(REFEREE) Dailog1, and Dialog2 (GC1)

D is in Call with C(REFER TO TARGET) Dialog3 and Dialog4 (GC2)

A sends REFER B on Dialog1 to C with REPLACES Dialog3

B and C in final call.

CSCE-Idle at Dialog1 with reason REFER and at Dialog3 with reason REPLACES

JTAPI Events:

ConnDisconnectedEv -A -GC1 CallCtlConnDisconnected
Ev-A-GC1

ConnDisconnectedEv -B-GC1 CallCtlConnDisconnected
Ev-B-GC1 CallInvalidEv-GC1

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REFER

Event at D:

ConnDisconnectedEv -D -GC2 CallCtlConnDisconnectedEv-D-GC2

ConnDisconnectedEv -C-GC2 CallCtlConnDisconnectedEv-C-GC2 CallInvalidEv-GC2

Cause = CAUSE_NORMAL CiscoFeatureReason=REASON_REPLACES

CPIC with reason REPLACES and Cgpn=B, Cdpn=C, Lrp=D OCdpn=C

JTAPI Events:

ConnDisconnectedEv -A-GC1 CallCtlConnDisconnected
Ev-A-GC1

ConnCreatedEv -C-GC1 ConnConnectedEv -C -GC1 CallCtlConnEstablishedEv-C-GC1

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES






JTAPI CallInfo:

Calling=A, Called=B, CurrentCalling=B, CurrentCalled=C, LastRedirecting=D

GCID with reason REPLACES and Cgpn=B, Cdpn=C, Lrp=D, OCdpn=C

JTAPI Events:

CiscoCallChangedEv(GC2-GC1) ConnDisconnectedEv -D CallCtlConnDisconnected
Ev-D

ConnDisconnectedEv -C CallCtlConnDisconnected
Ev-C CallInvalid-GC2

CallActive-CG1 ConnCreatedEv -C-GC1 ConnConnectedEv -C-GC1 CallCtlConnEstablishedEv-C-CG1

ConnCreatedEv -B -GC1 ConnConnectedEv -B-GC1 CallCtlConnEstablishedEv-B-CG2

Cause = CAUSE_NORMAL CiscoFeatureReason=
REASON_REPLACES

JTAPI CallInfo:

Calling=C, Called=C, CurrentCalling=B, CurrentCalled=C, LastRedirecting=D


SIP REFER

The following section describes the scenarios that might be encountered during a SIP REFER. There are two categories of REFER scenarios: IN-Dialog and OutOfDialog.

IN-Dialog REFER Scenario

There are 11 scenarios (A through K) described in the sections that follow for IN-Dialog REFERs.

Scenario One

A (SIP UA in cluster/in control) is in a call with B.
A (referrer) REFERs B (Referee) to C (Refer to target), C is Ringing.

JTAPI moves A's Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection into the "UNKNOWN" state.

CAUSE_CODE provided will be CAUSE_NORMAL, new API provides REASON_REFER.

For C a new Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection would be created.

CallInfo at B and C would be as follows:

At B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

At C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

Scenario Two

A(SIP UA in cluster/in control) is in a call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C Answers the Call.

JTAPI will Disconnect/Drop A's Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API would provide REASON_REFER.

For C Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to the Connected/Established/Active/Talking state.

CallInfo at B and C will be as follows

At B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

At C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

Scenario Three

A(SIP UA inside cluster) is in a call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C is ringing but C did not answer the call and has no forward configured. Refer fails, the original call between A and B is restored.

JTAPI will Disconnect/Drop the Connection/CallControlConnection/TerminalConnection/
CallControlTerminalConnection for C. CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER and move A's Connection/CallControlConnection/
TerminalConnection/CallControlTerminalConnection from the "Unknown" state to the Connected/
Established/Active/Talking state.

CallInfo at A and B will be as follows

At A: Cgpn=A, Cdpn=B, Lrp= OCdpn=B

At B: Cgpn=A, Cdpn=B, Lrp= OCdpn=B

JTAPI Application observing A will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=A

getCurrentCalledParty()=B

getLastRedirecting()= NULL

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=A

getCurrentCalledParty()=B

getLastRedirecting()=NULL

Scenario Four

A(SIP UA outside cluster) is in call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C is ringing.

JTAPI will create Connection/CallControlConnection/TerminalConnection/
CallControlTerminalConnection for C and will drop A's Connection/CallControlConnection on getting CPIC at B, CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER.

CallInfo at B and C will be as follows:

At B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

At C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

Scenario Five

A(SIP UA outside cluster) is in a call with B.
A(referrer) refers B(Referee) to C(Refer to target), C is ringing but C did not answer the call and has no forward configured. Refer fails, the original Call between A and B is restored.

JTAPI will create Connection/CallControlConnection for A again and drops Connection/
CallControlConnection/TerminalConnection/CallControlTerminalConnection for C.
CAUSE_CODE provided will be CAUSE_NORMAL and new API will provide REASON_REFER.

CallInfo at A and B will be as follows

At A: Cgpn=A, Cdpn=B, Lrp= OCdpn=B

At B: Cgpn=A, Cdpn=B, Lrp= OCdpn=B

JTAPI Application observing A will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=A

getCurrentCalledParty()=B

getLastRedirecting()=NULL

JTAPI Application observing C will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=A

getCurrentCalledParty()=B

getLastRedirecting()=NULL

Scenario Six

A(SIP UA in cluster/in control) is in a call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C answers the call.

JTAPI moves Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for C to the Connected/Established/Active/Talking state. CAUSE_CODE provided is CAUSE_NORMAL and the new API will provide REASON_REFER.

CallInfo at B and C will be as follows

At B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

At C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

Scenario Seven

A(SIP UA in cluster/in control) is in a call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C forwardAll to D, D is ringing.

JTAPI creates Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for D. CAUSE_CODE provided will be CAUSE_REDIRECT and the reason received from CTI would be ForwardAll.

CallInfo at B and D will be as follows

At B: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C

At D: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=D

getLastRedirecting()=C

JTAPI Application observing D will see:

getCallingParty() = B

getCalledParty() = D

getCurrentCallingParty()=B

getCurrentCalledParty()=D

getLastRedirecting()=C

Scenario Eight

A (SIP UA in cluster/in control) is in a call with B.
A(referrer) REFERs B(Referee) to C(Refer to target), C Redirect to D, D is ringing.

JTAPI creates Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for D. CAUSE_CODE provided will be CAUSE_REDIRECT and the reason received from CTI in NewCallEvent at D will be Redirect.

Callinfo when Call is offered at C:

At B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

At C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C

CallInfo in final Call:

At B: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C

At D: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C

JTAPI Application observing B will see in final Call:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=D

getLastRedirecting()=C

JTAPI Application observing D will see:

getCallingParty() = B

getCalledParty() = D

getCurrentCallingParty()=B

getCurrentCalledParty()=D

getLastRedirecting()=C

Scenario Nine

A(SIP UA in cluster/in control) is in a call with B.
B consult transfer to D, A(Referrer) REFERs B(Referee) to C(Refer to target), C is ringing,
B completes the transfer. Attempt to transfer will fail while C is ringing.

Scenario Ten

A(SIP UA in cluster/in control) is in a call with B.
B consult transfer to D, A(Referrer) REFERs B(Referee) to C(Refer to target), C answers the call.
Refer will be successful. B completes the transfer, transfer will be successful, C and D will be in call.

JTAPI Disconnect/Drops A's Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER.

For C, Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to Connected/Established/Active/Talking state.

CallInfo at D and C would be as follows

At D: Cgpn= C, Cdpn=D, Lrp=B OCdpn=D

At C: Cgpn=C, Cdpn=D, Lrp=B OCdpn=D

JTAPI Application observing D will see:

getCallingParty() = B

getCalledParty() = D

getCurrentCallingParty()=C

getCurrentCalledParty()=D

getLastRedirecting()=B

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=C

getCurrentCalledParty()=D

getLastRedirecting()=B

Scenario Eleven

B is in a call with D, B consults to A(SIP UA in cluster/in control).
A(Referrer) REFERs B(Referee) to C(Refer to target), C is ringing, B completes the transfer.
REFER would fail. Call at A will be dropped, transfer is successful, D is getting RingBack, C is ringing.

JTAPI Disconnect/Drops A's Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API would provide REASON_REFER, Application will not know if REFER failed.

For C, Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to Alerting/Alerting/Ringing/Ringing state.

CallInfo at D and C would be as follows:

At D: Cgpn= D, Cdpn=C, Lrp=B OCdpn=C

At C: Cgpn=D, Cdpn=C, Lrp=B OCdpn=C

JTAPI Application observing D will see:

getCallingParty() = B

getCalledParty() = D

getCurrentCallingParty()=D

getCurrentCalledParty()=C

getLastRedirecting()=B

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=D

getCurrentCalledParty()=C

getLastRedirecting()=B

OutOfDialog Refer

SIP-UA A REFERs B(Referee) to C (Refer To Target)
B gets newcall with Cgpn=A, Cdpn=B, Lrp=, OCdpn=B.

JTAPI Application will get CallActive, Connection, CallCtlConnection, TerminalConnecton and CallCtlTerminalConnection created for B with CAUSE_NORMAL, and the new API will return REASON_REFER.

B's Connection/CallCtlConnection, TerminalConnection/CallCtlTerminalConnection will go into the Connected/Established/Active/Talking state. JTAPI creates Connection and CallCtlConnection for A in "UNKNOWN" state based on FarEndPointType_ServerCall provided by CTI/CP.

B answers the call and is connected to A (at this point no RTPEvent will be sent).

B get CallPartyInfoChangedEv with Cgpn=B, Cdpn=C, Lrp=A, OCdpn=C, Reason=REFER.

C get NewCall offering with Cgpn=B, Cdpn=C, Lrp=A, OCdpn=C, Reason=REFER.

JTAPI Application will get Connection, CallControlConnection, TerminalConnecton and CallCtlTerminalConnection created for B with CAUSE_NORMAL, and the new API will return REASON_REFER.

C Accepts/Answers the call, B is connected to C (now Application receives RTP events).

C's Connection/CallCtlConnection, TerminalConnection/CallCtlTerminalConnection will go into the Connected/Established/Active/Talking state.

JTAPI Application observing B will see:

getCallingParty() = A

getCalledParty() = B

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

JTAPI Application observing C will see:

getCallingParty() = B

getCalledParty() = C

getCurrentCallingParty()=B

getCurrentCalledParty()=C

getLastRedirecting()=A

SIP 3XX Redirection

3XX Redirection - 302 Moved Temporarily

JTAPI application monitors 1000@ccm.cisco.com

Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com

CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE.

JTAPI reports CallActiveEv and Connection and CallCtlConnection events for 1000

JTAPI reports CallCtlConnEstablishedEv

SIP proxy reports a 302 for 333555@aaa.com. Based on the 302, the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com.

CallPartyInfoChange event is reported to application based on the SIPAlertInd from a Cisco Unified Communications Manager, if the called party information is changed.

JTAPI reports connection created events for 333777@bbb.com

CTI reports CtiCallStateNotify (Ringback) and CtiCallStateNotify (Connected).

JTAPI reports ConnAlertingEv and ConnEstablishedEv for far end.

3XX Redirection - Contact Busy

JTAPI CTI application monitors 1000@ccm.cisco.com

Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com

CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE.

JTAPI reports CallActiveEv and Connection and CallCtlConnection events for 1000

CTI reports CtiCallStateNotify (Proceeding)

JTAPI reports CallCtlConnEstablishedEv

SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com.

A 486 user busy response is reported by 333777@bbb.com. Based on this response the Cisco Unified Communications Manager initiates a call to 555888@cisco.com.

CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI reports connection created event for 555888@cisco.com.

CTI also reports CtiCallStateNotify (Ringback) and CtiCallStateNotify (Connected).

JTAPI reports CallCtlConnAlertingEv and CallCtlConnEstablishedEv for the new party

3XX Redirection - Contact Does Not Answer

JTAPI application monitors 1000@ccm.cisco.com

Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com

CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE.

JTAPI reports CallActiveEv and connection and terminalConnection events for 1000

CTI reports CtiCallStateNotify (Proceeding)

JTAPI reports CallCtlConnEstablishedEv for 1000

SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com. The Cisco Unified Communications Manager starts the RNAR timer.

CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI reports connection created events for 333777

RNAR timer expires and based on this expiration the Cisco Unified Communications Manager initiates a call to 555888@cisco.com.

CallPartyInfoChange event is reported to application based on the SIPAlertInd/CcNotifyReq from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI removes connection for 333777 and creates connection for 555888

CTI also reports CtiCallStateNotify (Connected).

JTAPI reports CallCtlConnEstablishedEv for 555888

3XX Redirection - Contact Within Cisco Unified Communications Manager Cluster Configured with Call Forward

JTAPI application monitors 1000@ccm.cisco.com

Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com

CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE.

JTAPI reports CallActiveEv and connection and terminalConnection events for 1000

CTI reports CtiCallStateNotify (Proceeding)

JTAPI reports CallCtlConnEstablishedEv for 1000

SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 2000@ccm.cisco.com.

A 486 user busy response is reported by 2000@ccm.cisco.com. 2000 has Call Forward busy configured so the Cisco Unified Communications Manager initiates a call to 3000@ccm.cisco.com. The Cisco Unified Communications Manager also starts the RNAR timer.

CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI reports connection created event for 3000

3000 does not answer and RNAR timer expires and based on this expiration the Cisco Unified Communications Manager initiates a call to 555888@cisco.com.

CallPartyInfoChange event is reported to application based on the SIPAlertInd/CcNotifyReq from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI destroys connection for 3000 and creates connection for 555888

CTI also reports CtiCallStateNotify (Connected).

JTAPI reports CallCtlConnEstablishedEv for 555888

3XX Redirection - Non-Available Target Member

JTAPI application monitors 1000@ccm.cisco.com

Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com

CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE.

JTAPI reports CallActiveEv and connection and terminalConnection events for 1000

CTI reports CtiCallStateNotify (Proceeding)

JTAPI reports CallCtlConnEstablishedEv for 1000

SIP proxy reports a 302 for 333555@aaa.com. 302 contains target list of 1212@ccm.cisco.com and 2000@ccm.cisco.com. 1212@ccm.cisco.com is an invalid DN. The Cisco Unified Communications Manager tries to contact 1212@ccm.cisco.com first, but gets an invalid DN and so attempts to place the call to 2000@ccm.cisco.com.

CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed.

JTAPI reports connection created event for 2000

CTI also reports CtiCallStateNotify (Ringback/Connected).

JTAPI reports CallCtlConnAlertingEv and CallCtlConnEstablishedEv for 2000.

Unicode Support

Unicode Display Name Scenario

Scenario
Events Delivered to JTAPI Applications

A line is configured on IP phone A with no ASCII name and a Unicode name in Japanese. IP phone B is configured with ASCII name and no Unicode name.
A calls B. Only B is observed.

Call info should contain:

getCurrentCalledPartyDisplayName=asciiNameB
getCurrentCalledPartyUnicodeDisplayName=null
getCurrentCallingPartyDisplayName=null
getCurrentCallingPartyUnicodeDisplayName=
japaneseNameA

A, B and C are in conference.

DisplayName does not apply. Applications should consider "conference" as the called party.

Shared lines - A and B are shared lines with different locales. A calls C. C is unobserved.

Calling party Unicode display name can change between A and B.


GetLocale and UniCodeCapabilities of Terminal

Scenario
Events delivered to JTAPI applications

A line is configured on IP phone A with no ASCII name and Unicode name in Japanese.

Application adds TerminalObserver on the Device.

Application queries the following using CiscoTerminal.



CiscoTerminalInServiceEv contains
getLocale = JAPANESE
getSupportedEncoding=
                        UCS2UNICODE_ENCODING

CiscoTerminal.getLocale = JAPANESE
CiscoTerminal. getSupportedEncoding= UCS2UNICODE_ENCODING


Backward Compatibility Enhancements

This feature is not expected to change the performance or scalability of Cisco Unified Communications Manager JTAPI. There is no change in the number of events between JTAPI and CTI. For features involving GCID changes this feature introduces one extra event which should not cause any performance issues.

In all cases events listed below are delivered to call observers when only one party is in control list. TERMA indicates terminal of A.

Scenario One

A calls B, B transfers the call to C. GC1 is the call between A and B, GC2 is the consult call between B and C. Similar events are delivered for Conference and other features.

Action
Events

B completes the transfer. Events to call observer on C

GC2 CiscoTransferStartEv Cause: CAUSE_NORMAL
Reason=REASON_TRANSFER

CallActiveEv GC1 Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED Reason=REASON_TRANSFER

ConnCreatedEv C Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED Reason=REASON_TRANSFER

ConnCreatedEv B Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED Reason=REASON_TRANSFER

CiscoCallChangedEv SurvingCall=GC1, original call=GC2
CiscoCause: NORMAL
Reason: REASON_TRANSFER

Events delivered to CallObserver of B (transfer controller)

ConnConnectedEv C Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL
CallControlCause: CAUSE_TRANSFER
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

TermConnCreatedEv TERM C Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

TermConnActiveEv TERM C Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

CallCtlTermConnTalkingEv TERM C Cause: CAUSE_NORMAL
CallControlCause: CAUSE_TRANSFER
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

ConnConnectedEv B Cause: CAUSE_NORMAL
CiscoCause: CAUSE_NORMALUNSPECIFIED
Reason=REASON_TRANSFER

GC2: ConnDisconnectedEv B REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL

GC2: ConnDisconnectedEv C REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL

GC2: TermConnDropped TERMB REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL

GC2: CalInvalid REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL

GC1: CallCtlTermConnHeldEv TERMB REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC2: ConsultCallActive REASON=NORMAL
Cause: CAUSE_NEW_CALL

GC2: ConnCreatedEv B REASON=NORMAL
Cause: CAUSE_NORMAL

GC2: ConnConnectedEv B REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: ConnDisconnectedEv B
REASON=REASON_TRANSFER
Cause: CAUSE_UNKNOWN

Events delivered to CallObserver of B (transfer controller)
(continued)

GC1: CallCtlConnDisconnectedEv B
REASON=REASON_TRANSFER
Cause: CAUSE_UNKNOWN
CallControlCause: CAUSE_TRANSFER

GC1: TermConnDroppedEv TERMB
REASON=REASON_TRANSFER
Cause: CAUSE_UNKNOWN

GC1: CallCtlTermConnDroppedEv TERMB
REAASON=REASON_TRANSFER
CallControlCause: CAUSE_TRANSFER

GC1: ConnDisconnectedEv A
REASON=REASON_TRANSFER

GC1: CallCtlConnDisconnectedEv A
REASON=REASON_TRANSFER
CallControlCause: CAUSE_TRANSFER

GC1: CallInvalidEv
REASON=REASON_TRANSFER

GC2: ConnDisconnectedEv C
REASON=REASON_TRANSFER

GC2: CallCtlConnDisconnectedEv C
REASON=REASON_TRANSFER
CallControlCause: CAUSE_TRANSFER

GC2: TermConnDroppedEv TERMB
REASON=REASON_TRANSFER

GC2: CallCtlTermConnDroppedEv TERMB
REASON=REASON_TRANSFER
CallControlCause: CAUSE_TRANSFER

GC2: ConnDisconnectedEv B
REASON=REASON_TRANSFER

GC2: CallCtlConnDisconnectedEv B
REASON=REASON_TRANSFER
CallControlCause: CAUSE_TRANSFER

GC2: CallInvalidEv
REASON=REASON_TRANSFER

GC2: CallObservationEndedEv
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1 CiscoTransferEndEv
REASON=REASON_TRANSFER
Cause: CAUSE_NORMAL

GC2 CallObservationEndedEv
REASON=NORMAL
Cause: CAUSE_NORMAL


Scenario Two

A calls B, call=GC1. B parks the call at 99999. C unparks the call using call GC2.

Action
Events

Events delivered to call observer on A when call is parked.


When call is unparked using GC2

GC1: ConnDisconnectedEv B
REASON=REASON_PARK
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv B
REASON=REASON_PARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC1: ConnCreatedEv 9999
REASON=REASON_PARK
Cause: CAUSE_NORMAL

GC1: ConnInProgressEv 9999
REASON=REASON_PARK
Cause: CAUSE_NORMAL

GC1: CallCtlConnQueuedEv 9999
REASON=REASON_PARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC2: CiscoCallChangedEv Surviving= GC2
origcall= GC1 address= A
REASON=REASON_UNPARK

CallActiveEv
REASON=REASON_UNPARK
Cause: CAUSE_NEW_CALL

GC2: ConnCreatedEv A
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC2: ConnConnectedEv A
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC2: CallCtlConnEstablishedEv A
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC2: TermConnCreatedEv TERMA
REASON=REASON_UNPARK

GC2: TermConnActiveEv TERMA
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC2: CallCtlTermConnTalkingEv TERMA
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

 

GC1: ConnDisconnectedEv 9999
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv 9995
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC1: TermConnDroppedEv TERMA
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC1: CallCtlTermConnDroppedEv TERMA
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC1: ConnDisconnectedEv A
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv A
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK

GC1: CallInvalidEv
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC1: CallObservationEndedEv
REASON=NORMAL
Cause: CAUSE_NORMAL

GC2: ConnCreatedEv C
REASON=REASON_UNPARK
Cause: CAUSE_NORMAL

GC2: ConnConnectedEv C
REASON=UNPARK
Cause: CAUSE_NORMAL

GC2: CallCtlConnEstablishedEv C
REASON=UNPARK
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_PARK


Scenario Three

A calls B, B has forward no answer to C. B does not answer and call is offered to C.

Action
Events

Events delivered to call observer on A.

GC1: CallActiveEv
REASON=NORMAL
Cause: CAUSE_NEW_CALL

GC1: ConnCreatedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: ConnConnectedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnInitiatedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: TermConnCreatedEv TERMA
REASON=NORMAL

GC1: TermConnActiveEv TERMA
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlTermConnTalkingEv TERMA
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: CallCtlConnDialingEv A
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: CallCtlConnEstablishedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: ConnCreatedEv B
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: ConnInProgressEv B
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnOfferedEv B
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

Events delivered to call observer on A. (continued)

GC1: ConnAlertingEv B
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnAlertingEv B
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: ConnCreatedEv C
REASON=REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL

GC1: ConnInProgressEv C
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL

GC1: CallCtlConnOfferedEv C
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_REDIRECTED

GC1: ConnAlertingEv C
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL

GC1: CallCtlConnAlertingEv C
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: ConnDisconnectedEv B
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv B
REASON= REASON_FORWARDNOANSWER
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_REDIRECTED

GC1: ConnConnectedEv C
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnEstablishedEv C
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL


Scenario Four

A call B, B redirects the call to C.

Action
Events

Events delivered to call observer on B.

GC1: CallActiveEv
REASON=NORMAL
Cause: CAUSE_NEW_CALL

GC1: ConnCreatedEv B
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: ConnInProgressEv
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnOfferedEv B
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: ConnCreatedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: ConnConnectedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnEstablishedEv A
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: ConnAlertingEv B
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlConnAlertingEv B
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

GC1: TermConnCreatedEv TERMB
REASON=NORMAL
Cause: Other: 0

GC1: TermConnRingingEv TERMB
REASON=NORMAL
Cause: CAUSE_NORMAL

GC1: CallCtlTermConnRingingEvImpl TERMB
REASON=NORMAL
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL

Events delivered to call observer on B. (continued)

GC1: ConnDisconnectedEv A
REASON=REDIRECT
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv A
REASON=REDIRECT
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_REDIRECTED

GC1: TermConnDroppedEv TERMB
REASON=REDIRECT
Cause: CAUSE_NORMAL

GC1: CallCtlTermConnDroppedEv TERMB
REASON=REDIRECT
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_REDIRECTED

GC1: ConnDisconnectedEv B
REASON=REDIRECT
Cause: CAUSE_NORMAL

GC1: CallCtlConnDisconnectedEv B
REASON=REDIRECT
Cause: CAUSE_NORMAL
CallControlCause: CAUSE_REDIRECTED

GC1: CallInvalidEv
REASON=REDIRECT
Cause: CAUSE_NORMAL


Half Duplex Media

RTP Event at A and B.

Action
RTP Events
Check Interface

A calls B ,
B answers the call.

A - CiscoRTPInputStartedEv CiscoRTPOutputStartedEv

B - CiscoRTPInputStartedEv CiscoRTPOutputStartedEv

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false

B puts Call on hold

A - CiscoRTPInputStoppedEv CiscoRTPOutputStoppedEv

B - CiscoRTPInputStoppredEv CiscoRTPOutputStoppedEv

A-CiscoRTPInputStartedEv

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false

Ev.isHalfDuplex() returns True

B Retrieves the Call

A- CiscoRTPInputStoppredEv

A - CiscoRTPInputStartedEv CiscoRTPOutputStartedEv

B - CiscoRTPInputStartedEv CiscoRTPOutputStartedEv

Ev.isHalfDuplex() returns True

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false

Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false


Recording and Monitoring

A and TA are address and terminal of monitor target or recording initiator

B and TB are address and terminal of monitor initiator.

Scenario One

Application user is configured with recording capability only.

Action
Events
Call Info

ciscoProvider.getCapabilities().canRecord()

JTAPI returns TRUE

NA:

ciscoProvider.getCapabilities().canMonitor()

JTAPI returns FALSE

NA:


Scenario Two

Administrator enables monitoring capability for the user.

Action
Events
Call Info
 

CiscoProviderCapabilityChangedEv

hasMonitorCapabilityChanged() on this event returns true

hasRecordingCapabilityChanged() returns true

NA

ciscoProvider.getCapabilities().canMonitor()

JTAPI returns true

NA


Scenario Three

Recording setting. A has auto recording setup.

Action
Events
Call Info

ciscoAddressA.getRecordingConfig()

CiscoAddress.AUTO_RECORDING is returned

NA:

Recording status on address is changed to application controlled recording.

CiscoAddressRecordingConfigChangedEv.getRecordingConfig()

ciscoAddressA.getRecordingConfig()

CiscoAddressRecordingConfigChangedEv

CiscoAddress.APPLICATION_CONTROLLED

CiscoAddress.APPLICATION_CONTROLLED

NA


Scenario Four

AutoRecording. A has auto recording setup. Caller X calls A. A answers the call. A has call observer. TA has observer.

Action
Events
Call Info

A hangs up

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv TA Cause: CAUSE_NORMAL CallControlCause:

CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL CallControlCause:

CAUSE_NORMAL

CallInvalidEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Five

AutoRecording. A has auto recording setup. Caller X calls A. A answers the call. Application calls startRecording().

Action
Events
Call Info

Call.startRecording()

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CallControlCause: CAUSE_NORMAL

JTAPI throws exception

CiscoRTPOutputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Six

AutoRecording. A has auto recording setup. Caller X calls A. A answers the call. Application calls startRecording ().

Action
Events
Call Info

Call.startRecording()

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CallControlCause: CAUSE_NORMAL

JTAPI throws exception

CiscoRTPOutputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Seven

StartRecording(). A has application controlled setup. Caller X calls A. Application calls startRecording(). A answers the call. Application calls startRecording().

Action
Events
Call Info

Call.startRecording()

A answers the call

Call.startRecording()

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

...

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

JTAPI throws InValidStateException

CiscoRTPOutputStartedEv

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Eight

stopRecording(). A has application controlled recording setup. Caller X calls A. A answers the call. Application calls stopRecording().

Action
Events
Call Info

A answers the call

Call.startRecording()

Call.stopRecording()

A hangs up

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

...

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL

CallControlCause: CAUSE_NORMAL

CallInvalidEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Nine

Hold. A has auto recording configured. Caller X calls A. a answers the call and holds the call. A resumes the call. RTP events are delivered to terminal observer and are independent of call events.

Action
Events
Call Info

A answers the call

A puts the call on

HOLD

A resumes the call

A drops the call

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

...

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

CiscoRTPOutputStoppedEv

CallCrlTermConnHeldEv Cause: CAUSE_NORMAL

CiscoRTPInputStoppedEv

CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

...

...

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL

CallControlCause: CAUSE_NORMAL

CiscoRTPOutputStoppedEv

CallInvalidEv

CiscoRTPInputStoppedEv

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Ten

Conference controller and recording initiator. A has auto recording configured. Caller X calls A. A answers the call. A initiates consult call to Y. Y answers and A completes conference.

Action
Events
Call Info

A answers call GC1

A consults Y with GC2

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

...

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPOutputStoppedEv

CiscoTermConnRecordingTargetInfoEv

GC1:CallCrlTermConnHeldEv Cause: CAUSE_NORMAL

CiscoRTPInputStoppedEv

GC1:CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

...

...

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

GC2:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC2:ConnConnectedEv for A Cause: CAUSE_NORMAL

...

...

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A

A completes conference

GC2:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

GC2: ConnConnected Y

CiscoRTPOutputStartedEv

GC2:CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

CiscoConferenceStartEv(GC2 -> GC1)

GC2: CiscoTermConnRecordingEndEv TA

GC2:CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL

GC2:CiscoRTPOutputStoppedEv

...

GC2:CallInvalidEv

GC2:CiscoRTPInputStoppedEv

GC1: CallCtlTermConnTalkingEv TA

GC1: ConnCreatedEv X

GC1: ConnCreatedEv Y

...

GC1: CiscoTermConnRecordingStartEv TA

CiscoConferenceEndEv

CiscoTermConnRecordingTargetInfoEv

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

(recording start could be seen after conference end event)

 

Scenario Eleven

Conference target and recording initiator. A has auto recording configured. Caller X calls Y GC1. Y consults with A, A answers the call (GC2) and Y completes the conference.

Action
Events
Call Info

A answers call GC2

Y completes conference

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

GC2:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC2:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC2: ConnConnectedEv Y

...

GC2:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC2:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC2:CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

GC1: CallActiveEv

GC1: ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1: ConnCreatedEv for Y Cause: CAUSE_NORMAL

CiscoConferenceStartEv(GC2->GC1)

CiscoCallChangedEv

....

CiscoRTPOutputStoppedEv

CiscoRTPInputStoppedEv

GC2: CallCrlTermConnDroppedEv TA

GC2: CallInvalidEv

...

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC1: CallCrlTermConnTalkingEv TA

GC1: ConnConnectedEv Y

GC1: ConnConnectedEv X

GC1: CiscoConferenceEndEv

...

(recording start could be seen before conference end event)

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Twelve

Transfer controller and recording initiator. A has recording configured. Caller X calls A. A answers the call. A initiates consult call to Y. Y answers and A completes transfer.

Action
Events
Call Info

A answers call GC1

A consults Y with GC2

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

...

CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

CiscoRTPOutputStoppedEv

GC1:CallCrlTermConnHeldEv Cause: CAUSE_NORMAL

CiscoRTPInputStoppedEv

GC1:CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL

...

...

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

GC2:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC2:ConnConnectedEv for A Cause: CAUSE_NORMAL

...

...

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A

GC2:

Calling: A

Called: Y

LRP: null

Current calling: A

Current called: Y

A completes transfer

GC2:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

GC2: ConnConnected Y

CiscoRTPOutputStartedEv

GC2:CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoRTPInputStartedEv

CiscoTermConnRecordingTargetInfoEv

CiscoTransferStartEv(GC2 -> GC1)

GC2:CiscoTermConnRecordingEndEv

GC2:CallCtlTermConnDroppedEv TA

GC2:CiscoRTPOutputStoppedEv

...

GC2:CallInvalidEv

GC2:CiscoRTPInputStoppedEv

GC1: CallCtlTermConnDroppedEv TA

...

GC1: CallInvalidEv

CiscoTransferEndEv

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

(recording end may not be seen after A completes transfer)

GC1:

Calling: X

Called: Y

LRP: A

Current calling: X

Current called: Y


Scenario Thirteen

Transfer target and recording initiator. A has auto recording configured. Caller X calls Y GC1. Y consults with A, A answers the call (GC2) and Y completes the transfer.

Action
Events
Call Info

A answers call GC2

Y completes transfer

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

GC2:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC2:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC2: ConnConnectedEv Y

...

GC2:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC2:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC2:CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL

CiscoTermConnRecordingTargetInfoEv

GC1: CallActiveEv

GC1: ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1: ConnCreatedEv for Y Cause: CAUSE_NORMAL

CiscoTransferStartEv(GC2->GC1)

CiscoCallChangedEv

....

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A

Caller or A drops the call

CiscoRTPOutputStoppedEv

CiscoRTPInputStoppedEv

GC1: CallCrlTermConnTalkingEv TA

GC1: CallCtlConnDisconnectedEv Y

GC1: ConnConnectedEv X

GC2: CallCrlTermConnDroppedEv TA

GC2: CallInvalidEv

...

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

...

GC1:CiscoTermConnRecordingEndEv

...

GC1: CallInvalidEv

 

Scenario Fourteen

Start and Stop monitor: A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. Application has monitoring capability enabled.

Action
Events
Call Info

A answers GC1

B calls start monitor using

GC2 giving CI1,

A and TermA from GC1

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC2:CallActive Cause: CAUSE_NORMAL

GC2: GC1:ConnConnectedEv for B Cause: CAUSE_NORMAL

GC2: CallCtlTermConnTalkingEv TB

GC2: ConnCreatedEv A

(No terminal connection for A or GC2)

GC2: ConnConnectedEv A

GC2:CiscoTermConnMonitorTargetInfoEv Cause:

CAUSE_NORMAL address:A, terminal name: TA, rtphandle=CI1

GC1: CiscoTermConnMonitorStartEv TA

GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause:

CAUSE_NORMAL address:B, device name: TB

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A

GC2:

Calling: B

Called: A

LRP: null

Current calling: B

Current called: A

A puts the call on hold

A resumes the call

B calls drop on GC2 to stop monitoring

GC2: CiscoRTPOutputStoppedEv

GC1: CiscoRTPOutputStoppedEv

GC1: CallCtlTermConnHeldEv TA

GC2:CiscoRTPInputStoppedEv

GC1: CiscoRTPInputStoppedEv

GC1: CiscoRTPOutputStartedEv

GC2: CiscoRTPOutputStartedEv

GC1: CallCtlTermConnTalking TA

GC2:CiscoRTPInputStartedEv

GC1: CiscoRTPInputStartedEv

GC2: CallCtlTermConnDroppedEv TB

GC2: ConnDisconnEv A

GC1: CiscoTermConnMonitorEndEv TA

GC2: ConnDisconnEv B

GC2: CallInvalidEv

 

Scenario Fifteen

Monitor initiator transfers the call to Y. A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. application has monitoring capability enabled. B transfers the call to Y.

Action
Events
Call Info

A answers GC1

B calls start monitor using

GC2 and ci2 giving CI1, A and

TermA from GC1

Or using the teminalconnection of A.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC2:CallActive Cause: CAUSE_NORMAL

GC2: ConnConnectedEv for B Cause: CAUSE_NORMAL

GC2: CallCtlTermConnTalkingEv TB

GC2: ConnCreatedEv A

(No terminal connection for A or GC2)

GC2: ConnConnectedEv A

GC2:CiscoTermConnMonitorTargetInfoEv Cause:

CAUSE_NORMAL Monitor_TARGET address:A, device name: TA,

rtphandle=CI1

GC1: CiscoTermConnMonitorStartEv TA

GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause:

CAUSE_NORMAL address:B, device name: TB rtphandle=ci2

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A

B consults Y using GC3 and completes transfer.

Call observer on Y would see

GC3: CallActiveEv

GC3: ConnConnectedEv B

GC3: CallCtlTermConnTalkingEv TB

GC3: ConnConnectedEv Y

CiscoTransferStartEv(GC3->GC2)

GC3: ConnDisconnectedEv Y

GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause:

CAUSE_NORMAL address:Y, device name: TY

GC3: ConnDisconnectedEv B

GC3: CallCtlTermConnDroppedEv TB

GC3: CallInvalidEv

GC2: CallCtlTermConnDroppedEv TB

....

GC2: CallInvalidEv

CiscoTransferEndEv

GC3: CallActive

GC3: CallCtlTermConnRingingEv TY

GC3: CallCtlTermConnTalkingEv TY

CiscoTransferStartEv

CiscoCallChangedEv GC3->GC2

GC2: ConnConnectedEv Y

GC2: ConnConnectedEv B

GC2: CiscoTermConnMonitorTargetInfoEv TY Cause:

CAUSE_NORMAL address:A, device name: TA

GC3: ConnDisconnectedEv Y

GC3: CallCtlTermConnDroppedEv TY

GC3: CallInvalidEV

GC2: ConnConnectedEv X

GC2: ConnDisconnectedEv A

CiscoTransferEndEv

(CiscoTermConnMonitorInitiatorInfoEv on GC1 is independent of transfer events on GC3 and GC2 and can be delivered at any time before or after end event.)

GC1:

Calling: X

Called: A

LRP: A

Current calling: X

Current called: Y


Scenario Sixteen

Monitoring a barged call: A and A' are shared lines. Caller calls A, A answers the call. A' barge into the call. B calls start monitor.

Action
Events
Call Info

A answers GC1

A' barges the call

B calls start monitor using

GC2 giving CI1,

A and TermA from GC1

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

CiscoRTPInputStartedEv

GC1: CallCtlTermConnBridgedEv TermA'

GC1: GC1:CallCrlTermConnTalkingEv TA'

Exception is thrown to startMonitor request.

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Seventeen

Monitor and recording: A is monitor target and has auto recording configured. B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. Application has monitoring capability enabled.

Action
Events
Call Info

A answers GC1

B calls start monitor using

GC2 giving CI1,

A and TermA from GC1

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

CiscoRTPOutputStartedEv

GC1: CiscoTermConnRecordingStartEv TA

GC1: CiscoTermConnRecordingTargetInfoEv TA

CiscoRTPInputStartedEv

GC2:CallActive Cause: CAUSE_NORMAL

GC2: GC1:ConnConnectedEv for B Cause: CAUSE_NORMAL

GC2: CallCtlTermConnTalkingEv TB

GC2: ConnCreatedEv A

(No terminal connection for A on GC2)

GC2: ConnConnectedEv A

GC2:CiscoTermConnMonitorTargetInfoEv Cause:

CAUSE_NORMAL address:A, device name: TA, rtphandle=CI1

GC1: CiscoTermConnMonitorStartEv TA

GC1: CiscoTermConnMonitorTargetInfoEv TA Cause:

CAUSE_NORMAL address:B, device name: TB

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Eighteen

Observing remote in use shared line in Monitoring: A and A' are shared lines. Caller calls A, A answers the call. B calls start monitor. Application has call observer on A' only. B initiates monitor request for connected call on A. No start events are delivered to call observer of A'.

Action
Events
Call Info

A answers GC1 and B initiates monitor

A puts the call on HOLD

A' answers the call

B drops the call

and initiates start

monitor using

GC3 giving the

terminal connection of A'

in monitor request.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A' Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnRingingEv TA' Cause: CAUSE_NORMAL

GC1: CallCtlTermConnBridgedEv TermA'

Cause: CAUSE_NORMAL

GC1: CallCrlTermConnHeldEv TA'

GC1:CallCrlTermConnTalkingEv TA'

GC1: CiscoTermConnMonitorStartEv TA'

GC1: CiscoTermConnMonitorInitiatorInfoEv TA' Cause:

CAUSE_NORMAL address:B, device name: TB

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Nineteen

Snap Shot events for Monitor and recording: A is monitor target and has auto recording configured. B is monitor initiator. X calls A, A answers the call GC1 (ci1), B calls start monitor using GC2. Another application adds call observer on A after monitoring and recording sessions are established.

Action
Events
Call Info
 

CallActiveEv for callID=GC1 Cause: CAUSE_SNAPSHOT

GC1:ConnCreatedEv for A Cause: CAUSE_SNAPSHOT

GC1:ConnConnectedEv for A Cause: CAUSE_SNAPSHOT

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_SNAPSHOT

GC1: CiscoTermConnRecordingStartEv TA Cause: CAUSE_SNAPSHOT

GC1: CiscoTermConnRecordingTargetInfoEv TA Cause:

CAUSE_SNAPSHOT

GC1: CiscoTermConnMonitorStartEv TA Cause: CAUSE_SNAPSHOT

GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause:

CAUSE_SNAPSHOT address:B, device name: TB

GC1:

Calling: X

Called: A

LRP: null

Current calling: X

Current called: A


Scenario Twenty

Chained conference and recording: A has auto recording configured. A, B and C are in conference in GC1. A consults D using GC3. D sets up conference (with E and F) using Gc4 and adds A's consult call to conference. A completes conference, resulting in a conference chain.

Action
Events
Call Info

B calls A, A answers the call on GC1

A consults C using GC2

CallActiveEv for callID=GC1

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1: ConnConnectedEv X

...

GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

GC1: CiscoTermConnRecordingStartEv TA Cause: CAUSE_NORMAL

GC1: CiscoTermConnRecordingTargetInfoEv TA Cause: CAUSE_NORMAL

GC1: CiscoTermConnMonitorStartEv TA Cause: CAUSE_NORMAL

GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB

GC1: TermConnHeldEv TA

GC2: CallActiveEv

GC1: CiscoTermConnRecordingEndEv TA Cause: CAUSE_NORMAL

...

GC2: CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL

GC2: CiscoTermConnRecordingStartEv TA Cause: CAUSE_NORMAL

....

NA

A completes conference

A consults to D using GC3

D answers

D consults with E and F and completes conference

A completes conference

GC2: CiscoTermConnRecordingEndEv TA Cause: CAUSE_NORMAL

......

GC2: CallInvalidEv

GC1: CiscoTermConnRecordingStartEv TA Cause: CAUSE_NORMAL

GC1: TermConnTalkingEv TA

GC3: CallActiveEv

GC1: CallCrlTermConnHeldEv TA

GC1: CiscoTermConnRecordingEndEv TA Cause: CAUSE_NORMAL

GC3: CallCrlTermConnTalkingEv TA

GC3: CiscoTermConnRecordingStartEv TA Cause: CAUSE_NORMAL

GC3: CiscoTermConnRecordingEndEv TA

GC1: CallCrlTermConnTalkingEv TA

...

GC3: CallInvalidEv

GC1: CiscoTermConnRecordingStartEv

 

Intercom

Configuration: terminal T1 has intercom line A with TargetDN B, label Bob, Unicode label UBob. Terminal T2 has intercom line B. Application provider has both T1 and T2 in control list.

C, Carol, UCarol is in the same intercom group as A, and B.

D, David, UDavid is not in the same intercom group as A, B and C.

Action
Result
Call Info

Application opens provider, after provider comes in service, application issues provider.getIntercomAddresses()

JTAPI returns A and B as array of CiscoIntercomAddress.

N.A

Application issues CiscoIntercomAddress.getIntercomTargetDN(),

CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTarget Label() request at A.

JTAPI will return B as target DN and Bob and UBob as target label.

N.A

Application issues CiscoIntercomAddress.getDafaultIntercomTargetDN(),

CiscoIntercomAddress.getDefaultIntercomTargetLabel() and CiscoIntercomAddress.getDefaultIntercomUnicodeTargetLabel() request at A.

JTAPI will return B as target DN and Bob and UBob as target label.

N.A

Application issues CiscoIntercomAddres.setIntercomTarget(C, Carol, UCarol) on intercom address A.

After successful response, Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A.

AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL

JTAPI will return C as target DN and Carol and UCarol as target label.

N.A

Application1 is observing CiscoIntercomAddress A and has AddressObserverAdded to it. Application2 sets intercom target, label to C, Carol, UCarol.

App1 : AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL

N.A

After above step Application1 issues CiscoIntercomAddres.setIntercomTarget(B, Bob, UBob) on intercom address A.

Exception will be thrown to application as another application instance has already set the target to C, Carol, UCarol.

N.A

Intercom target DN and label for intercom address A is set to default, now application issues CiscoIntercomAddres.setIntercomTarget(D, David, UDavid) on intercom address A.

Exception will be thrown as D, David, UDavid is not in the same intercom group.

N.A

Application has set intercom target DN and label to C, Carol, UCarol for intercom address A. Now CTI Manager goes out of service, JTAPI failover to another CTIManager node. After intercom address A come back in service, JTAPI will restore intercom target DN and label to C, Carol, UCarol respectively.

Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A.

AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL

JTAPI will return C as target DN and Carol and UCarol as target label.

N.A

Application has set intercom target DN and label to C, Carol for intercom address A. Now CTI Manager goes out of service, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN, label and UnicodeLabel to C, Carol, UCarol respectively, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI.

AddressObserver at A: CiscoAddrIntercomInfoRestorationFailedEv Cause: CAUSE_NORMAL

N.A

Application is connected to a CTIManager node, Cisco Unified Communications Manager node goes down, intercom device failsover to another Cisco Unified Communications Manager node, after intercom address comes back in service. CTIManager should restore intercom target Dn and label.

Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A.

AddressObserver at A:

CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL

JTAPI will return C as target DN and Carol and UCarol as target label.

N.A

Application is connected to a CTIManager node, Cisco Unified Communications Manager node goes down, intercom device failsover to another Cisco Unified Communications Manager node, after intercom address comes back in service. CTIManager tries to restore intercom target Dn and label, however due to race condition some other application has already set the target Dn and Label, hence CTI is not able to restore the intercom target DN and label.

AddressObserver at A: CiscoAddrIntercomInfoRestorationFailedEv Cause: CAUSE_NORMAL

N.A

Application is observing intercom addresses A and B. A has target set to B. User initiates intercom call.

Intercom call is successful.

CallObserver at A and B: CallActiveEv GC1 Cause: CAUSE_NORMALConnCreatedEv A, Cause: CAUSE_NORMALConnConnectedEv A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv A Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMALTermConnCreatedEv A- T1 Cause: CAUSE_NORMAL TermConnActiveEv A- T1 Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv A - T1 Cause: CAUSE_NORMAL

CallCtlCause=CAUSE_NORMAL

CallCtlConnDialingEv A Cause: CAUSE_NORMAL

CallCtlCause=CAUSE_NORMAL

CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL

CallCtlCause=CAUSE_NORMAL

ConnCreatedEv B, Cause: CAUSE_NORMAL ConnConnectedEv B Cause: CAUSE_NORMAL CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

CallCtlConnEstablishedEv B Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

Cg=A

Cd=B

CurrentCg=A

CurredCd=B

LRP = null

 

TermConnCreatedEv B- T2 Cause: CAUSE_NORMAL TermConnPassiveEv B - T2 Cause: CAUSE_NORMAL

CallCtlTermConnBridgeEv B - T2 Cause: CAUSE_NORMAL CallCtl Cause=CAUSE_NORMAL

CiscoToneChangedEv - T1 -GC1

CiscoToneChangedEv - T2 -GC1

CiscoRTPOutputStartedEv - T1

CiscoRTPInputStartedEv - T2

 

User at B presses talkback softkey to get connected to intercom initiator.

CallObserver at A and B: TermConnActiveEv B - T2 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv B - T2 Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

CiscoRTPOutputStartedEv - T2CiscoRTPInputStartedEv - T1

Cg=A

Cd=B

CurrentCg=A

CurredCd=B

LRP = null

Intercom address A has target defined as B. Application initiates an intercom call by calling interface Address.ConnectIntercom() with dialeddigit as empty.

Intercom call is successful.

CallObserver at A and B :

CallActiveEv GC1 Cause: CAUSE_NORMAL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv A Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

TermConnCreatedEv T1 Cause: CAUSE_NORMAL TermConnActiveEv T1 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv T1 Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

CallCtlConnDialingEv A Cause: CAUSE_NORMAL CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

ConnCreatedEv B Cause: CAUSE_NORMAL C ConnConnectedEv B Cause: CAUSE_NORMAL CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

CallCtlConnEstablishedEv B Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

TermConnCreatedEv B- T2 Cause: CAUSE_NORMAL TermConnPassiveEv B - T2 Cause: CAUSE_NORMAL CallCtlTermConnBridgeEv B - T2 Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

Cg=A

Cd=B

CurrentCg=A

CurredCd=B

LRP = null

 

CiscoToneChangedEv - T1 -GC1

CiscoToneChangedEv - T2 -GC1

CiscoRTPOutputStartedEv - T1

CiscoRTPInputStartedEv - T2

 

Application initiate TerminalConnection.join() request on TerminalConnection of B to talkback.

Request is successful.

CallObserver at A and B :

TermConnActiveEv B - T2 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv B - T2 Cause: CAUSE_NORMAL CallCtlCause=CAUSE_NORMAL

CiscoRTPOutputStartedEv - T2 CiscoRTPInputStartedEv - T1

Cg=A

Cd=B

CurrentCg=A

CurredCd=B

LRP = null

Application tried to put the intercom call on hold at A by issuing TerminalConnection.hold()

PlatformException will be thrown, intercom call stay connected.

N.A

Application tried to accept intercom call at intercom target by issuing connection.accept() at connection of B.

PlatformException will be thrown, intercom call stay connected.

N.A

Application tried to reject intercom call at intercom target by issuing connection.reject() at connection of B.

Intercom call will be disconnected.

N.A

Application tried to redirect intercom call by issuing connection.redirect() at connection of A or B.

PlatformException will be thrown, intercom call stay connected.

N.A

Application tried to park call by issuing connection.park() at Connection of A or B.

PlatformException will be thrown, intercom call stay connected.

N.A

Terminal T1 has intercom address A which has intercom target set to B.

Terminal T2 has intercom address B and another address C. C is in call with D, GC1.

A initiates intercom call to B, intercom call is auto-answered at B

No event to GC1 call, it will stay in Connected State.

N.A

Application tries to set forward on intercom address A by issuing CiscoIntercomAddress. setForwarding ()

PlatformException will be thrown.

N.A

Application tries to setRingerStatus on intercom address A by issuing CiscoIntercomAddress. setRingerStatus()

PlatformException will be thrown.

N.A

Application tries to setMessageWaiting on intercom address A by issuing CiscoIntercomAddress.setMessageWaiting()

PlatformException will be thrown.

N.A

Application tries to setAutoAcceptEnabled on intercom address A at CTIPort by issuing CiscoIntercomAddress. setAutoAcceptStatus ()

PlatformException will be thrown.

N.A

Application tries to getAutoAcceptEnabled on intercom address A at CTIPort by issuing CiscoIntercomAddress. getAutoAcceptStatus ()

PlatformException will be thrown.

N.A


DeviceState Whisper Scenario

Configuration: Terminal T1 has intercom address B, Terminal T2 has intercom address A. Application has set CiscoTermEvFilter to enable CiscoTermDeviceStateWhisperEv as well as all other DeviceState filters on T1 and T2. Application had added Terminal observer on both T1 and T2.

Action
Events
Call Info

Intercom address A has target defined as B. Application initiates an intercom call by calling interface Address.ConnectIntercom() with dialeddigit as empty.

Event received at TerminalObserver of T1

CiscoTermDeviceStateActiveEv T1 Cause: CAUSE_NORMAL

Event received at TerminalObserver of T2

CiscoTermDeviceStateWhisperEv T1 Cause: CAUSE_NORMAL

N.A

Application issue join() request on TerminalConnection of T2 (intercomTarget) to talkback to T1(intecomInitiator)

Event received at TerminalObserver of T1

None.

Event received at TerminalObserver of T2

CiscoTermDeviceStateActiveEv T1 Cause: CAUSE_NORMAL

N.A

Terminal T2 already have intercom target call, Application enables CiscoTermFilter for CiscoTermDeviceStateWhisperEv.

Event received at TerminalObserver of T2

CiscoTermDeviceStateWhisperEv T1 Cause: CAUSE_SNAPSHOT

N.A


Do Not Disturb

Configuration: Application is observing terminal A and terminal B.

Scenario One

Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is enabled via setDNDChangedEvFilter. DND is enabled on the terminal. Application invokes getDNDStatus() from CiscoTerminal.

Action
Events
Call Info

Application adds terminal observer to terminal A. Filter is enabled via setDNDChangedEvFilter() in CiscoTermEvFilter. DND is enabled on the terminal through phone or admin page.

Application invokes getDNDStatus() from CiscoTerminal.

NEW META EVENT_________
META_CALL_STARTING

CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true

DND status = true is returned to the application

N.A


Scenario Two

Application enables filter to receive events. Application adds Terminal observer to terminal A using Terminal.addObserver(). DND is enabled on the terminal. Application invokes getDNDStatus() from CiscoTerminal.

Action
Events
Call Info

Application enables filter to receive events. Application adds terminal observer to terminal

A. DND is enabled on the device through phone or admin pages.

Application invokes getDNDStatus() from CiscoTerminal.

NEW META

EVENT_________META_CALL_STARTING

CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true

DND status = true is returned to the application

N.A


Scenario Three

Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is disabled via setDNDChangedEvFilter() in CiscoTermEvFilter. Application invokes getDNDStatus() from CiscoTerminal.

Action
Events
Call Info

Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is disabled via setDNDChangedEvFilter() in CiscoTermEvFilter.

Application invokes getDNDStatus() from CiscoTerminal.

CiscoTermDNDStatusChangedEv is not delivered to application.

N.A


Scenario Four

Application does not add Terminal observer to terminal. Application invokes getDNDStatus() from CiscoTerminal.

Action
Events
Call Info

Application does not add Terminal observer to terminal. Application invokes getDNDStatus() from CiscoTerminal.

InvalidStateException is thrown

N.A


Scenario Five

Application does not enable the filter to receive events. Application adds Terminal observer to terminal A. DND status is set to true through the phone or admin pages. Application now enables the filter to receive events. Application invokes getDNDStatus() from CiscoTerminal.

Action
Events
Call Info

Application does not enable the filter to receive events.Application adds Terminal observer to terminal A. DND status is set to true through the phone or admin pages.

Application now enables the filter to receive events

Application invokes getDNDStatus() from

CiscoTerminal.

CiscoTermDNDStatusChangedEv is not delivered to application.

NEW META EVENT_________META_CALL_STARTING

CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true

DND status = true is returned to application

N.A


Scenario Six

Application sets DND status to false by invoking the setDNDStatus() interface on CiscoTerminal.

Action
Events
Call Info

Application invokes setDNDStatus() from CiscoTerminal.

NEW META EVENT_________META_CALL_STARTINGCiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false

N.A


Scenario Seven

Application 1 and Application 2 are observing terminal a, and both the applications have enabled the filter to receive events. Application 1 sets DND status to false on Terminal A. Application 2 is observing Terminal A.

Action
Events
Call Info

Application invokes setDNDStatus() from CiscoTerminal.

NEW META EVENT_________META_CALL_STARTINGCiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false

N.A


Scenario Eight

DND Type is RingerOff and CFNA is not set. Terminal B calls Terminal A. Call is presented to A and call is not answered.

Action
Events
Call Info

Application invokes redirect() API with feature priority set to 3 from CiscoCall.

Call is presented to the device, irrespective of the DND settings on the device. CER call overrides DND setting.

N.A

Application invokes selectRoute() API with feature priority set to 3 from CiscoRouteSession.

Call is presented to the device, irrespective of the DND settings on the device. CER call overrides DND setting.

N.A


Action
Events
Call Info

DND Type is RingerOff and CFNA is not set. Terminal B calls Terminal A .Call is presented to A and call is not answered.

ConnFailedEv Cause: CAUSE_NO ANSWER

N.A


Scenario Nine

Scenario Ten

DND Type is CallReject and CFB is not set. Terminal B calls Terminal A. Call is not presented to A.

Action
Events
Call Info

DND Type is CallReject and CFB is not set. Terminal B calls Terminal A. Call is not presented to A

ConnFailedEv Cause: CAUSE_USER BUSY

N.A


Scenario Eleven

DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Application invokes getDNDStatus() on CiscoTerm in ServiceEv.

Action
Events
Call Info

DND is enabled on the terminal A. Terminal A comes IN_SERVICE.

CiscoTermInServiceEv Cause: CAUSE_NORMAL

DND Status =true

N.A


Scenario Twelve

DND is enabled on terminal A. Terminal A comes IN_SERVICE. Application invokes setDNDStatus(). DB failure happens after the setDNDStatus() request is sent.

Action
Events
Call Info

DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Application invokes setDNDStatus(). DB failure follows and value is not updated in DB.

PlatformException is thrown "Could not meet post conditions of setDNDStatus()"

No CiscoTermDNDStatusChangedEv is received.

N.A


Scenario Thirteen

DND is enabled on the terminalA. Terminal A comes IN_SERVICE,DND status is currently true in phone/admin. Application tries to set the same value i.e. invokes setDNDStatus(true).

Action
Events
Call Info

DND is enabled on the terminal A. Terminal A comes IN_SERVICE.DND status is currently true in phone/admin.Application tries to set the same value i.e. invokes setDNDStatus(true).

InvalidStateException is caught: DND status with value true is already set

No CiscoTermDNDStatusChangedEv is received.

N.A


DND-R

Scenario One

Application adds Terminal observer to terminal A using Terminal.addObserver (). DND-R is enabled on the terminal B via the Admin page or the Common profile page.

Action
Events
Call Info

Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page.

A issues Call.connect to B with the feature Priority = 1 (Normal)

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

ConnFailedEv B Cause:.

Cause: CAUSE_USERBUSY.

N.A

Scenario Two

Application adds Terminal observer to terminal A using Terminal.addObserver (). DND-R is enabled on the Terminal B via the Admin page or the Common profile page.

Action
Events
Call Info

Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page.

A issues Call.connect to B with the feature Priority = 3 (Emergency)

NEW META EVENT_________META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause:
CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause:
CAUSE_NORMAL

ConnInProgressEv for B Cause:
CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause:
CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A

Called: B


Scenario Three

DND-Call reject with CFB not set.

Action
Events
Call Info

Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page with no CFB Setting.

Terminal A issues Call.connect to Terminal B.

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause:
CAUSE_NORMAL

ConnConnectedEv for A Cause:
CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause:
CAUSE_NORMAL

ConnFailedEv B Cause:
CAUSE_USERBUSY.

NA


Scenario Four

DND - Call reject with CFB set to C.

Action
Events
Call Info

Application is Observing Terminal A, B & C.

DND-R is Enabled in Terminal B with CFB set to Terminal C.

Terminal A issues Call.connect to Terminal B.

Call is not Presented on Terminal B and is Forwarded to Terminal C.

NEW META EVENT_________META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause:
CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for C cause: REDIRECTED CALL

ConnInProgressEv for C Cause: REDIRECTED CALL

CallCtlConnOfferedEv for C Cause: REDIRECTED CALL

ConnAlertingEv for C Cause REDIRECTED CALL

CallCtlConnAlertingEv for C Cause: REDIRECTED CALL

TermConnCreatedEv for C Cause: REDIRECTED CALL

TermConnRingingEv for C Cause: REDIRECTED CALL

CallCtlTermConnTalkingEv Cause: CAUSE_REDIRECTED

Calling: A

Called: C

LastRedirectedParty: B


Secure Conferencing

Action
Events
Call Info

Scenario:1

Configuration: A (secure) and B (secure).

A calls B. B answers.

Application issues

getCallSecurtyStatus().

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1

Returns the call security status of the call.

Calling: A

Called: B

CallSecurityStatus = 3

(ENCRYPTED) will get updated in the call info.

CallSecurityStatus = 3

(ENCRYPTED).

Configuration: A (secure), B (secure) and C (non-secure).

Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv ()

A calls B. B answers.

B call C. C answers.

B completes conference.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1.

Participants: A, B, C

CallSecurityStatus = 1 (NOTAUTHENTICATED). Note: Though CallSecurityStatus=NotAuthenticated, A and B will continue to have secure media between themselves and the conference bridge, i.e. they will continue to receive SRTP key info because they are encrypted parties.

Scenario:3

Configuration: A (secure), B (secure) and C (secure).

Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv ()

A calls B. B answers.

B call C. C answers.

B completes conference.

Application issues
getCallSecurtyStatus().

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1.

Returns the call security status of the call (Secure).

Participants: A, B, C

CallSecurityStatus = 3

(ENCRYPTED) will get updated in the call info.

Scenario:4

Application does not add call observers on A, B, C.

Configuration: A (secure), B (secure) and C (non-secure).

A calls B. B answers.

B call C. C answers.

B completes conference.

Application later adds call observers on A, B, C.

Application issues getCallSecurtyStatus().

CallSecurityStatusChangedEv for callID=GC1 with Cause=CAUSE_SNAPSHOT

Returns the call security status of the call.

Participants: A, B, C

CallSecurityStatus = 1

(NOTAUTHENTICATED)

will get updated in the call info.

Scenario:5

Configuration: A (secure), B (secure).

Application sets ini parameter = true by issuing

enableSecurtyStatusChangedEv()

A calls B. B answers.

B puts call on hold.

B resumes call.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1

CallSecurityStatusChangedEv for callID=GC1

CallSecurityStatusChangedEv for callID=GC1

CallSecurityStatus = 3

(ENCRYPTED) will get updated in the call info.

CallSecurityStatus = 0

(UNKNOWN) will get updated in the call info.

CallSecurityStatus =

(ENCRYPTED) will get updated in the call info.

Scenario:6

Configuration: A (secure), B (secure) and C (non-secure).

Application sets ini parameter = true by issuing

enableSecurtyStatusChangedEv()

A calls B. B answers.

B consults C. C answers.

B completes transfer.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

GC2:ConnCreatedEv for B' Cause: CAUSE_NORMAL

GC2:ConnCreatedEv for C' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC2

CallCtlSecurityStatusChangedEv for callID=GC1

CallSecurityStatus = 3

(ENCRYPTED) will get updated in the call info for GC1.

CallSecurityStatus = 1

(NOTAUTHENTICATED) will get updated in the call info for GC2.

CallSecurityStatus = 1

(NOTAUTHENTICATED) will get updated in the call info for GC1.

Scenario:7

Configuration: A (secure), B (secure), C (secure), D (secure), and E (Authenticated).

Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv()

A, B and C are part of a conference Call 1.

C, D and E are a part of another conference Call 2.

C chains the 2 conferences.

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for C' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallActiveEv for callID=GC1 Cause:

CAUSE_NEW_CALL

GC2:ConnCreatedEv for C' Cause: CAUSE_NORMAL

GC2:ConnCreatedEv for D' Cause: CAUSE_NORMAL

GC2:ConnCreatedEv for E' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallCtlSecurityStatusChangedEv for callID=GC1

CallSecurityStatus = 3

(ENCRYPTED) will get updated in the call info for GC1.

CallSecurityStatus = 2

(AUTHENTICATED) will get updated in the call info for GC2.

CallSecurityStatus = 1

(NOTAUTHENTICATED) will get updated in the call info for GC1 and GC2.

Scenario:8

Configuration: A (secure), B (secure), B (authenticated)

Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv()

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

GC1:ConnCreatedEv for A' Cause: CAUSE_NORMAL

GC1:ConnCreatedEv for B' Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv

CallSecurityStatusChangedEv for callID=GC1.

CallSecurityStatus = 2

(AUTHENTICATED) will get updated in the call info for GC1.

Note: Applications who have added call observers on B' will also get the event, i.e. the new event will be delivered to RIU Parties as well.


JTAPI Cisco Unified IP 7931G Phone Interaction

A and C are JTAPI application controllable Addresses. B1 and B2 are Address on Cisco Unified IP 7931G Terminal. Cisco Unified IP 7931G Terminal is configured to do Transfer across Addresses. B1 and B2 has shared Line B1' and B2' respectively configured on JTAPI controllable Terminal.

Action
Events
Call Info

Scenario:1

Application is observing A:

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2

User presses transfer key to complete transfer.

JTAPI Event received to CallObserver at A

GC-1 CiscoTransferStartedEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1,

TransferredCall= null)

GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN

GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC-1 CiscoTransferEndEv

Calling=A

Called=B1

CurrCalling=A

CurrCalled=B1

LRP=B1

Scenario:2

Application is observing A, B1':

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses transfer key to complete transfer

JTAPI Event received to CallObservers at A and B1'

GC-1 CiscoTransferStartedEv (ControllerAddress=B1,

ControllerTerminalConnection= TC at TB1', FinalCall=GC1,

TransferredCall= null)

GC1- TermConnDroppedEv for TB1' Cause: CAUSE_NORMAL

GC1- CallCtlTermConnDroppedEv for TB1' Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN

GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause:

CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC-1 CiscoTransferEndEv

Calling=A

Called=B1

CurrCalling=A

CurrCalled=B1

LRP=B1

Scenario:3

Application is observing A, B1', B2':

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses transfer key to complete transfer

JTAPI Event received to CallObserver at A and B1'

GC-1 CiscoTransferStartedEv (ControllerAddress=B1,

ControllerTerminalConnection= TC at TB1', FinalCall=GC1, TransferredCall= GC2)

GC1- TermConnDroppedEv for TB1' Cause: CAUSE_NORMAL

GC1- CallCtlTermConnDroppedEv for TB1' Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN

GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

Calling=A

Called=B1

CurrCalling=A

CurrCalled=B1

LRP=B1

 

GC2- TermConnDroppedEv for TB2' Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for TB2' Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL

CallControlCause: CAUSE_TRANSFER

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC-1 CiscoTransferEndEv

CallControlCause: CAUSE_TRANSFER

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC-1 CiscoTransferEndEv

 

Scenario:4

Application is observing A, B1', B2' and C:

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses transfer key to complete transfer

JTAPI Event received to CallObserver at A, B1', B2' and C

GC-1 CiscoTransferStartedEv (ControllerAddress=B1,

ControllerTerminalConnection=TC at TB1', FinalCall=GC1,

TransferredCall= GC2)

GC1- TermConnDroppedEv for TB1' Cause: CAUSE_NORMAL

GC1- CallCtlTermConnDroppedEv for TB1' Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN

GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC1- TermConnCreatedEv CT Cause: Other: 31

GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL

GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

Calling=A

Called=B1

CurrCalling=A

CurrCalled=B1

LRP=B1

 

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- TermConnDroppedEv for TB2' Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for TB2' Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for

C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC-1 CiscoTransferEndEv

 

Scenario:5

Application is observing C:

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and

dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses transfer key to complete transfer

JTAPI Event received to CallObserver at C

GC1- CallActiveEv for callID=101 Cause: CAUSE_NEW_CALL

GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL

GC1- ConnCreatedEv for B2 Cause: CAUSE_NORMAL

GC-1CiscoTransferStartEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1,

TransferredCall= GC2) Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC1- TermConnCreatedEv CT Cause: Other: 31

GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL

GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

Calling=B2

Called=C

CurrCalling=A

CurrCalled=C

LRP=B1

 

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2-

CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC1- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC1- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC1- 1 CiscoTransferEndEv Cause: CAUSE_NORMAL

 
 

GC1- ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for A Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for B2 Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

CallControlCause: CAUSE_TRANSFER

 

Scenario:6

Application is observing both A and C:

A calls B1, B1 answers - GC1

User presses transfer key on Cisco Unified IP 7931G phone and

dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses transfer key to complete transfer

JTAPI events at observer of A & C:

GC-1CiscoTransferStartEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1,

TransferredCall= GC2) Cause: CAUSE_NORMAL

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC1- 1 CiscoTransferEndEv Cause: CAUSE_NORMAL

Calling=A

Called=B1

CurrCalling=A

CurrCalled=C

LRP=B1

 

GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER

GC1- TermConnCreatedEv CT Cause: Other: 31

GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL

GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER NEW META

GC-1 ConnDisconnectedEv for B1 -GC1 Cause: CAUSE_UNKNOWN

GC-1 CallCtlConnDisconnectedEv for B1 - GC1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER

 

Scenario:7

Application is observing A:

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and

dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference

JTAPI Event received to CallObserver at A

GC-1 CiscoConferenceStartedEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1, ConsultCall= null)

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC-1 CiscoConferenceEndEv

Calling=A

Called=B1

CurrCalling=A

CurrCalled= Conference

LRP=B1

Scenario:8

Application is observing A, B1':

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and

dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference

JTAPI Event received to CallObserver at A

GC-1 CiscoConferenceStartedEv (ControllerAddress=B1,

ControllerTerminalConnection=TC at TB1', FinalCall=GC1,

ConsultCall= null)

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1 TermConnPassiveEv TB1'

GC1 CallCtlTermConnBridgedEv TB1'

GC-1 CiscoConferenceEndEv

Calling=A

Called=B1

CurrCalling=A

CurrCalled= Conference

LRP=B1

Scenario:9

Application is observing

A, B1', B2':

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference

JTAPI Event received to CallObserver at A, B1' and B2'

GC-1 CiscoConferenceStartedEv (ControllerAddress=B1,

ControllerTerminalConnection= TC at TB1', FinalCall=GC1, ConsultCall= GC2)

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1 TermConnPassiveEv - TB1'

GC1 CallCtlTermConnBridgedEv - TB1'

GC2- TermConnDroppedEv for TB2' Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for TB2' Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

Calling=A

Called=B1

CurrCalling=A

CurrCalled= Conference

LRP=B1

 

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC-1 CiscoConferenceEndEv

 

Scenario:10

Application is observing A, B1', B2', and C:

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference

JTAPI Event received to CallObserver at A, B1', B2' and C

GC-1 CiscoConferenceStartedEv (ControllerAddress=B1,

ControllerTerminalConnection= TC at TB1', FinalCall=GC1,

ConsultCall= GC2)

GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL

GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL

GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1 TermConnPassiveEv - TB1'

GC1 CallCtlTermConnBridgedEv - TB1'

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- TermConnDroppedEv for TB2' Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for TB2' Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

Calling=A

Called=B1

CurrCalling=A

CurrCalled= Conference

LRP=B1

 

GC2- TermConnDroppedEv for TC Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for TC Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2-

CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC-1 CiscoConferenceEndEv

 

Scenario:11

Application is observing C:

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference.

JTAPI Event received to CallObserver at C

GC1- CallActiveEv for callID=101 Cause: CAUSE_NEW_CALL

GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL

GC1- ConnCreatedEv for B2 Cause: CAUSE_NORMAL

GC-1CiscoConferenceStartEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1,

ConsultCall= GC2) Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- TermConnCreatedEv CT Cause: Other: 31

GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL

GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- ConnConnectedEv for B2 Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

Calling=B2

Called=C

CurrCalling=A

CurrCalled= Conference

LRP=B1

 

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC1- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC1- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- ConnCreatedEv for A Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for A Cause: CAUSE_NORMAL

 
 

GC1- CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- ConnCreatedEv for B1 Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for B1 Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for B1 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- 1 CiscoConferenceEndEv Cause: CAUSE_NORMAL

 

Scenario:12

Application is observing both A and C:

A calls B1, B1 answers - GC1

User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C:

B2 calls C, C answers - GC2

User presses conference key to complete conference.

JTAPI events at observer of A & C:

GC-1CiscoConferenceStartEv (ControllerAddress=B1,

ControllerTerminalConnection=Null, FinalCall=GC1,

ConsultCall= GC2) Cause: CAUSE_NORMAL

GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL

GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL

GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRAN

CAUSE_CONFERENCE SFER

GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL

GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC2- CallInvalidEv Cause: CAUSE_NORMAL

GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL

GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL

GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

Calling=A

Called=B1

CurrCalling=A

CurrCalled= Conference

LRP=B1

 

GC1- TermConnCreatedEv CT Cause: Other: 31

GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL

GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE

GC1- 1 CiscoConferenceEndEv Cause: CAUSE_NORMAL

 

Locale Infrastructure Development Scenarios

Scenario 1— JTAPI client machine has connectivity to CallManager TFTP Server

During install, JTAPI client would prompt user to enter TFTP IP address.

TFTP-IP Address is stored in JTAPI.ini parameter.

JTAPI Preferences application is run first time, it will take user to language tab to language selection.

User can select language for running JTAPI Preference application.

JTAPI Preference application is run second time, it will present UI in the language that user selected before.

Scenario 2— JTAPI client machine doesn't have connectivity to CallManager TFTP Server

During install JTAPI Client would prompt user to Enter TFTP-IP Address

TFTP-IP Address is stored in JTAPI.ini parameter.

JTAPI Preferences application is run first time, it will take user to language tab to language selection but user will have only English language to select.

JTAPI Preference application is run second time, it will present UI in the English languages.

TFTP connectivity is restored. Now JTAPI Preferences UI is run, it will take user to language selection

Scenario 3—JTAPI client machine has connectivity to CallManager TFTP Server

During install JTAPI Client would prompt user to Enter TFTP-IP Address

TFTP-IP Address is stored in JTAPI.ini parameter.

JTAPI Preferences application is run first time, it will take user to language tab to language selection.

User can select language for running JTAPI Preference application.

JTAPI Preference application is run second time, it will present UI in the language that user selected before.

Now new locale files are available with added support for a new languages.

User runs JTAPI Preferences application, JTAPI Preferences application would notify user about available.

Application restart JTAPI Preferences application, user will be support for new language.

Calling Party Normalization

Scenario 1—Incoming call from a PSTN Number (Local) to JTAPI Observed terminal.

Action
Events
Call Info

A call is offered from a PSTN Number [55555555] A & the Number type is [Subscriber] through the gateway to a JTAPI Observed Terminal [2222] B.

NEW META EVENT_________
META_CALL_STARTINGCallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause:
CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause
CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (55555555)

Called: B (2222)

getModifiedCallingAddress (): A (55555555)

getModifiedCalledAddress (): B (2222.)

getCurrentCalledAddress(): B (2222)

getCurrentCalledPartyInfo(): B (2222)

getGlobalizedCallingParty: A +140855555555

getCurrentCallingPartyInfoNumberType().getNumberType() would return: Subscriber


Scenario Two—Incoming call from a National PSTN Number to JTAPI Observed terminal.

Action
Events
Call Info

A call is offered from a Dallas PSTN Number [55555555] A & the Number type is [National] through a gateway to a JTAPI Observed Terminal [2222] B.

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (97255555555)

Called: B (2222)

getModifiedCallingAddress (): 97255555555

getModifiedCalledAddress (): 2222

getCurrentCalledAddress(): 2222

getCurrentCalledPartyInfo(): 2222

getGlobalizedCallingParty (): +197255555555

getCurrentCallingPartyInfoNumberType().getNumberType() would return: National


Scenario Three—Incoming call from Inter-National PSTN Number to JTAPI Observed terminal.

Action
Events
Call Info

A Call is offered from India PSTN Number [918028520261] & the Number type is [Inter-national] through a San Jose Gateway to a JTAPI observed Terminal [2222]

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (918028520261)

Called: B (2222)

getModifiedCallingAddress (): 918028520261

getModifiedCalledAddress (): 2222

getCurrentCalledAddress(): 2222

getCurrentCalledPartyInfo(): 2222

getGlobalizedCallingParty (): +918028520261

getCurrentCallingPartyInfoNumberType().getNumberType() would return: Inter-National


Scenario Four—Outgoing call from a JTAPI Observed Terminal to a PSTN number [SUBSCRIBER]

Action
Events
Call Info

A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to a PSTN number [44444444] and the Number type is [SUBSCRIBER]

NEW META EVENT_________META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (2222)

Called: B (44444444)

getModifiedCallingAddress (): 2222

getModifiedCalledAddress (): 44444444

getCurrentCalledAddress(): 44444444

getCurrentCalledPartyInfo(): 44444444

getGlobalizedCallingParty (): 2222

getCurrentCallingPartyInfoNumberType ().getNumberType () would return: Unknown.


Scenario Five—Outgoing call from a JTAPI Observed Terminal to a National PSTN number.

Action
Events
Call Info

A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to a Dallas PSTN number [97244444444] & the Number type is [NATIONAL]

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (2222)

Called: B (97244444444)

getModifiedCallingAddress (): 2222

getModifiedCalledAddress (): 97244444444

getCurrentCalledAddress(): 97244444444

getCurrentCalledPartyInfo(): 97244444444

getGlobalizedCallingParty (): 2222 getCurrentCallingPartyInfoNumberType().getNumberType() would return: Unknown.


Scenario Six—Outgoing call from a JTAPI Observed Terminal to Inter-National PSTN number.

Action
Events
Call Info

A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to India PSTN number [918028520261] & the Number type is [INTERNATIONAL]

NEW META EVENT_________
META_CALL_STARTING

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause: CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

Calling: A (2222)

Called: B (918028520261)

getModifiedCallingAddress (): 2222

getModifiedCalledAddress (): 918028520261

getCurrentCalledAddress():918028520261

getCurrentCalledPartyInfo(): 918028520261

getGlobalizedCallingParty (): 2222

getCurrentCallingPartyInfoNumberType().getNumberType() would return: Unknown.


Scenario Seven—Incoming call from a PSTN Redirected to another PSTN by a JTAPI Observed Terminal.

Action
Events
Call Info

A call is offered from PSTN [55555555] through a San Jose

NEW META EVENT_________
META_CALL_STARTING

Calling: A (55555555)
Called: B (2222)

Gateway to a JTAPI observed terminal [2222] which redirects the call to another San Jose PSTN [44444444].

In CallState [Idle] the fwdDestinationAddress (Redirect Address) should be a minus (-).

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause:
CAUSE_NORMAL

ConnConnectedEv for A Cause: CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause: CAUSE_NORMAL

TernConnActiveEv for A Cause: CAUSE_NORMAL

CallCtlConnDialingEv for A Cause: CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL

ConnCreatedEv for B cause:
CAUSE_NORMAL

ConnInProgressEv for B Cause: CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL

ConnAlertingEv for B Cause: CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL

getModifiedCallingAddress (): 55555555

getModifiedCalledAddress (): 2222

getCurrentCalledAddress(): 2222

getCurrentCalledPartyInfo(): 2222

getGlobalizedCallingParty (): +140855555555

getCurrentCallingPartyInfoNumberType().getNumberType() would return: SUBSCRIBER

destinationAddress: 44444444.

getCurrentCallingPartyInfoNumberType().getNumberType() would return: Unknowns

 

TermConnCreatedEv for B Cause: CAUSE_NORMAL

TermConnRingingEv for B Cause: CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL

CallRedirectReq Redirect Address = C CallRedirectRes

ConnCreatedEv at C Cause: CAUSE_REDIRECTED

ConnInProgress Calling party:
A, Called Party: C, LRP: B

CallRedirectRes CallStateChangedEv (IDLE) Reason: REDIRECT

 

Scenario Eight—Incoming call from a PSTN Number (Local) to JTAPI Observed terminal who transfer to another JTAPI observed terminal.

Action
Events
Call Info

A call is offered from a PSTN Number [55555555] A & the Number type is [Subscriber] through a San Jose gateway to a JTAPI observed Terminal [1111] X which transfers the call to another JTAPI Observed Terminal [2222] B

After Transfer:

GC1:

CiscoTransferStartEv

ConnCreatedEv for B

ConnConnectedEv for B

CallCtlConnEstablishedEv for B

TermConnDroppedEv for X

ConnDisconnectedEv for X

CallCtlConnDisconnectedEv for X

CiscoTransferStartEv

GC2:

CiscoTransferStartEv

TermConnDroppedEv for X

ConnDisconnectedEv for X

CallCtlConnDisconnectedEv for X

CiscoTransferStartEv

After Transfer:

Calling: A (55555555)

Called: B (2222)

getModifiedCallingAddress (): A (+140855555555)

getModifiedCalledAddress (): B (2222.)

getCurrentCalledAddress(): B (2222)

getCurrentCalledPartyInfo(): B (2222)

getGlobalizedCallingParty: A +140855555555

getCurrentCallingPartyInfoNumberType().getNumberType() would return: Subscriber


Click to Conference

A, B, C and D are addresses and TermA, TermB, TermC and TermD are corresponding terminals.

Action
Events
Call Info

A and B are in a call GC1 created using click-to-call. User adds C to the conference call. GC2 is the initial call at C. Application is observing only C

GC2: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CONFERENCE

callingAddress=unknown calledAddress=C

CurrentCalling=unknown

CurrentCalled=C

 

GC2: ConnCreatedEv C CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: ConnInProgressEv C CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallCtlConnOfferedEv C CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: ConnAlertingEv C CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallCtlConnAlertingEv C CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: TermConnCreatedEv TermC

 
 

GC2: TermConnRingingEv TermC CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallCtlTermConnRingingEv TermC CiscoFeatureReason=REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

CiscoCallChangedEv GC2->GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnCreatedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnAlertingEv C GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnAlertingEv C GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: TermConnCreatedEv TermC

 
 

GC1: TermConnRingingEv TermC CiscoCallChangedEv GC2->GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: TermConnDroppedEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallCtlTermConnDroppedEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: ConnDisconnectedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallCtlConnDisconnectedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC2: CallInvalidEv CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnCreatedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnConnectedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnEstablishedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnCreatedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnConnectedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnEstablishedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnConnectedEv C CiscoFeatureReason =REASON_NORMALCause: CAUSE_NORMAL

 
 

GC1: CallCtlConnEstablishedEv C CiscoFeatureReason =REASON_NORMALCause: CAUSE_NORMAL

 
 

GC1: TermConnTalkingEv TermC CiscoFeatureReason =REASON_NORMALCause: CAUSE_NORMAL

 

A calls B using click-to-call - GC1. A adds C to the call using click-2-conf. Application has call observer on A

GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_REFER

Calling address: A

Called address: B

Current calling: A

Current called: B

Last redirecting party=null

After C is conferenced, callinfo is not applicable.

 

GC1: ConnCreatedEv A CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: ConnInProgressEv A CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnOfferedEv A CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: ConnAlertingEv A CiscoFeatureReason=REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnAlertingEv A CiscoFeatureReason=REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: TermConnCreatedEv TermA

 
 

GC1: TermConnRingingEv TermA CiscoFeatureReason=REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: CallCtlTermConnRingingEv TermA CiscoFeatureReason=REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: GC1: ConnConnectedEv A CiscoFeatureReason =REASON_NORMAL cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnEstablishedEv A CiscoFeatureReason =REASON_NORMAL Cause: CAUSE_NORMAL

 
 

TermConnActiveEv TermA CiscoFeatureReason =REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: TermConnTalkingEv TermA CiscoFeatureReason =REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: ConnCreatedEv B CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: ConnInProgressEv B CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnOfferedEv B CiscoFeatureReason= REASON_REFER Cause: CAUSE_NORMAL

 
 

GC1: ConnAlertingEv B CiscoFeatureReason= REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnAlertingEv B CiscoFeatureReason= REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: GC1: ConnConnectedEv B CiscoFeatureReason = REASON_NORMAL: CAUSE_NORMAL

 
 

GC1: CallCtlConnEstablishedEv B CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL

 
 

GC1: ConnCreatedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnAlertingEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnAlertingEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL

 

A consults with D-GC3. A completes conference. The events received by application remains the same (as that of consult conference).

GC1: TermConnHeldEv TermA

For consult call GC3: Calling address: A

Called address: D

Callinfo not applicable after conference is completed.

 

GC3: ConsultCallActiveEv

 
 

GC3: ConnCreatedEv A

 
 

GC3: ConnCreatedEv D

 
 

GC3: CallCtlConnAlerting D

 
 

GC3: ConnConnectedEv D

 
 

GC3: CallCtlConnEstablishedEv B

 
 

CiscoConferenceStartEv GC3->GC1

 
 

GC3: CallCtlConnDisconnectedEv A

 
 

GC3: CallCtlConnDisconnectedEv D

 
 

GC1: ConnCreatedEv D

 
 

GC1: CallCtlConnEstablishedEv D

 
 

GC1: TermConnTalkingEv TermA

 
 

GC3: CallInvalidEv

 
 

CiscoConferenceEndEvent

 

User drops D using click-2-conf feature

User drops C using click-2-conference interface

GC1: ConnDisconnectedEv D CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL

Calling address: A

Called address: B

 

GC1: CallCtlConnDisconnectedEv D CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: ConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL

 
 

GC1: CallCtlConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL

 

Drop all parties a conference.

A calls B using click-2-call. User adds C to the conference using click-2-conference.

All parties are dropped using click to conference.

Application has call observers on A, B and C.

GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_REFER

GC1: ConnCreatedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

Calling address: A

Called address: B

GC2: Calling address=unknown

Called address: C

 

GC1: ConnInProgressEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: CallCtlConnOfferedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: ConnAlertingEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: CallCtlConnAlertingEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: TermConnCreatedEv TermA

 
 

GC1: TermConnRingingEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnRingingEv TermA

 
 

GC1: ConnConnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: TermConnActiveEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnTalkingEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: ConnCreatedEv B Cause: CAUSE_NORMAL CiscoFeatureReason:REASON_REFER

 
 

GC1: ConnInProgressEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER

 
 

GC1: ConnAlertingEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlConnAlertingEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: TermConnCreatedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: TermConnRingingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnRingingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: ConnConnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlConnEstablishedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: TermConnActiveEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnTalkingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CONFERENCE

 
 

GC2: ConnCreatedEv Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE

 
 

GC2: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE

 
 

GC2: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE

 
 

GC2: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: TermConnCreatedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: TermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: CallCtlTermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC2: CiscoCallChangedEv GC2->GC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: TermConnCreatedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason REASON_CLICK_TO_CONFERENCE

 
 

GC1: TermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: CallCtlTermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC2: TermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC2: CallCtlTermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC2: ConnDisconnectedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC2: CallCtlConnDisconnectedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC2: CallInvalidEv Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnConnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: TermConnActiveEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: CallCtlTermConnTalkingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

All parties are dropped using click-2-conference

GC1: TermConnDroppedEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlTermConnDroppedEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: TermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlTermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: TermConnDroppedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlTermConnDroppedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallInvalidEv

 

A calls B using click-to-call - GC1. A adds C to the call using click-2-conf. User drops party C. Application has call observer on C only.

GC1: TermConnDroppedEv TermC CiscoFeatureReason= REASON_CONFERENCE

NA

 

GC1: CallCtlTermConnDroppedEv TermC CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv C CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv C CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv A CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv A CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: ConnDisconnectedEv B CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallCtlConnDisconnectedEv B CiscoFeatureReason= REASON_CONFERENCE

 
 

GC1: CallInvalidEv

 

A calls B using GC1. Address C is configured on TermC1 and TermC2. Application has call observer on C

GC2: CallActiveEv CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_ CONFERENCE

Calling=unknown

Called=C

Last redirecting=null

User uses click-to-conference to C.

GC2: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CONFERENCE

 
 

GC2: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CONFERENCE

 
 

GC2: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CONFERENCE

 
 

GC2: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC2: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC2: TermConnCreatedEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC2: TermConnRingingEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC2: TermConnCreatedEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC2: TermConnRingingEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ NORMAL

 
 

GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

CiscoCallChangedEv GC2->GC1 TermConn TermC1 CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE

 
 

GC1: ConnAlertingEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnAlertingEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: TermConnCreatedEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: TermConnRingingEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

CiscoCallChangedEv GC2->GC1 TermConn TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: TermConnCreatedEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: TermConnRingingEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC2: CallCtlConnDisconnectedEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC2: TermConnDroppedEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC2: TermConnDroppedEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC2: CallInvalidEv

 
 

GC1: ConnCreatedEv B Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: ConnConnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnEstablishedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: ConnCreatedEv A Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: ConnConnectedEv A Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_ CLICK_TO_CONFERENCE

 
 

GC1: ConnConnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

C answers at TermC1

 

GC1: CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnTalkingEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: TermConnPassEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 
 

GC1: CallCtlTermConnInUseEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL

 

Call Pickup

The basic scenarios are as follows:

B and C are devices in a call pick up group. A is a device not in it.

A calls B.

C goes off-hook, and presses it's "Pickup" softkey.

C is now on the call with A.

Each device was observed as follows:

Observing A, B, and C

Observing A and B

Observing A and C

Observing B and C

Observing only A

Observing only B

Observing only C

Only observing C, was the primary concern for this fix, as it was what the customer was doing in their scenario. The feature request was for when only observing C, being able to get information about the original called party (A) on Pickup. All test cases passed and the correct info was shown for all of them.

These test cases were run with auto-pickup both enabled and disabled, and the functionality of the two differed greatly. Most of the test cases are enumerated below.

The "basic call" from A to B is the same in all cases, and is only shown in the first case below.

Scenario One

Observing all devices and auto-pickup enabled.

Action
Events
Call Info (GCID Info)

A goes offhook and dials B (Basic Call) B is ringing C goes offhook and presses "Pickup" softkey Old Conn for C is dropped B is dropped / cleaned up C connection on Call 1 is established

GC1-CallActiveEvent-NONE

Calling: A, CCalled: NONE

Calling: A, Called: NONE

 

GC1-ConnCreatedEvent-A

CAUSE_NEW_CALL

 

GC1-ConnConnectedEvent-A

REASON_NORMAL

 

GC1-CallCtlConnInitiatedEv-A

LRP: NONE

 

GC1-TermConnCreatedEvent

CCalling: A, CCalled: B

 

GC1-TermConnActiveEvent

Calling: A, Called: B

 

GC1-CallCtlTermConnTalkingEv

CCalling: C, CCalled: NONE

 

GC1-CallCtlConnDialingEv-A

CAUSE_NEW_CALL

 

GC1-CallCtlConnEstablishedEv-A

REASON_NORMAL

 

GC1-ConnCreatedEvent-B

LRP: NONE

 

GC1-ConnInprogressEvent-B

REASON_CALLPICKUP

 

GC1-CallCtlConnOfferedEv-B

CCalling: A, CCalled: C

 

GC1-ConnAlertingEvent-B

LRP: NONE

 

GC1-CallCtlConnAlertingEv

REASON_CALLPICKUP

 

GC1-TermConnCreatedEvent

CCalling: C, CCalled: NONE

 

GC1-TermConnRingingEvent

LRP: NONE

 

GC1-CallCtlTermConnRingingEv

REASON_NORMAL

 

GC2-CallActiveEvent-NONE

REASON_CALLPICKUP

 

GC2-ConnCreatedEvent-C

CCalling: A, CCalled: C

 

GC2-ConnConnectedEvent-C

REASON_NORMAL

 

GC2-CallCtlConnInitiatedEv-C

 
 

GC2-TermConnCreatedEvent

 
 

GC2-TermConnActiveEvent

 
 

GC2-CallCtlTermConnTalkingEv

 
 

GC2-CiscoCallChangedEv

 
 

GC1-ConnCreatedEvent-C

 
 

GC1-ConnConnectedEvent-C

 
 

GC1-CallCtlConnInitiatedEv-C

 
 

GC1-TermConnCreatedEvent

 
 

GC1-TermConnActiveEvent

 
 

GC1-CallCtlTermConnTalkingEv

 
 

GC2-TermConnDroppedEv

 
 

GC2-CallCtlTermConnDroppedEv

 
 

GC2-ConnDisconnectedEvent-C

 
 

GC2-CallCtlConnDisconnectedEv-C

 
 

GC2-CallInvalidEvent

 
 

GC2-CallObservationEndedEv

 
 

GC1-TermConnDroppedEv

 
 

GC1-CallCtlTermConnDroppedEv

 
 

GC1-ConnDisconnectedEvent-B

 
 

GC1-CallCtlConnDisconnectedEv-B

 
 

GC1-CallCtlConnEstablishedEv-C

 


Note Both B and C in the following scenarios have exactly the same behavior and events. Only the behavior of device C (the one picking up the call) changes.


Scenario Two

Observing all devices with auto-pickup disabled.

Action
Events
Call ID Info

C goes offhook and presses Pickup softkey

Call 2 gets dropped / invalidated

C gets a connection on Call 1

B is dropped from Call 1

C is ringing

C is on call with A

GC2-CallActiveEvent

GC2-ConnCreatedEvent-C

GC2-ConnConnectedEvent-C

GC2-CallCtlConnInitiatedEv-C

GC2-TermConnCreatedEvent

GC2-TermConnActiveEvent

GC2-CallCtlTermConnTalkingEv

GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-ConnCreatedEvent-C
GC1-ConnInprogressEvent-C
GC1-CallCtlConnOfferedEv-C

GC1-TermConnDroppedEv
GC1-CallCtlTermConnDroppedEv
GC1-ConnDisconnectedEvent-B
GC1-CallCtlConnDisconnectedEv-B

GC1-ConnAlertingEvent-C
GC1-CallCtlConnAlertingEv-C
GC1-TermConnCreatedEvent
GC1-TermConnRingingEvent
GC1-CallCtlTermConnRingingEv

GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv

CCalling C, CCalled: NONE

LRP: NONE

REASON_NORMAL

REASON_CALLPICKUP

CCalling A, CCalled: C

Calling: A, Called: C, LRP: B

REASON_CALLPICKUP

Calling A, CCalled: C

Calling: A, Called: C, LRP: B

REASON_CALLPICKUP

REASON_NORMAL

REASON_NORMAL


The flow of events differs greatly when the auto-pickup option is enabled or disabled. When Auto Call Pickup is disabled and a user presses the Pickup softkey (C), the phone rings. The user has to answer the phone as if it is a normal call. When the phone is ringing, the original call that was created when they went offhook is destroyed, they are connected to the existing call, and the old party (B) is removed from the call. There is no CiscoCallChangedEv generated when "Auto Call Pickup" is disabled, because the call does not change, it is destroyed before C joins the new call.

A Group Pickup scenario follows, during which the Group Pickup softkey is used in place of the Pickup softkey. This required actually dialing the number for the pickup group. Group Pickup also is subject to the Auto Call Pickup service parameter. The general flow and call events are identical to the normal Call Pickup scenarios, except with added events for the required dialing of the pickup number. These additional events bold in the table to clearly show the changes that Group Pickup makes.

Scenario Three

Observing all devices with group pickup and auto-pickup enabled.

Action
Call Event
Call ID Info

C goes offhook and presses "Group Pickup" softkey





C is dialing the PU Number




C is added to the original call
Pickup added to original call







Pickup # is removed Call 2

C is dropped from Call 2





Pickup # is removed Call 1

B is dropped / invalidated

GC1 [add to others to clarify]


GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv

GC2-CallCtlConnDialingEv-C
GC2-ConnCreatedEvent-PU
GC2-ConnInprogressEvent-PU
GC2-CallCtlConnEstablishedEv-C
GC2-CiscoCallChangedEv

GC1-ConnCreatedEvent-C
GC1-ConnCreatedEvent-PU
GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C
GC1-TermConnCreatedEvent
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv
GC1-ConnInprogressEvent-PU
GC1-CallCtlConnOfferedEv-PU

GC2-ConnDisconnectedEvent-PU
GC2-CallCtlConnDisconnectedEv-PU
GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-ConnDisconnectedEvent-PU
GC1-CallCtlConnDisconnectedEv-PU

GC1-TermConnDroppedEv
GC1-CallCtlTermConnDroppedEv
GC1-ConnDisconnectedEvent-B
GC1-CallCtlConnDisconnectedEv-B

CCalling: C, CCalled: NONE
LRP: NONE
REASON_NORMAL




CCalling: C, CCalled: NONE
REASON_CALLPICKUP
CCalling: C, CCalled: PU, LRP: PU

CCalling C, CCalled: PU
CCalling: A, CCalled: C, LRP: B
Calling: A, Called: B
REASON_CALLPICKUP





CCalling: A, CCalled: C, LRP:B
REASON_CALLPICKUP, LRP: PU

CCalling: C, CCalled: PU
REASON_CALLPICKUP

CCalling: A, CCalled C, LRP: B
REASON_CALLPICKUP


CCalling: A, CCalled C, LRP: B
REASON_CALLPICKUP


There are only a handful of changes for the above Group Pickup case, and they all directly relate to the extra required step of dialing the pickup number.

Scenario Four

Observing all devices with Group Pickup and Auto-Pickup disabled.

Action
Event
Call Info

C goes offhook and pressed "Group Pickup" softkey





C is dialing the PU number



PU is removed from Call 2



C is removed from Call 2

Call 2 is destroyed

C gets a connection on Call 1


B is dropped from Call 1






C is ringing


C picks up

GC1


GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv

GC2-CallCtlConnDialingEv-C
GC2-ConnCreatedEvent-PU
GC2-ConnInprogressEvent-PU
GC2-CallCtlConnEstablishedEv-C

GC2-ConnDisconnectedEvent-PU
GC2-CallCtlConnDisconnectedEv-PU
GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-ConnCreatedEvent[ADDRS]
GC1-ConnInprogressEvent
GC1-CallCtlConnOfferedEv

GC1-TermConnDroppedEv
GC1-CallCtlTermConnDroppedEv
GC1-ConnDisconnectedEvent
GC1-CallCtlConnDisconnectedEv
GC1-ConnAlertingEvent
GC1-CallCtlConnAlertingEv
GC1-TermConnCreatedEvent

GC1-TermConnRingingEvent
GC1-CallCtlTermConnRingingEv
GC1-ConnConnectedEvent
GC1-CallCtlConnEstablishedEv
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv


CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL





CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL

CCalling: C, CCalled: PU

CCalling: C, CCalled: PU, LRP: PU
REASON_CALLPICKUP






CCalling: A, CCalled: C, LRP: B
Calling: A, Called: B
REASON_CALLPICKUP

CCalling: A, CCalled: C, LRP: B
REASON_CALLPICKUP


REASON_NORMAL


CCalling: A, CCalled: C, LRP: B
REASON_NORMAL


The tables above have scenarios during which all of the devices were observed. The devices were run with every possible combination, across all varieties of Pickup and Group Pickup. Parts of the scenarios had the exact same output and others were redundant and are not shown here. For example, device A and B were identical and shown only once.

Scenario Five

Only observing device B.

Action
Call Events
Call IDs/Call Info

A is in the process of calling B









B is ringing

A is removed from Call 1

B is removed from Call 1

GC1-CallActiveEvent-NONE
GC1-ConnCreatedEvent-B
GC1-ConnInprogressEvent-B
GC1-CallCtlConnOfferedEv-B
GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-A
GC1-CallCtlConnEstablishedEv-A
GC1-ConnAlertingEvent-B
GC1-CallCtlConnAlertingEv-B
GC1-TermConnCreatedEvent

GC1-TermConnRingingEvent
GC1-CallCtlTermConnRingingEv

GC1-ConnDisconnectedEvent-A
GC1-CallCtlConnDisconnectedEv-A

GC1-TermConnDroppedEv
GC1-CallCtlTermConnDroppedEv
GC1-ConnDisconnectedEvent-B
GC1-CallCtlConnDisconnectedEv-B
GC1-CallInvalidEvent
GC1-CallObservationEndedEv

CCalling: A, CCalled: B,
Calling: A, Called: B, LRP: NONE
REASON_NORMAL









REASON_CALLPICKUP





REASON_NORMAL


Scenario Six

Observing only device A.

Action
Call Events
Call IDs/Call Info

A goes offhook and dials B











B is ringing




C is ringing

B is removed from Call 1

GC1-CallActiveEvent-NONE
GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-A
GC1-CallCtlConnInitiatedEv-A
GC1-TermConnCreatedEvent
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv
GC1-CallCtlConnDialingEv-A
GC1-CallCtlConnEstablishedEv-A
GC1-ConnCreatedEvent-B
GC1-ConnInprogressEvent-B
GC1-CallCtlConnOfferedEv-B

GC1-ConnAlertingEvent-B
GC1-CallCtlConnAlertingEv-B
GC1-ConnCreatedEvent-C
GC1-ConnInprogressEvent-C
GC1-CallCtlConnOfferedEv-C

GC1-ConnAlertingEvent-C
GC1-CallCtlConnAlertingEv-C

GC1-ConnDisconnectedEvent-B
GC1-CallCtlConnDisconnectedEv-B
GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C

CCalling: A, CCalled: NO, NO LRP
REASON_NORMAL






CCalling A, CCalled B,
Called: NOT SET LRP: NONE




CCalling: A, CCalled: C, LRP: B
Called: NOT SET
REASON_CALLPICKUP

REASON_NORMAL

REASON_CALLPICKUP

REASON_NORMAL


Scenario Seven

Observing only device C with Auto-Pickup enabled.

Action
Call Events
Call IDs/Call Info

C goes offhook and presses "Pickup" hotkey











C is connected to Call 1

C is dropped from Call 2



Call 2 is invalidated / cleared

A and C are connected on Call 1

GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv
GC2-CiscoCallChangedEv
GC1-CallActiveEvent-NONE
GC1-ConnCreatedEvent-C
GC1-ConnConnectedEvent-C
GC1-CallCtlConnInitiatedEv
GC1-TermConnCreatedEvent

GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv

GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-A
GC1-CallCtlConnEstablishedEv-A
GC1-CallCtlConnEstablishedEv-C

CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL





REAON_CALLPICKUP
CCalling A, CCalled: NONE
LRP: NONE



CCalling: A, CCalled: C, LRP: B
REASON_CALLPICKUP

CCalling: C, CCalled: NONE
REASON_CALLPICKUP


REASON_CALLPICKUP

CCalling A, CCalled: C, LRP: B
REASON_CALLPICKUP

REASON_NORMAL


Scenario Eight

Observing only device C with Auto-Pickup disabled.

Action
Call Events
Call IDs/Call Info

C goes offhook and pressed "Pickup" softkey





Call 2 is destroyed





C is added to Call 1, but does not pick up








C is ringing

C picks up, and is connected to Call 1

GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv

GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-CallActiveEvent
GC1-ConnCreatedEvent-C
GC1-ConnInprogressEvent-C
GC1-CallCtlConnOfferedEv-C
GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-A
GC1-CallCtlConnEstablishedEv-A
GC1-ConnAlertingEvent-C
GC1-CallCtlConnAlertingEv-C
GC1-TermConnCreatedEvent
GC1-TermConnRingingEvent
GC1-CallCtlTermConnRingingEv

GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv

CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL





REASON_CALLPICKUP
CCalling: C, CCalled: NONE



REASON_NORMAL

CCalling: A, CCalled: C, LRP: B
REASON_CALLPICKUP





REASON_NORMAL






CCalling: A, CCalled: C, LRP: B
REASON_NORMAL


Scenario Nine

Observing only device C with Group Pickup and AutoPickup enabled.

Action
Call Event
Call IDs/Call Info

C goes offhook and presses "Pickup" softkey





C dials the Pickup Number





C is added to Call 1
PU is added to Call 1







PU # is removed from Call 2



C is removed from Call 2

Call 2 I invalidated / cleared

C is connected to Call 1




PU is removed from Call 1

GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv

GC2-CallCtlConnDialingEv-C
GC2-ConnCreatedEvent-PU
GC2-ConnInprogressEvent-PU
GC2-CallCtlConnEstablishedEv-C
GC2-CiscoCallChangedEv
GC1-CallActiveEvent

GC1-ConnCreatedEvent-C
GC1-ConnCreatedEvent-PU
GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C
GC1-TermConnCreatedEvent
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv
GC1-ConnInprogressEvent-PU
GC1-CallCtlConnOfferedEv-PU

GC2-ConnDisconnectedEvent-PU
GC2-CallCtlConnDisconnectedEv-PU
GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv

GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent
GC2-CallObservationEndedEv

GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-PU
GC1-CallCtlConnEstablishedEv-PU
GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C

GC1-ConnDisconnectedEvent-PU
GC1-CallCtlConnDisconnectedEv-PU

CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL


CCalling: C, CCalled: PU





CCalling: C, CCalled: PU, LRP: PU
REASON_CALLPICKUP
REASON_NORMAL
REASON_CALLPICKUP
CCalling: A,C Called: C

CCalling: A, CCalled: C, LRP: B
Calling: A, Called: B
REASON_CALLPICKUP






CCalling C, CCalled: PU, LRP: PU
REASON_CALLPICKUP




CCalling C, CCalled: PU, LRP: PU
REASON_CALLPICKUP

REASON_NORMAL

CCalling: A, CCalled: C
REASON_CALLPICKUP





CCalling: A, CCalled: C
REASON_CALLPICKUP


Scenario Ten

Observing only device C with Group Pickup and Auto-Pickup disabled.

Action
Call Events
Call IDs/Call Info

C goes offhook, and presses "Group Pickup" softkey





C dials the PU Number



PU is dropped from Call 2



C is dropped from Call 2

Call 2 is destroyed

C is added to Call 1









C is ringing

C is connected to A

GC2-CallActiveEvent-NONE
GC2-ConnCreatedEvent-C
GC2-ConnConnectedEvent-C
GC2-CallCtlConnInitiatedEv-C
GC2-TermConnCreatedEvent
GC2-TermConnActiveEvent
GC2-CallCtlTermConnTalkingEv

GC2-CallCtlConnDialingEv-C
GC2-ConnCreatedEvent-PU
GC2-ConnInprogressEvent-PU
GC2-CallCtlConnEstablishedEv-C

GC2-ConnDisconnectedEvent-PU
GC2-CallCtlConnDisconnectedEv-PU
GC2-TermConnDroppedEv
GC2-CallCtlTermConnDroppedEv
GC2-ConnDisconnectedEvent-C
GC2-CallCtlConnDisconnectedEv-C
GC2-CallInvalidEvent

GC1-CallObservationEndedEv

GC1-CallActiveEvent
GC1-ConnCreatedEvent-C
GC1-ConnInprogressEvent-C
GC1-CallCtlConnOfferedEv-C
GC1-ConnCreatedEvent-A
GC1-ConnConnectedEvent-A
GC1-CallCtlConnEstablishedEv-A
GC1-ConnAlertingEvent-C
GC1-CallCtlConnAlertingEv-C
GC1-TermConnCreatedEvent

GC1-TermConnRingingEvent
GC1-CallCtlTermConnRingingEv

GC1-ConnConnectedEvent-C
GC1-CallCtlConnEstablishedEv-C
GC1-TermConnActiveEvent
GC1-CallCtlTermConnTalkingEv

CCalling: C, CCalled: NO, NO LRP
REASON_NORMAL






CCalling: C, CCalled: PU, LRP: PU
REASON_CALLPICKUP
REASON_NORMAL

REASON_CALLPICKUP





REASON_CALLPICKUP
REASON_NOTMAL

CCalling: A, CCalled: C, LRP: B
REASON_CALLPICKUP





REASON_NORMAL


selectRoute() with Calling Search Space and Feature Priority

The selectRoute() API with calling search space and feature priority as array of int. is shown in the following table.

Action
Events
Call Info

Add call observer on phones A,B,C,D.

Register Route Point RP

Register route call back, with select route API with three rows
  route selected: A,.....CSS: 0, FP:  1   

  route selected: B,.....CSS: 1, FP:  3 
  route selected: D,.....CSS: 1, FP:  1 

C calls RP

Call rings at A.

A answers. C-A call is connected.

GC1 CallActiveEv

GC1 ConnCreatedEv C:

GC1 ConnConnectedEv C

GC1 CallCtlConnInitiatedEv C:

GC1 TermConnCreatedEv TC

GC1 TermConnActiveEv TC

GC1 CallCtlTermConnTalkingEv TC

GC1 CallCtlConnDialingEv C:

GC1 CallCtlConnEstablishedEv C:

GC1 ConnCreatedEv RP:

GC1 ConnInProgressEv RP:

GC1 CallCtlConnOfferedEv RP:

After redirect request is processed

GC1 ConnCreatedEv A:

GC1 ConnInProgressEv A:

GC1 CallCtlConnOfferedEv A:

GC1 ConnDisconnectedEv RP:

GC1 CallCtlConnDisconnectedEv RP:

GC1 ConnAlertingEv A:

GC1 CallCtlConnAlertingEv A:

GC1 TermConnCreatedEv TA

GC1 TermConnRingingEv TA

GC1 CallCtlTermConnRingingEvImpl TA

GC1 ConnConnectedEv A:

GC1 CallCtlConnEstablishedEv A:

GC1 TermConnActiveEv A

GC1 TermConnActiveEv A

[C] CiscoRTPInputStartedEv

[A] CiscoRTPOutputStartedEv

[A] CiscoRTPInputStartedEv

[C] CiscoRTPOutputStartedEv

calling: C

lastRedirected:RP

called: A


Extension Mobility Login Username

Terminal A is in control list of user, Terminal B is not in control list of User. Extension Mobility login username is John, end user id user for application is John.

Action
Result
Call Info

Open provider,  Terminal  A doesn't have any observer,  Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

InvalidStateException is thrown.

NA

Open provider, Add Observer to Terminal A,  Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

Application should get empty string "" for username.

NA

Open provider, User "John" EMLogin to Terminal A and add observer to the Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A

Application should get String "John"

NA

User "John" EMLogin to Terminal A, now open provider,  add observer  to Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

Application should get String "John"

NA

User "John" EMLogin to Terminal A, now open provider,  add observer  to Terminal A, User "John" EMLogout of Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

Application should get empty string "" for username

NA

OpenProvider, User "John" EMLogin to Terminal B, add observer, application calls CiscoTerminal.getEMLoginUserName() at Terminal B

Application should get String "John"

NA

User "John" EMLogin to Terminal B, OpenProvider, add observer to Terminal B, Application calls CiscoTerminal.getEMLoginUserName() at Terminal B

Application should get String "John"

NA


Terminal A is in control list of user and configured with the Extension Mobility logout profile of user Kerry. The Kerry profile is configured with logout username as Kerry. There is another profile with login username of John.

Action
Result
Call Info

User John logs into Terminal A, OpenProvider and add observer to Terminal A. Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

John logs out at Terminal A. Application calls CiscoTerminal.getEMLoginUserName() at Terminal A.

Application should get String John.

Application should get String Kerry.

NA

NA


Calling Party IP Address

The following are some examples of call scenarios.

Basic Call Scenario

JTAPI application monitors party B

Party A is an IP phone

A calls B

IP Address of A is available to JTAPI application monitoring party B

Consultation Transfer Scenario

JTAPI application monitors party C

Party B is an IP phone

A talking B

B initiates a consultation transfer call to C

IP Address of B is available to JTAPI application monitoring party C.

Consultation Conference Scenario

JTAPI application monitors party C

Party B is an IP phone

A talking B

B initiates a consultation conference call to C

IP Address of B is available to JTAPI application monitoring party C.

Redirect Scenario

JTAPI application monitors party B and party C

Party A is an IP phone

A calls B

IP Address of A is available to JTAPI application monitoring party B

Party A redirects B to party C (

Calling IP address is not available to JTAPI application monitoring party B (not a supported scenario).

Calling IP address of B is provided to JTAPI application monitoring party C.

CiscoJtapiProperties

1) Set Socket Connect Timeout to 5 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager and do a normal provider open. Expected Result: Socket Connect to Primary CTI Manager should fail in not more than 5 secs

2) Set Socket Connect Timeout to 5 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager, set security options to True and do a secured provider open. Expected Result: Socket Connect to Primary CTI Manager should fail in not more than 5 secs (Socket Connect timed-out in ~5 seconds, though it took some additional time initially for verifying security certificates)

3) Set Socket Connect Timeout to 0 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager, set security options to true and do a secured provider open. Expected Result: Socket Connect to Primary CTI Manager will no longer rely on new Service Parameter (Socket Connect timed-out in ~23 seconds, though it took some additional time initially for verifying security certificates).

IPv6 Support

Use Case1 - Basic Call Scenario: Calling is IPv6 enabled phone; Called is IPv6

Action
Events
Call Info/Expected Result

IPv6 enabled phone A calls JTAPI Observed IPv6 enabled device B using GC1.

NEW META EVENT_________META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object.

getCallingPartyIpAddr() will return null

getRemoteAddress() on CiscoRTPOutputProperties in CiscoOutputStartedEv will contain the far-end Ipv6 RTP address(of A)

getRemoteAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone(B)

B Answers

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B cause : CAUSE_NORMAL

ConnInProgressEv for B Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause : CAUSE_NORMAL

ConnAlertingEv for B Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TermConnRingingEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case2 - Basic Call Scenario: Calling is IPv6 enabled phone; Called is IPv4

Action
Events
Call Info/Expected Result

IPv6 enabled phone A calls JTAPI Observed IPv4 enabled device B using GC1.

NEW META EVENT_________META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object.

getCallingPartyIpAddr() will return null

getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv4 RTP address of the monitored phone

B Answers

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B cause : CAUSE_NORMAL

ConnInProgressEv for B Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause : CAUSE_NORMAL

ConnAlertingEv for B Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TermConnRingingEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case3 - Basic Call Scenario: Calling is IPv4 enabled phone; Called is IPv6

Action
Events
Call Info/Expected Result

IPv4 enabled phone A calls JTAPI Observed IPv6 enabled device B using GC1.

NEW META EVENT_________META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object.

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null

getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone

B Answers

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B cause : CAUSE_NORMAL

ConnInProgressEv for B Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause : CAUSE_NORMAL

ConnAlertingEv for B Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TermConnRingingEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case4 - Basic Call Scenario: Calling is IPv4 enabled phone; Called is IPv4

Action
Events
Call Info/Expected Result

IPv4 enabled phone A calls JTAPI Observed IPv4 enabled device B using GC1.

NEW META EVENT_________META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object.

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null

getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv4 RTP address.

getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv4 RTP address of the monitored phone

B Answers

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B cause : CAUSE_NORMAL

ConnInProgressEv for B Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for B Cause : CAUSE_NORMAL

ConnAlertingEv for B Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TermConnRingingEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case5 - Consultation transfer scenario, IPv6 device consults:

Action
Events
Call Info/Expected Result

GC1: Call between A & B

Consult Call:

IPv6 enabled phone B consults JTAPI Observed device C for Transfer using GC2.

NEW META EVENT_________META_CALL_STARTING

For Consult Call:

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for B in an InetAddress object to the JTAPI Application observing C.

While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return null

C Answers

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

ConnCreatedEv for B Cause: CAUSE_NORMAL

ConnConnectedEv for B Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TernConnActiveEv for B Cause : CAUSE_NORMAL

CallCtlConnDialingEv for B Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for B Cause : CAUSE_NORMAL

ConnCreatedEv for C cause : CAUSE_NORMAL

ConnInProgressEv for C Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL

ConnAlertingEv for C Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL

TermConnCreatedEv for C Cause : CAUSE_NORMAL

TermConnRingingEv for C Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case6 - Consultation transfer scenario, IPv4 device consults:

Action
Events
Call Info/Expected Result

GC1: Call between A & B

Consult Call:

IPv4 enabled phone B consults JTAPI Observed device C for Transfer using GC2.

NEW META EVENT_________META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for B in an InetAddress object to the JTAPI Application observing C

While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null

C Answers

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

ConnCreatedEv for B Cause: CAUSE_NORMAL

ConnConnectedEv for B Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TernConnActiveEv for B Cause : CAUSE_NORMAL

CallCtlConnDialingEv for B Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for B Cause : CAUSE_NORMAL

ConnCreatedEv for C cause : CAUSE_NORMAL

ConnInProgressEv for C Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL

ConnAlertingEv for C Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL

TermConnCreatedEv for C Cause : CAUSE_NORMAL

TermConnRingingEv for C Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case7: Redirect scenario:

Action
Events
Call Info/Expected Result

GC1: Call between A(IPv6) & B

Redirect Call:

phone B redirects call to JTAPI Observed device C using GC2.

New Meta Event_______META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A in an InetAddress object to the JTAPI Application observing C

While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return null

C Answers

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

ConnCreatedEv for B Cause: CAUSE_NORMAL

ConnConnectedEv for B Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TernConnActiveEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv for B Cause : CAUSE_NORMAL

CallCtlConnDialingEv for B Cause : CAUSE_NORMAL

ConnCreatedEv for A Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for C cause : CAUSE_NORMAL

ConnInProgressEv for C Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL

ConnAlertingEv for C Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL

TermConnCreatedEv for C Cause : CAUSE_NORMAL

 
 

TermConnRingingEv for C Cause : CAUSE_NORMAL

TermConnDroppedEv for B Cause : CAUSE_NORMAL

ConnDisconnectedEv for B Cause : CAUSE_NORMAL

CallCtlTermConnDroppedEv for B Cause : CAUSE_REDIRECTED

ConnConnectedEv for C Cause : CAUSE_NORMAL

TermConnActiveEv for C Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case8: Redirect scenario (IPv4):

Action
Events
Call Info/Expected Results

GC1: Call between A(IPv4) & B

Redirect Call:

phone B redirects call to JTAPI Observed device C using GC2.

New Meta Event_______META_CALL_STARTING

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object to the JTAPI Application observing C

While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null

C Answers

CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

ConnCreatedEv for B Cause: CAUSE_NORMAL

ConnConnectedEv for B Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TernConnActiveEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv for B Cause : CAUSE_NORMAL

CallCtlConnDialingEv for B Cause : CAUSE_NORMAL

 
 

ConnCreatedEv for A Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for C cause : CAUSE_NORMAL

ConnInProgressEv for C Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL

ConnAlertingEv for C Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL

TermConnCreatedEv for C Cause : CAUSE_NORMAL

TermConnRingingEv for C Cause : CAUSE_NORMAL

TermConnDroppedEv for B Cause : CAUSE_NORMAL

ConnDisconnectedEv for B Cause : CAUSE_NORMAL

CallCtlTermConnDroppedEv for B Cause : CAUSE_REDIRECTED

ConnConnectedEv for C Cause : CAUSE_NORMAL

TermConnActiveEv for C Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case9: Redirect scenario, calling device redirects:

Action
Events
Call Info/Expected Result

GC1: A calls B(IPv4)

Redirect Call:

Phone A redirects call to JTAPI Observed device C using GC2.

New Meta Event_______META_CALL_STARTING
CallActiveEv for callID=GC2 Cause: CAUSE_NEW_CALL

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for B in an InetAddress object to the JTAPI Application observing C

CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr()
or, CiscoCallCtlConnOfferedEv.
getCallingPartyIpAddr()_v6
will not return IP address for A in an InetAddress object to the JTAPI Application observing B after redirect.

C Answers

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B Cause : CAUSE_NORMAL

CallCtlConnEstablishedEv for B Cause : CAUSE_NORMAL

ConnCreatedEv for C cause : CAUSE_NORMAL

ConnInProgressEv for C Cause : CAUSE_NORMAL

CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL

ConnAlertingEv for C Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL

TermConnCreatedEv for C Cause : CAUSE_NORMAL

TermConnRingingEv for C Cause : CAUSE_NORMAL

TermConnDroppedEv for A Cause : CAUSE_NORMAL

ConnDisconnectedEv for A Cause : CAUSE_NORMAL

CallCtlTermConnDroppedEv for A Cause : CAUSE_REDIRECTED

ConnConnectedEv for C Cause : CAUSE_NORMAL

TermConnActiveEv for C Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case10: Route scenario, IPv6 enabled calls RoutePoint which Routes call to IPv6 device:

Action
Events
Call Info/Expected Result

IPv6 enabled phone A calls RoutePoint which routes the call to JTAPI Observed IPv6 enabled device B using GC1.

NEW META EVENT_________META_CALL_STARTING

CiscoRouteEvent.getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object.

While, CiscoRouteEvent. getCallingPartyIpAddr() will return null

getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv6 RTP address

getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone

B Answers

CallActiveEv for callID=GC1 Cause: CAUSE_NEW_CALL

ConnCreatedEv for A Cause: CAUSE_NORMAL

ConnConnectedEv for A Cause : CAUSE_NORMAL

CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL

TermConnCreatedEv for A Cause : CAUSE_NORMAL

TernConnActiveEv for A Cause : CAUSE_NORMAL

CallCtlConnDialingEv for A Cause : CAUSE_NORMAL

CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL

ConnCreatedEv for B cause : CAUSE_NORMAL

ConnInProgressEv for B Cause : CAUSE_NORMAL

CallRouteEv for B Cause : CAUSE_NORMAL

ConnAlertingEv for B Cause : CAUSE_NORMAL

CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL

TermConnCreatedEv for B Cause : CAUSE_NORMAL

TermConnRingingEv for B Cause : CAUSE_NORMAL

CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL

 

Use Case11: Enterprise parameter "Enable IPv6" is enabled.

Application does an open provider by providing the list of CTI Manager IPs as

IPv4 address of CTI Manager1

IPv6 address of CTI Manager1

IPv4 address of CTI Manager2

IPv6 address of CTI Manager2

Now once the JTAPI is able to establish a connection with CTI Manager and later on if CTI Manager1 goes down, in failover attempt application can see delay in connecting as JTAPI will first try to connect with IPv6 address of CTI Manger1 (which is next in the list) even though that IP address is of the same CTI Manager and only once it times out it will try with the IPv4 address of the CTI Manager2 which will succeed (assuming CTI Manager2 is running).

Provider Open Scenario

1. Service Parameter for Reconnect Attempt is not set(or set to 0), Enterprise parameter "Enable IPv6" is disabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is stared again and connection is restored.

Enterprise parameter "Enable IPv6"is enabled and CTI manager is restarted - JTAPI will be able to reconnect to CTI Manager with the same IPv4 address.

2. Service Parameter for Reconnect Attempt is not set (or set to 0), Enterprise parameter "Enable IPv6" is enabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI Manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is stared again and connection is restored.

Enterprise parameter "Enable IPv6"is disabled and CTI manager is restarted - JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. But, the existing devices registered with IPv6 address will be closed with "CiscoTermRegistrationFailedEv" with a new reason code "IP_CAPABILITY_MISMATCH"

3. Service Parameter for Reconnect Attempt is not set (or set to 0), Enterprise parameter "Enable IPv6" is enabled. Application tries to open a provider with IPv6 address. JTAPI will be able to open a connection with CTI Manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is started again and connection is restored.

Enterprise parameter "Enable IPv6"is disabled and CTI manager is restarted - JTAPI will not be able to reconnect to CTI Manager, as it no longer supports IPv6 address but JTAPI will try reconnecting to CTI Manager indefinitely till the time service parameter is again enabled and CTI Service restarted.

4. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter "Enable IPv6" is disabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider.

Enterprise parameter "Enable IPv6"is enabled and CTI manager is restarted - JTAPI will be able to reconnect to CTI Manager with the same IPv4 address.

5. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter "Enable IPv6" is enabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI Manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider.

Enterprise parameter "Enable IPv6"is disabled and CTI manager is restarted - JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. But, the existing devices registered with IPv6 address will be closed with "CiscoTermRegistrationFailedEv" with a new reason code "IP_CAPABILITY_MISMATCH"

6. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter "Enable IPv6" is enabled. Application tries to open a provider with IPv6 address. JTAPI will be able to open a connection with CTI Manager.

CTI Manager is stopped - JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider.

Enterprise parameter "Enable IPv6"is disabled and CTI manager is restarted - JTAPI will not be able to reconnect to CTI Manager, as it no longer supports IPv6 address but JTAPI will try reconnecting to CTI Manager 5 more times (as the same can again be enabled on Cisco Unified CM) before closing all the devices and provider.

7. Enterprise parameter "Enable IPv6" is disabled. Application tries to open a provider with IPv6 address. JTAPI will not be able to open a connection with CTI manager. Retry attempts are applicable only if connection gets established once, but since in this scenario even the first attempt is failing so there will be no subsequent reconnect attempts.

Enterprise parameter "Enable IPv6" is enabled. Application does an open provider by providing the list of CTI Manager IPs as

IPv4 address of CTI Manager1

IPv6 address of CTI Manager1

IPv4 address of CTI Manager2

IPv6 address of CTI Manager2

Now once the JTAPI is able to establish a connection with CTI Manager and later on if CTI Manager1 goes down, in failover attempt application can see delay in connecting as JTAPI will first try to connect with IPv6 address of CTI Manger1 (which is next in the list) even though that IP address is of the same CTI Manager and only once it times out it will try with the IPv4 address of the CTI Manager2 which will succeed (assuming CTI Manager2 is running).

Calling Party IP Address scenarios:

1. Ipv6 enabled phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv6 calling party IP address.
getCallingPartyIpAddr() will return NULL
getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address.

2. Ipv4 enabled phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 calling party IP address (existing behavior)
getCallingPartyIpAddr() will return the actual calling Party IPv4 address.
getCallingPartyIpAddr_v6() will return NULL.

3. Ipv6 only phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv6 calling party IP address.
getCallingPartyIpAddr() will return NULL
getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address

4. Ipv4 enabled phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 formatted calling party IP address.
getCallingPartyIpAddr() will return the actual calling Party IPv4 address.
getCallingPartyIpAddr_v6() will return NULL.

5. Ipv4_v6(Dual Stack) phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 and Ipv6 calling party IP addresses.
getCallingPartyIpAddr() will return the actual calling Party IPv4 address.
getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address

6. Ipv4_v6(Dual Stack) phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 and Ipv6 calling party IP addresses.
getCallingPartyIpAddr() will return the actual calling Party IPv4 address.
getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address

RTP Addresses

1. An Ipv6 enabled phone calls an Ipv6 JTAPI Observed phone and the call is answered. JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone.

2. An Ipv4 enabled phone calls an Ipv4 JTAPI Observed phone and the call is answered. JTAPI will generate(existing behavior):

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone.

3. An Ipv4 enabled phone calls an Ipv6 JTAPI Observed device and the call is answered. JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone.

4. An Ipv6 enabled phone calls an Ipv4 JTAPI Observed device and the call is answered. JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone.

5. A Dual stack(Ipv4_v6) phone calls another dual stack(Ipv4_v6) JTAPI Observed device, preferred media termination is set to IPv6, and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone.

6. A Dual stack(Ipv4_v6) phone calls another dual stack(Ipv4_v6) JTAPI Observed device, preferred media termination is set to IPv4, and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone.

7. A Dual stack(Ipv4_v6) phone calls an Ipv4 JTAPI Observed device and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone.

8. A Dual stack(Ipv4_v6) phone calls an Ipv6 JTAPI Observed device and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone.

9. An IPv4 phone calls a dual stack (Ipv4_v6) JTAPI Observed device and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone.

10. An IPv6 phone calls a dual stack (Ipv4_v6) JTAPI Observed device and the call is answered then JTAPI will generate:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone.

11. JTAPI observed IPv6 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for Transfer. C answers and B completes the Transfer, then JTAPI will generate:

At A:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of C.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of A.

At C:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of A.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of C.

12. JTAPI observed IPv4 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for Transfer. C answers and B completes the Transfer, then JTAPI will generate:

At A:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of A.

At C:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of C.

13. JTAPI observed IPv6 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for conference. C answers and B completes the conference. Conference Bridge has an IPv4 address. Then JTAPI will generate:

At A:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of A.

At B:

CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the Conference Bridge.

CiscoRTPInputStartedEv containing the Ipv4 RTP address of B.

At C:

CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion.

CiscoRTPInputStartedEv containing the Ipv6 RTP address of C.

CTI Port/Route Point Registration Scenarios

1. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4_v6'. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv6 address and Application addressing capability as IPv6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv6 address.

2. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4_v6'. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 address and Application addressing capability as IPv4. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 address.

3. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4_v6'. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 and IPv6 addresses and Application addressing capability as IPv4_v6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 and IPv6 addresses.

4. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4 only'. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 address and Application addressing capability as IPv4. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 address.

5. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv6 only'. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv6 address and Application addressing capability as IPv6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv6 address.

6. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4 only'. Application tries a static register of that CTI Port/Route Point by providing an IPv6 address or/and by advertising application addressing capability as IPv6 (or Ipv4_v6) only then request will fail with a CiscoRegistrationException.

7. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv6 only'. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4 (or IPv4_v6) only. Then the request will be denied with a CiscoRegistrationException.

8. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4 only (or IPv4_v6 both)'. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4 only. Then the registration will succeed and CTI Port/Route point will get registered with IPv4 address when the same is provided with SetRTPParams request.

9. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv6 only (or IPv4_v6 both)'. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv6 only. Then the registration will succeed and CTI Port/Route point will get registered with IPv6 address when the same is provided with SetRTPParams request.

10. CTI Port/Route Point has `IP Addressing Mode' configured as `IPv4_v6 both'. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4_v6 both. Then the registration will succeed and CTI Port/Route point will get registered with IPv4_v6 address when the same is provided with SetRTPParams request.

11. If an application tries to dynamically register a CTI Port/Route Point by advertising its IP capabilities as IPv6,which is already registered to another application with IPv4 address. Then the request will be declined with a CiscoRegistrationException or "CiscoTermRegistrationFailedEv" will be sent with new reason code "IP_CAPABILITY_MISMATCH".

Advance Test Cases:

1. Application does a provider Open with IPv4 address to a CTI Manager which has enterprise parameter "Enable IPv6" enabled. Application tries to register a CTI Port/Route point with an IPv6 address whose device IP Addressing Mode is set to "IPv4_v6" by advertising applications addressing capability as "IPv6 only". The registration request will succeed.

2. JTAPI observed IPv6 device A calls another JTAPI observed IPv4 device B, call is offered and answered at B. In that case:
CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr() will return NULL
CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr_v6() will the actual calling Party IPv6 address

At B:

CiscoRTPInputStartedEv will have B's IPv4 Address

CiscoRTPOutputStartedEv will have IPv4 address of the MTP Resource

Interesting thing to notice here is CiscoRTPOutputStartedEv has an IPv4 address while calling party IP Address is an IPv6 address.

Direct Transfer Across Lines Use Cases

Action
Events
Call Info/Expected Result

Application is observing A, B1, B2, and C (B1 and B2 are two Addresses on the same Terminal TB)

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

GC1: CiscoTransferStartEv

GC1: CiscoCallChangedEv

GC1: ConnCreatedEv for C

GC1: ConnConnectedEv for C

GC1: CallCtlConnEstablishedEv for C

GC1: TermConnCreatedEv for TC

GC1: TermConnActiveEvent for TC

GC1: CallCtlTermConnTalkingEv TC

GC2: TermConnDroppedEv for TC

GC2: CallCtlTermConnDroppedEv for TC

GC2: ConnDisconnectedEv for C

GC2: CallCtlConnDisconnectedEv for C

GC1: TermConnDroppedEv for TB

GC1: CallCtlTermConnDroppedEv for TB

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC2: TermConnDroppedEv for TB

GC2: CallCtlTermConnDroppedEv for TB

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: CallInvalidEvent

GC2: CallObservationEndedEv

GC1: CiscoTransferEndEv

CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

Application is observing A, B1, B2, and C (B1 and B2 are two Addresses on the same Terminal which allows connected transfer across lines over phone manually which supports this feature)

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

 


CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

User B2 presses transfer and user selects active call(AB call) from the phone UI and presses transfer again to do connected Transfer Across Lines

GC2: CallCtlTermConnHeldEv for TB

GC3: CiscoConsultCallActiveEv

GC3: ConnCreatedEv for B2

GC3: ConnConnectedEv for B2

GC3: CallCtlConnInitiatedEv for B2

GC3: TermConnCreatedEv for TB2

GC3: TermConnActiveEvent for TB2

GC3: CallCtlTermConnTalkingEv for TB2

 

User Presses transfer again to complete connected transfer across lines

GC3: TermConnDroppedEv for TB2

GC3: CallCtlTermConnDroppedEv for TB2

GC3: ConnDisconnectedEv for B2

GC3: CallCtlConnDisconnectedEv for B2

GC3: CallInvalidEvent

GC3: CallObservationEndedEv

GC2: CiscoTransferStartEv

GC1: CiscoCallChangedEv

GC2: ConnCreatedEv for A

GC2: ConnConnectedEv for A

GC2: CallCtlConnEstablishedEv for A

GC2: TermConnCreatedEv for TA

GC2: TermConnActiveEvent for TA

GC2: CallCtlTermConnTalkingEv for TA

GC1: TermConnDroppedEv for TA

GC1: CallCtlTermConnDroppedEv for TA

GC1: ConnDisconnectedEv for A

GC1: CallCtlConnDisconnectedEv for A

GC2: TermConnDroppedEv for TB2

GC2: CallCtlTermConnDroppedEv for TB2

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC1: TermConnDroppedEv for TB1

GC1: CallCtlTermConnDroppedEv for TB1

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC1: CallInvalidEvent

GC1: CallObservationEndedEv

GC2: CiscoTransferEndEv

 

Application is observing A, B1, B2:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

GC1: CiscoTransferStartEv

GC1: CiscoCallChangedEv

GC1: ConnCreatedEv for C

GC1: ConnConnectedEv for C

GC1: CallCtlConnEstablishedEv for C

GC2: ConnDisconnectedEv for C

GC2: CallCtlConnDisconnectedEv for C

GC1: TermConnDroppedEv for TB

GC1: CallCtlTermConnDroppedEv for TB

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC2: TermConnDroppedEv for TB

GC2: CallCtlTermConnDroppedEv for TB

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: CallInvalidEvent

GC2: CallObservationEndedEv

GC1: CiscoTransferEndEv


CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

Application is observing B1, B2:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

GC1: CiscoTransferStartEv

GC1: ConnDisconnectedEv for A

GC1: CallCtlConnDisconnectedEv for A

GC1: TermConnDroppedEv for TB

GC1: CallCtlTermConnDroppedEv for TB

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC1: CallInvalidEv

GC2: ConnDisconnectedEv for C

GC2: CallCtlConnDisconnectedEv for C

GC2: TermConnDroppedEv for TB

GC2: CallCtlTermConnDroppedEv for TB

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: CallInvalidEvent

GC1: CiscoTransferEndEv
GC1: CallObservationEndedEv


CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

Application is observing only B1:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

JTAPI will throw PlatformException "Transfer controller is not set and could not find a suitable TerminalConnection". Since JTAPI can not get/find call leg for B2 from GC2

 

Application is observing only A:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

User presses transfer and selects active call(AB call) from the phone UI and preses Transfer again to do Connected Transfer Across Lines

GC2: CallActiveEvent

GC2: ConnCreatedEv for A

GC2: ConnCreatedEv for C

GC1: CiscoCallChangedEv

GC2: ConnConnectedEv for A

GC2: CallCtlConnEstablishedEv for A

GC2: TermConnCreatedEv for A

GC2: TermConnActiveEvent for A

GC2: CallCtlTermConnTalkingEv for A

GC2: ConnConnectedEv for C

GC2: CallCtlConnEstablishedEv for C

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC1: TermConnDroppedEv for A

GC1: CallCtlTermConnDroppedEv for A

GC1: ConnDisconnectedEv for A

GC1: CallCtlConnDisconnectedEv for A

GC1: CallInvalidEvent

GC1: CallObservationEndedEv


CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

Application is observing only B2:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

JTAPI will throw PlatformException "Transfer controller is not set and could not find a suitable TerminalConnection" Since JTAPI can not get/find call leg for B1 from GC1

 

Application is observing only C:

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

User presses transfer and selects active call(AB call) from the phone UI and preses Transfer again to do Connected Transfer Across Lines.

GC2: CiscoTransferStartEv

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: ConnCreatedEv for A

GC2: ConnConnectedEv for A

GC2: CallCtlConnEstablishedEv for A
GC2: CiscoTransferEndEv

CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

New user role(Standard Supports Connected Xfer/Conf) is associated with application user

Application opens a provider and disassociates the above mentioned user role

JTAPI delivers:

ProvInServiceEv

CiscoProviderCapabilityChangedEv

CiscoTermRestrictedEv

CiscoAddrRestrictedEv

(for all the phones that support connected tx/conf across lines)

CiscoProviderCapabilityChangedEv.hasConnectedTransferConferenceCapabilityChanged() returns True

Application is observing A, B1, B2, C and C' (B1 and B2 are two Addresses on the same Terminal, C' is sharedline of C)

A calls B1, B1 answers - GC1

B2 calls C, C answers - GC2

setTransferController to B1

GC1.transfer(GC2)

At Transfer:

GC1: CiscoTransferStartEv
GC2: CiscoCallChangedEv

GC1: ConnCreatedEv for C

GC1: ConnConnectedEv for C

GC1: CallCtlConnEstablishedEv for C

GC1: TermConnCreatedEv for TC'

GC1: TermConnPassiveEvent for TC'

GC1: CallCtlTermConnInUseEv for TC'

GC2: TermConnDroppedEv for TC'

GC2: CallCtlTermConnDroppedEv for TC'

GC2: CiscoCallChangedEv

GC1: TermConnCreatedEv for TC

GC1: TermConnActiveEvent for TC

GC1: CallCtlTermConnTalkingEv for TC

GC2: TermConnDroppedEv for TC

GC2: CallCtlTermConnDroppedEv for TC

GC2: ConnDisconnectedEv for C

GC2: CallCtlConnDisconnectedEv for C

GC1: TermConnDroppedEv for TB

GC1: CallCtlTermConnDroppedEv for TB

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC2: TermConnDroppedEv for TB

GC2: CallCtlTermConnDroppedEv for TB

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: CallInvalidEvent

GC2: CallObservationEndedEv

GC1: CiscoTransferEndEv

CiscoTransferStartEv.getControllerTerminalName() returns Terminal name for B1&B2

New user role(Standard Supports Connected Xfer/Conf) is not associated with application user

Application tries to add observer on phone which allows connected transfer/conference across lines

Phones that allow connected transfer/conference across lines are exposed as restricted.

JTAPI throws PlatformExceptionImpl ("Terminal is restricted", CiscoJtapiException.CTIERR_DEVICE_RESTRICTED ).

CiscoTerminal.isRestricted() returns TRUE

New user role(Standard Supports Connected Xfer/Conf) is not associated with application user

Application opens a provider and associates the above mentioned user role

JTAPI delivers:

ProvInServiceEv

CiscoProviderCapabilityChangedEv

CiscoAddrActivatedEv

CiscoTermActivatedEv

(for all the phones that support connected tx/conf across lines)

CiscoProviderCapabilityChangedEv.hasConnectedTransferConferenceCapabilityChanged() returns True


Connected Conference or Join Across Lines Use Cases - New Phones Behavior

Action
Events
Call Info/Expected Result

New Role "Standard Supports Connected Xfer/Conf" to control phones which support connected conference across lines is Not Associated with user.
Phones TA(Line A), TB(Lines B1, B2) and T3(Lines C); TC is a phones which allows connected conference across lines.

Observe All;
GC1: A calls B1,
GC2: B2 calls C

   

Do connected Conference Across Lines manually on Phone TB (which supports this feature) to conference GC1 and GC2

App, gets an PlatformExceptionImpl ("Terminal is restricted", CiscoJtapiException.CTIERR_DEVICE_RESTRICTED ) when the add observer on TB, B1 and B2
GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEvent
GC3: CallObservationEndedEv
GC2: CiscoConferenceStartEv
GC1: CiscoCallChangedEv
GC2: ConnCreatedEv for A
GC2: ConnConnectedEv for A
GC2: CallCtlConnEstablishedEv for A
GC2: TermConnCreatedEv for TA
GC2: TermConnActiveEvent for TA
GC2: CallCtlTermConnTalkingEv for TA
GC1: TermConnDroppedEv for TA
GC1: CallCtlTermConnDroppedEv for
TA
GC1: ConnDisconnectedEv for A
GC1: CallCtlConnDisconnectedEv for A
GC1: ConnDisconnectedEv for B
GC1: CallCtlConnDisconnectedEv for B
GC1: CallInvalidEvent
GC1: CallObservationEndedEv
GC2: CiscoConferenceEndEv

CiscoConferenceStartEv.getControllerAddress() returns B1
CiscoConferenceStartEv.getControllerTerminalName() returns TB


Enhanced MWI Use Cases

Action
Result

Application calls CiscoAddress.setMessageSummary() to set voice and fax counts on a phone that supports the enhanced message waiting counts.

Phone displays updated voice and fax counts provided and also updates the MWI indicator accordingly. A successful response is returned.

Application calls CiscoAddress.setMessageSummary() to set voice and fax counts on a phone that does not support the enhanced message waiting counts.

Phone only updates the MWI indicator accordingly—no voice and fax counts are displayed on the phone. A successful response is returned

Application calls CiscoAddress.setMessageSummary() to set voice counts, but the "high priority" voice counts provided are bigger than "total" voice counts provided.

The request fails with the following error returned: INVALID_HIGH_PRIORITY_VOICE_COUNTS

Application calls CiscoAddress.setMessageSummary() to set fax counts, but the "total" fax counts provided is bigger than maximum size allowed.

The request fails with the following error returned: INVALID_TOTAL_FAX_COUNTS


Join Across Lines Enhancements

A, C, D, E and F are addresses on different terminals. B1 and B2 are addresses on the same terminal TermB.

A, B1 and C are in a conference call GC1 with B1 as the controller and connected to conference bridge Conference-1. B2, D and E are in conference call GC2 with D as controller and connected to bridge Conference-2.

Action
Events

Application conferences the two calls on B1 and B2 by invoking GC1.conference(GC2) to chain two conference call.

Events to CallObserver of A,C and B1:
TermConnActiveEv TermB GC1
CallCtlTermConnTalkingEv TermB GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1
ConnConnectedEv Conference-2 GC1
CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv GC1
Ev.getAddedConnection will return connection for Conference-2
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-2
Ev.getConferenceChain().getChainedConferenceCalls() will return
GC1

Event for CallObserver at B2, D & E:
ConnDisconnectedEv B2 GC2 Cause=NORMAL
CallCtlConnDisconnectedEv B2 GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE
TermConnDroppedEv TermB GC2 Cause=NORMAL
CallCtlTermConnDroppedEv TermB GC2 Cause=NORMAL, callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC2
ConnConnectedEv Conference-1 GC2
CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2
Ev.getAddedConnection will return connection of Conference-1
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-1 & Conference-2
Ev.getConferenceChain().getChainedConferenceCalls() will return
GC1 & GC2

Application invokes GC2.conference(GC1) to chain two conference calls.

Event for CallObserver at B2, D & E:

TermConnActiveEv TermB GC2
CallCtlTermConnTalkingEv TermB GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC2
ConnConnectedEv Conference-1 GC2
CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2
Ev.getAddedConnection will return connection for Conference-1
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-1
Ev.getConferenceChain().getChainedConferenceCalls() will return GC2

Events for CallObservers at A, B1 & C:
ConnDisconnectedEv B1 GC1 Cause=NORMAL
CallCtlConnDisconnectedEv B1 GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE
TermConnDroppedEv TermB GC1 Cause=NORMAL
CallCtlTermConnDroppedEv TermB GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1
ConnConnectedEv Conference-2 GC1
CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1
Ev.getAddedConnection will return connection for Conference-2
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-2
Ev.getConferenceChain().getChainedConferenceCalls() will return
GC1

A, B1, C are in conference-1 (GC1), B1,D, E are in conference-2 ( GC2), B2, F, G are in conference-3 (GC-3)

Application completes conference at C by initiating GC1.conference(GC2, GC3) setting B1 as controller.

Event for CallObserver at A, B1 & C:

TermConnActiveEv TermB GC1
CallCtlTermConnTalkingEv TermB GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-2 GC1
ConnConnectedEv Conference-2 GC1
CallCtlConnEstablishedEv Conference-2 GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1
Ev.getAddedConnection will return connection for Conference-2
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-2
Ev.getConferenceChain().getChainedConferenceCalls() will return GC1

TermConnDroppedEv TermB GC2
CallCtlTermConnDroppedEv TermB GC2

ConnCreatedEv Conference-3 GC1
ConnConnectedEv Conference-3 GC1
CallCtlConnEstablishedEv Conference-3 GC1 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC1
Ev.getAddedConnection will return connection for Conference-3
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-2 & Conference-3
Ev.getConferenceChain().getChainedConferenceCalls() will return
GC2 & GC3

Event for CallObserver at B1,D & E:
ConnDisconnectedEv B1 GC2 Cause=NORMAL
CallCtlConnDisconnectedEv B1 GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE
TermConnDroppedEv TermB GC2 Cause=NORMAL
CallCtlTermConnDroppedEv TermB GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

 

ConnCreatedEv Conference-1 GC2
ConnConnectedEv Conference-1 GC2
CallCtlConnEstablishedEv Conference-1 GC2 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC2
Ev.getAddedConnection will return connection for Conference-1
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-1-GC2
Ev.getConferenceChain().getChainedConferenceCalls() will return
GC2

Event for CallObserver at B2, F & G:

ConnDisconnectedEv B2 GC3 Cause=NORMAL
CallCtlConnDisconnectedEv B2 GC3 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE
TermConnDroppedEv TermB GC3 Cause=NORMAL
CallCtlTermConnDroppedEv TermB GC3 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

ConnCreatedEv Conference-1 GC3
ConnConnectedEv Conference-1 GC3
CallCtlConnEstablishedEv Conference-1 GC3 Cause=NORMAL,
callCtlCause=CAUSE_CONFERENCE

CiscoConferenceChainAddedEv - GC3
Ev.getAddedConnection will return connection for Conference-1
Ev.getConferenceChain().getChainedConferenceConnections() will
return connections of Conference-1
Ev.getConferenceChain().getChainedConferenceCalls() will return GC3


Call Scenario: A, B1 and C are in conference call GC1 with B1 as controller. B2 is in call GC2 with D

Application sets the requestor as B2 and calls GC2.conference(GC1)

getControllerAddress() returns B2.

getOriginalControllerAddress() returns B1.

A
CiscoConferenceStartEv
CallCtlTermConnTalkingEv TermB GC1
ConnCreatedEv D GC1
ConnConnectedEv D GC1
CallCtlTermConnDroppedEv TermB GC2
CiscoConferenceEndEv

B1

CallCtlTermConnHeldEv TermB GC1
CiscoConferenceStartEv
CallCtlTermConnTalkingEv TermB GC1
ConnCreatedEv D
ConnConnectedEv
CiscoConferenceEndEv

B2

ConnDisconnectedEv B GC2
CallCtlTermConnHeldEv TermB GC2

D
CallActiveEv GC2
ConnAlertingEv D GC2
ConnConnectedEv D GC2

CiscoConferenceStartEv
TermConnDroppedEv TermB GC2

CallActiveEv GC1

CiscoCallChangedEv

TermConnTalkingEv TermB GC1
TermConnDroppedEv TermD GC2
CallObservationEndedEv GC2
CiscoConferenceEndEv

If application uses B1 as request controller in the above setup

getControllerAddress() returns B1.

getOriginalControllerAddress() returns B1.

Events are same as above


Swap or Cancel and Transfer or Conference Behavior Change

Use Case 1

Connected Transfer on the phone which allows connected Transfer


GC1 & GC2 call will be created as normal.

 
A calls B, B answers - GC1

B puts AB call on hold

B calls C, C answers - GC2

GC1: CallCtlTermConnHeldEv for TB

 

User B presses transfer and user selects active call(AB call) from the phone UI

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB

 

User B presses transfer again

GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEvent
GC3: CallObservationEndedEv
GC2: CiscoTransferStartEv
GC1: CiscoCallChangedEv
GC2: ConnCreatedEv for A
GC2: ConnConnectedEv for A
GC2: CallCtlConnEstablishedEv for A
GC2: TermConnCreatedEv for TA
GC2: TermConnActiveEvent for TA
GC2: CallCtlTermConnTalkingEv for TA
GC1: TermConnDroppedEv for TA
GC1: CallCtlTermConnDroppedEv for TA
GC1: ConnDisconnectedEv for A
GC1: CallCtlConnDisconnectedEv for A
GC2: TermConnDroppedEv for TB
GC2: CallCtlTermConnDroppedEv for TB
GC2: ConnDisconnectedEv for B
GC2: CallCtlConnDisconnectedEv for B
GC1: TermConnDroppedEv for TBGC1: CallCtlTermConnDroppedEv for TB
GC1: ConnDisconnectedEv for B
GC1: CallCtlConnDisconnectedEv for B
GC1: CallInvalidEvent
GC1: CallObservationEndedEv
GC2: CiscoTransferEndEv

 

Use Case 2

Connected Transfer on phone with sharedline (A and A' are sharedlines)

A calls B, B answers - GC1

B puts AB call on hold

B calls C, C answers - GC2

User B presses transfer and selects active calls (AB call),


User B presses transfer again

GC1 & GC2 call will be created as normal.

GC1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB|


GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEv
GC2: CiscoTransferStartEv
GC1: CiscoCallChangedEv
GC2: ConnCreatedEv for A
GC2: ConnConnectedEv for A
GC2: CallCtlConnEstablishedEv for A
GC2: TermConnCreatedEv for TA'
GC2: TermConnPassiveEvent for TA'
GC2: CallCtlTermConnInUseEv for TA'
GC1: TermConnDroppedEv for TA'
GC1: CallCtlTermConnDroppedEv for TA'
GC2: TermConnCreatedEv for TA
GC2: TermConnActiveEvent for TA
GC2: CallCtlTermConnTalkingEv for TA
GC1: TermConnDroppedEv for TA
GC1: CallCtlTermConnDroppedEv for TA
GC1: ConnDisconnectedEv for A
GC1: CallCtlConnDisconnectedEv for AGC2:
TermConnDroppedEv for TB2
GC2: CallCtlTermConnDroppedEv for TB2
GC2: ConnDisconnectedEv for B2
GC2: CallCtlConnDisconnectedEv for B2
GC1: TermConnDroppedEv for TB1
GC1: CallCtlTermConnDroppedEv for TB1
GC1: ConnDisconnectedEv for B1

 
 
GC1: CallCtlConnDisconnectedEv for B1
GC1: CallInvalidEvent
GC1: CallObservationEndedEv
GC2: CiscoTransferEndEv
 

Use Case 3

Connected Transfer/Conference - Cancel feature

A calls B, B answers - GC1

B puts AB call on hold

B calls C, C answers - GC2

User B presses transfer hard key

User B presses cancel key

GC1 & GC2 call will be created as normal.
GC1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB

GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEv
GC2: CiscoCallFeatureCancelledEv

CiscoCallFeatureCancelledEv.getConsultCall() returns GC3

Use Case 4a

Connected Transfer/Conference - Cancel feature

A calls B, B answers - GC1

B puts AB call on hold

B calls C, C answers - GC2

User B presses transfer hard key

User press select active calls key.

User B presses cancel key

GC1 & GC2 call will be created as normal.
GC1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB

GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEv


GC2: CiscoCallFeatureCancelledEv


CiscoCallFeatureCancelledEv.getConsultCall() returns null

Use Case 4b

Connected Transfer/Conference - Cancel feature

A calls B, B answers - GC1

B puts AB call on hold

B calls C, C answers - GC2

User B presses transfer (or conference) hard key.


User press select active calls key and also selects GC1 (AB call)


User B presses cancel key

GC1 & GC2 call will be created as normal.
GC1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB

GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEv


GC2: CiscoCallFeatureCancelledEv

CiscoCallFeatureCancelledEv.getConsultCall() returns GC1

Use Case 5

Consult Transfer - Swap calls

A calls B, B answers - GC1

B puts AB call on hold

B setup consult Transfer to C, C answers - GC2

User B presses Swap key,

User B presses transfer to complete the transfer


GC1 & GC2 call will be created as normal.

GC1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB

GC1: CallCtlTermConnTalkingEv for TB

GC1: CiscoTransferStartEv

GC1: CiscoCallChangedEv

GC1: ConnCreatedEv for C

GC1: ConnConnectedEv for C

GC1: CallCtlConnEstablishedEv for C

GC1: TermConnCreatedEv for TC

GC1: TermConnActiveEvent for TC

GC1: CallCtlTermConnTalkingEv TC

GC2: TermConnDroppedEv for TC

GC2: CallCtlTermConnDroppedEv for TC

GC2: ConnDisconnectedEv for C

GC2: CallCtlConnDisconnectedEv for C

GC1: TermConnDroppedEv for TB

GC1: CallCtlTermConnDroppedEv for TB

GC1: ConnDisconnectedEv for B1

GC1: CallCtlConnDisconnectedEv for B1

GC2: TermConnDroppedEv for TB

GC2: CallCtlTermConnDroppedEv for TB

GC2: ConnDisconnectedEv for B2

GC2: CallCtlConnDisconnectedEv for B2

GC2: CallInvalidEvent

GC2: CallObservationEndedEv

GC1: CiscoTransferEndEv



getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL

Use Case 6

Consult Transfer - Swap/Cancel

A calls B, B answers - GC1

A puts AB call on hold

B setup consult Transfer to C, C answers - GC2

User B presses press Swap softkey,

User B presses Cancel softkey

GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB



For TA (GC2), CallCtlTermConnHeldEv
For TA (GC1), CallCtlTermConnTalkingEv


GC1: CiscoCallFeatureCancelledEv



getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL


CiscoCallFeatureCancelledEv.getCall() returns GC1
CiscoCallFeatureCancelledEv.getConsultCall() returns GC2

Use Case 7

Consultative Transfer Initiated from Phone, App sends SetupTransfer/Conference request - request fails

A calls B, B answers - GC1

B setups transfer call to C

B calls C, C answers - GC2

Application creates a new call and sends another consult() request

GC1 & GC2 call will be created as normal.




Request will fail with PlatformException "CTIERR_CONSULTCALL_ALREADY_OUTSTANDING"

 

Use Case 8a

Consult Transfer/Conference - Application Resumes primary call on phone which supports connected transfer/conference and sends another consult setup request

GC1: A calls B
GC2: B consults C

Application resumes GC1 on TB

Application creates another call and sends consult() request to call D; D answers

GC1 and GC2 will be created as normal

For TB (GC2), CallCtlTermConnHeldEv

For TB (GC1), CallCtlTermConnTalkingEv

CiscoCallFeatureCancelledEv

Consult call will go through and GC3 will be created as normal





getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL

CiscoCallFeatureCancelledEv.getCall() returns GC1

CiscoCallFeatureCancelledEv.getConsultCall() returns GC2

Use Case 8b

Consult Transfer/Conference - Manually Resume primary call on phone which supports connected transfer/conference and then sends another consult setup request

GC1: A calls B
GC2: B consults C

User manually resumes (SWAP) GC1 on B

Application creates another call and sends consult() request to call D; D answers

GC1 and GC2 will be created as normal

On Manual Resume or Swap, Consult Call will not be cancelled on the phone, nor will application get CiscoCallFeatureCancelledEv.


When application tries to setup another consult, it will go through (GC3 will be created as normal) and it will cancel the existing consult call and application will get:
CiscoCallFeatureCancelledEv

CiscoCallFeatureCancelledEv.getCall() returns GC1

CiscoCallFeatureCancelledEv.getConsultCall() returns GC2

Use Case 9

Connected Conference
A (Phone which allows connected conference) calls B, B answer, B puts A onhold,
B calls C, C answer

B press "Conference" hardkey, and picks active call from UI, and selects AB call

B press "Conference" again to complete connected conference

GC1 & GC2 call will be created as normal.
C1: CallCtlTermConnHeldEv for TB

GC2: CallCtlTermConnHeldEv for TB
GC3: CiscoConsultCallActiveEv
GC3: ConnCreatedEv for B
GC3: ConnConnectedEv for B
GC3: CallCtlConnInitiatedEv for B
GC3: TermConnCreatedEv for TB
GC3: TermConnActiveEvent for TB
GC3: CallCtlTermConnTalkingEv for TB

GC3: TermConnDroppedEv for TB
GC3: CallCtlTermConnDroppedEv for TB
GC3: ConnDisconnectedEv for B
GC3: CallCtlConnDisconnectedEv for B
GC3: CallInvalidEvent
GC3: CallObservationEndedEv
GC2: CiscoConferenceStartEv
GC1: CiscoCallChangedEv
GC2: ConnCreatedEv for A
GC2: ConnConnectedEv for A
GC2: CallCtlConnEstablishedEv for A
GC2: TermConnCreatedEv for TA
GC2: TermConnActiveEvent for TA
GC2: CallCtlTermConnTalkingEv for TA
GC1: TermConnDroppedEv for TA
GC1: CallCtlTermConnDroppedEv for TA
GC1: ConnDisconnectedEv for A
GC1: CallCtlConnDisconnectedEv for A
GC1: TermConnDroppedEv for TB
GC1: CallCtlTermConnDroppedEv for TB
GC1: ConnDisconnectedEv for B
GC1: CallCtlConnDisconnectedEv for B
GC1: CallInvalidEvent
GC1: CallObservationEndedEv
GC2: CiscoConferenceEndEv

 

Use Case 10

Consult Conference from Phone, then Swap and complete conference through phone

A calls B,B answer
B setup conference to C, C answer

B press "Swap" softkey

A press "Conference"

GC1 & GC2 call will be created as normal.


GC2: CallCtlTermConnHeldEv for TB
GC1: CallCtlTermConnTalkingEv for TB

GC2: CiscoConferenceStartEv
GC1: CiscoCallChangedEv
GC2: ConnCreatedEv for A
GC2: ConnConnectedEv for A
GC2: CallCtlConnEstablishedEv for A
GC2: TermConnCreatedEv for TA
GC2: TermConnActiveEvent for TA
GC2: CallCtlTermConnTalkingEv for TA
GC1: TermConnDroppedEv for TA
GC1: CallCtlTermConnDroppedEv for TA
GC1: ConnDisconnectedEv for A
GC1: CallCtlConnDisconnectedEv for A
GC1: TermConnDroppedEv for TB
GC1: CallCtlTermConnDroppedEv for TB
GC1: ConnDisconnectedEv for B
GC1: CallCtlConnDisconnectedEv for B
GC1: CallInvalidEvent
GC1: CallObservationEndedEv
GC2: CiscoTransferEndEv


getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL

Use Case 11

Consult Conference from Phone and then Swap and Cancel conference thru phone A calls B, B answer

B setup conference to C, C answer

A press "Swap" key, and picks active call from UI, and selects AB call

B press "Cancel"

GC1 & GC2 call will be created as normal.

GC1: CallCtlTermConnTalkingEv for TB
GC2: CallCtlTermConnHeldEv for TB

GC1: CiscoCallFeatureCancelledEv(consultCall = GC2)


getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL

CiscoCallFeatureCancelledEv.getCall() returns GC1

CiscoCallFeatureCancelledEv.getConsultCall() returns GC2

Use Case 12

Connected Conference Across Lines

Same as JAL scenario but we will have a temporary call GC3

 

Use Case 13

Manual Consult followed by transfer complete by application

GC1: A calls B1
GC2: B1 setups consult call to C manually over phone

G1.transfer(GC2)

At Transfer:
GC1: CiscoTransferStartEv
GC1: CiscoCallChangedEv
GC1: ConnCreatedEvent for C
GC1: ConnConnectedEvent for C
GC1: CallCtlConnEstablishedEv for C
GC1: TermConnCreatedEvent for TC
GC1: TermConnActiveEvent for TC
GC1: CallCtlTermConnTalkingEv TC
GC2: TermConnDroppedEv for TC
GC2: CallCtlTermConnDroppedEv for TC
GC2: ConnDisconnectedEvent for C
GC2: CallCtlConnDisconnectedEv for C
GC1: CiscoCallFeatureCancelledEv
GC1: TermConnDroppedEv for TB
GC1: CallCtlTermConnDroppedEv for TB
GC1: ConnDisconnectedEvent for B1
GC1: CallCtlConnDisconnectedEv for B1
GC2: TermConnDroppedEv for TB
GC2: CallCtlTermConnDroppedEv for TB
GC2: ConnDisconnectedEvent for B2
GC2: CallCtlConnDisconnectedEv for B2
GC2: CallInvalidEvent
GC1: CiscoTransferEndEv

 

Use Case 14

Manual consult followed by conference complete by application

GC1: A calls B1

GC2: B1 setups consult call to C manually over phone

G1.conference(GC2)

At Conference:
GC1: CiscoCallFeatureCancelledEv
GC1: CiscoConferenceStartEv
GC1: CiscoCallFeatureCancelledEv
GC1: CiscoCallChangedEv
GC1: ConnCreatedEvent for C
GC1: ConnConnectedEvent for C
GC1: CallCtlConnEstablishedEv for C
GC1: TermConnCreatedEvent for TC
GC1: TermConnActiveEvent for TC
GC1: CallCtlTermConnTalkingEv TC
GC2: TermConnDroppedEv for TC
GC2: CallCtlTermConnDroppedEv for TC
GC2: ConnDisconnectedEvent for C
GC2: CallCtlConnDisconnectedEv for C
GC2: TermConnDroppedEv for TB
GC2: CallCtlTermConnDroppedEv for TB
GC2: ConnDisconnectedEvent for B2
GC2: CallCtlConnDisconnectedEv for B2
GC2: CallInvalidEvent
GC1: CiscoConferenceEndEv

 

Drop Any Party Use Cases

- JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

- Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to FALSE.

- Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "never"

Scenario
Action
Result
CallInfo

Use Case 1

Application is observing A, B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of C.

Application invokes Connection.disconnect() on Connection of A.

InvalidStateException is thrown.

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

CallInvalidEv

A is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 2

Application is observing C, B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C.

InvalidStateException is thrown.

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

C is dropped out of conference.

N.A

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case3

Application is observing A and C. B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C.

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

N.A

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 4

Application is observing B, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

CallInvalidEv

And B is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case5

Application is observing A, B and C, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to TRUE.

Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "never"

Scenario
Action
Result
CallInfo

Use Case6

Application is observing A, B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of C.

Application invokes Connection.disconnect() on Connection of A.

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

CallInvalidEv

A is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 7

Application is observing C, B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C.

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

C is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 8

Application is observing A and C. B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C.

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 9

Application is observing B, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

CallInvalidEv

B is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 10

Application is observing A, B and C, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to FALSE. A and A' are shared line

Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "never"

Scenario
Action
Result
Call Info

Use Case 11

Application is observing A, B is conference controller. A, A' and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getPartyInfo() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

InvalidStateException is thrown.

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

A(abc) is dropped out of conference

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

Connections of A, and B are A(abc) is dropped out of conference.

N.A

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 12

Application is observing A', B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

. A'("xyz") is dropped out of conference...

InvalidStateException is thrown.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

A'("xyz") is dropped out of conference..

N,A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 13

Application is observing A and A'. B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

InvalidStateException is thrown.

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

A'(xyz) is dropped out of conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc) is dropped out of conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

A(abc) and A'(xyz)is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 14

Application is observing B, and B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

No Events

A'(xyz) is dropped out of conference.

No Events

A(abc) is dropped out of conference.

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

CallInvalidEv

B is disconnected from conference.g

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

Connections of A, and B are disconnected, A(abc) and A'(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Use Case 15

Application is observing A, A' and B, and B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of B.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

A(xyz), dropped out of conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc), dropped out of conference.

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is disconnected from conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

 

Application invokes Connection.disconnect() on Connection of A.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

Connections of A, and B are disconnected, A(abc) and A'(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to TRUE. A and A' are shared line

Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "never"

Scenario
Action
Result
CallInfo

Use Case 16

Application is observing A, B is conference controller. A, A' and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

No Events.

A'(xyz) is disconnected from conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

A(abc) dropped out of conference

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(abc) is dropped out of conference.

N.A

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Use Case 17

Application is observing A', B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

No Events.

A(abc) is disconnected from conference.

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

A'(xyz) dropped out of conference

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(xyz) is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Use Case 18

Application is observing A and A'. B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

No Events.

A'(xyz) is disconnected from conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc) dropped out of conference

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(xyz) is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Use Case 19

Application is observing B, and B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect() on Connection of B.

Application invokes Connection.disconnect(xyz) on Connection of A.

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

B is disconnected from conference.

No Events.

A'(xyz) is disconnected from conference.

No Events

A(abc) dropped out of conference

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(abc), A(xyz) and B is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Use Case 20 Application is observing A, A' and B, and B is conference controller. A, A', and B are in conference.

Display name for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames () at Connection of A.

Application invokes Connection.disconnect () on Connection of B

Application invokes Connection.disconnect (xyz) on Connection of A.

Application invokes Connection.disconnect (abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

B is dropped out of conference.

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

A'(xyz) is disconnected from conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc) dropped out of conference

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(abc), A(xyz) and B is dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


A, B, C are in conference.

Application invokes CiscoCall.isConferenceCall()

Interface Returns "True"

N..A

A, B, C are in conference. B drops from conference

Application invokes CiscoCall.isConferenceCall()

Interface Returns "False"

N..A

A, B, B' are in conference.

Application invokes CiscoCall.isConferenceCall()

Interface Returns "True"

N..A

A, B, B' are in conference, B' drops from conference.

Application invokes CiscoCall.isConferenceCall()

Interface Returns "False"

N..A

A, B, C are in conference. Applications opens provider, gets snapshot call event

Application invokes CiscoCall.isConferenceCall()

Interface Returns "True"

N..A

A, B, B' are in conference. Applications opens provider, gets snapshot call event

Application invokes CiscoCall.isConferenceCall()

Interface Returns "True"

N..A


JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to FALSE.

Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "When controller leaves"

Scenario
Action
Result
CallInfo

Use Case 21

Application is observing A, B and C, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

TermConnDropEv

CallCtlTermConnDroppedEv

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

CallInvalidEV

A, B C is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE


- JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

- Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to TRUE.

- Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "When controller leaves"

Scenario
Action
Result
CallInfo

Use Case 22

Application is observing A, B and C, and B is conference controller. A, B, and C are in conference.

Application invokes Connection.disconnect() on Connection of A.

Application invokes Connection.disconnect() on Connection of C

Application invokes Connection.disconnect() on Connection of B.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A is dropped out of conference.

TermConnDropEv-TC

CallCtlTermConnDroppedEv-TC

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

C is dropped out of conference.

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

TermConnDropEv-TC

CallCtlTermConnDroppedEv-TC

ConnDisconnectedEv-C

CallCtlConnDisconnectedEv-C

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A, B, and C are dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE


- JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

- Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to FALSE.

- Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "When controller leaves"

Scenario
Action
Result
CallInfo

Use Case 23 Application is observing A, A' and B, and B is conference controller. A, A', and B are in conference.

Displayname for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.getDisplayNames() at Connection of A.

Application invokes Connection.disconnect(xyz) on Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

A(xyz), dropped out of conference.

N.A.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

 

Application invokes Connection.disconnect(abc) on Connection of A.

Application invokes Connection.disconnect() on Connection of B.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc), dropped out of conference.

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A, A' and B is disconnected from conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

 

Application invokes Connection.disconnect() on Connection of A.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalidEv

Connections of A, and B are disconnected, A(abc) and A'(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


JTAPI INI parameter is enabled to allow dropAnyPartyFeature.

Cisco Unified CM service parameter "Advanced Ad Hoc Conference Enable" is set to TRUE.

Cisco Unified CM service parameter "Drop Ad Hoc Conference" set "When controller leaves"

Scenario
Action
Result
CallInfo

Use Case 24

Application is observing A, A' and B, and B is conference controller. A, A', and B are in conference.

Application invokes Connection.getDisplayNames () at Connection of A.

JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of "abc" and "xyz"

N.A.

Display name for A is "abc", and displayname for A' is "xyz"

Application invokes Connection.disconnect () on Connection of B

Application invokes Connection.disconnect (xyz) on Connection of A.

Application invokes Connection.disconnect (abc) on Connection of A.

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

A, A' and B is dropped out of conference.

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

A'(xyz) is disconnected from conference.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

A(abc) dropped out of conference

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_CONFERENCE

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL

Application invokes Connection.disconnect() on Connection of A.

TermConnDropEv-TA

CallCtlTermConnDroppedEv-TA

TermConnDropEv-TA'

CallCtlTermConnDroppedEv-TA'

ConnDisconnectedEv-A

CallCtlConnDisconnectedEv-A

TermConnDropEv-TB

CallCtlTermConnDroppedEv-TB

ConnDisconnectedEv-B

CallCtlConnDisconnectedEv-B

CallInvalid

A(abc), A(xyz) and B is dropped out of conference.

Cause = CAUSE_NORMAL

CiscoFeatureReason = REASON_NORMAL


Park Monitoring Support

Phone B—Cisco Unified IP Phone 7900 Series with SIP/SCCP

Phone A—Future models.

Phone A'—Cisco Unified IP Phone 7900 Series with SIP/SCCP

Park DN—P1, P2

Phone C—Cisco Unified IP Phone 7900 Series with SIP/SCCP

All the default values for the Park Monitoring Reversion timer and Park Monitoring Forward No reversion timers apply.

Use Case 1: Park Monitoring States

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A


GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

After step 1, Park Monitoring reversion timer expires after the configured time

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= REMINDER
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3

After step 1 or 2, application sends unpark request CiscoTerminal.unpark() on Terminal of C.

Events received at Call Observer on A,B

GC2 CallActiveEv
GC2 ConnCreatedEv C
GC2 ConnConnectedEv C
GC2 CallCtlConnInitiatedEv C
GC2 TermConnCreatedEv TC
GC2 TermConnActiveEv TC
GC2 CallCtlTermConnTalkingEv TC
GC2 CallCtlConnDialingEv C
GC2 CallCtlConnEstablishedEv C

GC2 ConnCreatedEv P1
GC2 ConnInProgressEv P1
GC2 CallCtlConnOfferedEv P1

GC1 CiscoCallChangedEv

GC2 ConnCreatedEv B
GC2 ConnConnectedEv B
GC2 CallCtlConnEstablishedEv B
GC2 TermConnCreatedEv TB
GC2 TermConnActiveEv TB
GC2 CallCtlTermConnTalkingEv TB

GC2 ConnConnectedEv P1
GC2 CallCtlConnEstablishedEv P1
GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B
GC1 CallInvalidEv

GC2 ConnDisconnectedEv P1
GC2 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= RETRIEVED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 4

After step 1 or 2 above, B drops off the call invoking CiscoConnection.disconnect() on the connection of B.

Events received at Call Observer on A,B

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1
GC1 CallInvalidEv

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= ABANDONED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 5

Consider Park Monitoring forward no retrieve destination on A is configured as F

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded to F

Events received at Call Observer on A,B

GC1 ConnCreatedEv F
GC1 ConnInProgressEv F
GC1 CallCtlConnOfferedEv F
GC1 ConnAlertingEv F
GC1 CallCtlConnAlertingEv F

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= CiscoFeatureReason.FORWARD_NO_RETRIEVE


Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID =CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 6

Consider Forward no retrieve destination on A is configured to self

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= CiscoFeatureReason.FORWARD_NO_RETRIEVE

Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID =CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 7

Consider Forward no retrieve destination is not configured

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded/reverted to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= CiscoFeatureReason.PARKREMINDER

Cause= CAUSE_NORMAL

park state= FORWARDED

sub ID =1234

CiscoCallID = CiscoCallID for GC1

park DN =P1

parked party=B

terminal= TA


Use case 2: Shared line scenario - Cisco Unified IP Phone Does Park

Initial scenario: Application has added Call Observer on A, B, A'. Application has added Address Observer on A. B calls A. A/A' ring. A answers.

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 TermConnDroppedEv TA'
GC1 CallCtlTermConnDroppedEv TA'
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

Consider Forward no retrieve destination is not configured,

Consider Park Monitoring Reversion timer and Park Monitoring Forward no reversion timer expires.

Call is forwarded/reverted to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA
GC1 ConnInProgressEv A
GC1 ConnAlertingEv A
GC1 TermConnCreatedEv TA'
GC1 TermConnRingingEv TA'
GC1 CallCtlTermConnRingingEvImpl TA'

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Note: all shared lines ring as is today


Reason= CiscoFeatureReason.PARKREMINDER

Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


Use case 3: Shared Line Scenario - Cisco Unified IP Phone 7900 Series with SIP Does Park

Initial scenario: Application has added Call Observer on A, B, A'. Application has added Address Observer on A. B calls A. A/A' ring. A' answers.

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 TermConnDroppedEv TA'
GC1 CallCtlTermConnDroppedEv TA'
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Note: New event is not seen as Cisco Unified IP Phone 7900 Series does park

 

Step 2

Consider Park Reversion timer expires

Call is reverted to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA
GC1 ConnInProgressEv A
GC1 ConnAlertingEv A
GC1 TermConnCreatedEv TA'
GC1 TermConnRingingEv TA'
GC1 CallCtlTermConnRingingEvImpl TA'

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Note: All shared lines including the Cisco Unified IP Phone (future model) phone A receives the incoming call

Reason= CiscoFeatureReason.PARKREMINDER


Use Case 4: Use Case for Snap Shot Scenario

Initial scenario: Application has added Call Observer on A, B. Application has NOT added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Step 2

After step 1, application now adds Address Observer on A.

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_SNAPSHOT
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3a

After step 2, consider Park Monitoring Reversion timer expires

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3b

After step 1, application sends unpark request CiscoTerminal.unpark() on Terminal of C.

Events received at Call Observer on A,B

GC2 CallActiveEv
GC2 ConnCreatedEv C
GC2 ConnConnectedEv C
GC2 CallCtlConnInitiatedEv C
GC2 TermConnCreatedEv TC
GC2 TermConnActiveEv TC
GC2 CallCtlTermConnTalkingEv TC
GC2 CallCtlConnDialingEv C
GC2 CallCtlConnEstablishedEv C

GC2 ConnCreatedEv P1
GC2 ConnInProgressEv P1
GC2 CallCtlConnOfferedEv P1

GC1 CiscoCallChangedEv

GC2 ConnCreatedEv B
GC2 ConnConnectedEv B
GC2 CallCtlConnEstablishedEv B
GC2 TermConnCreatedEv TB
GC2 TermConnActiveEv TB
GC2 CallCtlTermConnTalkingEv TB

GC2 ConnConnectedEv P1
GC2 CallCtlConnEstablishedEv P1
GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B
GC1 CallInvalidEv

GC2 ConnDisconnectedEv P1
GC2 CallCtlConnDisconnectedEv P1

 

Step 4

After step 3, application now adds Address Observer on A.

New address event with park

state=RETRIEVED is not received at A, since the call is already retrieved

 

Use Case 5: Park DN is Monitored

Initial scenario: Application has added Call Observer on A, B. Application invokes registerFeature() API on Provider in order to monitor park DN P1. Application has added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring reversion timer starts

Events received at Provider Observer Prov1

CiscoProvCallParkEv

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


Use case 6: Query Number of Parked Calls

Initial scenario: Application has added Call Observer on A, B, C.

Action
Result
Event/Call Info

Step 1

B calls A. A answers. Application invokes CiscoConnection.park() on connection on A.

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A


GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Step 2

C calls A. A answers. Application invokes CiscoConnection.park() on connection on A for the second call on A.

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P2
GC1 ConnInProgressEv P2
GC1 CallCtlConnQueuedEv P2

 

Step 3

Application invokes CiscoAddress.getAddressCallInfo( Term A)

Application invokes CiscoAddressCallInfo.getNumParkedCalls()

CiscoAddressCallInfo is returned which includes information about number of parked calls

getNumParkedCalls() returns 2

 

Use case 7: Filter Enabling or Disabling

Initial scenario: Application has added Call Observer on A, B. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Initially filter is disabled.

Application adds AddressObserver on A.

Application now invokes CiscoConnection.park() on connection on A.

Park reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1
Events received at Address Observer on A

No event received as filter is disabled

Step 2

After step 1, Application enables filter via setCiscoAddrParkStatusEvFilter(true) and then by invoking CiscoAddress.setFilter(CiscoAddrEvFilter), for being able to receive the events.

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_SNAPSSHOT
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


Use case 8: Filter Enabling or Disabling

Initial scenario: From the phone B calls A. A answers.(Call Observers are not added)

Action
Result
Event/Call Info

Step 1

Initially filter is enabled.

Application adds AddressObserver on A.

Application now invokes park directly from the phone A.

Park reversion timer starts

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


Use case 9: Filter Enabling or Disabling

Initial scenario: From the phone B calls A. A answers.(Call Observers are not added)

Action
Result
Event/Call Info

Step 1

Initially filter is disabled.

Application adds AddressObserve on A.

Application now invokes park directly from the phone A.

Park reversion timer starts.

Application now enables filter and invokes CiscoAddress.setFilter(CiscoAddrEvFilter)

Events received at Address Observer on A

No event received yet, since filter is disabled

Events received at Address Observer on A

CiscoAddrParkStatusEv A










Cause= CAUSE_SNAPSHOT
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

Park reminder timer expires

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= REMINDER
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


Use Case 10: Filter Enabling or Disabling

Initial Scenario : Initial scenario: Application has added Call Observer on A, B. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Initially all filters are disabled in CiscoAddEvFilter

Application adds AddressObserver on A.

Application now invokes CiscoConnection.park() on connection on A.

Park reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

No event received as filter is disabled

Step 2

After step 1, Application invokes setCiscoAddrParkStatusEvFilter(true) but does not invoke CiscoAddress.setFilter(CiscoAddrEvFilter)

Events received at Address Observer on A

No event received as the address filter is not set.

Step 3

Now the application invokes setFilter(CiscoAddrEvFilter) on CiscoAddress

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_SNAPSSHOT

park state= PARKED

sub ID =1234

CiscoCallID = CiscoCallID for GC1

park DN =P1

parked party=B

terminal= TA


Additional Use Cases for Park Monitoring

Phone B—Cisco Unified IP Phone 7900 Series with SIP/SCCP

Phone A—Future models.

Phone A'—Cisco Unified IP Phone 7900 Series with SIP/SCCP

Park DN—P1, P2

Phone C—Cisco Unified IP Phone 7900 Series with SIP/SCCP

All the default values for the Park Monitoring Reversion timer and Park Monitoring Forward No reversion timers apply.

1. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Filter value has been set to `true' through setCiscoAddrParkStatusEvFilter().

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

After step 1, Park Monitoring reversion timer expires after the configured time

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= REMINDER
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3

After step 1 or 2, application sends unpark request CiscoTerminal.unpark() on Terminal of C.

Events received at Call Observer on A,B

GC2 CallActiveEv
GC2 ConnCreatedEv C
GC2 ConnConnectedEv C
GC2 CallCtlConnInitiatedEv C
GC2 TermConnCreatedEv TC
GC2 TermConnActiveEv TC
GC2 CallCtlTermConnTalkingEv TC
GC2 CallCtlConnDialingEv C
GC2 CallCtlConnEstablishedEv C

GC2 ConnCreatedEv P1
GC2 ConnInProgressEv P1
GC2 CallCtlConnOfferedEv P1

GC1 CiscoCallChangedEv

GC2 ConnCreatedEv B
GC2 ConnConnectedEv B
GC2 CallCtlConnEstablishedEv B
GC2 TermConnCreatedEv TB
GC2 TermConnActiveEv TB
GC2 CallCtlTermConnTalkingEv TB

GC2 ConnConnectedEv P1
GC2 CallCtlConnEstablishedEv P1
GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B
GC1 CallInvalidEv

GC2 ConnDisconnectedEv P1
GC2 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A


Cause= CAUSE_NORMAL
park state= RETRIEVED
sub ID =1234
CiscoCallID =CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 4

After step 1 or 2 above, B drops off the call invoking CiscoConnection.disconnect() on the connection of B.

Events received at Call Observer on A,B

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1
GC1 CallInvalidEv

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= ABANDONED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 5

Consider Park Monitoring forward no retrieve destination on A is configured as F

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded to F

Events received at Call Observer on A,B

GC1 ConnCreatedEv F
GC1 ConnInProgressEv F
GC1 CallCtlConnOfferedEv F
GC1 ConnAlertingEv F
GC1 CallCtlConnAlertingEv F

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= CiscoFeatureReason.FORWARD_NO_RETRIEVE



Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID =CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 6

Consider Forward no retrieve destination on A is configured to self

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= FORWARD_NO_RETRIEVE


Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID =CiscoCallID for GC1
park DN =P1
parked party=B

terminal= TA

Step 7

Consider Forward no retrieve destination is not configured

After step 2, Park Monitoring Forward no retrieve timer starts

Park Monitoring Forward no retrieve timer expires.

Call is forwarded/reverted to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Reason= PARKREMINDER

Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


2. Initial scenario: Application has added Call Observer on A, B, A'. Application has added Address Observer on A. B calls A. A/A' ring. A answers. Filter value has been set to `true' through setCiscoAddrParkStatusEvFilter().

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 TermConnDroppedEv TA'
GC1 CallCtlTermConnDroppedEv TA'
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

Consider Forward no retrieve destination is not configured,

Consider Park Monitoring Reversion timer and Park Monitoring Forward no reversion timer expires.

Call is forwarded/reverted to parker's line A

Events received at Call Observer on A,B

GC1 ConnCreatedEv A
GC1 ConnInProgressEv A
GC1 CallCtlConnOfferedEv A
GC1 ConnAlertingEv A
GC1 CallCtlConnAlertingEv A
GC1 TermConnCreatedEv TA
GC1 TermConnRingingEv TA
GC1 CallCtlTermConnRingingEvImpl TA
GC1 ConnInProgressEv A
GC1 ConnAlertingEv A
GC1 TermConnCreatedEv TA'
GC1 TermConnRingingEv TA'
GC1 CallCtlTermConnRingingEvImpl TA'

GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

 
 

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Note: All shared lines ring as is today

Cause= CAUSE_NORMAL
park state= FORWARDED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


3. Initial scenario: Application has added Call Observer on A, B. Application has NOT added Address Observer on A. B calls A. A answers. Filter value has been set to `true' through setCiscoAddrParkStatusEvFilter().

Action
Result
Event/Call Info

Step 1

Application invokes CiscoConnection.park() on connection on A.

Park Monitoring reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

 

Step 2

After step 1, application now adds Address Observer on A.

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_SNAPSHOT
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3a

After step 2, consider Park Monitoring Reversion timer expires

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_NORMAL
park state= REMINDER
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 3b

After step 1, application sends unpark request CiscoTerminal.unpark() on Terminal of C.

Events received at Call Observer on A,B

GC2 CallActiveEv
GC2 ConnCreatedEv C
GC2 ConnConnectedEv C
GC2 CallCtlConnInitiatedEv C
GC2 TermConnCreatedEv TC
GC2 TermConnActiveEv TC
GC2 CallCtlTermConnTalkingEv TC
GC2 CallCtlConnDialingEv C
GC2 CallCtlConnEstablishedEv C

GC2 ConnCreatedEv P1
GC2 ConnInProgressEv P1
GC2 CallCtlConnOfferedEv P1

GC1 CiscoCallChangedEv

GC2 ConnCreatedEv B
GC2 ConnConnectedEv B
GC2 CallCtlConnEstablishedEv B
GC2 TermConnCreatedEv TB
GC2 TermConnActiveEv TB
GC2 CallCtlTermConnTalkingEv TB

GC2 ConnConnectedEv P1
GC2 CallCtlConnEstablishedEv P1
GC1 ConnDisconnectedEv P1
GC1 CallCtlConnDisconnectedEv P1

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B
C1 CallInvalidEv

GC2 ConnDisconnectedEv P1
GC2 CallCtlConnDisconnectedEv P1

 

Step 4

After step 3, application now adds Address Observer on A.

New address event with park state=RETRIEVED is not received at A, since the call is already retrieved

 

4. Initial scenario: Application has added Call Observer on A, B, C. Filter value has been set to `true' through setCiscoAddrParkStatusEvFilter().

Action
Result
Event/Call Info

Step 1

B calls A. A answers. Application invokes CiscoConnection.park() on connection on A.

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

 

Step 2

C calls A. A answers. Application invokes CiscoConnection.park() on connection on A for the second call on A.

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P2
GC1 ConnInProgressEv P2
GC1 CallCtlConnQueuedEv P2

 

Step 3

Application invokes CiscoAddress.getAddressCallInfo( Term A)

Application invokes CiscoAddressCallInfo.getNumParkedCalls()

CiscoAddressCallInfo is returned which includes information about number of parked calls

getNumParkedCalls() returns 2

 

5. Use case to check for address event filter to control event notification- Filter value is set to `false' through setCiscoAddrParkStatusEvFilter(). This is also the default value.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

By default the address event filter value is false. Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

No event notification since filter value is false


6. Use case to check for address event filter to control event notification. Filter value has been set to `true' through setCiscoAddrParkStatusEvFilter().

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Application enables the filter through CiscoAddrEvFilter.setCiscoAddrParkStatusEvFilter(true). Application invokes CiscoConnection.park() on connection on A.

Park Monitoring Reversion timer starts

Events received at Call Observer on A, B

GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A

GC1 ConnCreatedEv P1
GC1 ConnInProgressEv P1
GC1 CallCtlConnQueuedEv P1

Events received at Address Observer on A

CiscoAddrParkStatusEv A




Cause= CAUSE_NORMAL
park state= PARKED
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA

Step 2

After step 1 above, Application now disables the filter through CiscoAddrEvFilter.setCiscoAddrParkStatusEvFilter(false).

Consider Park Monitoring Reversion timer expires

Events received at Address Observer on A

No event notification as filter is disabled

Step 3

After step 2 above, Application now enables the filter through CiscoAddrEvFilter.setCiscoAddrParkStatusEvFilter(true).

Events received at Address Observer on A

CiscoAddrParkStatusEv A

Cause= CAUSE_SNAPSHOT
park state= REMINDER
sub ID =1234
CiscoCallID = CiscoCallID for GC1
park DN =P1
parked party=B
terminal= TA


7. Use case to check the value of the filter set for the event CiscoAddrPArkrStatusEv.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers.

Action
Result
Event/Call Info

Step 1

Application disables the filter through CiscoAddrEvFilter.setCiscoAddrParkStatusEvFilter(false)

Application invokes the API getCiscoAddrParkStatusEvFilter() on CiscoAddrEvFilter.

The application receives the Boolean value `false'.

 

Step 2

Application enables the filter value through CiscoAddrEvFilter.setCiscoAddrParkStatusEvFilter(true)

Application invokes the API getCiscoAddrParkStatusEvFilter on CiscoAddrEvFilter.

The Application receives the Boolean value `true'.

 

8. Use case to check the notification of CiscoAddrIntercomInfoChangedEv and the value of the filter for the event, when the Intercom feature (target DN and/or intercom taget label) has not been changed.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers

Action
Result
Event/Call Info

Step 1

Application has set the filter value to `false' through CiscoAddrEvFilter.setAddrIntercomInfoChangedEvFilter(false)

Application invokes the API getCiscoAddrIntercomInfoChangedEvFilter() on CiscoAddrEvFilter.

Events received at Address Observer on A

No address notification as filter is disabled.

The application receives the Boolean value `false'.

 

Step 2

Application enables the filter value through CiscoAddrEvFilter.setCiscoAddrIntercomInfoChangedEvFilter(true)

Application invokes the API getCiscoAddrIntercomInfoChangedEvFilter on CiscoAddrEvFilter.

Events Received at Address Observer on A

No events received as the intercom Feature is unchanged.



The application receives the Boolean value `true'.

 
 

9. Use case to check the notification of CiscoAddrIntercomInfoChangedEv and the value of the filter for the event, when the Intercom feature (target DN and/or intercom taget label) has been changed.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers

Action
Result
Event/Call Info

Step 1

Application has set the filter value to `false' through CiscoAddrEvFilter.setAddrIntercomInfoChangedEvFilter(false)

Application issues CiscoIntercomAddress.setIntercomTarget() on intercom address A

Application invokes the API getCiscoAddrIntercomInfoChangedEvFilter() on CiscoAddrEvFilter.

Events received at Address Observer on A

No address notification as filter is disabled.


The application receives the Boolean value `false'.

 

Step 2

Application enables the filter value through CiscoAddrEvFilter.setCiscoAddrIntercomInfoChangedEvFilter(true)

Application issues CiscoIntercomAddress.setIntercomTarget() on intercom address A

Application invokes the API getCiscoAddrIntercomInfoChangedEvFilter on CiscoAddrEvFilter.

Events Received at Address Observer on A

CiscoAddrIntercomInfoChangedEv A


The application receives the Boolean value `true'.

 

10. se case to check the notification of CiscoAddrIntercomInfoRestorationFailedEv and the value of the filter for this event.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers

Action
Result
Event/Call Info

Step 1

Application has set the filter value to `false' through CiscoAddrEvFilter.setCiscoAddrIntercomInfoRestorationEvFilter(false)

Application has set intercom target DN and label for intercom address A. Now CTI Manager goes outofservice, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN , label and UnicodeLabel to the set values, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI.

Applications invokes the API getCiscoAddrIntercomInfoRestorationEvFilter() on CiscoAddrEvFilter.

Events Received at Address Observer on A

No notification as the filter is disabled.


The Application receives a Boolean value `false'

 

Step 2

The application enables the filter through the API CiscoAddrEvFilter.setCiscoAddrIntercomInfoRestorationEvFilter(true)

Application has set intercom target DN and label for intercom address A. Now CTI Manager goes outofservice, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN , label and UnicodeLabel to the set values, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI.

Applications invokes the API getCiscoAddrIntercomInfoRestorationEvFilter() on CiscoAddrEvFilter.

Events Received at Address Observer on A

CiscoAddrIntercomInfoRestorationFailedEv A

The Application receives a Boolean value `true'

 

11. Use case to check the notification of CiscoAddrRecordingConfigChangedEv and the value of the filter for this event.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers

Recording Profile Configurations Settings have not been changed

Action
Result
Event/Call Info

Step 1

Application has set the filter value to `false' through CiscoAddrEvFilter.setCiscoAddrRecordingConfigChangedEvFilter is set to default value (false)

Application invokes the API getCiscoAddrRecordingConfigChangedEvFilter() on CiscoAddrEvFilter.

Events received at Address Observer on A

No address notification as filter is disabled.

The application receives the Boolean value `false'.

 

Step 2

Application enables the filter value through CiscoAddrEvFilter.setCiscoAddrRecordingConfigChangedEvFilter(true)

Application invokes the API getCiscoAddrRecordingConfigChangedEvFilter on CiscoAddrEvFilter.

Events Received at Address Observer on A

No events as the Recording settings are unchanged.


The application receives the Boolean value `true'.

 

12. Use case to check the notification of CiscoAddrRecordingConfigChangedEv and the value of the filter for this event.

Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers

Action
Result
Event/Call Info

Step 1

Application has set the filter value to `false' through CiscoAddrEvFilter.setCiscoAddrRecordingConfigChangedEvFilter (false)

User changes the Recording Profile Configurations, through the Admin Pages.

Application invokes the API getCiscoAddrRecordingConfigChangedEvFilter() on CiscoAddrEvFilter.

Events received at Address Observer on A

No address notification as filter is disabled.



The application receives the Boolean value `false'.

 

Step 2

Application enables the filter value through CiscoAddrEvFilter.setCiscoAddrRecordingConfigChangedEvFilter(true)

User changes the Recording Profile Configurations, through the Admin Pages.

Application invokes the API getCiscoAddrRecordingConfigChangedEvFilter on CiscoAddrEvFilter.

Events Received at Address Observer on A

CiscoAddrRecordingConfigChangedEv A


The application receives the Boolean value `true'.

 

Use Cases Related to DPark

Initial set up:

-Application has added call observer on B and A

-User has configured DPark DN D

- B is a future model Cisco Unified IP Phone

-A calls B. B answers with GCID GC1

Call Scenario
Expected behavior

Assisted DPark from a Cisco Unified IP Phone:

Cisco Unified IP Phone phone B (which is on active call with A) presses the pre-configured `DPark BLF' button

The parked party A will be connected to D and hear
MoH

When A( parked party) is connected to D, the following events are received

Events received at Call Observer on B,A

GC1 CallCtlTermConnHeldEv TB (CiscoFeatureReason. REASON_ DPARK_CALLPARK)
GC1 CiscoTermConnSelectChangedEv TB
GC1 ConnUnknownEv B
GC1 CallCtlConnUnknownEv B
GC1 TermConnUnknownEv TB (CiscoFeatureReason. REASON_REFER))


GC1 ConnCreatedEv D
GC1 ConnInProgressEv D
GC1 CallCtlConnQueuedEv D (CiscoFeatureReason. REASON_REFER))

GC1 TermConnDroppedEv TB
GC1 CallCtlTermConnDroppedEv TB
GC1 ConnDisconnectedEv B
GC1 CallCtlConnDisconnectedEv B(CiscoFeatureReason. REASON_REFER))

DPark from Cisco Unified IP Phone

Cisco Unified IP Phone phone B (which is on active call with A) presses the `Transfer' softkey

Parked party A is put on hold, and parker B dials D

Parker B is connected to D and hears MOH.

Parker B presses"Transfer" softkey again to complete the transfer of the parked party A to Dpark code D.

Parked party A is connected to D

No change in behavior. All events/reason remain the same as is today

DPark from JTAPI API

Application requests for a consult call from B, using the consult() API with destination address as DPark DN D. Say this call has GCID-GC2

Application complete transfer, using the transfer() API GC1.transfer(GC2)

When transfer is completed A is connected to DPark DN

No change in behavior. All events/reason remain the same as is today

Unpark from JTAPI API

Consider application is observing C.

After step 3, application issues a request to unpark using the connect() API, with destination address as the prefix code followed by DPark code.

A is connected to C

No change in behavior. All events/reason remain the same as is today

Redirect to DPark DN via JTAPI API

B redirects to DPark code D, via the redirect() API with redirect destination as D.

No change in behavior. B is connected to DPark DN, but no park operation.


Logical Partitioning Feature Use Cases

Redirect from a Logical Partition (LP) Restricted Cluster

Terminal TA is configured with address A and is registered to a cluster which is configured with logical partition restrictions. Terminal TX is registered with address X which is configured to a cluster with no LP configuration.

Action
Result

X calls A. A redirects the call to a local PSTN number

PlatformException is thrown to redirect request.

getErrorCode() on the exception returns CiscoJtapiException. REDIRECT_CALL_PARTITIONING_POLICY

A calls X (GC1) , X redirects the call to its local PSTN number

Originating cluster recognizes that the call is redirect to a PSTN and disconnects the call

Events delivered to Call Observer of A

GC1 ConnFailedEv A CAUSE:
CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED

GC1 CallCtlConnFailedEv CAUSE:
CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED

GC1: GC1 TermConnDroppedEv A
GC1 CallCtlTermConnDroppedEv TA
GC1 ConnDisconnectedEv A
GC1 CallCtlConnDisconnectedEv A
GC1 ConnDisconnected X
GC1 CallCtlConnDisconnectedEv X
GC1 CallInvalidEv


Call forward: Call to a address which is forward all to PSTM in GeoLocation with "disallowed" policy

Action
Result

setForward on A t o local PSTN

Application is monitoring X.

X calls A using GC1.connect()

Connect() API succeeds but the call is dropped due to restrictions on A side.

Events delivered to call observer of X

GC1 ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED

GC1 CallCtlConnFailedEv CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED

GC1: GC1 TermConnDroppedEv X
GC1 CallCtlTermConnDroppedEv TX
GC1 ConnDisconnectedEv X
GC1 CallCtlConnDisconnectedEv X
GC1 ConnDisconnected A
GC1 CallCtlConnDisconnectedEv A
GC1 CallInvalidEv


Call Transfer: Transferring a call from different geo location to PSTN by controller in GeoLocation with "disallowed" policy

Action
Result

X calls A, A consults to PSTN number.

Application is monitoring A.

A completes the transfer.

Platform exception is thrown to transfer() request.

getErrorCode() returns CiscoJtapiException. TRANSFERFAILED


Call Conference: Conferencing a call from different location to PSTN by controller in GeoLocation with "disallowed" policy

Action
Result

X calls A, A consults to PSTN number.

Application is monitoring A.

A completes the conference.

Platform exception is thrown to conference() request.

getErrorCode() returns CiscoJtapiException. CTIERR_FEATURE_NOT_AVAILABLE.


Call Park / UnPark: Parking and un parking a PSTN call.

A and B are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as B

Action
Result

PSTN number calls A, A answers and parks the call.

Application is monitoring A and B

B un-parks the call using unpark() API.

Call fails:

ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED

CallCtlConnFailedEv CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED


Shared Lines

TermA and TermA' are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as TermA.

Action
Result

PSTN number calls A. Only TermA rings

GC1: CallActiveEv
GC1: ConnAlertingEv A
GC1: TermConnRingingEv TermA
GC1: CallCtlTermConnRingingEv TermA


Call Park Reversion with Shared Lines in Different Geographic Locations

TermA and TermA' are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as TermA.

Action
Result

PSTN number calls A, TermA answers and parks the call.

After time out call is offered at TermA and not at TermA'


GC1: CallActiveEv
GC1: ConnAlertingEv A
GC1: TermConnRingingEv TermA
GC1: CallCtlTermConnRingingEv TermA


ComponentUpdater Enhancement Use cases

Action
Result

Application calls ComponentUpdater(null)

Updater.log is creaated in the same directory

Application calls ComponentUpdater("C:\\temp\\")

Updater.log is created in c:\temp

Application calls ComponentUpdater("readonlydirectory")

Application does not have write permission to Readonlydirectory


No log is created.


IPv6 Support

Use case for getIPAddressingMode()

Action
Result

Step 1

IP Adrressing mode for terminal A in Unified CM Admin pages is set as IPv4

Application invokes CiscoTerminal.getIPAddressingMode() on terminal A.

getIPAddressingMode() returns 0

Step 2

After step 1, the IP Addressing mode is changed from IPv4 to IPv6. User would be prompted to re set the device.

Now application invokes CiscoTerminal.getIPAddressingMode() on terminal A.

getIPAddressingMode() returns 1
( provided user had re-set the device)


Support for Cisco Unified IP Phone 6900 Series

<
Scenario / Description
Events to application

Application connects to CTIManager.

TermA is a Cisco Unified IP Phone 6921.

TermB is a Cisco Unified IP Phone 7931 with roll over mode.

Admin now enables the new user role.

CiscoProviderCapabilityChangedEv - CiscoProvider.canObserverTerminalsWithRoleOver() returns true.

CiscoProviderCapabilityChangedEv .hasObserverTerminalsWithRoleOverChanged() returns true.

Events to Provider Observer:

CiscoTermActivatedEv TermA
CiscoTermActivatedEv TermB

Admin removes the new user role.

CiscoProviderCapabilityChangedEv - CiscoProvider.canObserverlTerminalsWithRoleOver() returns false.

CiscoProviderCapabilityChangedEv .hasObserverTerminalsWithRoleOverChanged() returns true.

Events to Provider Observer:

CiscoTermRestrictedEv TermA
CiscoTermRestrictedEv TermB

Term A is a Cisco Unfied IP 6900 series phone. Application does not have the new role enabled. Term A is in application control list

Application adds observer on TermA

PlatformException is thrown. getErrorCode() returns CiscoJtapiException.CTIERR_DEVICE_RESTRICTED

Call Scenarios:

 

Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions.
Application has the new role "Standard CTI Allow Control of Phones supporting roll over mode"enabled.

Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1)

Application issues consult request to Y (GC2). Call is created on A:P1

Events delivered to Terminal Observer

GC1: ConnConnectedEv A
GC1: CallCtlConnEstablishedEv A
GC1: CallCtlTermConnTalkingEv TermA

GC1: CallCtlTermConnHeldEv TermA

GC2: CallActiveEv
GC2: ConnCreatedEv A:P1
GC2: ConnConnectedEv A:P1
GC2: CallCtlConnInitiatedEv A:P1

No roll over for incoming calls:

Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions.
Application has the new role "Standard CTI Allow Control of Phones supporting roll over mode"enabled.

Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1).

Applications calls A from B using connect API.

Events delivered to Terminal Observer

GC1: ConnConnectedEv A
GC1: CallCtlConnEstablishedEv A
GC1: CallCtlTermConnTalkingEv TermA



GC2: CallActiveEv
GC2: ConnCreatedEv B
GC2: ConnConnectedEv B
GC2: CallCtlConnInitiatedEv B
GC2: TermConnCreatedEv TernB
GC2: CallCtlConnDialingEv B
GC2: CallCtlConnEstablishedEv B
GC2: ConnFailedEv B.

getCiscoCause() returns CiscoCallEv.CAUSE_USERBUSY

Roll over for Transfer and Conference (consult())only:

Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions.
Application has the new role "Standard CTI Allow Control of Phones supporting roll over mode"enabled.

Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1).

Applications calls connect() API from Adress A to Y. Similar exception will be seen for unPark(), startMonitor() requests.

Events delivered to Terminal Observer

GC1: ConnConnectedEv A
GC1: CallCtlConnEstablishedEv A
GC1: CallCtlTermConnTalkingEv TermA



PlatformException is thrown. getErrorCode() returns CiscoJtapiException.CTIERR_MAXCALL_LIMIT_REACHED

Only 1 address has callObserver:

Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions.
Application has the new role "Standard CTI Allow Control of Phones supporting roll over mode"enabled.

Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on address A only.

X calls A, call is answered

Applications consults with Y using consult() API. On phone call consult call is created on A:P1