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—Page 1

Direct Transfer/Arbitrary Transfer—Page 2

Consult Transfer Scenario

Conference and Join

Join/Arbitrary Conference Scenario—Page 1

Join/Arbitrary Conference Scenario—Page 2

Consult Conference Scenario

Barge and Privacy

Barge Feature

CBarge Feature

Privacy

CallSelect and UnSelect

Dynamic CTIPort Registration Per Call

Dynamic Registration for CTIPort

Media Termination at Route Point

Redirect Set OriginalCalledID

Scenario One

Scenario Two

Single Step Transfer

Modifying Calling Number

Scenario One

Scenario Two

AutoAccept for CTIPort and RoutePoint

Forced Authorization and Customer Matter Codes Scenarios

Scenario One

Scenario Two

Scenario Three

Scenario Four

Scenario Five

Super Provider Message Flow

SuperProvider and Change Notification Enhancements Use Cases

Scenario A

Scenario B

Scenario C

Scenario D

Scenario E

Scenario F

Scenario G

QSIG Path Replacement Use Cases

Device State Server Message Flow

Partition Support

Using getPartition() API

Using getAddress(String number, String partition) API

Simple Call Scenario

Park DN Scenario

Change in Partition

Use Cases for JTAPI Partition Support

Hairpin Support

Use Cases for Hairpin Support

QoS Support

Use Cases for JTAPI QoS

TLS Security

SRTP Key Material

Use Case 1

Use Case 2

Use Case 3

Device and Line Restriction

SIP Support

SIP REFER/REPLACE

REPLACES Message Flow

REFER Message Flow

Scenarios for IN-Dialog REFER

Scenario A

Scenario B

Scenario C

Scenario D

Scenario E

Scenario F

Scenario G

Scenario H

Scenario I

Scenario J

Scenario K

For OutOfDialog Refer

SIP 3XX Redirection

3XX Redirection - 302 Moved Temporarily

3XX Redirection - Contact Busy

3XX Redirection - Contact Does Not Answer

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

3XX Redirection - Non-Available Target Member

Unicode Support

Use Cases for Unicode Display Name

Use Cases to Get Locale and UniCodeCapabilities of Terminal

Backward Compatibility Enhancements

Scenario A

Scenario B

Scenario C

Scenario D

Half Duplex Media Support Message Flow

Recording and Monitoring

Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Scenario 8

Scenario 9

Scenario 10

Scenario 11

Scenario 12

Scenario 13

Scenario 14

Scenario 15

Scenario 16

Scenario 17

Scenario 18

Scenario 19

Scenario 20

Intercom

Used case for intercom call Scenario

Used case for DeviceState whisper

Do Not Disturb

Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Scenario 8

Scenario 9

Scenerio 10

Scenario 11

Scenario 12

Scenario 13

Secure Conferencing

JTAPI Cisco Unified IP 7931G Phone Interaction

Message Sequence Charts

---

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

•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—Page 1

–Consult Transfer Scenario

•Conference and Join

–Join/Arbitrary Conference Scenario—Page 1

–Consult Conference Scenario

•Barge and Privacy

–Barge Feature

–CBarge Feature

–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 Scenarios

•Super Provider Message Flow

•SuperProvider and Change Notification Enhancements Use Cases

•QSIG Path Replacement Use Cases

•Device State Server Message Flow

•Partition Support

•Hairpin Support

•QoS Support

•TLS Security

•SRTP Key Material

•Device and Line Restriction

•SIP Support

•SIP REFER/REPLACE

•Unicode Support

•Backward Compatibility Enhancements

•Half Duplex Media Support Message Flow

•Recording and Monitoring

•Intercom

•Do Not Disturb

•Secure Conferencing

•JTAPI Cisco Unified IP 7931G Phone Interaction

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—Page 1

Direct Transfer/Arbitrary Transfer—Page 2

Consult Transfer Scenario

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 Scenario—Page 1

Join/Arbitrary Conference Scenario—Page 2

Consult Conference Scenario

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

Barge and Privacy

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

Barge Feature

CBarge Feature

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.

Dynamic Registration for CTIPort

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	Call1	ConnCreatedEv for D ConnConnectedEv for D CallCtlConnEstablishedEv for D	CallingParty=A CalledParty = B LastRedirectedParty=C CurrentCalledParty=D
META_CALL_REMOVE_PARTY	Call1	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 selectsRoute 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 Scenarios

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's ability to handle failover scenarios and the time required to shift between Superprovider and normal user modes.

Scenario A

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.

Expected Behavior

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 B

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

Expected Behavior

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

Scenario C

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

Expected Behavior

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

Scenario D

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

Expected Behavior

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

Scenario E

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

Expected Behavior

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 F

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

Expected Behavior

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

Scenario G

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

Expected Behavior

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

QSIG Path Replacement Use Cases

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 Message Flow

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) API

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) API

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.

Simple Call Scenario

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 Scenario

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.

Change in Partition

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.

Use Cases for 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.

Table A-1 Use Cases for JTAPI Partition Support 

S.No.	Pre-Condition	Use Case	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

Use Cases for Hairpin Support

Table A-2 Use Cases for 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

Use Cases for 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

Table A-3 Use Cases for JTAPI QoS

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.

Use Case 1

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

Use Case 2

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.

Use Case 3

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 isRestricted on T1,T2, T3 Application queries for isRestricted 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 REFER/REPLACE

REPLACES Message Flow

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

REFER Message Flow

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.

Scenarios for IN-Dialog REFER

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

Scenario A

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 B

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 C

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 D

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 E

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 F

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 G

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 H

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 I

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 J

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 K

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

For 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

Use Cases for Unicode Display Name

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.

Use Cases to Get Locale 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 A

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 B

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 C

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 D

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 Support Message Flow

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 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 delivered to

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 10

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 11

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 12

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 13

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 14

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 15

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 16

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 17

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 18

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 19

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 20

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

Used case for intercom call Scenario

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

Used case for DeviceState whisper

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 folters 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 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

Application sets the feature priority to FEATUREPRIORITY_EMERGENCY in redirect() and selectRoute() API in CiscoRouteSession.

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

Scenario 9

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
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

Scenerio 10

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 11

DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Application invokes getDNDStatus() on CiscoTermin 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 12

DND is enabled on terminal A. Terminal A comes IN_SERVICE. Application invokes setDNDStaus(). 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 13

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

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