Table Of Contents

Message Sequence Charts

Abbreviations

3XX

Blind Transfer

Call Control Discovery

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster2

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster2 with PSTN Failover Rule not Set

Basic Call Initiated from TAPI from Phone A(1900) and B(1901) on Cluster 1, B Redirects to Phone C(1000) on Cluster2 with PSTN Failover Rule Set

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 with PSTN Failover Rule

Call Initiated from TAPI from Phone A and B on Cluster 1, B setsupconference to Phone C(1000) on Cluster 2 with PSTN Failover Rule

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster 2 over SAF Trunk

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Redirects to Phone C(1000) on Cluster 2 over SAF Trunk

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 over SAF Trunk

CallFwdAll Notification

Application Pressed CFwdAll on TAPI Monitored Device

TAPI Monitored Device Goes Off Hook

Application Monitors Off Hook Device

Application Monitors Device after User Presses CFwdAll

User Presses CFwdAll Softkey after Device is Off Hook

User Presses CFwdAll Softkey on a Multiline Device

User Presses CFwdAll on a Multiline Device by Selecting a Line

Shared Line Scenario on Pressing CFwdAll Softkey

Cancellation of CFwdAll

Calling Party IP Address

Basic Call

Consultation Transfer

Consultation Conference

Redirect

Calling Party Normalization

Incoming Call from PSTN to End Point

Incoming Call from National PSTN to CTI-Observed End Point

Incoming Call from International PSTN to CTI-Observed End Point

Outgoing Call from CTI-Observed End Point to PSTN Number

Outgoing Call from CTI-Observed End Point to National PSTN Number

Outgoing Call from CTI-Observed End Point to International PSTN Number

Call PickUp

Registering CallPickUpGroup for Notification

UnRegistering CallPickUpGroup for Notification

Re-Registering CallPickUpGroup for Notification

Registering/UnRegistering CallPickUpGroup for Notification with InValid Information

CallPickUp after Enabling Auto Call Pickup Enabled

CallPickUp with Auto Call Pickup Enabled Disabled

CallPickUp with Multiple Calls Available

CallPickupGroup Changed for a Device on AdminPage

CallPickUpGroup Partition or DN Information Updated

CallPickUpGroup is Deleted

FailOver or FailBack Scenario

GroupCallPickup

OtherCallPickup

DirectCallPickup

CallPickup (Negative Use Case)

GroupCallPickup with SuperSet Call PickupDN

Group or Direct CallPickup with Invalid DN

Click to Conference

Drop Party by Using Click-2-Conference

Drop Entire Conference by Using Click-2-Conference Feature

Conference Enhancements

Noncontroller Adding Parties to Conferences

Chaining Two Ad Hoc Conferences by Using Join

Direct Transfer Across Lines

Do Not Disturb-Reject

Application Enables DND-R on a Phone

Normal Feature Priority

Feature Priority - Emergency

Drop Any Party

End-To-End Call Trace

Direct Call Scenario: Variation 1

Direct Call Scenario: Variation 2

Consult Transfer Scenario: Variation 1

Consult Transfer Scenario: Variation 2

Blind Transfer Scenario

Redirect Scenario

Shared Line Scenario

Shared Line Scenario with Barge

Call Park Scenario: Variation 1

Call Park Scenario: Variation 2

3- Party Conference Call Scenario

Three-party Conference Drop Down to Two-party Call Scenario

Conference Chaining Scenario using Join

Transfer Call Scenario via QSIP without Path Replacement

Transfer Call Scenario via QSIP with Path Replacement

Hunt List Scenario

Call Pickup Scenario: Variation 1

Call Pickup Scenario: Variation 2

Extension Mobility Cross Cluster

TAPI Application does LineInitializeEx and EMCC User Logs in to a Device

TAPI Application does LineInitializeEx and EMCCUser Logs Out of a Device

Application does PhoneInitializeEx and EMCC User Logs in to a Device

TAPI Application does PhoneInitializeEx and EMCC User Logs out of a Device

EMCC User Logs in to a Device from Cluster 2 (Visiting Cluster)

EMCC User Logs out of a Device from Cluster 2 (Visiting Cluster)

EMCC User Logs in to a Device with LineH Configured

EMCC User Logs out of a Device with LineH Configured

EMCC User Logs in to a DeviceH Configured for Multiple Lines (LineH)

EMCC User Logs in to a Device with LineH Configured and Administrator Removes the Device from Application Control list

EMCC User Logs in and out of a Device with LineH Configured and Administrator Removes the Device from Application Control List

EMCC User Logs in to a Device with LineH Configured and EM_Profile not Included in Application Control List

EMCC User Logs in to a DeviceV and EM_Profile is Removed by Administrator from Application Control List

EMCC User Logs in to a Device then Application does Provider Open

EMCC User Log in to a DeviceV in Visting Cluster and Administrator Adds the EM_Profile to Application Control List

External Call Control

Basic Call Initiated from TAPI with External Call Control on Translation Pattern and CEPM Returns Reject

Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Divert with Modified Calling and Called Parties

Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties

Conference Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties in the Consult Call

Call is Redirected to a Hunt List of Chaperones and Chaperone Enables Call Recording and Conferences in the Called Party

Forced Authorization and Client Matter Code Scenarios

Manual Call to a Destination that Requires an FAC

Manual Call to a Destination that Requires both FAC and CMC

lineMakeCall to a Destination that Requires an FAC

lineMakeCall to a Destination that Requires Both FAC and CMC

Timeout Waiting for FAC or Invalid FAC

Hunt List

Basic Hunt List Call

Hunt List Call Moved to Next Member

Hunt List Calls FWNA and FWNA is not Configured on HuntPilot

Hunt List Call FWNA with FWNA to B

Hunt List Call Dropped when Hunt List is Busy and FWB is not Configured

Hunt List Call is Forwarded when Hunt List is Busy and FWB is Configured to B

HuntList Call Redirected when in ACCEPT State

Hunt List Call Redirected when in Connected State

Hunt List Call - Member is CTI or RP Port

Hunt List Call Moved to Different Line Group Members and Answered by CTI Port

Hunt List Call is Redirected to Another Hunt List

Hunt List Call is Consult Transferred to Another Line

Hunt List Call Direct Transferred to Another Line

Hunt List Call is Conferenced to Another Line

Hunt List Call is Joined to Another Line

Hunt List Call is Conferenced to Another Hunt List after LG11 Answers

Hunt List Call Conferenced to the Same Hunt List and Completes Conference Before Hunt List Agent Answers

Hunt List Basic Call with SharedLine

Hunt List Basic Call with DND-R Configured on LG1

Hunt List Call Put in Conference via Join Operation

Hunt List Call is Picked up from Pickup Group - G-Pickup, Auto Pick Pp is Enabled

Hunt List Call is Picked Up from Pickup Group when LG1 is in Pickup Group 1 - Auto Pickup Disabled

Hunt List Call is Picked Up from Pickup Group when HP2 is in Pickup Group 2 - Auto Pick Up Enabled

Conferenced Hunt List Call Becomes Two-party Call

Hunt List Broadcast Scenario (Broadcast Option is Configured on HP1)

Hunt List Call is Involved in c-Barge Conference

Hunt List Feature Interact with Four-Party Conference

Caller Consult Transfer Call to Another Hunt List

Intercom

Application Invoking Speeddial

Agent Invokes Talkback

Change the SpeedDial

IPv6 Use Cases

Join Across Lines

Logical Partitioning Support

Manual Outbound Call

Monitoring and Recording

Monitoring a Call

Automatic Recording

Application-Controlled Recording

Park Monitoring

Presentation Indication

Making a Call Through Translation Pattern

Blind Transfer Through Translation Pattern

Redirect Set Original Called (TxToVM)

Refer and Replaces Scenarios

In-Dialog Refer - Referrer in Cisco Unified Communications Manager Cluster

In-Dialog Refer Where ReferToTarget Redirects the Call in Offering State

In-Dialog Refer Where Refer Fails or Refer to Target is Busy

Out-of-Dialog Refer

Invite with Replace for Confirmed Dialog

Refer with Replace for All in Cluster

Refer with Replace for All in Cluster, Replace Dialog Belongs to Another Station

Secure Conferencing

Conference with All Parties as Secure

Hold or Resume in Secure Conference

Secure Monitoring and Recording

Silent Monitoring

Basic Silent Monitoring Scenario in Secure Mode

Silent Monitoring Scenario on Non-Secure Call in Secure Mode

Silent Monitoring Scenario on non-Secure Call from Supervisor which is Secure

Silent Monitoring Scenario on Secure Call from Supervisor which is Non-Secure

Transfer of Monitored call from supervisor to other supervisor

Transfer of call from one customer to other

Park on Supervisor

Silent Monitoring on Conferenced Call

Conference on Monitored Call

Conference on Monitored Call

Supervisor Holds the Call

Recording

Basic Recording Scenario

Basic Recording Scenario in Secure Mode

Recording Scenario on Non-Secure call in Secure Mode

Recording Scenario on non-Secure Call using Secure Recording Profile/Device

Recording Scenario when Agent holds the call

Recording and Monitoring

Both Silent Monitoring and Recording on Agent Call in Secure Mode

Recording Silent Monitored Call on Supervisor

Shared Lines-Initiating a New Call Manually

SRTP

Media Terminate by Application (Open Secure CTI Port or RP)

Media Terminate by TSP Wave Driver (open secure CTI port)

Support for Cisco IP Phone 6900 Series

Support for Cisco Unified IP Phone 6900 and 9900 Series Use Cases

Swap or Cancel Support

Message Sequence Charts

---

This appendix contains message sequences or call scenarios and illustrates a subset of these scenarios that are supported by the Cisco Unified TSP. Be aware that the event order is not guaranteed in all cases and can vary depending on the scenario and the event.

This appendix contains the following sections:

•Abbreviations

•3XX

•Blind Transfer

•Call Control Discovery

•CallFwdAll Notification

•Calling Party IP Address

•Calling Party Normalization

•Call PickUp

•Click to Conference

•Conference Enhancements

•Direct Transfer Across Lines

•Do Not Disturb-Reject

•Drop Any Party

•End-To-End Call Trace

•Extension Mobility Cross Cluster

•External Call Control

•End-To-End Call Trace

•Hunt List

•IPv6 Use Cases

•Join Across Lines

•Logical Partitioning Support

•Manual Outbound Call

•Monitoring and Recording

•Park Monitoring

•Presentation Indication

•Redirect Set Original Called (TxToVM)

•Refer and Replaces Scenarios

•Secure Conferencing

•Secure Monitoring and Recording

•Shared Lines-Initiating a New Call Manually

•SRTP

•Support for Cisco IP Phone 6900 Series

•Support for Cisco Unified IP Phone 6900 and 9900 Series Use Cases

•Swap or Cancel Support

Abbreviations

The following list gives abbreviations that are used in the CTI events that are shown in each scenario:

•NP—Not Present

•LR—LastRedirectingParty

•CH—CtiCallHandle

•GCH—CtiGlobalCallHandle

•RIU—RemoteInUse flag

•DH—DeviceHandle

3XX

Application monitors B.

Table A-1 3XX

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
A calls external phone that is running SIP, which has CFDUNC set to B		TSPI: LINE_APPNEWCALL Reason = LINECALL REASON_REDIRECT

Blind Transfer

Table A-2 describes the message sequences for Blind Transfer when A calls B, B answers, and A and B are connected.

Table A-2 Message Sequences for Blind Transfer 

Action	CTI Messages	TAPI Messages	TAPI Structures
Party B does a lineBlindTranfser() to blind transfer call from party A to party C	Party A
	CallPartyInfoChangedEvent, CH=C1, CallingChanged=False, Calling=A, CalledChanged=True, Called=C, OriginalCalled=B, LR=B, Cause=BlindTransfer	LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTEDID, REDIRECTINGID, REDIRECTIONID	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NULL dwRedirectingID=NP dwRedirectionID=NP
	Party B
	CallStateChangedEvent, CH=C2, State=Idle, Reason=Direct, Calling=A, Called=B, OriginalCalled=B, LR=NULL	TSPI: LINE_CALLSTATE |hDevice=hCall-1 dwCallbackInstance=0 dwParam1=IDLE dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NULL dwRedirectingID=NULL dwRedirectionID=NULL
	Party C
	NewCallEvent, CH=C3, origin=Internal_Inbound, Reason=BlindTransfer, Calling=A, Called=C, OriginalCalled=B, LR=B	TSPI: LINE_APPNEWCALL hDevice=C dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=TRANSFER dwCallerID=A dwCalledID=C dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C
Party C is offering	Party A
	CallStateChangeEvent, CH=C1, State=Ringback, Reason=Direct, Calling=A, Called=C, OriginalCalled=B, LR=B	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1= RINGBACK dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C
	Party C
	CallStateChangedEvent, CH=C3, State=Offering, Reason=BlindTransfer, Calling=A, Called=C, OriginalCalled=B, LR=B	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1= OFFERING dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwCallerID=A dwCalledID=C dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C

Call Control Discovery

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster2

Configuration

SCCP phone A(1900) are registered to cluster A

Phones A are associated with the end-user cluster1

SCCP phone B(1000) registered to cluster B

Phones B are associated with the end-user cluster2

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network. TAPI is observing A.

Procedure

Application monitors A

Application sends a lineMakeCall at A to call B

Action	CTI Messages	TAPI Messages
A dials 1000, this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = ""
SIP trunk rejects this call due to no more bandwidth available	A receives CallStateChangeEvent (PROCEEDING)	LineA: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT CallerID = A / CalledID = 1000 / ConnectedID = / RedirectingID = / RedirectionID =
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW	A receives CPIC and CallStateChangeEvent (Ringback/connected) Provide TSPI_LinegetcallInfo on A connected with B	A:CPIC event received on party A LineA: LINE_CALLSTATE (LINECALLSTATE_RINGBACK / LINECALLSTATE_CONNECTED) CallReason = LINECALLREASON_DIRECT LINECALLINFO.dwCallID = 0x00400BBA LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1900(A) LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1000: LINECALLINFO.dwCalledIDName = CCD Pattern LINECALLINFO.dwConnectedID = 1000(B) LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1000 LINECALLINFO.dwRedirectingIDName = CCD Pattern ExtendCallReason = CtiReasonSAF_CCD_PSTNFailover(2B)

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster2 with PSTN Failover Rule not Set

Configuration

SCCP phone A are registered to cluster A.

Phones A are associated with the end-user "cluster1".

SCCP phone B(1000) registered to cluster B.

Phones B are associated with the end-user "cluster2".

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network is not set.

Procedure

Application monitors A.

Application sends a lineMakeCall at A to call B.

Action	CTI Messages	TAPI Messages
A dials 1000, this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = ""
SIP trunk rejects this call due to lack of bandwidth	A receives CallStateChangeEvent (PROCEEDING)	A:A receives CPIC event LineA: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT CallerID = A / CalledID = 1000 / ConnectedID = / RedirectingID = / RedirectionID =
	A receives CallStateChangeEvent (disconnected)	LineA: LINE_CALLSTATE (LINECALLSTATE_ Disconnected) EVENT = LINE_CALLSTATE = 2 m_lpfnEventProc = 0xXXX m_htLine = 0x000XXXX htCall = 0x000XXX
	Provide TSPI_linegetcallinfo on the Disconnected call	dwParam1 = 0x00004000(LINECALLSTATE_DISCONNECTED) dwParam2 = 0x00200000(LINEDISCONNECTMODE_SAFCCD) dwParam3 = 0x00000004 LINECALLINFO.dwCallID = 0x00400BCF LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1900 LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 10XX: LINECALLINFO.dwCalledIDName = CCD Pattern LINECALLINFO.dwConnectedID = LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000: LINECALLINFO.dwRedirectionIDName = CCD Pattern LINECALLINFO.dwRedirectingID = 1000: LINECALLINFO.dwRedirectingIDName = CCD Pattern ExtendCallReason = CtiReasonSAF_CCD_PSTNFailover

Basic Call Initiated from TAPI from Phone A(1900) and B(1901) on Cluster 1, B Redirects to Phone C(1000) on Cluster2 with PSTN Failover Rule Set

Configuration

SCCP phone A and B are registered to cluster A.

Phones A and B are associated with the end-user cluster1.

SCCP phone C(1000) registered to cluster B.

Phones C are associated with the end-user cluster2.

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network.

Procedure

Application monitors A and B.

Application sends a lineMakeCall at A to call B

Table A-3 Basic Call Initiated from TAPI from Phone A(1900) and B(1901) on Cluster 1, B Redirects to Phone C(1000) on Cluster2 with PSTN Failover Rule Set

Action	CTI Messages	TAPI Messages
A dials B	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected). B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected).	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING, LINECALLSTATE_CONNECTED,) CallerID = A / CalledID = B B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_RINGING, LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B
B setsupconference, consult call to C(1000), this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk SIP trunk rejects this call due to no more bandwidth available CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, i.e. 14089721000. Call is sent out to a PSTN GW TSPI_linegetcallinfo on the consult call between B and C. B completes conference.		B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) B: receives CPIC event LineB: LINE_CALLSTATE (LINECALLSTATE_RINGBACK / LINECALLSTATE_CONNECTED) ExtendCallReason = CtiReasonSAF_CCD_PSTNFailover A, B and C are in conference.

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 with PSTN Failover Rule

Configuration

SCCP phone A and B are registered to cluster A.

Phones A(1900) and B(1901) are associated with the end-user cluster1.

SCCP phone C(1000) registered to cluster B.

Phones C are associated with the end-user cluster2.

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network .

Procedure

Application monitors A and B.

Application sends a lineMakeCall at A to call B.

Table A-4 Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 with PSTN Failover Rule 

Action	CTI Messages	TAPI Messages
A(1900) dials B(1901)	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected). B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING, LINECALLSTATE_CONNECTED,) B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_RINGING, LINECALLSTATE_CONNECTED)
B(1901) setups transfer to C(1000) This call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk SIP trunk rejects this call due to no more bandwidth available CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, i.e. 14089721000. Call is sent out to a PSTN GW. TSPI_linegetcallinfo on Consult call on B with C. B completes transfer		B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) LINECALLINFO.dwCallID = 0x00400BBA LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1901(B) LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1000: LINECALLINFO.dwCalledIDName = CCD Pattern LINECALLINFO.dwConnectedID = 1000(C) LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1000 LINECALLINFO.dwRedirectingIDName = CCD Pattern Extendedcallreason = CtiReasonSAF_CCD_PSTNFailover B: LINE_CALLSTATE (LINECALLSTATE_DISCONNECTED) ExtendCallReason=CtiReasonTransferredCall
	A receives CallStateChangeEvent (Connected)	A: LineA: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT LINECALLINFO.dwCallID = 0x00400FB0 LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1901 LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1000: LINECALLINFO.dwCalledIDName = CCD Pattern LINECALLINFO.dwConnectedID = 1000 LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1000 LINECALLINFO.dwRedirectingIDName = CCD Pattern ExtendCallReason = CtiReasonTransferredCall

Call Initiated from TAPI from Phone A and B on Cluster 1, B setsupconference to Phone C(1000) on Cluster 2 with PSTN Failover Rule

Configuration

SCCP phone A and B are registered to cluster A

Phones A(1900) and B(1901) are associated with the end-user cluster1

SCCP phone C(1000) registered to cluster B

Phones C are associated with the end-user cluster2

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network

Procedure

Application monitors A and B

Application sends a lineMakeCall at A to call B

Table A-5 Call Initiated from TAPI from Phone A and B on Cluster 1, B setsupconference to Phone C(1000) on Cluster 2 with PSTN Failover Rule

Action	CTI Messages	TAPI Messages
A dials B	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected) B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING, LINECALLSTATE_CONNECTED,) CallerID = A / CalledID = B B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_RINGING, LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B
B setsupconference, consult call to C(1000), this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk SIP trunk rejects this call due to no more bandwidth available CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW TSPI_linegetcallinfo on the consult call between B and C B completes conference	B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) B: receives CPIC event LineB: LINE_CALLSTATE (LINECALLSTATE_RINGBACK / LINECALLSTATE_CONNECTED) ExtendCallReason = CtiReasonSAF_CCD_PSTNFailover A, B and C are in conference

Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster 2 over SAF Trunk

Configuration

SCCP phone A(1900) are registered to cluster A

Phones A are associated with the end-user cluster1

SCCP phone B(1000) registered to cluster B

Phones B are associated with the end-user cluster2

CUCM learns a pattern 10XX, no PSTN failover rule as SAF network has unlimited Bandwidth, TAPI is observing A

Procedure

Application monitors A

Application sends a lineMakeCall at A to call B

Table A-6 Basic Call Initiated from TAPI from Phone A on Cluster 1 to Phone B on Cluster 2 over SAF Trunk 

Action	CTI Messages	TAPI Messages
A dials 1000	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = ""
	A receives CallStateChangeEvent (PROCEEDING)	LineA: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT CallerID = A / CalledID = 1000 / ConnectedID = / RedirectingID = / RedirectionID =
	A receives CallStateChangeEvent (Ringback/connected)	A:CPIC event received on party A LineA: LINE_CALLSTATE (LINECALLSTATE_RINGBACK / LINECALLSTATE_CONNECTED) CallReason = LINECALLREASON_DIRECT CallerID = A / CalledID = 1000 / ConnectedID = 1000 / RedirectingID = 1000 / RedirectionID = 1000 LINECALLINFO.dwCallID = 0x00400FB1 LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1900 LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1000: LINECALLINFO.dwCalledIDName = CCD Pattern LINECALLINFO.dwConnectedID = 1000 LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1000: LINECALLINFO.dwRedirectingIDName = CCD Pattern

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Redirects to Phone C(1000) on Cluster 2 over SAF Trunk

Configuration

SCCP phone A and B are registered to cluster A

Phones A and B are associated with the end-user cluster1

SCCP phone C(1000) registered to cluster B

Phones C are associated with the end-user cluster2

CUCM learns a pattern 10XX, from SAF network as unlimited Bandwidth

Procedure

Application monitors A and B

Application sends a lineMakeCall at A to call B

Table A-7 Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Redirects to Phone C(1000) on Cluster 2 over SAF Trunk 

Action	CTI Messages	TAPI Messages
A dials B	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected) B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING, LINECALLSTATE_CONNECTED,) B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_RINGING, LINECALLSTATE_CONNECTED)
B redirects call to 1000 over ICT trunk TSPI_linegetcallinfo on A	A receives CallStateChangeEvent (Connected)	B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DISCONNECTED) ExtendCallReason= CtiReasonRedirect A:CPIC event received on A LineA: LINE_CALLSTATE (LINECALLSTATE_RINGBACK) LineA: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT LINECALLINFO.dwCallID = 0x00400FB2 LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1900 LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1901 LINECALLINFO.dwCalledIDName = LINECALLINFO.dwConnectedID = 1000 LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1000 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1901 LINECALLINFO.dwRedirectingIDName = ExtendCallReason = CtiReasonRedirect

Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 over SAF Trunk

Configuration

SCCP phone A and B are registered to cluster A

Phones A and B are associated with the end-user cluster1

SCCP phone C(1000) registered to cluster B

Phones C are associated with the end-user cluster2

CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network, SAF network has unlimited bandwidth.

Procedure

Application monitors A and B

Application sends a lineMakeCall at A to call B

Table A-8 Basic Call Initiated from TAPI from Phone A and B on Cluster 1, B Transfers to Phone C(1000) on Cluster 2 over SAF Trunk 

Action	CTI Messages	TAPI Messages
A calls B	A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected) B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING, LINECALLSTATE_CONNECTED,) B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_RINGING, LINECALLSTATE_CONNECTED)
B setuptransfer to C(1000), through the ICT(SAF) trunk Complete transfer on B TSPI_linegetcallinfo on disconnected call on B	B: receives CPIC event	B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING/Proceeding) LineB: LINE_CALLSTATE (LINECALLSTATE_RINGBACK / LINECALLSTATE_CONNECTED) CallReason = LINECALLREASON_DIRECT B: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DISCONNECTED) ExtendCallReason= CtiReasonTransferredCall
TSPI_linegetcallinfo on A	A receives CallStateChangeEvent (Connected)	A: LineA: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)/ LINE_CALLINFO CallReason = LINECALLREASON_DIRECT LINECALLINFO.dwCallID = 0x00400FB4 LINECALLINFO.dwOrigin = 0x00000001 LINECALLINFO.dwReason = 0x00000001 LINECALLINFO.dwCallerID = 1000 LINECALLINFO.dwCallerIDName = LINECALLINFO.dwCalledID = 1901 LINECALLINFO.dwCalledIDName = LINECALLINFO.dwConnectedID = 1000 LINECALLINFO.dwConnectedIDName = LINECALLINFO.dwRedirectionID = 1900 LINECALLINFO.dwRedirectionIDName = LINECALLINFO.dwRedirectingID = 1901 LINECALLINFO.dwRedirectingIDName = ExtendCallReason = CtiReasonTransferredCall

CallFwdAll Notification

Application Pressed CFwdAll on TAPI Monitored Device

Application opens the line with new ExtVersion 0x000A0000. User presses CFwdAll softkey on A when device is in on-hook condition.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000
User presses CFwdAll softkey	NewCallEvent received for A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask 0x00000040

TAPI Monitored Device Goes Off Hook

Application opens the line with new ExtVersion 0x000A0000. Device goes off hook.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000
A goes off-hook	NewCallEvent received for A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000

Application Monitors Off Hook Device

Device goes off hook. Application does a LineInitialize and opens line A with new ExtVersion 0x000A0000

Action	CTI Events	Expected Results
Device goes offhook
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000	ExistingCallEvent received at A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallType 00000000

Application Monitors Device after User Presses CFwdAll

User presses CFwdAll softkey on the device. Application does a LineInitialize and opens line A with new ExtVersion 0x000A0000.

Action	CTI Events	Expected Results
User presses CFwdAll softkey on the device
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000	ExistingCallEvent received for A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040

User Presses CFwdAll Softkey after Device is Off Hook

TAPI application does a LineInitialize and opens line A with new ExtVersion 0x000A0000. Device goes off hook and user presses CFwdAll softkey.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000	ExistingCallEvent received for A
A goes off-hook User presses CFwdAll softkey	NewCallEvent received for A	LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000

User Presses CFwdAll Softkey on a Multiline Device

TAPI application does LineInitialize and opens all lines- A1 and A2 for the device with new ExtVersion 0x000A0000. User presses the CFwdAll softkey.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A1, LineOPen on A2 with new ExtVesrion 0x000A0000
User presses CFwdAll softkey	NewCallEvent received for A1
LineGetCallInfo on A1		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040

User Presses CFwdAll on a Multiline Device by Selecting a Line

TAPI application does a LineInitialize and opens all lines- A1 and A2 for the device with new ExtVersion 0x000A0000. User selects line A2 and presses CFwdAll softkey.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A1, LineOPen on A2 with new ExtVesrion 0x000A0000
User selects line A2 and presses CFwdAll softkey	NewCallEvent received for A1
LineGetCallInfo on A2		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000

Shared Line Scenario on Pressing CFwdAll Softkey

TAPI application does a LineInitialize and opens a shared line A with new ExtVersion 0x000A0000 on devices P and Q. User presses CFwdAll softkey on device P.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A LineOpen on A' with new ExtVesrion 0x000A0000
On device P, user presses `CFwdAll' softkey	NewCallEvent received at A NewCallEvent received at A' for RIU call
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000

Cancellation of CFwdAll

TAPI application does a LineInitialize and open line A with new ExtVersion 0x000A0000. User sets CFwdAll for line A by pressing CFwdAll softkey followed by CallFwdAll destination number.

Later, user presses `CFwdAll' softkey again to cancel CFwdAll setting.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A with new ExtVesrion 0x000A0000
User presses CFwdAll and enters FwdAll destination	NewCallEvent received for A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
User again presses `CFwdAll' softkey	NewCallEvent received for A
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000080

Calling Party IP Address

Basic Call

TAPI application monitors party B

Party A represents an IP phone

A calls B

IP Address of A is available to TAPI application that is monitoring party B

Consultation Transfer

TAPI application monitors party C

Party B represents an IP phone

A talks to B

B intiates a consultation transfer call to C

IP Address of B is available to TAPI application that is monitoring party C.

B Completes the transfer

Calling IP address of A is not available to TAPI application that is monitoring party C (not a supported scenario).

Consultation Conference

TAPI application monitors party C

Party B represents an IP phone

A talks to B

B initiates a consultation conference call to C

IP Address of B is available to TAPI application that is monitoring party C.

B Completes the conference

Calling IP address of A and B is not available to TAPI application that is monitoring party C (not a supported scenario)

Redirect

TAPI application monitors party B and party C

Party A represents an IP phone

A calls B

IP Address of A is available to TAPI application that is monitoring party B

Party A redirects B to party C

Calling IP address is not available to TAPI application that is monitoring party B (not a supported scenario)

Calling IP address B is available to TAPI application that is monitoring party C

Calling Party Normalization

Incoming Call from PSTN to End Point

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets offered from a PSTN number 5551212/<SUBSCRIBER> through a San Jose gateway to a CCM end point 2000	CallStateChangedEvent, UnModified Calling Party=5551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=5551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=5551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=

Incoming Call from National PSTN to CTI-Observed End Point

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets offered from a Dallas PSTN number 5551212/<NATIONAL> through a San Jose gateway to a CCM end point 2000	CallStateChangedEvent, UnModified Calling Party=9725551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=9725551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=9725551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=

Incoming Call from International PSTN to CTI-Observed End Point

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets offered from a PSTN number in India 22221111/<INTERNATIONAL> through a San Jose gateway to a CCM end point 2000	CallStateChangedEvent, UnModified Calling Party=011914422221111, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=011914422221111, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=011914422221111, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type = UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=

Outgoing Call from CTI-Observed End Point to PSTN Number

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number 5551212/<NATIONAL>	CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=5551212, UnModified Original Called Party=5551212, Modified Calling Party=2000, Modified Called Party=5551212, Modified Original Called Party=5551212, Globalized Calling party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=SUBSCRIBER, Original Called Party Number Type,=SUBSCRIBER State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=2000, Displayed Called Party=5551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= SUBSCRIBER, Redirection Party Number Type=, Redirecting Party Number Type=

Outgoing Call from CTI-Observed End Point to National PSTN Number

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a Dallas PSTN number 9725551212/<NATIONAL>	CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=9725551212, UnModified Original Called Party=9725551212, Modified Calling Party=2000, Modified Called Party=9725551212, Modified Original Called Party=9725551212, Globalized Calling party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=NATIONAL, Original Called Party Number Type,=NATIONAL State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=2000, Displayed Called Party=9725551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= NATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=

Outgoing Call from CTI-Observed End Point to International PSTN Number

Action	CTI Messages	TAPI Messages	TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number in India 914422221111/<INTERNATIONAL>	CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=011914422221111, UnModified Original Called Party=011914422221111, Modified Calling Party=2000, Modified Called Party=011914422221111, Modified Original Called Party=011914422221111, Globalized Calling party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type=INTERNATIONAL, Original Called Party Number Type,=INTERNATIONAL State=Connected, Origin=OutBound, Reason = Direct	LINE_CALLSTATE = CONNECTED	LINECALLINFO Displayed Calling Party=2000, Displayed Called Party=011914422221111, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type = INTERNATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=

Call PickUp

Registering CallPickUpGroup for Notification

Configuration

Service parameter "Auto Call Pickup Enabled" is enabled.

Devices/Lines: 1000:P1,1001:P1.1002:P1,4000:P1 and 4001:P1

Pickup group P1:1111 is configured

P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen for P1:1111	LineOpenSuccessful LineInService Event as well
LineInfo	DN and Partition information will be pickup Group DN and partition. LineName - "CtiCallPickupDevice" LineType - LINEDEVCAPSDEVSPECIFIC_PICKUPDN - 0x00000004

UnRegistering CallPickUpGroup for Notification

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen for P1:1111	Line Open Successful
Application sends CciscoLineDevSpecificUnRegisterCallPickupGroupForNotification on new line opened for PickUpGroup P1:1111	Line_Reply with success. LINE_REMOVE event will be sent to Application for P1:1111

Re-Registering CallPickUpGroup for Notification

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen for P1:1111	Line Open Successful
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with Error "LINEERR_OPERATIONUNAVAIL"
Variant : Test the Same with UnRegister

Registering/UnRegistering CallPickUpGroup for Notification with InValid Information

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with InValid DN or Partition	Line_Reply with Error Code "LINEERR_OPERATIONFAILED"
Variant : Test the Same with UnRegister

CallPickUp after Enabling Auto Call Pickup Enabled

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen for P1:1111	Line Open Successful
P1:4000 calls P1:1002	LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo on new call on P1:1111	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin : Outbound dwCallReason : Direct Check for all fields of Calling and Called Information
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:1000	Events on P1:1000: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 4000, Called = 1002, Connected = 4000, dwReason= Direct, dwOrigin = Internal. Note There is no notification at P1:1111 after the call has been pickup.
Varaint : P1:4000 calls P1:1002 and P1:4001 calls P1:1002 Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:1000	First incoming Call will be picked up (i.e call from 4000 will be picked up by 1000)

CallPickUp with Auto Call Pickup Enabled Disabled

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:1000	Events on P1:1000: Call 1: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_IDLE Note First call will go IDLE state after Proceeding state. Call2: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_OFFERING Once the call is Answered LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 4000, Called = 1002, Connected = 4000, dwReason= PickUp, dwOrigin = Outbound Note There is no notification at P1:1111 after the call has been pickup.
Varaint : Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:1002	CallPickup Request will be successful and the newcall will be created and the call will be in Offering state

CallPickUp with Multiple Calls Available

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
P1:4001 calls P1:1001	Call 2: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo on Call LineGetCallInfo on Call2	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4001 dwCalledID : 1001 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:1000	Events on P1:1000: Call 3: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 4000, Called = 1002, Connected = 4000, dwReason= Direct, dwOrigin = Internal Note There is no notification at P1:1111 after the call has been pickup.

CallPickupGroup Changed for a Device on AdminPage

Pickup group P1:9999 is configured

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on 1000:P1	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
Now from Admin page change the CallPickupGroup of 1000:P1 line to None or some other group P1:9999 LineGetDevCaps with Extension Version - 000A0000 on 1000:P1	Changed CallPickUp Group DN and Partition Information will be sent to application

CallPickUpGroup Partition or DN Information Updated

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on 1000:P1	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information
Now From Admin Pages change the Partition or DN information of the Pickup Group	LINE_REMOVE for the line P1:1111
LineGetDevCaps with Extension Version - 000A0000 on 1000:P1	Changed CallPickUp Group DN and Partition Information will be sent to application

CallPickUpGroup is Deleted

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
Now From Admin Pages Pickup Group 1111:P1 is deleted	LINE_REMOVE for the line P1:1111

FailOver or FailBack Scenario

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on 1000:P1	CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information
Stop Primary CTI Manager	OutofService for the line P1:1111 INService for the line P1:1111. Note There will not be any notification for the existing calls.

GroupCallPickup

Configuration

Service parameter "Auto Call Pickup Enabled" is enabled.

Pickup group P1:1111 is configured and opened

P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111

P1:2000, P1:2001, P1:2002 are all in pickup group P1:2222

P1:4000 and P1:4001 are configured

Action	Expected
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	LineGetDevCaps with Extension Version - 000A0000 on P1:2000CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
LineGetCallInfo	LINE_CALLINFO dwCallState : PickupCallState (0x10000000) dwCallerId : 4000 dwCalledID : 1002 dwCallorigin: Internal dwCallReason : Direct Check for all fields of Calling and Called Information
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with GroupCallPickup option and GroupPickUp DN 1111 on P1:2000	Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with GroupCallPickup option and GroupPickUp DN 1111 on P1:2000Events on P1:2000: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 4000, Called = 1111, Connected = 4000, dwReason= Direct, dwOrigin = Internal Note There is no notification at P1:1111 after the call has been pickup.

OtherCallPickup

Configuration

Service parameter "Auto Call Pickup Enabled" is enabled.

Pickup groups P1:1111, P1:2222, P1:3333 is configured and opened

P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111

P1:2000, P1:2001, P1:2002 are all in pickup group P1:2222

P1:3000, P1:3001, P1:3002 are all in pickup group P1:3333

P1:1111, and P1:2222 are sub-groups, in order of priority, of pickup group P1:3333.

P1:4000 and P1:4001 are configured.

Action	Expected Event
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:2000 P1:4001 calls P1:1000	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111 Call 2: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with OtherPickup option on P1:3000 Note Group DN is not required	Events on P1:3000: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 4001, Called = 1000, Connected = 4001, dwReason= Direct, dwOrigin = Internal

DirectCallPickup

Action	Expected Event
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002 P1:4001 calls P1:1000	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111 Call 2: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with DirectCallPickup option with pickup groupDN (1000) on P1:10001	Events on P1:1001: LINE_NEWCALL and LINE_CALLSTATE with state = LINECALLSTATE_CONNECTED Call Info : Caller = 1001, Called = 1000, Connected = 4001, dwReason= Direct, dwOrigin = Internal

CallPickup (Negative Use Case)

Configuration

Service parameter Auto Call Pickup Enabled is enabled.

P1:2000 is already opened by the application.

Pickup groups P1:1111, P1:2222, P1:3333 is configured and opened.

P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111

P1:2000, P1:2001, P1:2002 are all in pickup group P1:2222

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with CallPickup option on P1:2000	Line_Reply with Error LINEERR_OPERATIONUNAVAIL

GroupCallPickup with SuperSet Call PickupDN

Configuration

Service parameter Auto Call Pickup Enabled is enabled.

Pickup groups P1:1111, P1:2222, P1:3333 is configured and opened.

P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111.

P1:2000, P1:2001, P1:2002 are all in pickup group P1:2222.

P1:3000, P1:3001, P1:3002 are all in pickup group P1:3333.

P1:1111, and P1:2222 are sub-groups, in order of priority, of pickup group P1:3333.

P1:4000 and P1:4001 are configured.

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:2000 P1:4001 calls P1:1000	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111 Call 2: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with GroupPickup option with pickup group(3333) on P1:3000	Line_Reply with Error LINEERR_CALLUNAVAIL

Group or Direct CallPickup with Invalid DN

Action	Expected Events
LineIntialize OpenLines - 1000:P1	Line Open Successful
LineGetDevCaps with Extension Version - 000A0000 on P1:2000	CallPickUp Group DN and Partition Information will be sent to application.(P1:2222)
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111	Line_Reply with success. LINE_CREATE event will sent to Application for P1:1111
LineOpen with new DeviceID	LineOpen Successful
P1:4000 calls P1:1002	Call1: LINE_APPNEWCALL LINE_CALLSTATE with State = LINECALLSTATE_UNKNOWN to Application on Line P1:1111
Application sends CciscoLineDevSpecificPickUpCallFromPickupGroup with GroupPickup option with pickup group(9999) on P1:3000 Variant - Direct Call Pickup with InValid DN	Line_Reply with Error LINEERR_OPERATIONFAILED Line_Reply with Error LINEERR_INVALLINESTATE

Click to Conference

Third-party conference gets created by using click-2-conference feature:

Action	Events
Use Click-to-Call to create call from A to B, and B answers	For A: CONNECTED reason = DIRECT Calling = A, Called = B, Connected = B For B: CONNECTED reason = DIRECT Calling = A, Called = B, Connected = A
Use Click-2-Conference feature to add C into conference, and C answers	For A: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = B CONFERENCED Calling = A, Called = C, Connected = C For B: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = A CONFERENCED Calling =B, Called = C, Connected = C For C CONNECTED Reason = UNKNOWN ExtendedCallReason = ClickToConference CONFERENCED Calling = C, Called = A, Connected = A CONFERENCED Calling = C, Called = B, Connected = B

Creating Four-Party Conference by Using Click-2-Conference Feature

Action	Events
Use Click-to-Call to create call from A to B	For A: CONNECTED reason = DIRECT Calling = A, Called = B, Connected = B For B: CONNECTED reason = DIRECT Calling = A, Called = B, Connected = A
Use Click-2-Conference feature to add C into conference	For A: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = B CONFERENCED Calling = A, Called = C, Connected = C For B: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = A CONFERENCED Calling = C, Called = C, Connected = C For C CONNECTED Reason = DIRECT ExtendedCallReason = ClickToConference CONFERENCED Calling = C, Called = A, Connected = A CONFERENCED Calling = C, Called = B, Connected = B
Use Click-2-Conference feature to add party D	For A: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = B CONFERENCED Calling = A, Called = C, Connected = C CONFERENCED Calling = A, Called = D, Connected = D For B: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = A CONFERENCED Calling = B, Called = C, Connected = C CONFERENCED Calling = B, Called = D, Connected = D For C CONNECTED Reason = UNKNOWN ExtendedCallReason = ClickToConference CONFERENCED Calling = C, Called = A, Connected = A CONFERENCED Calling = C, Called = B, Connected = B CONFERENCED Calling = C, Called = D, Connected = D For D CONNECTED Reason = UNKNOWN ExtendedCallReason = ClickToConference
	CONFERENCED Calling = D, Called = A, Connected = A CONFERENCED Calling = D, Called = B, Connected = B CONFERENCED Calling = D, Called = C, Connected = C

Drop Party by Using Click-2-Conference

Action	Events
Conference gets created by using Click-2-Conference feature to add C into conference	For A: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = B CONFERENCED Calling = A, Called = C, Connected = C For B: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = A CONFERENCED Calling = B, Called = C, Connected = C For C CONNECTED Reason = UNKNOWN ExtendedCallReason = ClickToConference CONFERENCED Calling = C, Called = A, Connected = A CONFERENCED Calling = C, Called = B, Connected = B
Drop C from Click-2-Conference feature	For A CONNECTED Reason = DIRECT ExtendedCallReason = DIRECT Calling = A, Called = B, Connected = B For B CONNECTED Reason = DIRECT ExtendedCallReason = DIRECT Calling = A, Called = B, Connected = A For C IDLE

Drop Entire Conference by Using Click-2-Conference Feature

Action	Events
Conference gets created by using Click-2-Conference feature to add C into conference	For A: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = B CONFERENCED Calling = A, Called = C, Connected = C For B: CONNECTED reason = DIRECT ExtendedCallReason = DIRECT CONFERENCED Calling = A, Called = B, Connected = A CONFERENCED Calling = B, Called = C, Connected = C For C CONNECTED Reason = UNKOWN ExtendedCallReason = ClickToConference CONFERENCED Calling = C, Called = A, Connected = A CONFERENCED Calling = C, Called = B, Connected = B
Drop entire conference	For A IDLE For B IDLE For C IDLE

Conference Enhancements

Noncontroller Adding Parties to Conferences

A,B, and C exist in a conference that A created.

Action	Events
A,B, and C exist in a conference	At A: Conference - Caller="A", Called="B", Connected="B" Connected Conference - Caller="A", Called="C", Connected="C" At B: Conference - Caller="A", Called="B", Connected="A" Connected Conference - Caller="B", Called="C", Connected="C" At C: Conference - Caller="B", Called="C", Connected="B" Connected Conference - Caller="C", Called="A", Connected="A"
C issues a linePrepareAddToConference to D	At A: Conference - Caller="A", Called="B", Connecgted="B" Connected Conference - Caller="A", Called="C", Connecgted="C" At B: Conference - Caller="A", Called="B", Connecgted="A" Connected Conference - Caller="B", Called="C", Connecgted="C" At C: Conference - Caller="B", Called="C", Connecgted="B" OnHoldPendConf Conference - Caller="C", Called="A", Connecgted="A" Connected - Caller="C", Called="D", Connecgted="D" At D: Connected - Caller="C", Called="D", Connecgted="C"
C issues a lineAddToConference to D	At A: Conference - Caller="A", Called="B", Connecgted="B" Connected Conference - Caller="A", Called="C", Connecgted="C" Conference - Caller="A", Called="D", Connecgted="D" At B: Conference - Caller="A", Called="B", Connecgted="A" Connected Conference - Caller="B", Called="C", Connecgted="C" Conference - Caller="B", Called="D", Connecgted="D" At C: Conference - Caller="B", Called="C", Connecgted="B" Connected Conference - Caller="C", Called="A", Connecgted="A" Conference - Caller="C", Called="D", Connecgted="D" At D: Conference - Caller="C", Called="D", Connecgted="C" Connected Conference - Caller="D", Called="A", Connecgted="A" Conference - Caller="D", Called="B", Connecgted="B"

Chaining Two Ad Hoc Conferences by Using Join

Table 1:

Actions	TSP CallInfo
A calls B, B answers, then B initiates conference to C, C answers, and B completes the conference	At A: GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = A Called = B CONFERENCED : Caller = A Called = C At B: GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = A Called = B CONFERENCED : Caller = B Called = C At C: GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = B Called = C CONFERENCED : Caller = C Called = A
C initiates or completes conference to D and E	No Change for A and B At C: - First conference GCID-1 ONHOLD : Caller = Unknown Caller = Unknown CONFERENCED : Caller = A Called = B CONFERENCED : Caller = A Called = C - Second conference GCID-2 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = C Called = D CONFERENCED : Caller = C Called = E At D: GCID-2 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = C Called = D CONFERENCED : Caller = D Called = E At E: GCID-2 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = C Called = E CONFERENCED : Caller = E Called = D
C initiates JOIN request to join to conference call together, with GCID as the primary call	At A: GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = A Called = B CONFERENCED : Caller = A Called = C CONFERENCED : Caller = A Called = Conference-2 At B : GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = A Called = B CONFERENCED : Caller = B Called = C CONFERENCED : Caller = B Called = Conference-2 At C: - First conference GCID-1 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = B Called = C CONFERENCED : Caller = C Called = A CONFERENCED : Caller = C Called = Conference-2
	At D: GCID-2 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = D Called = E CONFERENCED : Caller = D Called = Conference-1 At E : GCID-2 CONNECTED : Caller = Unknown Caller = Unknown CONFERENCED : Caller = E Called = D CONFERENCED : Caller = E Called = Conference-1

Direct Transfer Across Lines

Use cases related to Direct Transfer Across Lines feature are mentioned below:

---

Note The device mentioned in the use cases also apply to SCCP device and SIP TNP phones when Direct Transfer is issued from application.

---

Direct Transfer across Lines on RoundTable Phones via Application

Device A, B, and C where B is roundtable phone and has line B1 and B2 configured.

Action	Expected Events
A ‡B1 is connected, C ‡B2 is on hold	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1 For B1: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1, Connected = A For B2: LINE_CALLSTATE param1=x100, HOLD Caller = C, Called = B2 , Connected = C For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
Application sends CciscoLineDevSpecificDirectTransfer on B1 with B2 as consult call	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected C For B1: Call goes IDLE For B2: Call goes IDLE For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = A

Direct Transfer on Same Line on RoundTable Phones via Application

Device A, B, C where B is roundtable phone .

Action	Expected Events
A ‡ B (c1) is connected, C ‡ B (c2) is on hold	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B Connected B For B: Call-1 LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B, Connected = A Call-2 LINE_CALLSTATE param1=x100, HOLD Caller = C, Called = B, Connected = C For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B, Connected = B
Application sends CciscoLineDevSpecificDirectTransfer on B (c1) with c2 as consult call	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B Connected C For B: Call-1 and Call-2 will go IDLE For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B, Connected = A

Direct Transfer Across Lines on RoundTable Phones via Application with call in Offering State

Device A, B, C where B is roundtable phone and has line B1 and B2 configured .

Action	Expected Events
A (c1) ‡ B1(c2) is on hold, B2 (c3) ‡ C (c4) is ringing	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1 For B1: LINE_CALLSTATE param1=x100, HOLD Caller = A, Called = B1, Connected = A For B2: LINE_CALLSTATE param1=x100, RINGBACK Caller = B2, Called = C For C: LINE_CALLSTATE param1=x100, OFFERING Caller = B2, Called = C
Application sends CciscoLineDevSpecificDirectTransfer on B1 (c2) with B2 (c3) as consult call	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B Connected C For B1: Call goES IDLE For B2: Call goes IDLE For C: LINE_CALLSTATE param1=x100, OFFERING Caller = C, Called = B,

Failure of Direct Transfer Calls Across Lines

Device A, B, C where B is roundtable phone and has line B1 and B2 configured .

Action	Expected Events
A (c1) ‡ B1(c2) is on hold, Initiate new call (c3) on B2	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1 For B1: LINE_CALLSTATE param1=x100, HOLD Caller = A, Called = B1, Connected = A For B2: LINE_CALLSTATE param1=x100, DIALTONE
Application sends CciscoLineDevSpecificDirectTransfer on B1 (c2) with B2 (c3) as consult call	CciscoLineDevSpecificDirectTransfer gets error as LINEERR_INVALCALLSTATE.

Direct Transfer Calls Across Lines in Conference Scenario

Device A, B, C, D and E where C is roundtable phone and has line C1 and C2 configured .

Action	Expected Events
A/B/C1 in conference, B is controller, call on C1 is in hold state. C2 /D/E in conference, D is controller, call on C2 is in connect state.	For A: CONNECTED CONFERENCED Caller = A, called = B, connected = B CONFERENCED Caller = A, called = C1, connected = C1
	For B: CONNECTED CONFERENCED Caller = A, called = B, connected = B CONFERENCED Caller = B, called = C1, connected = C1
	For C1: ONHOLD CONFERENCED Caller = B, called = C1, connected = B CONFERENCED Caller = C1, called = A, connected = A
	For C2: CONNECTED CONFERENCED Caller = C2, called = D, connected = D CONFERENCED Caller = C2, called = E, connected = E
	For D: CONNECTED CONFERENCED Caller = D, called = C1, connected = C1 CONFERENCED Caller = D, called = E, connected = E
	For E: CONNECTED CONFERENCED Caller = D, called = E, connected = D CONFERENCED Caller = E, called = C2, connected = C2
Application sends CciscoLineDevSpecificDirectTransfer on C1 with C2-call as consult call	CciscoLineDevSpecificDirectTransfer will succeed. For A: CONNECTED CONFERENCED Caller = A, called = B, connected = B CONFERENCED Caller = A, called = CB-2, connected = CB-2 For B: CONNECTED CONFERENCED Caller = A, called = B, connected = B CONFERENCED Caller = B, called = CB-2, connected = CB-2 For C1: IDLE For C2: IDLE For D: CONNECTED CONFERENCED Caller = D, called = CB-1, connected = CB-1 CONFERENCED Caller = D, called = E, connected = E For E: CONNECTED CONFERENCED Caller = D, called = E, connected = D CONFERENCED Caller = E, called = CB-1, connected = CB-1

Connect Transfer Across Lines on RoundTable Phones

Device A, B, C where B is roundtable phone and has line B1 and B2 configured .

Action	Expected Events
A ‡ B1 is connected, C ‡ B2 is on hold	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1 For B1: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1, Connected = A For B2: LINE_CALLSTATE param1=x100, HOLD Caller = C, Called = B2, Connected = C For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
User performs connect transfer on B.	For A: LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected C For B1: Call goes IDLE For B2: Call goes IDLE For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = A

Do Not Disturb-Reject

Application Enables DND-R on a Phone

Action	TAPI Messages	TAPI Structures
Phone A enables DND-Reject in the admin pages	LINE_CALLDEVSPECIFIC hDevice=C dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_DND_OPTION_STATUS dwParam3=2

Normal Feature Priority

Action	TAPI Messages	TAPI Structures
With Phone B DND-R enabled, Phone A calls Phone B with feature priority as Normal	Party A
	LINE_CALLSTATE = IDLE
	Party B
	No TAPI messages

Feature Priority - Emergency

Action	TAPI Messages	TAPI Structures
With Phone B DND-R enabled, Phone A calls Phone B with feature priority as Emergency	Party A
	LINE_CALLSTATE = CONNECTED dwParam1 = 0x00000100 dwParam2 = 0x00000001	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=INTERNAL dwCallerID=A dwCalledID=B dwRedirectionID=NP dwRedirectingID=NP
	Party B
	LINE_CALLSTATE = CONNECTED dwParam1 = 0x00000100 dwParam2 = 0x00000001	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=INTERNAL dwCallerID=A dwCalledID=B dwRedirectionID=NP dwRedirectingID=NP

Shared Line Scenario for DND-R

Action	TAPI Messages		TAPI Structures
Phones B and B' represents shared lines. Phone B' is DND-R enabled but not B. Phone A calls Phone B with feature priority normal	Party A
	LINE_CALLSTATE = CONNECTED dwParam1 = 0x00000100 dwParam2 = 0x00000001		LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=INTERNAL dwCallerID=A dwCalledID=B dwRedirectionID=NP dwRedirectingID=NP
	Party B
	LINE_CALLSTATE = CONNECTED dwParam1 = 0x00000100 dwParam2 = 0x00000001		LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=INTERNAL dwCallerID=A dwCalledID=B dwRedirectionID=NP dwRedirectingID=NP
	Party B'
	LINE_CALLSTATE = CONNECTED dwParam1 = 0x00000100 dwParam2 = 0x00000002

Application Disables DND-R or Changes the Option for DND

Action	TAPI Messages	TAPI Structures
Phone A changes from DND-Reject to DND-RingerOff.	LINE_CALLDEVSPECIFIC hDevice=C dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_DND_OPTION_STATUS dwParam3=1

Drop Any Party

Use cases related to Drop Any Party feature are mentioned below:

Conference: Unified CM Service Parameter Advanced Ad Hoc Conference Enabled = False.

Action	Expected Events
A,B,C and D are in conference; B is conference Controller.	Conference Model: Each line in conference will be having 4 callLegs, 3 conferenced and 1 connected
	CallLegs on A: Connected - to Conference Bridge Conferenced - (Connected Id - B) Conferenced - (Connected Id - C) Conferenced - (Connected Id - D)
	CallLegs on B: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - C) Conferenced - (Connected Id - D)
	CallLegs on C: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - D)
	CallLegs on D: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - C)
Application does a LineOpen (B) with new Ext ver.
1. Application does LineRemoveFromConference on the `Conferenced' callLeg on B which is connected to A.	A is dropped out of conference. CallLegs after the Party is dropped from Conference: Each line in conference will be having 4 callLegs, 2 Conferenced,1 IDLE and 1 connected
	CallLegs on A: All 4 CallLegs will be in IDLE state
	CallLegs on B: Connected - to Conference Bridge Conferenced - (Connected Id - C) Conferenced - (Connected Id - D) IDLE - ( on the conferenced callLeg which was connected to A)
	CallLegs on C: Connected - to Conference Bridge IDLE - ( on the conferenced callLeg which was connected to A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - D)
	CallLegs on D: Connected - to Conference Bridge IDLE - ( on the conferenced callLeg which was connected to A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - C) Note All IDLE CallLegs will have CallStateChange Reason as CtiDropConferee.
Application does a LineOpen (A) with new Ext ver.
2. Application does LineRemoveFromConference on the `Conferenced' callLeg on A which is connected to B.	Error Message LINEERR_OPERATIONUNAVAIL will be sent to application

Conference - Unified CM Service Parameter Advanced Ad Hoc Conference Enabled = True'

Action	Expected Events
A,B,C and D are in conference; B is conference Controller.	Conference Model: Each line in conference will be having 4 callLegs, 3 conferenced and 1 connected
	CallLegs on A: Connected - to Conference Bridge Conferenced - (Connected Id - B) Conferenced - (Connected Id - C) Conferenced - (Connected Id - D)
	CallLegs on B: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - C) Conferenced - (Connected Id - D)
	CallLegs on C: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - D)
	CallLegs on D: Connected - to Conference Bridge Conferenced - (Connected Id - A) Conferenced - (Connected Id - B) Conferenced - (Connected Id - C)
Application does a LineOpen (A) with new Ext ver. Application does LineRemoveFromConference on the `Conferenced' callLeg on A which is connected to B.
1. Drop Ad Hoc Conference = Never	B is dropped out of conference. CallLegs after the Party is dropped from Conference: Each line in conference will be having 4 callLegs, 2 Conferenced,1 IDLE and 1 connected
	CallLegs on B: All 4 CallLegs will be in IDLE state
	CallLegs on A: Connected - to Conference Bridge Conferenced - (Connected Id - C) Conferenced - (Connected Id - D) IDLE - ( on the conferenced callLeg which was connected to B)
	CallLegs on C: Connected - to Conference Bridge IDLE - ( on the conferenced callLeg which was connected to B) Conferenced - (Connected Id - A) Conferenced - (Connected Id - D)
	CallLegs on D: Connected - to Conference Bridge IDLE - ( on the conferenced callLeg which was connected to B) Conferenced - (Connected Id - A) Conferenced - (Connected Id - C) Note All IDLE CallLegs will have CallStateChange Reason as CtiDropConferee.
2. Drop Ad Hoc Conference = `When Conference Controller Leaves'	B is dropped out of conference and Conference will be ended. CallLegs after the Party is dropped from Conference: Each line in conference will be having 4 callLegs, all in IDLE state CallLegs on A,B,C and D: All 4 CallLegs will be in IDLE state

Shared Line-Scenario

Action	Expected Events
A,B,C and A' are in conference; A is conference Controller Unified CM Parameter "Drop Ad Hoc Conference = Never"	Conference Model: Lines B and C in conference will be having 4 callLegs, 3 conferenced and 1 connected Lines A and A' will be having 8 CallLegs
	CallLegs on A: Connected - to Conference Bridge (Active) Conferenced - (caller Id - A ;Called Id - B; Connected Id - B) (Active) Conferenced - (caller Id - A ;Called Id - C; Connected Id - C) (Active) Conferenced - (caller Id - A ;Called Id - A' ; Connected Id - A') (Active) Connected - to Conference Bridge (Remote in Use) Conferenced - (caller Id - A' ;Called Id - B; Connected Id - B) (Remote in Use) Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Remote in Use) Conferenced - (caller Id - A' ;Called Id - A; Connected Id - A) (Remote in Use)
	CallLegs on A': Connected - to Conference Bridge (Active) Conferenced - (caller Id - A' ;Called Id - B; Connected Id - B) (Active) Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Active) Conferenced - (caller Id - A' ;Called Id - A; Connected Id - A) (Active) Connected - to Conference Bridge (Remote in Use) Conferenced - (caller Id - A ;Called Id - B; Connected Id - B) (Remote in Use) Conferenced - (caller Id - A ;Called Id - C; Connected Id - C) (Remote in Use) Conferenced - (caller Id - A ;Called Id - A'; Connected Id - A') (Remote in Use)
	CallLegs on B: Connected - to Conference Bridge Conferenced - (caller Id - B ;Called Id - A; Connected Id - A) Conferenced - (caller Id - B ;Called Id - C; Connected Id - C) Conferenced - (caller Id - B ;Called Id - A'; Connected Id - A')
	CallLegs on C: Connected - to Conference Bridge Conferenced - (caller Id - C ;Called Id - A; Connected Id - A) Conferenced - (caller Id - C ;Called Id - B; Connected Id - B) Conferenced - (caller Id - C ;Called Id - A' ; Connected Id - A')
Application does a LineOpen (A) with new Ext ver. Unified CM Parameter `Advanced Ad Hoc Conference Enabled = False'
1. Application does LineRemoveFromConference on the `Conferenced' CallLeg on A which is connected to B and mode is "Inactive or Remote In use".	Error LINEERR_INVALCALLSTATE is sent to application.
2. Application does LineRemoveFromConference on the `Conferenced' CallLeg on A which is connected to B and mode is `Active'.	B will be dropped out of conference. LINECALLSTATE Event will be sent to Application with state = Idle.
	CallLegs after the Party is dropped from Conference: CallLegs on A: Connected - to Conference Bridge (Active) IDLE - (on the conferenced callLeg which was connected to A - B) Conferenced - (caller Id - A ;Called Id - C; Connected Id - C) (Active) Conferenced - (caller Id - A ;Called Id - A'; Connected Id - A') (Active) Connected - to Conference Bridge (Remote in Use) IDLE - (on the conferenced callLeg which was connected to A' - B) Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Remote in Use) Conferenced - (caller Id - A' ;Called Id - A; Connected Id - A) (Remote in Use)
	CallLegs on A': Connected - to Conference Bridge (Active) IDLE - (on the conferenced callLeg which was connected to A' - B) Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Active) Conferenced - (caller Id - A' ;Called Id - A; Connected Id - A) (Active) Connected - to Conference Bridge (Remote in Use) IDLE - (on the conferenced callLeg which was connected to A - B) Conferenced - (caller Id - A ;Called Id - C; Connected Id - C) (Remote in Use) Conferenced - (caller Id - A ;Called Id - A'; Connected Id - A') (Remote in Use)
	CallLegs on B: All 4 CallLegs are in IDLE state
	CallLegs on C: Connected - to Conference Bridge Conferenced - (caller Id - C ;Called Id - A; Connected Id - A) IDLE - (on the conferenced callLeg which was connected to C - B) Conferenced - (caller Id - C ;Called Id - A'; Connected Id - A')
Application does a LineOpen (B) with new Ext ver. Unified CM Parameter Advanced Ad Hoc Conference Enabled = True
3. Application does LineRemoveFromConference on the `Conferenced' CallLeg on B which is connected to A and mode is "Active".	A will be dropped out of conference. LINECALLSTATE Event will be sent to Application with state = Idle.
	CallLegs after the Party is dropped from Conference: CallLegs on A: IDLE - (on the Connected callLeg which was connected to Conference Bridge,A- CFB) IDLE - (on the conferenced callLeg which is connected to A - B) IDLE - (on the conferenced callLeg which is connected to A - C) IDLE -(on the conferenced callLeg which is connected to A - A') Connected - to Conference Bridge (Remote in Use) Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Remote in Use) Conferenced - (caller Id - A' ;Called Id - B; Connected Id - B) (Remote in Use)
	CallLegs on A': IDLE - (on the Connected callLeg which was connected to Conference Bridge,A - CFB) IDLE - (on the conferenced callLeg which is connected to A - B) IDLE - (on the conferenced callLeg which is connected to A - C) IDLE -(on the conferenced callLeg which is connected to A - A') Connected - to Conference Bridge Conferenced - (caller Id - A' ;Called Id - C; Connected Id - C) (Active) Conferenced - (caller Id - A' ;Called Id - B; Connected Id - B) (Active)
	CallLegs on B: Connected - to Conference Bridge Conferenced - (caller Id - B ;Called Id - A; Connected Id - A') IDLE - (on the conferenced callLeg which was connected to B - A) Conferenced - (caller Id - B ;Called Id - C; Connected Id - C)
	CallLegs on C: Connected - to Conference Bridge Conferenced - (caller Id - C ;Called Id - A'; Connected Id - A') IDLE - (on the conferenced callLeg which was connected to C - A) Conferenced - (caller Id - C ;Called Id - B; Connected Id - B)

Chained Conference

Action	Expected Events
A,B and CB2 are in conference(CB1); B is conference Controller C,D and E are in Conference (CB2); D is conference Controller Unified CM Parameter Advanced Ad Hoc Conference Enabled = True Application does a LineOpen (A) with new Ext ver. 1. Application does LineRemoveFromConference on the Conferenced" CallLeg on A which is connected to B.	B is disconnected and dropped out of Conference. A is now in conference with CB2. LINECALLSTATE Event is sent to Application for Line B with state = Idle.

C-Barge: Unified CM Service Parameter Advanced Ad Hoc Conference Enabled = True.

Action	Expected Events
B call A and A'; A answers the call and on A' do c-Barge; A,B and A' will be in conference; A is conference Controller Unified CM Parameter "Drop Ad Hoc Conference = Never" Application does a LineOpen (A) with new Ext ver.
Application does a LineOpen (A) with new Ext ver. 1. Application does LineRemoveFromConference on the "Conferenced" CallLeg on A which is connected to B and mode is Active	B is dropped out of conference. LINECALLSTATE Event will be sent to Application with state = Idle. CallLegs after the Party is dropped from Conference: CallLegs on A: Connected - (on the conferenced callLeg which was connected to A - A') (Active) Connected - on the conferenced callLeg which was connected to A' - A) (Remote in Use) IDLE - (on the conferenced callLeg which was connected to A - B) IDLE - (on the connected callLeg which is connected to conference Bridge; A - CFB) IDLE - (on the conferenced callLeg which was connected to A' - B) IDLE - (on the connected callLeg which is connected to conference Bridge; A' - CFB)
	CallLegs on A': Connected - (on the conferenced callLeg which was connected to A' - A) (Active) Connected - on the conferenced callLeg which was connected to A - A') (Remote in Use) IDLE - (on the conferenced callLeg which was connected to A - B) IDLE - (on the connected callLeg which is connected to conference Bridge; A - CFB) IDLE - (on the conferenced callLeg which was connected to A' - B) IDLE - (on the connected callLeg which is connected to conference Bridge; A' - CFB)
	CallLegs on B: All 4 CallLegs are in IDLE state A' is dropped out of conference. LINECALLSTATE Event will be sent to Application with state = Idle.
2. Application does LineRemoveFromConference on the Conferenced CallLeg on A which is connected to A' and mode is Active.	CallLegs after the Party is dropped from Conference: CallLegs on A: Connected -(on the conferenced callLeg which was connected to A - B) (Active) IDLE -(on the conferenced callLeg which was connected to A' - B) (Remote in Use) IDLE - (on the conferenced callLeg which was connected to A - A') (active) IDLE - (on the connected callLeg which is connected to conference Bridge; A - CFB) IDLE - (on the conferenced callLeg which was connected to A' - A) (Remote in Use) IDLE - (on the connected callLeg which is connected to conference Bridge; A' - CFB)
	CallLegs on A': Connected -(on the conferenced callLeg which was connected to A - B) (Remote in Use) IDLE -(on the conferenced callLeg which was connected to A' - B) IDLE - (on the conferenced callLeg which was connected to A - A') (active) IDLE - (on the connected callLeg which is connected to conference Bridge; A - CFB) IDLE - (on the conferenced callLeg which was connected to A' - A) (Remote in Use) IDLE - (on the connected callLeg which is connected to conference Bridge; A' - CFB)
	CallLegs on B: Connected -(on the conferenced callLeg which was connected to B - A) IDLE -(on the conferenced callLeg which was connected to A' - B) IDLE - (on the connected callLeg which is connected to conference Bridge; B - CFB)

End-To-End Call Trace

Direct Call Scenario: Variation 1

Application does a LineInitializ. Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1

Direct Call Scenario: Variation 2

A calls B and B answers the call. Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000.

Action	CTI Events	Expected Results
A calls B. B answers the call
LineInitialize LineOpen on A, LineOpen on B with new ExtVesrion 0x000A0000	ExistingCallEvent received for A ExistingCallEvent received for A	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1

Consult Transfer Scenario: Variation 1

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up transfer to C, C answers the call, and B completes the transfer. A is connected to C.

Action	CTI Event	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C	NewCallEvent received for B NewCallEvent received for C	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on B (Consultation call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C (Consultation call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes transfer.	CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A (Call between A and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C2 (Consultation call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Consult Transfer Scenario: Variation 2

A calls B and B answers the call. B sets up transfer to C. Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. Application completes the transfer. A is connected to C.

Action	CTI Events	Expecte Results
A calls B and B answers the call. B setups transfer to C and C answers the call	LineInitialize LineOpen on A , LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000	ExistingCallEvent received for A (Primary Call between A and B)	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
	ExistingCallEvent received for B (Primary Call between A and B)	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B
	ExistingCallEvent received for B (Consultation Call between B and C)	LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received
	ExistingCallEvent received for C (Consultation Call between B and C)	dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A (Primary Call between A and B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B (Primary Call between A and B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Applications completes Transfer	CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Blind Transfer Scenario

Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B does lineBlindTransfer to C. A is connected to C.

Action	CTI Event	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B lineBlindTransfer to C	NewCallEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1

Redirect Scenario

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application redirects B to C; A is connected to C.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A , LineOpen on B with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B redirects call to C.C answers the call	NewCallEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1

Shared Line Scenario

Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000. A calls B, B'. B answers the call.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A , LineOpen on B, LineOpen on B' with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B NewCallEvent received for B'	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B' LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B'		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1

Shared Line Scenario with Barge

Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B, B'. B answers the call.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A , LineOpen on B, LineOpen on B' with new ExtVesrion 0x000A0000
A calls B, B'answers the call	NewCallEvent received for A NewCallEvent received for B NewCallEvent received for B'	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B' LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B'		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B' barges in	NewCallEvent received for B NewCallEvent received for B' CallGlobalCallHandleChangedEvent received for B	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2 For B' LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
	CallGlobalCallHandleChangedEvent received for B'	For B' LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
LineGetCallInfo on B'		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3

Call Park Scenario: Variation 1

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application initiates a CallPark on B. A is parked on parkedDn. C calls parkDn and C is connected to A

Service Parameter Preserve globalcallid For Parked Calls set to False

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Application initiates linepark on B
C dials parkDn	NewCallEvent received for C CallGlobalCallHandleChangedEvent received for A	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1 For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A2
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A2
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1

Call Park Scenario: Variation 2

Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application initiates a CallPark on B. A is parked on parkedDn. C calls parkDn and C is connected to A

Service Parameter Preserve globalcallid For Parked Calls set to True

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Application initiates linepark on B
C dials parkDn	NewCallEvent received for C CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

3- Party Conference Call Scenario

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up conference to C, C answers the call, and B completes conference. A, B and C are in conference.

---

Note For all conference scenarios, conference call leg's Unique Call Reference ID is 0.

---

Action	CTI Events	Expected Results
LineInitialize LineOpen on A , LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B setupConference to C	NewCallEvent received for B NewCallEvent received for C	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
LineGetCallInfo on B (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallnfo on C (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes conference	CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Three-party Conference Drop Down to Two-party Call Scenario

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up conference with C, C answers the call, and B completes conference. A,B and C in conference. C drops from the conference.A connected to B.

Action	CTI Events	Expected Results
LineInitialize Call lineNegotiateVersion with LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B setupConference to C	NewCallEvent received for B NewCallEvent received for C	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on B (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallnfo on C (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes conference	CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
C drops from conference
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1

Conference Chaining Scenario using Join

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A, B and C are in Conference1. C, D and E are in another Conference2. Application sends CallJoinRequest to join both the conference calls.

E drops from the conference.

Action	CTI Events	Expected Results
A, B and C are in conference		For A Unique Call Reference ID = ID1 For B Unique Call Reference ID = ID2 For C Unique Call Reference ID = ID3
C, D and E are in conference		For C Unique Call Reference ID = ID4 For D Unique Call Reference ID = ID5 For E Unique Call Reference ID = ID6
Application Joins two confeences		No change in Unique Call Reference ID after join
E drops from Conference	CallGlobalCallHandleChanged received for D	For D LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID1
LineGetCallnfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID
LineGetCallnfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID3
LineGetCallInfo on D		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID7

Transfer Call Scenario via QSIP without Path Replacement

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A in Cluster 1 calls B in Cluster 2, B answers the call, and B sets up transfer to C in Cluster 1. C answers the call and B completes the transfer. A connected to C.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C	NewCallEvent received for B NewCallEvent received for C	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on B (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call.B completes transfer.
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1

Transfer Call Scenario via QSIP with Path Replacement

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A in Cluster 1 calls B in Cluster 2, B answers the call and sets up transfer with C in Cluster 1. C answers the call amd B completes the transfer. A connected to C.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C	NewCallEvent received for B NewCallEvent received for C	For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on B (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C (Consultation Call between B and C)		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call.B completes transfer	CallGlobalCallHandleChangedEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Hunt List Scenario

LineGroup LG1,LG2 and LG3 configured with A,B and C. HuntList "Hunt_List" configured with Line Groups LG1,LG2 and LG3. Hunt Pilot "99999" configured with this "Hunt"List".

Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000. D calls `99999". Call is routed through A, B and C.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A , LineOpen on B, LineOpen on C, LineOpen on D with new ExtVesrion 0x000A0000
D calls Hunt Pilot DN.Call is first offered to Phone A, followed by B and then C.	NewCallEvent received for D NewCallEvent received for A NewCallEvent received for B NewCallEvent received for C	For D LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on D		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference D1
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1

Call Pickup Scenario: Variation 1

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000.

B and C in same Call Pickup Group. Service Parameter, Auto Call Pickup Enabled, is set to False. A calls B and C presses the NewCall softkey followed by Call Pickup softkey. Call is redirected to C.

Same Behaviour for Group Pickup.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
C presses NewCall softkey followed by Call Pickup softkey	NewCallEvent received for C NewCallEvent received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Call Pickup Scenario: Variation 2

Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000.

B and C are in the same Call Pickup Group. Service Parameter Auto Call Pickup Enabled is set to True. A calls B, C presses NewCall softkey followed by Call Pickup softkey, and call is redirected to C.

Same Behaviour for Group Pickup.

Action	CTI Events	Expected Results
LineInitialize LineOpen on A, LineOpen on B, LineOpen on C with new ExtVesrion 0x000A0000
A calls B	NewCallEvent received for A NewCallEvent received for B	For A LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For B LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
C presses NewCall softkey followed by Call Pickup softkey	NewCallEvent received for C CallGlobalCallHandleChanged received for C	For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0 For C LINE_CALLDEVSPECIFIC event is received dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO dwParam3 = 0
LineGetCallInfo on A		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C		LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2

Extension Mobility Cross Cluster

Common Configuration

•User A has a device profile EM_Profile1 configured with Line1 in Cluster1 (home cluster)

•CiscoTSP uses CTIManager on Cluster1 (home cluster) in order to open provider

TAPI Application does LineInitializeEx and EMCC User Logs in to a Device

Title	EMCC user logs in to a device
Description	Testing the scenario where TAPI Application does LineInitializeEx and EMCCUserLogin to a Device
Test Setup	EM_Profile1 is included in application control list DeviceH is not in application control list Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to DeviceH on Cluster1.
Expected Results	Step 2: Application receives LINE_CREATE for Line1

TAPI Application does LineInitializeEx and EMCCUser Logs Out of a Device

Title	EMCC user logs out of a device
Description	Tesing the scenario where TAPI Application does LineInitializeEx and EMCCUserLogs out of a Device
Test Setup	EM_Profile1 is included in application control list DeviceH is not in application control list Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM logout of a device DeviceH on Cluster1.
Expected Results	Step 2: Application receives LINE_REMOVE for Line1

Application does PhoneInitializeEx and EMCC User Logs in to a Device

Title	EMCC user logs in to a device
Description	Testing the scenario where TAPI Application does PhoneInitializeEx and EMCCUserLogin to a Device
Test Setup	EM_Profile1 is included in application control list DeviceH is not in application control list Step 1 Step1: Open the TAPI Application with User A and do PhoneInitializeEx. Step 2 Step2: User A EM login to DeviceH on Cluster1.
Expected Results	Step 2: Application receives PHONE_CREATE for Line1

TAPI Application does PhoneInitializeEx and EMCC User Logs out of a Device

Title	EMCC user logs out of a device
Description	Tesing the scenario where TAPI Application does PhoneInitializeEx and EMCCUserLogs out of a Device
Test Setup	EM_Profile1 is included in application control list DeviceH is not in application control list Step 1 Step1: Open the TAPI Application with User A and do PhoneInitializeEx. Step 2 Step2: User A EM logout of a device DeviceH on Cluster1.
Expected Results	Step 2: Application receives PHONE _REMOVE for Line1

EMCC User Logs in to a Device from Cluster 2 (Visiting Cluster)

Title	EMCC user logs in to a device from cluster 2 (visiting cluster)
Description	Testing the scenario where EMCCUser Login to a Device from cluster 2 (visiting cluster)
Test Setup	EM_Profile1 is included in application control list. Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A goes to the Cluster 2(visiting Cluster) and EM login to a device DeviceV.
Expected Results	Step 2: Application receives LINE_CREATE for Line1

EMCC User Logs out of a Device from Cluster 2 (Visiting Cluster)

Title	EMCC user logs out of a device from cluster 2 (visiting cluster)
Description	Testing the scenario where EMCCUser LogOut of a Device from cluster 2 (visiting cluster)
Test Setup	EM_Profile1 is included in application control list. Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 After the Execution of the above usecase User A EM logout of a device DeviceV.
Expected Results	Step 2: Application receives LINE_REMOVE for Line1

EMCC User Logs in to a Device with LineH Configured

Title	EMCC user logs in to a device with LineH configured
Description	Testing the scenario where EMCCUserLogin to a Device with LineH configured
Test Setup	EM_Profile1 is included in application control list DeviceH is included in application control list with LineH configured Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to a device DeviceH on Cluster1.
Expected Results	Step 2: •Application receives LINE_REMOVE for LineH •Application receives LINE_CREATE for Line1

EMCC User Logs out of a Device with LineH Configured

Title	EMCC user logs out of a device
Description	Testing the scenario where EMCCUserLogs out of a Device
Test Setup	EM_Profile1 is included in application control list DeviceH is included in application control list with LineH configured Step 1 After the Execution of the above usecase User A EM logout of a device DeviceH on Cluster1.
Expected Results	Step 2: •Application receives LINE_REMOVE for Line1 •Application receives LINE_CREATE for LineH

EMCC User Logs in to a DeviceH Configured for Multiple Lines (LineH)

Title	EMCC user logs in to a DeviceH
Description	Testing the scenario where EMCCUser Login to a DeviceH which is configured for multiple lines
Test Setup	EM_Profile1 is included in application control list Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A goes to the Cluster 2(visiting Cluster) and EM login to a device DeviceH(A device with multiple lines (LineH)).
Expected Results	Step 2: •Application receives 2 LINE_REMOVE for LineH •Application receives LINE_CREATE for Line1

EMCC User Logs in to a Device with LineH Configured and Administrator Removes the Device from Application Control list

Title	EMCC user logs in to a device with LineH configured and the administrator removes the device from the Application Control list
Description	Testing the scenario where EMCCUserLogin to a device with LineH configured and administrator removes the device from the Application Control list
Test Setup	EM_Profile1 is included in application control list DeviceH is included in application control list with LineH configured Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to a device DeviceH on Cluster1. Step 3 Administrator removes the DeviceH from application control list.
Expected Results	Step 2: •Application receives LINE_REMOVE for LineH •Application receives LINE_CREATE for Line1 Step3: •Application will not receive any events.

EMCC User Logs in and out of a Device with LineH Configured and Administrator Removes the Device from Application Control List

Title	EMCC user logs in and logs out of a device with LineH configured and Administrator removes the device from the Application Control List
Description	Testing the scenario where EMCCUserLogin to a Device with LineH configured and Administrator removes the device from the Application Control List
Test Setup	EM_Profile1 is included in application control list DeviceH is included in application control list with LineH configured Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to a device DeviceH on Cluster1. Step 3 User A EM logout of the device DeviceH on Cluster1. Step 4 Administrator removes the DeviceH from application control list.
Expected Results	Step 2: •Application receives LINE_REMOVE for LineH •Application receives LINE_CREATE for Line1 Step3: •Application receives LINE_REMOVE for Line1 •Application receives LINE_CREATE for LineH Step4: •Application receives LINE_REMOVE for LineH

EMCC User Logs in to a Device with LineH Configured and EM_Profile not Included in Application Control List

Title	EMCC user logs in to a device with LineH configured and administrator removes the device from the Application Control list
Description	Testing the scenario where EMCCUserLogin to a device with LineH configured and administrator removes the device from the Application Control list
Test Setup	EM_Profile1 is not included in Application Control list DeviceH is included in Application Control list with LineH configured Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to a device DeviceH on Cluster1. Step 3 Administrator removes the DeviceH from application control list. Step 4 User A EM logout of the device DeviceH on Cluster1.
Expected Results	Step 2: •Application receives LINE_REMOVE for LineH •Application receives LINE_CREATE for Line1 Step3: •Application receives no events since EM_Profile1 is not in control list. Step4: •Application receives LINE_REMOVE for LineH

EMCC User Logs in to a DeviceV and EM_Profile is Removed by Administrator from Application Control List

Title	EMCC user logs in to a DeviceV and administrator removes the EM_Profile from the Application Control list
Description	Testing the scenario where EMCCUserLogin to a DeviceV and administrator removes the EM_Profile from Application Control list
Test Setup	EM_Profile1 is included in Application Control list. Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User A EM login to a DeviceV (Visiting Device). Step 3 Administrator removes the EM_Profile1 from application control list.
Expected Results	Step 2: •Application receives LINE_CREATE for Line1 Step3: •Application receives LINE_REMOVE for Line1

EMCC User Logs in to a Device then Application does Provider Open

Title	EMCC user logs in to a DeviceV
Description	Testing the scenario where EMCCUserLogin to a DeviceV(cluster2). Then the application does Provider Open
Test Setup	EM_Profile1 is included in Application Control list DeviceH is not in Application Control list Step 1 User A EM login to DeviceV on Cluster2. Step 2 Open the TAPI Application with User A and do LineInitializeEx.
Expected Results	Step2: •DeviceV/Line1 will be included in TAPI device/line enumeration

EMCC User Log in to a DeviceV in Visting Cluster and Administrator Adds the EM_Profile to Application Control List

Title	EMCC user logs in to a DeviceV in Visting cluster and administrator adds the EM_Profile to the Application Control List
Description	Testing the scenario where EMCCUserLogin to a DeviceV in Visting cluster and Administrator adds the EM_Profile to the Application Control list
Test Setup	EM_Profile1 is not included in Application Control list Step 1 Open the TAPI Application with User A and do LineInitializeEx. Step 2 User B EM login to a DeviceV on Cluster2. Step 3 Administrator Adds the EM_Profile1 to the application control list.
Expected Results	Step 2: •Application will not receive any events as EM_Profile1 not in the Application Control list. Step3: •Application receives LINE_CREATE for Line1

External Call Control

Basic Call Initiated from TAPI with External Call Control on Translation Pattern and CEPM Returns Reject

Configuration

Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.

Procedure

Application sends a lineMakeCall at A to call B.

Result

Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns Reject.

Party	TSP Message to App data
A initiates Call to B A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = "" mod Calling = A / mod Called = ""
A receives CallStateChangeEvent (Disconnect)	A: LINE_CALLSTATE (LINECALLSTATE_DISCONNECTED, LINEDISCONNECTMODE_REJECT) CallerID = A / CalledID = "" mod Calling = A / mod Called = ""

Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Divert with Modified Calling and Called Parties

Configuration

Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.

Procedure

Application sends a lineMakeCall at A to call B.

Result

Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.

CEPM returns divertTo=C, with ModifiedCalling= MA and ModifiedCalled = MB

Call will be extended to C (modified calling and modified called in divertTo routing directive, overrides the calling and called number transformation configured for translation pattern and the call is diverted to C)

Party	TSP Message to App data
A initiates call to B A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = "" mod Calling = A / mod Called = ""
A receives CallStateChangeEvent (Proceeding)	A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallerID = A / CalledID = B1 mod Calling = A1 / mod Called = B1
A receives CallStateChangeEvent (RingBack) C receives NewCallEvent	A: LINE_CALLSTATE (LINECALLSTATE_RINGBACK)/ LINE_CALLINFO CallerID = A / CalledID = B1 / RedirectingID = MB / RedirectionID = C mod Calling = MA / mod Called = B1 / mod Redirecting = MB / mod Redirection = C C: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED dwReason = LINECALLREASON_UNKNOWN extendCallReason = CtiReasonCallIntercept CallerID = A / CalledID = MB / RedirectingID = MB / RedirectionID = C mod Calling = MA / mod Called = MB / mod Redirecting = MB / mod Redirection = C
C answers A and C receives Connected Call state	A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B1 / ConnectedID = C / RedirectingID = MB / RedirectionID = C mod Calling = MA / mod Called = B1 / mod Connected = C / mod Redirecting = MB / mod Redirection = C C: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED CallerID = A / CalledID = MB / ConnectedID = A / RedirectingID = MB / RedirectionID = C mod Calling = MA / mod Called = MB / mod Connected = MA / mod Redirecting = MB / mod Redirection = C

Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties

Configuration

Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.

Procedure

Application sends a lineMakeCall at A to call B.

Result

Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.

CEPM returns continue with ModifiedCalling= MA and ModifiedCalled = MB

Call will be extended to MB (modified calling and modified called in continue routing directive, overrides the calling & called number transformation configured for translation pattern)

Party	TSP Message to App Data
A initiates Call to B A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = "" mod Calling = A / mod Called = ""
A receives CallStateChangeEvent (Proceeding)	A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallerID = A / CalledID = B1 mod Calling = A1 / mod Called = B1
A receives CallStateChangeEvent (RingBack) MB receives NewCallEvent	A: LINE_CALLSTATE (LINECALLSTATE_RINGBACK)/ LINE_CALLINFO CallerID = A / CalledID = B1 mod Calling = MA / mod Called = B1 MB: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED CallerID = A / CalledID = MB mod Calling = MA / mod Called = MB
MB answers A and MB receives Connected Call state	A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B1 / ConnectedID = MB mod Calling = MA / mod Called = B1 / mod Connected = MB MB: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = MB / ConnectedID = A mod Calling = MA / mod Called = MB / mod Connected = MA

Conference Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties in the Consult Call

Configuration

Phone A, B, C are in cluster devices.

C matches the translation pattern CXXX which has calling and called party transformation defined to transform B to A1 and C to C1 and External Call Control is also enabled.

Procedure

Application sends a lineMakeCall at A to call B. Application sends a lineSetupConference/lineAddToconference to B to consult conference the call to C.

Result

Dialed number C matches the translation pattern CXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.

CEPM returns continue with ModifiedCalling= MB and ModifiedCalled = MC

Call will be extended to "MC" (modified calling and modified called in continue routing directive, overrides the calling & called number transformation configured for translation pattern)

After conference is complete, the correct number of CONFERENCE calls are see at all the participants.

Party	TSP Message to App Data
A and B receives Connected Call state	A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B / ConnectedID = B mod Calling = A / mod Called = B / mod Connected = B B: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B / ConnectedID = A mod Calling = A / mod Called = B / mod Connected = A
B does a lineSetupConference / lineDial to call C. MC receives NewCallEvent	B: Call-1 LINE_CALLSTATE (LINECALLSTATE_ONHOLDPENDCONF) CallerID = A / CalledID = B / ConnectedID = A mod Calling = A / mod Called = B / mod Connected = A Call-2 LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallerID = B / CalledID = C1 mod Calling = MB / mod Called = C1 MC: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED) CallerID = B / CalledID = MC mod Calling = MB / mod Called = MC
MC answers the call	B: Call-2 LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = B / CalledID = C1 / ConnectedID = MC mod Calling = MB / mod Called = C1 / mod Connected = MC MC: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = B / CalledID = MC / ConnectedID = B mod Calling = MB / mod Called = MC / mod Connected = MB
B1 does a lineAddToConference	A: CONFERENCE CallerID = A / CalledID = B / ConnectedID = B mod Calling = A / mod Called = B / mod Connected = B CONNECTED CONFERENCE CallerID = A / CalledID = MC / ConnectedID = MC mod Calling = A / mod Called = MC / mod Connected = MC B: CONFERENCE CallerID = A / CalledID = B / ConnectedID = A mod Calling = A / mod Called = B / mod Connected = A CONNECTED CONFERENCE CallerID = B / CalledID = C1 / ConnectedID = MC mod Calling = B/ mod Called = C1 / mod Connected = MC MC: CONFERENCE CallerID = B / CalledID = MC / ConnectedID = B mod Calling = B / mod Called = MC / mod Connected = B CONNECTED CONFERENCE CallerID = MC / CalledID = A / ConnectedID = A mod Calling = MC / mod Called = A / mod Connected = A

Call is Redirected to a Hunt List of Chaperones and Chaperone Enables Call Recording and Conferences in the Called Party

Configuration

Phone A, C1, D are in cluster devices. B matches the translation pattern BXXX where External Call Control is enabled. Application sends a lineMakeCall at A to call B.

CEPM determines this calls need to have a chaperone's supervise. CEPM returns the permit decision with the obligation <divert>, destination HuntPilot C, which is a hunt pilot of chaperones, and a reason string "chaperone".

CUCM redirects the call to the hunt pilot C, and the chaperone member C1 answers the call.

After talking to A briefly and discovered that A intended to talk to D, the chaperone C1 starts to establish a conference to D. C1 presses the conference softkey and dials D.

CUCM queries CEPM for the call, with calling user C1 with DN C1, and called user D with DN D.

CEPM returns the response with permit decision with <continue> call routing directive, since the policy server detects that the caller is the chaperone.

CUCM rings D's phone and D answers the call.

C1 presses the conference softkey again, and the conference is established.

The chaperone C1 presses the "record" softkey. This triggers the call recording being setup from C1's IP phone to the recorder.

When the call recording is eablished successfully, the recording warning tone is playing to the C1's phone. The recording warning tone is enabled by setting service parameter Play Recording Notification Tone To Observed Target to True.

A and D starts to talk under the supervision of the chaperone.

Party	TSP Message to App Data
A initiates Call to B A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)	A: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_DIALTONE/ LINECALLSTATE_DIALING) CallerID = A / CalledID = "" mod Calling = A / mod Called = ""
A receives CallStateChangeEvent (Proceeding) webmail	A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallerID = A / CalledID = B mod Calling = A / mod Called = B
A receives CallStateChangeEvent (RingBack) C1 receives NewCallEvent	A: LINE_CALLSTATE (LINECALLSTATE_RINGBACK)/ LINE_CALLINFO CallerID = A / CalledID = B / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Redirecting = B / mod Redirection = C C1: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED CallerID = A / CalledID = B / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Redirecting = B / mod Redirection = C LINECALLINFO::DEVSPECIFIC would contain IsChaperoneCall = 0x1
C1 answers A and C1 receives Connected Call state	A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B / ConnectedID = C / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Redirecting = B / mod Connected = B / mod Redirection = C C1: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = A / CalledID = B / ConnectedID = C / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Redirecting = B / mod Connected = B / mod Redirection = C
Application issues a lineRedirect on call at C1	Line_Reply is returned with an error code of LINEERR_OPERATION_FAIL_CHAPERONE_DEVICE
C1 does a lineSetupConference / lineDial to call D. D receives NewCallEvent	C1: Call-1 LINE_CALLSTATE (LINECALLSTATE_ONHOLDPENDCONF) CallerID = A / CalledID = B / ConnectedID = A / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Connected = A / mod Redirecting = B / mod Redirection = C CONNECTED LINECALLINFO::DEVSPECIFIC would contain IsChaperoneCall = 0x1 Call-2 LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)/ LINE_CALLINFO CallerID = C1 / CalledID = D mod Calling = C1 / mod Called = D D: LINE_APPNEWCALL, LINE_CALLSTATE (LINECALLSTATE_OFFERING/ LINECALLSTATE_ACCEPTED) CallerID = C1 / CalledID = D mod Calling = C1 / mod Called = D
D answers the call	C1: Call-2 LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = C1 / CalledID = D / ConnectedID = D mod Calling = C1 / mod Called = D / mod Connected = D D: LINE_CALLSTATE (LINECALLSTATE_CONNECTED) CallerID = C1 / CalledID = D / ConnectedID = C1 mod Calling = C1 / mod Called = D / mod Connected = C1
C1 does a lineAddToConference	A: CONFERENCE CallerID = A / CalledID = B / ConnectedID = C / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Redirecting = B / mod Connected = C / mod Redirection = C CONNECTED CONFERENCE CallerID = A / CalledID = D / ConnectedID = D mod Calling = A / mod Called = D / mod Connected = D C1: CONFERENCE CallerID = A / CalledID = B / ConnectedID = A / RedirectingID = B / RedirectionID = C mod Calling = A / mod Called = B / mod Connected = A / mod Redirecting = B / mod Redirection = C CONNECTED LINECALLINFO::DEVSPECIFIC would contain IsChaperoneCall = 0x1 CONFERENCE CallerID = C / CalledID = D / ConnectedID = D mod Calling = C / mod Called = D / mod Connected = D D: CONFERENCE CallerID = C / CalledID = D / ConnectedID = C mod Calling = C / mod Called = D / mod Connected = C CONNECTED CONFERENCE CallerID = D / CalledID = A / ConnectedID = A mod Calling = D / mod Called = A / mod Connected = A
Chaperone C1 starts recording to recording device R	C1: LINE_DEVSPECIFIC(SLDSMT_RECORDING_STARTED, 0, 0) LINE_DEVSPECIFIC(SLDSMT_LINECALLINFO_DEVSPECIFICDATA, SLDST_CALL_ATTRIBUTE_INFO, 0) CallAttributeTye = `Recording' C1's CCMCallId Address = R's DN, Partition = R's Partition, DeviceName = R's DeviceName

Forced Authorization and Client Matter Code Scenarios

Manual Call to a Destination that Requires an FAC

Table A-9 describes the message sequences for the Forced Authorization and Client Matter Code scenario of Manual Call to a Destination that requires an FAC.

Preconditions

Party A is Idle. Party B requires an FAC.

The scenario remains similar if Party B requires a CMC instead of an FAC.

Table A-9 Message Sequences for Manual Call to a Destination that Requires an FAC 

Actions	CTI Message	TAPI Messages	TAPI Structures
Party A goes off-hook	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_APPNEWCALL hDevice=A dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALTONE dwParam2=UNAVAIL dwParam3=0	No change
Party A dials Party B	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=True, CMCRequired=False	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_FACREQUIRED	No change
Party A dials the FAC, and Party B accepts the call	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change

Manual Call to a Destination that Requires both FAC and CMC

Table A-10 describes the message sequences for the Forced Authorization and Client Matter Code scenario of a manual call to a destination that requires both FAC and CMC.

Preconditions

Party A is Idle. Party B requires an FAC and a CMC.

Table A-10 Message Sequences for Manual Call to a Destination that Requires both FAC and CMC 

Actions	CTI Message	TAPI Messages	TAPI Structures
Party A goes off-hook	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_APPNEWCALL hDevice=A dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALTONE dwParam2=UNAVAIL dwParam3=0	No change
Party A dials Party B	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=True, CMCRequired=True	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_FACREQUIRED, CZIPZIP_CMCREQUIRED	No change
Party A dials the FAC	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=False, CMCRequired=True	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_CMCREQUIRED	No change
Party A dials the CMC, and Party B accepts the call	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change

lineMakeCall to a Destination that Requires an FAC

Table A-11 describes the message sequences for the Forced Authorization and Client Matter Code scenario of lineMakeCall to a destination that requires an FAC.

Preconditions

Party A is Idle. Party B requires an FAC. Note that the scenario is similar if Party requires a CMC instead of an FAC.

Table A-11 Message Sequences for lineMakeCall to a Destination that Requires an FAC 

Actions	CTI Message	TAPI Messages	TAPI Structures
Party A does a lineMakeCall() to Party B	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=ORIGIN dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1= REASON, CALLERID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=True, CMCRequired=False	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_FACREQUIRED	No change
Party A does a lineDial() with the FAC in the dial string and Party B accepts the call	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change

lineMakeCall to a Destination that Requires Both FAC and CMC

Table A-12 describes the message sequences for the Forced Authorization and Client Matter Code scenario of lineMakeCall to a destination that requires both FAC and CMC. In this scenario, Party A is Idle and Party B requires both an FAC and a CMC.

Table A-12 Message Sequences for lineMakeCall to a Destination that Requires Both FAC and CMC 

Actions	CTI Message	TAPI Messages	TAPI Structures
Party A does a lineMakeCall() to Party B	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=ORIGIN dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1= REASON, CALLERID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=True, CMCRequired=True	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_FACREQUIRED, CZIPZIP_CMCREQUIRED	No change
Party A does a lineDial() with the FAC in the dial string	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=False, CMCRequired=True	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_CMCREQUIRED	No change
Party A does a lineDial() with the CMC in the dial string and Party B accepts the call	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change

Timeout Waiting for FAC or Invalid FAC

Table A-13 describes the message sequences for the Forced Authorization and Client Matter Code scenario of timeout waiting for FAC or invalid FAC entered. Here, Party A is Idle and Party B requires an FAC.

The scenario remains similar if Party B required a CMC instead of a FAC.

Table A-13 Message Sequences for Timeout Waiting for FAC or Invalid FAC

Actions	CTI Message	TAPI Messages	TAPI Structures
Party A does a lineMakeCall() to Party B	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=ORIGIN dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1= REASON, CALLERID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	CallToneChangedEvent, CH=C1, Tone=ZipZip, Feature=FACCMC, FACRequired=True, CMCRequired=False	LINE_DEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1=SLDSMT_CALL_TONE_CHANGED dwParam2=CTONE_ZIPZIP dwParam3= CZIPZIP_FACREQUIRED	No change
T302 timer times out waiting for digits, or Party A does a lineDial() with an invalid FAC	CallStateChangedEvent, CH=C1, State=Disconnected, Cause= CtiNoRouteToDDestination, Reason=FACCMC, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DISCONNECTED dwParam2=DISCONNECT MODE_FACCMC1 dwParam3=0	No change
	CallStateChangedEvent, CH=C1, State=Idle, Cause=CtiCauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=IDLE dwParam2=0 dwParam3=0	No change

1 dwParam2 get set to DISCONNECTMODE_FACCMC if the extension version on the line is set to at least 0x00050000. Otherwise, dwParam2 get set to DISCONNECTMODE_UNAVAIL.

Hunt List

Phones - A, B, C and X

Hunt Pilots: HP1

Member LG1, LG2, LG3

HP2.

Member LG11, LG12, LG13 are CTI port

Pickup Group1 : has LG1, lG2, LG3, X

Pickup Group2: has HP1, X

TSP app opens all lines, otherwise will be stated in use case.

Basic Hunt List Call

Table A-14 Message Sequence for Basic Hunt List Call 

Action	Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1 HuntPilot = HP1
LG1 answers the call	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG2 answers the call	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG2 HuntPilot = HP1 At LG2: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
Variance : perform the test with all HuntList algorithm Top-Down algorithm Circular algorithm Longest Idle Time algorithm

Hunt List Call Moved to Next Member

Table A-15 Message Sequence for Hunt List Call Moved to Next Member 

Action	Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, Called Name = HP1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call moves from LG1 to LG2	Call at LG1 goes IDLE At LG2: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
LG2 answers the call	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG2 HuntPilot = HP1 At LG2: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A

Hunt List Calls FWNA and FWNA is not Configured on HuntPilot

Table A-16 Message Sequence for Hunt List Calls FWNA and FWNA is not Configured on HuntPilot 

Action	Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call moves from LG1 to LG2	Call at LG1 goes IDLE At LG2: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call moves from LG2 to LG3	Call at LG2 goes IDLE At LG3: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call is aborted since LG3 does not answer the call.	At A: call will go IDLE LINEDISCONNECTMODE_NOANSWER? At LG3: call will go IDLE LINEDISCONNECTMODE_NOANSWER ?

Hunt List Call FWNA with FWNA to B

Table A-17 Message Sequence for Hunt List Call FWNA with FWNA to B 

Action	Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call moves from LG1 to LG2	Call at LG1 goes IDLE At LG2: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call moves from LG2 to LG3	Call at LG2 goes IDLE At LG3: LINE_CALLSTATE - ACCEPTED Caller = A, Called = HP1, HuntPilot = HP1
Call is FWNA to B, and B answer	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connectedid = B At LG3: call will go IDLE At B: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A Redirecting = HP1 Redirection = B

Hunt List Call Dropped when Hunt List is Busy and FWB is not Configured

Table A-18 Message Sequence for Hunt List Call Dropped when Hunt List is Busy and FWB is not Configured

Action	Events, Requests and Responses
Make LG1, LG2, LG3 busy App initiates call from A to HP1	At A: Call disconnected after it is initiated. LINEDISCONNECTMODE_BUSY

Hunt List Call is Forwarded when Hunt List is Busy and FWB is Configured to B

Table A-19 Message Sequence for Hunt List Call is Forwarded when Hunt List is Busy and FWB is Configured to B

Action	Events, Requests and Responses
Make LG1, LG2, LG3 busy App initiates call from A to HP1 and the call is forwarded to B	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, Called Name = HP1 HuntPilot = HP1 At B: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1 Redirecting = HP1 Redirection = B

HuntList Call Redirected when in ACCEPT State

Table A-20 Message Sequence for HuntList Call Redirected when in ACCEPT State

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1
LG1 redirects call to B	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: Call goes IDLE At B: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1 RedirectingID = HP1 RedirectionID = B

Hunt List Call Redirected when in Connected State

Table A-21 Message Sequence for Hunt List Call Redirected when in Connected State 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1
LG1 answers the call	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 redirects call to B	At A : LINE_CALLSTATE - RINGBACK Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 RedirectingID = LG1 RedirectionID = B At LG1: Call goes IDLE At B: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1 RedirectingID = LG1 RedirectionID = B

Hunt List Call - Member is CTI or RP Port

Table A-22 Message Sequence for Hunt List Call - Member is CTI or RP Port

Action	Events, Requests and Responses
Same as 8.1, but with CTI port	Similar expectation

Hunt List Call Moved to Different Line Group Members and Answered by CTI Port

Table A-23 Message Sequence for Hunt List Call Moved to Different Line Group Members and Answered by CTI Port

Action	Events, Requests and Responses
Same as 8.2, but with CTI port	Similar expectation

Hunt List Call is Redirected to Another Hunt List

Table A-24 Message Sequence for Hunt List Call is Redirected to Another Hunt List 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
A redirects the call to HP2 and call offered to LG11	At A: Call goes IDLE At LG1: LINE_CALLSTATE - RINGBACK Caller = LG1 HuntPilot = HP1 Called = HP1 HuntPilot = HP1 RedirectionID = HP2 RedirectingID = A At LG11: LINE_CALLSTATE - ACCEPTED Caller = LG1 HuntPilot = HP1 Called = HP2, HuntPilot = HP2 RedirectionID = HP2 RedirectingID = A
LG11 answers the call	At LG1: LINE_CALLSTATE - CONNECTED Caller = LG1 HuntPilot = HP1 Called = HP1 HuntPilot = HP1 Connected = LG11 HuntPilot = HP2 RedirectingID = A RedirectionID =HP2 At LG11: LINE_CALLSTATE - OFFERING Caller = LG1 HuntPilot = HP1 Called = HP2, HuntPilot = HP2 Connected = LG1 HuntPilot = HP1 RedirectionID = HP2 RedirectingID = A

Hunt List Call is Consult Transferred to Another Line

Table A-25 Message Sequence for Hunt List Call is Consult Transferred to Another Line 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup transfer to B, B answer	At LG1 Call-1 is put on HOLD Call-2 LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = LG1
LG1 completes transfer	At A : LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = B RedirectionID = B RedirectingID = LG1 At LG1: both call goes IDLE At B: LINE_CALLSTATE - CONNECTED Caller = A Called = B Connected = A RedirectionID = B RedirectingID = LG1

Hunt List Call Direct Transferred to Another Line

Table A-26 Message Sequence for Hunt List Call Direct Transferred to Another Line 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1
LG1 calls to B, B answer	At LG1 Call-1 is put on HOLD Call-2 LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B
LG1 performs Direct Transfer	At A : LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = B RedirectionID = B RedirectingID = LG1 At LG1: both call goes IDLE At B: LINE_CALLSTATE - CONNECTED Caller = A Called = B Connected = A RedirectionID = B RedirectingID = LG1

Hunt List Call is Conferenced to Another Line

Table A-27 Message Sequence for Hunt List Call is Conferenced to Another Line 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to B, B answers the call	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONNECTED Caller = LG1 Called = B Connected = B At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = B Connected = B At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B At B: CONNECTED CONFERENCED Caller = LG1 Called = B Connected = LG1 CONFERECED Caller = B Called = A Connected = A

Hunt List Call is Joined to Another Line

Table A-28 Message Sequence for Hunt List Call is Joined to Another Line 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 calls B, B answers the call	At LG1 Call-1: ONHOLD Caller = A Called = HP1 HuntPilot = HP1 Connected = A Call-2: CONNECTED Caller = LG1 Called = B Connected = B At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B
LG1 performs Join	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = B Connected = B At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B At B: CONNECTED CONFERENCED Caller = LG1 Called = B Connected = LG1 CONFERECED Caller = B Called = A Connected = A

Hunt List Call is Conferenced to Another Hunt List after LG11 Answers

Table A-29 Message Sequence for Hunt List Call is Conferenced to Another Hunt List after LG11 Answers 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2 At LG11: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG1 HuntPilot = HG1
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = HP2 ->LG11 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2 At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2
	At LG11: CONNECTED CONFERECED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG1 HuntPilot = HG1 HP name =- empty CONFERECED Caller = LG11 Called = A Connected = A

Hunt List Call Conferenced to the Same Hunt List and Completes Conference Before Hunt List Agent Answers

Table A-30 Message Sequence for Hunt List Call Conferenced to the Same Hunt List and Completes Conference Before Hunt List Agent Answers 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to HG1, where alerting on LG2,	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A RINGBACK Caller = LG1 Called = HP1 HuntPilot = HP1 At LG2: LINE_CALLSTATE - ACCEPTED Caller = LG1 Called = HP2 HuntPilot = HP2
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = HP1 HuntPilot = HP1 At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = HP1 HuntPilot = HP1 Connected = HP1 HuntPilot = HP1
	At LG2: ACCEPTED CONFERECED Caller = LG1 Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HG1 CONFERECED Caller = LG2 Called = A Connected = A
LG2 answers the call	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 Called Name = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG2 ConnectedName = LG2 HuntPilot = HP1 At LG1: CONNECTED CONFERECED Caller = A Called = HP1 Connected = A CONFERENCED Caller = LG1 Called = HP1 HuntPilot = HP1 Connected = LG2 HuntPilot = HP1 Called = A Connected = A
	At LG2: CONNECTED CONFERECED Caller = LG1 Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HG1 CONFERECED Caller = LG11

Hunt List Basic Call with SharedLine

LG1' is sharedline with LG1

Table A-31 Message Sequence for Hunt List Basic Call with SharedLine

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A At LG1': LINE_CALLSTATE - CONNECTED INACTIVE Caller = A Called = HP1 HuntPilot = HP1 Connected = A

Hunt List Basic Call with DND-R Configured on LG1

Table A-32 Message Sequence for Hunt List Basic Call with DND-R Configured on LG1

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG2 since LG1 has DND enabled.. Then LG2 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG2 HuntPilot = HP1 At LG2: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A

Hunt List Call Put in Conference via Join Operation

Table A-33 Message Sequence for Hunt List Call Put in Conference via Join Operation 

Action	Events, Requests and Responses
B calls A, A answer	At A: Call-1 LINE_CALLSTATE - CONNECTED Caller = B Called = A Connected = B At G: LINE_CALLSTATE - CONNECTED Caller = B Called = A Connected = A
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: Call-1 is on HOLD Call-2 LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
Application initiates JOIN calls on A with final call as call-1	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = B Called = A Connected = B At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B At B: CONNECTED CONFERENCED Caller = B Called = A Connected = A CONFERECED Caller = B Called = LG1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1

Hunt List Call is Picked up from Pickup Group - G-Pickup, Auto Pick Pp is Enabled

Table A-34 Message Sequence for Hunt List Call is Picked up from Pickup Group - G-Pickup, Auto Pick Pp is Enabled 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1
Line X got notification of the call	Got call pickup notification of call offering at LG1
Line X does group pick from LG1	At A: LINE_CALLSTATE - CONNECTED Caller = X Called = HP1, HuntPilot = HP1 ConnectedID = X At X: LINE_CALLSTATE - PROCEEDING Caller = X Called = PickGroup# LINE_CALLSTATE - CONNECTED Caller = X Called = PickGroup#, ConnectedID = A

Hunt List Call is Picked Up from Pickup Group when LG1 is in Pickup Group 1 - Auto Pickup Disabled

Table A-35 Message Sequence for Hunt List Call is Picked Up from Pickup Group when LG1 is in Pickup Group 1 - Auto Pickup Disabled 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1
Line X got notification of the call	Got call pickup notification of call offering at LG1
Line X does group pick from LG1	Original pickup call goes IDLE
X got server call about the pickup call	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1, HuntPilot = HP1 ConnectedID = X At X: new call offered at X from server, and answer LINE_CALLSTATE - CONNECTED Caller = A Called = X ConnectedID = A

Hunt List Call is Picked Up from Pickup Group when HP2 is in Pickup Group 2 - Auto Pick Up Enabled

Table A-36 Message Sequence for Hunt List Call is Picked Up from Pickup Group when HP2 is in Pickup Group 2 - Auto Pick Up Enabled

Action	Events, Requests and Responses
App initiates call from A to HP2 and the call is offered at LG11	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP2, HuntPilot = HP2 At LG11: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP2, HuntPilot = HP2
Line X got notification of the call	Got call pickup notification of call offering at HP2
Line X does group pick from HP2	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP2, HuntPilot = HP2 ConnectedID = X At X: LINE_CALLSTATE - CONNECTED Caller = X Called = PickGroup#, ConnectedID = A

Conferenced Hunt List Call Becomes Two-party Call

Table A-37 Message Sequence for Conferenced Hunt List Call Becomes Two-party Call 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2 At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 Called Name = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = LG11 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2 At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2
	At LG11: CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2 CONFERECED Caller = LG11 Called = A Connected = A
LG11 drops call	At A: Conf Parent call goes IDLE CONFERENCED call to LG11 goes IDLE CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: Conf Parent call goes IDLE CONFERENCED call to LG11 goes IDLE CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A At LG11: Calls go IDLE

Hunt List Broadcast Scenario (Broadcast Option is Configured on HP1)

Table A-38 Message Sequence for Hunt List Broadcast Scenario (Broadcast Option is Configured on HP1)

Action	Events, Requests and Responses
App initiates call from A to HP1, and call is offered at LG1, LG2 and LG3	At A: LINE_CALLSTATE - RINGBACK Caller = A Called = HP1, HuntPilot = HP1 At LG1: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1 At LG2: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1 At LG3: LINE_CALLSTATE - ACCEPTED Caller = A Called = HP1, HuntPilot = HP1

---

Note HP Broadcast is not supported when interacting with Call PickUp feature.

---

Hunt List Call is Involved in c-Barge Conference

LG1' is sharedline with LG1

Table A-39 Message Sequence for Hunt List Call is Involved in c-Barge Conference 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A At LG1': LINE_CALLSTATE - CONNECTED INACTIVE Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to B, B answers the call	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONNECTED Caller = LG1 Called = B Connected = B At LG1': LINE_CALLSTATE - CONNECTED INACTIVE Caller = A Called = HP1 HuntPilot = HP1 Connected = A LINE_CALLSTATE - CONNECTED INACTIVE CONNECTED Caller = LG1 Called = B Connected = B At B: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = B Connected = B
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = B Called Name = B Connected = B Called Name = B At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B
	At LG1': CONNECTED INACTIVE CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B At B: CONNECTED CONFERENCED Caller = LG1 Called = B Connected = LG1 CONFERECED Caller = B Called = A Connected = A
LG1' cBarges in	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = B Connected = B CONFERENCED Caller = A Called = LG1' Connected = LG1' At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = LG1 Called = B Connected = B CONFERENCED Caller = LG1 Called = LG1' Connected = LG1'
	CONNECTED INACTIVE CONFERECED Caller = LG1' Called = LG1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = LG1' Called = B Connected = B CONFERENCED Caller = LG1' Called = A Connected = A At LG1': CONNECTED CONFERECED Caller = LG1' Called = LG1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = LG1' Called = B Connected = B CONFERENCED Caller = LG1' Called = A Connected = A CONNECTED INACTIVE
	CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERENCED Caller = LG1 Called = B Connected = B CONFERENCED Caller = LG1 Called = LG1' Connected = LG1' At B: CONNECTED CONFERENCED Caller = LG1 Called = B Connected = LG1 CONFERECED Caller = B Called = A Connected = A CONFERENCED Caller = B Called = LG1' Connected = LG1'

Hunt List Feature Interact with Four-Party Conference

Table A-40 Message Sequence for Hunt List Feature Interact with Four-Party Conference 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call	At LG1 ONHOLDPENDINGCONF CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONNECTED Caller = LG1 Called = LG11 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2 At LG11: LINE_CALLSTATE - CONNECTED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG1 HuntPilot = HG1
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = HG2 Connected = LG11 HuntPilot = HP2 At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERECED Caller = LG1 Called = HP2 Connected = LG11 HuntPilot = HP2 At LG11: CONNECTED CONFERECED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG2
	CONFERECED Caller = LG11 Called = A Connected = A
LG1 setup conference to X, X answers the call	At LG1: ONHOLDPENDINGCONFERENCE CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERECED Caller = LG1 Called = HP2 Connected = LG11 HuntPilot = HP2 CONNECTED Caller = LG1 Called = X Connected = X At X: CONNECTED Caller = LG1 Called = X Connected = LG1
LG1 completes conference	At A: CONNECTED CONFERENCED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 CONFERENCED Caller = A Called = LG11 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2 CONFERENCED Caller = A Called = X Connected = X At LG1: CONNECTED CONFERECED Caller = A Called = HP1 HuntPilot = HP1 Connected = A CONFERECED Caller = LG1 Called = HP2 Connected = LG11 HuntPilot = HP2 CONFERENCED Caller = LG1 Called = X Connected = X
	At LG11: CONNECTED CONFERECED Caller = LG1 Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HG1 CONFERECED Caller = LG11 Called = A Connected = A CONFERENCED Caller = LG11 Called = X Connected = X

Caller Consult Transfer Call to Another Hunt List

Table A-41 Message Sequence for Caller Consult Transfer Call to Another Hunt List 

Action	Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers	At A: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = LG1 HuntPilot = HP1 At LG1: LINE_CALLSTATE - CONNECTED Caller = A Called = HP1 HuntPilot = HP1 Connected = A
A setup transfer to HP2, offered at LG11, LG11 anwser	At A Call-1 is put on HOLD Call-2 LINE_CALLSTATE - CONNECTED Caller = A Called = HP2 HuntPilot = HP2 Connected = LG11 HuntPilot = HP2 At LG11: LINE_CALLSTATE - CONNECTED Caller = A Called = HP2 HuntPilot = HP2 Connected = A
A completes transfer	At LG1 : LINE_CALLSTATE - CONNECTED Caller = LG1 HuntPilot = HP1 Called = HP1 HuntPilot = HP1 Connected = LG11 HuntPilot = HP2 RedirectionID = LG11 RedirectingID = A At A: both call goes IDLE At LG11: LINE_CALLSTATE - CONNECTED Caller = LG1 HuntPilot = HP1 Called = HP2 HuntPilot = HP2 Connected = LG1 HuntPilot = HP1 RedirectionID = LG11 RedirectingID = A

Intercom

This configuration gets used for all the following use cases:

1. IPPhone A has two lines, line1 (1000) and line2 (5000). Line2 represents an intercom line. Speeddial to 5001 with label ìAssistant_1î gets configured.

2. IPPhone B has three lines, line1 (1001), line2 (5001), and Line3 (5002). Line2 and Line3 represent intercom lines. Speeddial to 5000 with label ìManager_1î gets configured on line2. Line 3 does not have Speeddial configured for it.

3. IPPhone C has two lines, line1 (1002) and line2 (5003). 5003 represents an intercom line that is configured with Speeddial to 5002 with label ìAssistant_5002î.

4. IPPhone D has one line (5004). 5004 represnts an intercom line.

5. CTIPort X has two lines, line1 (2000) and line2 (5555). Line2 represents an intercom line. Speedial to 5001 gets configured with label ìAssistant_1î.

6. Intercom lines (5000 to 5003) exists in same partition = Intercom_Group_1 and they remain reachable from each other. 5004 exists in Intercom_Group_2.

7. Application monitoring all lines on all devices.

Assumption: Application initialized and CTI provided the details on speeddial and lines with intercom line on all the devices. Behavior should act the same for phones that are running SCCP, and those that are running SIP.

Application Invoking Speeddial

Action	Events
LineOpen on 5000 & 5001 Initiate InterCom Call on 5000	For 5000 receive LINE_CALLSTATE cbInst=x0 param1=x03000000 param2=x1, ACTIVE param3=x0, Receive StartTransmission event For 5001 receive LINE_CALLSTATE cbInst=x0 param1= x03000000 param2=x1, ACTIVE param3=x0, Receive StartReception event Receive zipzip tone with reason as intercom

Agent Invokes Talkback

Table 2:

Action	Events
Continuing from the previous use case, 5001 initiates LineTalkBack from application on the InterCom call	For 5000 receive LINE_CALLSTATE device=x10218 param1=x100, CONNECTED param2=x1, ACTIVE param3=x0, Receive StartReception event For 5001 receive LINE_CALLSTATE device=x101f6 cbInst=x0 param1=x100, CONNECTED param2=x1, ACTIVE param3=x0, Receive StartTransmission event

Change the SpeedDial

Action	Events
Open line 5000 LineChangeSpeeddial request (speeddial to 5003, label = "Assistant_5003")	The new speed dial and label is successfully set for the intercom line Receive LineSpeeddialChangeEvent from CTI Send LINE_DEVSPECIFIC to indicate that speeddial and label changed
Application issues LIneGetDevCaps to retrieve speeddial/label that is set on the line	TAPI returns configured speeddial/label that is configured on the line.

IPv6 Use Cases

The use cases related to IPv6 are provided below:

Register CTI Port with IPv4 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4 .

Steps

Expected Result

1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4 only on common device config page. 2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion 3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode 4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv4. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.

Application is able to register CTI Port with IPv4 address.

Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv6.

Steps

Expected Result

1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv6 only on common device config page. 2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion 3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode 4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.

Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL

Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4_v6.

Steps

Expected Result

1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4_v6 on common device config page. 2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion 3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode 4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.

Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL

IPv6 Phone A calls IPv6 Phone B

Steps

Expected Result

1. Enterprise parameter for IPv6 is enabled. 2. Open two lines A and B 3. Phone A which is IPv6 calls Phone B which is IPv6 4. Events at Phone B 5. While Media is established: •Events on phone A •Event on phone B

FireCallState = Offering, Do a GetlineCallInfo. LineCallInfo contains the following in devspecific part, FarEndIPAddress: Blank FarEndIPAddressIpv6: IPv6 address of A Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of B. ReceptionRTPDestinationAddress = IPv6 address of A. Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of A. ReceptionRTPDestinationAddress = IPv6 address of B.

IPv4_v6 Phone calls IPv6 Phone.

Steps

Expected Result

1. Enterprise parameter for IPv6 is enabled. 2. Open two lines A and B 3. Phone A which is IPv4_v6 calls Phone B which is IPv6 4. Events at Phone B 5. While Media is established: •Events on phone A •Event on phone B

FireCallState = Offering, Do a GetlineCallInfo. LineCallInfo contains the following in devspecific part, FarEndIPAddress: IPv4 address of A FarEndIPAddressIpv6: IPv6 address of A Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of B. ReceptionRTPDestinationAddress = IPv6 address of A. Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of A. ReceptionRTPDestinationAddress = IPv6 address of B.

IPv4 Phone Calls IPv6 Phone.

Steps

Expected Result

1. Enterprise parameter for IPv6 is enabled. 2. Open two lines A and B 3. Phone A which is IPv4 calls Phone B which is IPv6 4. Events at Phone B 5. While Media is established: •Events on phone A •Event on phone B

FireCallState = Offering, Do a GetlineCallInfo. LineCallInfo contains the following in devspecific part, FarEndIPAddress: IPv4 address of A FarEndIPAddressIpv6: Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv4 address of MTP Resource. ReceptionRTPDestinationAddress = IPv4 address of A. Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of MTP Resource. ReceptionRTPDestinationAddress = IPv6 address of B.

IPv6 Phone Calls IPv4 Phone.

Steps

Expected Result

1. Enterprise parameter for IPv6 is enabled. 2. Open two lines A and B 3. Phone A which is IPv6 only calls Phone B which is IPv4 4. Events at Phone B 5. While Media is established: •Events on phone A •Event on phone B

FireCallState = Offering, Do a GetlineCallInfo. LineCallInfo contains the following in devspecific part, FarEndIPAddress: FarEndIPAddressIpv6: IPv6 address of A Do a GetLinecallInfo, LineCallInfo will contain the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of MTP Resource. ReceptionRTPDestinationAddress = IPv6 address of A. Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv4 address of MTP Resource. ReceptionRTPDestinationAddress = IPv4 address of B.

IPv6 Phone Calls IPv4_v6 Phone.

Steps

Expected Result

1. Enterprise parameter for IPv6 is enabled. 2. Phone A which is IPv6 only calls Phone B which is IPv4_v6 only. 3. Open lines A and B 4. Events at Phone B 5. While Media is established: •Events on phone A •Event on phone B

Existing Call, Do a GetlineCallInfo. LineCallInfo contains the following in devspecific part, FarEndIPAddress: FarEndIPAddressIpv6: IPv6 address of A Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of MTP Resource. ReceptionRTPDestinationAddress = IPv6 address of A. Do a GetLinecallInfo, LineCallInfo contains the following in devspecific part, TransmissionRTPDestinationAddress = IPv6 address of Phone A. ReceptionRTPDestinationAddress = IPv6 address of B.

Common Device Configuration Device Mode Changes from IPv4_v6 to IPv4.

Steps	Expected Result
User changes the device configuration on common device configuration from IPv4_v6 to IPv4 only	Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv6 get a LINE_CLOSE Event. Application can then re-register these lines later.

Common Device Configuration Device Mode Changes from IPv4 to IPv6 .

Steps	Expected Result
User changes the device configuration on common device configuration from IPv4 only to IPv6 only	Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv4 get a LINE_CLOSE Event. Application can then re-register these lines later.

Join Across Lines

Setup

Line A on device A

Line B1 and B2 on device B

Line C on device C

Line D on device D

Line B1' on device B1', B1' is a shared line with B1

Join Two Calls from Different Lines to B1

Action	Expected Events
A ‡ B1 is HOLD	For A
C ‡ B2 is connected	LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
	For B1: LINE_CALLSTATE param1=x100, HOLD Caller = A, Called = B1, Connected = A
	For B2: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
	For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
	For B1': LINE_CALLSTATE param1=x100, CONNECTED, INACTIVE Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call	For A
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	CONFERENCED Caller=A Called=C, Connected=C
	For B1
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	For B2
	Call will go IDLE
	For C
	CONNECTED
	CONFERENCED Caller=C, Called=B2, Connected=B1 (or A)
	CONFERENCED Caller=C Called=A, Connected=A (or B1)
	For B1'
	CONNECTED INACTIVE
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C

Join Three Calls from Different Lines to B1

Action	Expected Events
A ‡ B1 is hold,
C ‡ B2 is hold
D ‡ B2 is connected	For A:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
	For B1:
	LINE_CALLSTATE
	param1=x100, HOLD Caller = A, Called = B1, Connected = A
	For B2:
	LINE_CALLSTATE for call-1
	param1=x100, HOLD Caller = C, Called = B2 , Connected = C
	LINE_CALLSTATE for call-2
	param1=x100, CONNECTED Caller = D, Called = B2 , Connected = D
	For C:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
	For D:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = D, Called = B2, Connected = B2
	For B1':
	LINE_CALLSTATE
	param1=x100, HOLD Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call	For A
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	CONFERENCED Caller=A Called=C, Connected=C
	CONFERENCED Caller=A Called=D, Connected=D
	For B1
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	CONFERENCED Caller=B1 Called=D, Connected=D
	For B2
	Call-1 and call-2 will go IDLE
	For C
	CONNECTED
	CONFERENCED Caller=B1, Called=C, Connected=B1
	CONFERENCED Caller=C Called=A, Connected=A
	CONFERENCED Caller=C Called=D, Connected=D
	For D
	CONNECTED
	CONFERENCED Caller=B1, Called=C, Connected=B1
	CONFERENCED Caller=D Called=A, Connected=A
	CONFERENCED Caller=D Called=C, Connected=C
	For B1'
	CONNECTED INACTIVE
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	CONFERENCED Caller=B1 Called=D, Connected=D

Join Calls from Different Lines to B1 with Conference

Action	Expected Events
A,B1,C in conference where B1 is controller	For A:
D‡ B2 Connected
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=A Called=C, Connected=C
	For B1:
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	For B2:
	LINE_CALLSTATE for call-1
	param1=x100, CONNECTED Caller = D, Called = B2 , Connected = D
	For C:
	CONNECTED
	CONFERENCED Caller=C, Called=A, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	For D:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = D, Called = B2, Connected = B2
	For B1':
	LINE_CALLSTATE
	CONNECTED INACTIVE
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call	For A
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	CONFERENCED Caller=A Called=C, Connected=C
	CONFERENCED Caller=A Called=D, Connected=D
	For B1
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	CONFERENCED Caller=B1 Called=D, Connected=D
	For B2
	Call will go IDLE
	For C
	CONNECTED
	CONFERENCED Caller=B1, Called=C, Connected=B1
	CONFERENCED Caller=C Called=A, Connected=A
	CONFERENCED Caller=C Called=D, Connected=D
	For D
	CONNECTED
	CONFERENCED Caller=B1, Called=C, Connected=B1
	CONFERENCED Caller=D Called=A, Connected=A
	CONFERENCED Caller=D Called=C, Connected=C
	For B1'
	CONNECTED INACTIVE
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C
	CONFERENCED Caller=B1 Called=D, Connected=D

Join Two Calls from Different Lines to B1 while B1 is not Monitored by TAPI

Action	Expected Events
A ‡ B1 is HOLD,
C ‡ B2 is connected	For A:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
	For B2:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
	For C:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
User issues join request from phone with the call on B1 as survival call	For A
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	CONFERENCED Caller=A Called=C, Connected=C
	For B2
	Call will go IDLE
	For C
	CONNECTED
	CONFERENCED Caller=C, Called=B2, Connected=B1 (or A)
	CONFERENCED Caller=C Called=A, Connected=A (or B1)

Join Two Calls from Different Lines to B2

Action	Expected Events
A ‡ B1 is HOLD,
C ‡ B2 is connected	For A:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
	For B1:
	LINE_CALLSTATE
	param1=x100, HOLD Caller = A, Called = B1, Connected = A
	For B2:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
	For C:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
	For B1':
	LINE_CALLSTATE
	param1=x100, HOLD Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call	For A
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	CONFERENCED Caller=A Called=C, Connected=C
	For B1
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C ??
	For B2
	Call will go IDLE
	For C
	CONNECTED
	CONFERENCED Caller=C, Called=B2, Connected=B1 (or A)
	CONFERENCED Caller=C Called=A, Connected=A (or B1)
	For B1'
	CONNECTED INACTIVE
	CONFERENCED Caller=A, Called=B1, Connected=A
	CONFERENCED Caller=B1 Called=C, Connected=C

Action	Expected Events
A ‡ B1 is HOLD,	For A:
B1 issues setup conference
C ‡ B2 is connected
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
	For B1:
	Primary call
	LINE_CALLSTATE
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B1
	Consult call
	DIALTONE
	For B2:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
	For C:
	LINE_CALLSTATE
	param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
	For B1':
	LINE_CALLSTATE
	param1=x100, HOLD Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B2 as survival call	For A:
	CONNECTED
	CONFERENCED Caller=A, Called=B1, Connected=B2
	CONFERENCED Caller=A Called=C, Connected=C
	For B1
	Both calls will go IDLE
	For B2
	CONNECTED
	CONFERENCED Caller=B1, Called=A, Connected=A
	CONFERENCED Caller=C Called=B1, Connected=C
	For C
	CONNECTED
	CONFERENCED Caller=C, Called=B2, Connected=B2 (or A)
	CONFERENCED Caller=C Called=A, Connected=A (or B2)
	For B1'
	Calls go IDLE

B1 Performs a Join Across Line Where B1 is already in a Conference Created by A

Action	Expected Events
A, B1, C are in a conference created by A	For A:
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	Connected
	Conference - Caller="B1", Called="C", Connected="C"
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	For A:
	B2 calls D, D answers
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	OnHold
	Conference - Caller="B1", Called="C", Connected="C"
	For B2:
	Connected - Caller="B2", Called="D", Connected="D"
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	Connected - Caller="B2", Called="D", Connected="B2"
B1 issues a lineDevSpecific(SLDST_JOIN) to join the calls on B1 and B2.	For A:
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	Conference - Caller="A", Called="D", Connected="D"
	For B1:
	Conference - Caller="A", Called="B1", Connected="B1"
	Conference - Caller="A", Called="B1", Connected="A"
	Connected
	Conference - Caller="B1", Called="C", Connected="C"
	Conference - Caller="B1", Called="D", Connected="D"
	For B2:
	Call will go IDLE
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	Conference - Caller="C", Called="D", Connected="D"
	For D:
	Conference - Caller="B1", Called="D", Connected="B1"
	Connected
	Conference - Caller="D", Called="A", Connected="A"
	Conference - Caller="D", Called="C", Connected="C"

B2 Performs a Join Across Line Where B1 is already in a Conference Created by A

Action	Expected Events
A,B1,C are in a conference created by A	For A:
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	Connected
	Conference - Caller="B1", Called="C", Connected="C"
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
B2 calls D, D answers	For A:
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	OnHold
	Conference - Caller="B1", Called="C", Connected="C"
	For B2:
	Connected - Caller="B2", Called="D", Connected="D"
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	For D:
	Connected - Caller="B2", Called="D", Connected="B2"
B2 issues a lineDevSpecific(SLDST_JOIN) to join the calls on B1 and B2.	For A:
	Conference - Caller="A", Called="B1", Connected="B2"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	Conference - Caller="A", Called="D", Connected="D"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	Connected
	Conference - Caller="B1", Called="C", Connected="C"
	Conference - Caller="B1", Called="D", Connected="D"
	For B2:
	Call will go IDLE
	For C:
	Conference - Caller="B2", Called="C", Connected="B2"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	Conference - Caller="C", Called="D", Connected="D"
	For D:
	Conference - Caller="B2", Called="D", Connected="B2"
	Connected
	Conference - Caller="D", Called="A", Connected="A"
	Conference - Caller="D", Called="C", Connected="C"

B1 Performs a Join Across Line Where B1 is in One Conference and B2 is in a Separate Conference

Action	Expected Events
A,B1,C are in conference1	For A (GCID-1):
D, B2, E are in conference2
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	For B1 (GCID-1):
	Conference - Caller="A", Called="B1", Connected="A"
	OnHold
	Conference - Caller="B1", Called="C", Connected="C"
	For C (GCID-1):
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	For D (GCID-2):
	Conference - Caller="D", Called="B2", Connected="B2"
	Connected
	Conference - Caller="D", Called="E", Connected="E"
	For B2 (GCID-2):
	Conference - Caller="D", Called="B2", Connected="D"
	Connected
	Conference - Caller="B2", Called="E", Connected="E"
	For E (GCID-2):
	Conference - Caller="B2", Called="E", Connected="B2"
	Connected
	Conference - Caller="E", Called="D", Connected="D"
B1 issues a lineDevSpecific(SLDST_JOIN) to join the calls on B1 and B2.	For A:
	Conference - Caller="A", Called="B1", Connected="B1"
	Connected
	Conference - Caller="A", Called="C", Connected="C"
	Conference - Caller="A", Called="CFB-2", Connected=" CFB-2"
	For B1:
	Conference - Caller="A", Called="B1", Connected="A"
	Connected
	Conference - Caller="B1", Called="C", Connected="C"
	Conference - Caller="B1", Called=" CFB-2", Connected=" CFB-2"
	For B2:
	Call will go IDLE
	For C:
	Conference - Caller="B1", Called="C", Connected="B1"
	Connected
	Conference - Caller="C", Called="A", Connected="A"
	Conference - Caller="C", Called=" CFB-2", Connected=" CFB-2"
	For D:
	Connected
	Conference - Caller="D", Called="E", Connected="E"
	conference - Caller="D", Called=" CFB-1", Connected=" CFB-1"
	For E:
	Connected
	Conference - Caller="E", Called="D", Connected="D"
	Conference - Caller="E", Called=" CFB-1", Connected=" CFB-1"

Logical Partitioning Support

Use cases related to Logical Partitioning feature are mentioned below:

Basic Call Scenario

Basic Call Scenario ; Logical partitioning Enabled = true
Description	Basic Call failure due to Logical partitioning Feature Policy.
Test Setup	A (VOIP) on one Geolocation A calls B: LineMakeCall on A Dails B (DN) Variant 1: B Geo-Location was not Configured;B(PSTN);Policy Config : Interior to Interior Variant 2: B (PSTN) on another GeoLocation
Expected Results	Variant 1: Call will be successful; Reason: LP_IGNORE. Variant 2: A goes to Proceeding State and then On A there will be a DISCONNECTED call state will be sent to application with cause as LINEDISCONNECTMODE_UNKNOWN.

Redirect Scenario

Redirect Scenario ; Logical partitioning Enabled = true
Description	Redirect Call failure due to Logical partitioning Feature Policy.
Test Setup	Two Clusters (Cluster1 and Cluster2) configured with logical partition policy that will restrict the VOIP calls from Cluster1 to PSTN calls on Cluster2. (vice versa PSTN to VIOP) A on Cluster1 (VOIP) B on Cluster2 (VOIP) C on Cluster2 (PSTN) A calls B B redirects the call to C
Expected Results	Operation fails with error code LINEERR_OPERATION_FAIL_PARTITIONING_POLICY. Error code is processed on Cluster2
Variants	For Forward Operation same behaviour will be observed.

Transfer Call Scenario

Transfer Call Scenario ; Logical partitioning Enabled = true
Description	Transfer Call failure due to Logical partitioning Feature Policy.
Test Setup	A (VOIP) in one GeoLocation (GeoLoc 1) B (VOIP) in another GeoLocation(GeoLoc 2) C (PSTN)in same GeoLocation as B (GeoLoc 2) A calls B SetUpTransfer on B. On Consult Call at B; Dials C. Complete Transfer on B.
Expected Results	Operation fails with error code "LINEERR_OPERATIONUNAVAIL".
Variants	For Operation Adhoc Conference same behaviour will be observed.

Join Scenario

Join Scenario; Logical partitioning Enabled = true
Description	Join failure due to Logical partitioning Feature Policy.
Test Setup	A (VOIP) in one GeoLocation (GeoLoc 1) B (VOIP) in another GeoLocation(GeoLoc 2) C (VOIP)in same GeoLocation as B (GeoLoc 2) D (PSTN) in same GeoLocation as B (GeoLoc 2) B has Three Calls 1. B -> A 2. B -> C 3. B -> D Variant 1: Join on B with B -> A as Primary Call. Variant 2: Join on B with B -> D as Primary Call. Variant 3: Join on B with B -> C as Primary Call.
Expected Results	Variant 1: A, B and C will be in conference. Variant 2: B, C and D will be in conference. Variant 3:Either A or D will be in conference with B and C.

Shared Line Scenario

CallPickUp Scenario ; Logical partitioning Enabled = true
Description	CallPickUp Failure due to Logical partitioning Feature Policy.
Test Setup	A (PSTN) on one Geolocation - GeoLoc1 B (VOIP) on one Geolocation - GeoLoc1 C (VOIP) on one Geolocation - GeoLoc2 A Dails B B Parks the call C does LineUnPark
Expected Results	Call will be successful on A and A' call will not be present
Variants	Shared line features like barge, cbarge, hold & remote resume should be disabled for calls.

CallPark: Retrieve Scenario

CallPickUp Scenario ; Logical partitioning Enabled = true
Description	CallPickUp Failure due to Logical partitioning Feature Policy.
Test Setup	A (PSTN) on one Geolocation - GeoLoc1 B (VOIP) on one Geolocation - GeoLoc1 C (VOIP) on one Geolocation - GeoLoc2 A Dails B B Parks the call C does LineUnPark
Expected Results	CallUpark Will fail with error code "LINEERR_OPERATIONUNAVAIL".

Basic Call Scenario

Basic Call Scenario ; Logical partitioning Enabled = true
Description	Basic Call failure due to Logical partitioning Feature Policy.
Test Setup	A (VOIP) on one Geolocation A calls B: LineMakeCall on A Dails B (DN) Variant 1: B Geo-Location was not Configured;B(PSTN);Policy Config: Interior to Interior Variant 2: B (PSTN) on another GeoLocation
Expected Results	Variant 1: Call will be successful; Reason: LP_IGNORE. Variant 2: A goes to Proceeding State and then On A there will be a DISCONNECTED call state will be sent to application with cause as LINEDISCONNECTMODE_UNKNOWN.

Manual Outbound Call

Table A-42 describes the message sequences for Manual Outbound Call when party A is idle.

Table A-42 Message Sequences for Manual Outbound Call 

Action	CTI Messages	TAPI Messages	TAPI Structures
1. Party A goes off-hook	NewCallEven CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_APPNEWCALL hDevice=A dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALTONE dwParam2=UNAVAIL dwParam3=0	No change
2. Party A dials Party B	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
3. Party B accepts call	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change
4. Party B answers call	CallStateChangedEvent, CH=C1, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=ACTIVE dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=B dwRedirectionID=NP dwRedirectionID=NP
	CallStartReceptionEvent, DH=A, CH=C1	LINE_DEVSPECIFIC1 hDevice=hCall-1 dwCallBackInstance=0 dwParam1=StartReception dwParam2=IP Address dwParam3=Port	No change
	CallStartTransmissionEvent, DH=A, CH=C1	LINE_DEVSPECIFIC2 hDevice=hCall-1 dwCallBackInstance=0 dwParam1=StartTransmission dwParam2=IP Address dwParam3=Port	No change

1 LINE_DEVSPECIFIC events are sent only if the application has requested them by using lineDevSpecific() 2 LINE_DEVSPECIFIC events are sent only if the application has requested them by using lineDevSpecific()

Monitoring and Recording

Monitoring a Call

A (agent) and B (customer) get connected. BIB on A gets set to on.

Action	CTI Messages	TAPI Messages	TAPI Structures
	Party C
C(supervisor) issues start monitoring req with A's permanentLineID as input	NewCallEvent, CH=C3, GCH=G2, Calling=C, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=ORIGIN dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=REASON, CALLERID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=C dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectingID=NP
A's BIB automatically answers	Party C
	CallStateChangedEvent, CH=C3, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=C, Called=A, OrigCalled=A, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=ACTIVE dwParam3=0	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=C dwCalledID=A dwConnectedID=A dwRedirectionID=NP dwRedirectingID=NP
	Party A
	MonitoringStartedEvent, CH = C1	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_MONITOR_STARTED dwParam2=0 dwParam3=0	LINECALLINFO (hCall-2) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP
	Party C
	LineCallAttributeInfoEvent, CH=C3, Type = 2 (MonitorCall_Target), CI = C1, Address=A's DN, Partition=A's Partition, DeviceName = A's Name	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_ATTRIBUTE_INFO dwParam3=0	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=C dwCalledID=A dwConnectedID=A dwRedirectionID=NP dwRedirectingID=NP DevSpecifc Data: Type: CallAttribute_SilentMonitorCall_Target, CI = C1, DN = A's DN, Partition = A's Partition, DeviceName = A's Name
	Party A
	LineCallAttributeInfoEvent, CH=C1, Type = 1 (MonitorCall), CI = C3 Address=C's DN, Partition=C's Partition, DeviceName = C's Name	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_ATTRIBUTE_INFO dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP DevSpecifc Data: Type:CallAttribute_SilentMonitorCall, CI = C3 DN = C's DN, Partition = C's Partition, DeviceName = C's Name
C drops the call	Party C
	CallStateChangedEvent, CH=C3, State=Idle, Cause=CauseNoError, Reason=Direct, Calling=C, Called=A, OrigCalled=A, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=IDLE dwParam2=0 dwParam3=0
	Party A
	MonitoringEndedEvent, CH = C1	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_MONITOR_ENDED dwParam2= DisconnectMode_Normal dwParam3=0

Automatic Recording

Recording type on A (agent Phone) is configured as Automatic. D is configured as a Recorder Device.

Action	CTI Messages	TAPI Messages	TAPI Structures
A recieves a call from B, and A answers the call Recording session gets established between the agent phone and the recorder	Party A
	CallStateChangedEvent, CH=C1, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=B, Called=A, OrigCalled=A, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=ACTIVE dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP
	RecordingStartedEvent, CH = C1	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_RECORDING_STARTED dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP
	LineCallAttributeInfoEvent CH = C1, Type = 3 (Automatic Recording), Address = D's DN, Partition = D's Partition, DeviceName = D's Name	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_ATTRIBUTE_INFO dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP DevSpecifc Data: Type: App Controlled Recording, DN = D's DN, Partition = D's Partition, DeviceName = D's Name

Application-Controlled Recording

A (C1) and B (C2) connect. Recording Type on A gets configured as `Application Based'. D gets configured as a Recorder Device.

Action	CTI Messages	TAPI Messages	TAPI Structures
A issues start recording request Recording session gets established between the agent phone and the recorder	Party A
	RecordingStartedEvent, CH = C1	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_RECORDING_STARTED dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP
	LineCallAttributeInfoEvent CH = C1, Type = 4 (App Controlled Recording), Address = D's DN, Partition = D's Partition, DeviceName = D's Name	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_ATTRIBUTE_INFO dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP DevSpecifc Data: Type: App Controlled Recording, DN = D's DN, Partition = D's Partition, DeviceName = D's Name
A issues stop monitoring request	RecordingEndedEvent, CH = C1	LINE_CALLDEVSPECIFIC hDevice=hCall-1 dwCallbackInstance=0 dwParam1 = SLDSMT_RECORDING_ENDED dwParam2= DisconnectMode_Normal dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=A dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP

Park Monitoring

Use cases related to Park Monitoring feature are mentioned below:

Park Monitoring Feature Disabled

Setup:

The Park Monitoring message flag is disabled by default.

Cisco Unified IP Phones (future version) running SIP: A(3000), B(3001)

All lines are monitered by TSP

Action	Expected Events
1. A(3000) calls B(3001) 2. B(3001) receives the call and parks the call	Application will not be notified about the New Parked call through LINE_NEWCALL event as the park Monitoring flag is disabled.

Park Monitoring Feature Enabled

Setup:

Cisco Unified IP Phones (future version) running SIP: A(3000), B(3001),C(3002)

All lines are monitered by TSP

Action	Expected Events
Scenario 1: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call at 5555	Park Status Event on B: At Step 3: Application will be notified about the New Parked call through LINE_NEWCALL event At Step 3: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. Application does a LineGetCallInfo.
	LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName : TransactionIDID = Sub1. dwBearerMode: ParkStatus = 2 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 2: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call at 5555 4. The Park Monitoring Reversion Timer expires while the call is still parked.	Park Status Event on B: At Step 3: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder. Application does a LineGetCallInfo. LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName : TransactionIDID = Sub1. dwBearerMode: ParkStatus = 3 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 3: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. The Park Monitoring Forward No Retrieve destination configured on B(3001) as C(3002) 3. A(3000) calls B(3001) 4. B(3001) receives the call and parks the call 5. The Park Monitoring Reversion Timer Expires while the call is still parked. 6. The Park Monitoring Forward No Retrieve timer expires and now the call is forwarded to the Park Monitoring Forward No Retrieve Destination C(3002).	Park Status Event on B: At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 5: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder. At Step 6: Application will receive the LINE_CALLSTATE event with the Park Status = Forwarded Application will receive the LINE_CALLSTATE event with callstate IDLE. The reason code CtiReasonforwardedNoRetrieve will be updated in the LINECALLINFO::dwDevSpecificData.ExtendedCallInfo.dwExtendedCallReason = CtiReasonforwardedNoRetrieve.
	Application does a LineGetCallInfo. LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName : TransactionIDID = Sub1. dwBearerMode: ParkStatus = 6 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 4: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call 4. A(3000) hangs up the call.	Park Status Event on B: At Step 3: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Abandoned. Application will receive the LINE_CALLSTATE event with callstate IDLE. Application does a LineGetCallInfo.
	LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName TransactionIDID = Sub1. dwBearerMode: ParkStatus = 4 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 5: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call 4. The Park Monitoring Reversion Timer Expires while the call is still parked. 5. C(3002) retrieves the call	Park Status Event on B: At Step 3: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder. At Step 5: Application will receive the LINE_CALLSTATE event with the Park Status = Retrieved. Application will receive the LINE_CALLSTATE event with callstate IDLE.
	Application does a LineGetCallInfo. hline: LH = 1 dwCallID: CallID dwReason: LINECALLREASON_PARKED dwRedirectingIDName: TransactionIDID = Sub1. dwBearerMode: ParkStatus = 5 dwCallerID: ParkDN = 5555 dwCallerName: ParkDNPartition = P1 dwcalled: ParkedParty = 3000 dwCalledIDName: ParkedPartyPartition = P1.
Scenario 6: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. The Park Monitoring Forward No retrieve destination not configured. 3. A(3000) calls B(3001) 4. B(3001) receives the call and parks the call 5. The Park Monitoring Reversion Timer Expires while the call is still parked 6. The Park Monitoring Forward No Retrieve timer expires and the call is forwarded to the Parkers line.	Park Status Event on B At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 5: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder. At Step 6: Application will receive the LINE_CALLSTATE event with the Park Status = Forwarded. Application will receive the LINE_CALLSTATE event with callstate IDLE. Application does a LineGetCallInfo.
	LineCallInfo will contain the following: hline: LH = 1 dwCallID: CallID dwReason: LINECALLREASON_PARKED dwRedirectingIDName: TransactionIDID = Sub1. dwBearerMode: ParkStatus = 6 dwCallerID: ParkDN = 5555 dwCallerName: ParkDNPartition = P1 dwcalled: ParkedParty = 3000 dwCalledIDName: ParkedPartyPartition = P1.
Scenario 7: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. The Park Monitoring Forward No retrieve destination configured as self(Parkers Line) 3. A(3000) calls B(3001) 4. B(3001) receives the call and parks the call 5. The Park Monitoring Reversion Timer Expires while the call is still parked 6. The Park Monitoring Reversion Timer Expires while the call is still parked 7. The Park Monitoring Forward No Retrieve timer expires and the call is forwarded to the Parkers line.	Park Status Event on B At Step 5: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 6: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder. At Step 7: Application will receive the LINE_CALLSTATE event with the Park Status = Forwarded. Application will receive the LINE_CALLSTATE event with callstate IDLE.
	Application does a LineGetCallInfo. LineCallInfo will contain the following: hline: LH = 1 dwCallID: CallID dwReason: LINECALLREASON_PARKED dwRedirectingIDName: TransactionIDID = Sub1. dwBearerMode: ParkStatus = 6 dwCallerID: ParkDN = 5555 dwCallerName: ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.

Parked Call Exists

Setup:

Cisco Unified IP Phones (future version) running SIP: A(3000), B(3001).

B is not monitered by TSP.

Action

Expected Events

Scenario 1: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call 4. Now the Line B(3001) is monitered by TSP

Park Status Event on B: At Step 4: Application will be notified about the Parked call through LINE_NEWCALL event.when ever cisco TSP recives the LINE_PARK_STATUS event for already parked call. Application does a LineGetCallInfo. LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName TransactionIDID = Sub1. dwBearerMode: ParkStatus = 2 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.

Shared Line Scenario

Setup:

A(3000) ,D(3003) are Cisco Unified IP Phones (future version) running SIP

B(3001) and B'(3001) are shared lines for Cisco Unified IP Phones (future version) running SIP

C(3002) and C'(3002) are shared lines where C is a Cisco Unified IP Phone (future version) running SIP and C' is a Cisco Unified IP Phone 7900 Series running SIP .

For the shared lines the events will be delivered to the phone which parks the call .Events will not be delivered to the other phone though the line is shared.

Action	Expected Events
Scenario 1: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) and B'(3001) starts ringing. B(3001) receives the call and parks the call 4. Park Monitoring reversion timer expires while the call is still parked. 5. D(3003) retrieves the call	Park Status Event on B: At Step 3: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Reminder.
	At Step 5: Application will receive the LINE_CALLSTATE event with the Park Status = Retrieved Application will receive the LINE_CALLSTATE event with callstate IDLE.
	Application does a LineGetCallInfo. hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName :TransactionIDID = Sub1. dwBearerMode: ParkStatus = 5 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 2: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. The Park Monitoring Forward No retrieve destination configured as B(3001) 3. A(3000) calls B(3001) 4. B(3001) and B'(3001) starts ringing. B(3001)receives the call and parks the call 5. The Park Monitoring Reversion Timer Expires while the call is still parked. 6. The Park Monitoring Forward No Retrieve timer expires and call is forwarded to B(3001).Both B(3001) and B'(3001) starts ringing as they are shared lines.	Park Status Event will be sent only to B not B'. At Step 4: Application will receive the LINE_CALLSTATE event with the Park Status = Parked. At Step 5: Application receives the LINE_CALLSTATE event with the Park Status = Reminder. At Step 6: Application receives the LINE_CALLSTATE event with the Park Status = Forwarded.
	Application receive the LINE_CALLSTATE event with callstate IDLE. Application does a LineGetCallInfo. LineCallInfo contains the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName : TransactionIDID = Sub1. dwBearerMode: ParkStatus = 6 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.
Scenario 3: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls C(3002) 3. C(3002) and C'(3002) starts ringing. C'(3002) receives the call and parks the call 4. D(3003) retrieves the call	Park Status Event on C'. At Step 3: Application is notified about the New Parked call through LINE_NEWCALL event as the call is parked by the Normal TNP phone.

Park Monitoring Feature Disabled

Setup:

The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for line B(3001).

A(3000), D(3003) is a Cisco Unified IP Phones (future version)

Application invokes the Line_open () API on provider to monitor ParkDN

.

Action

Expected Events

Scenario 1: 1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001). 2. A(3000) calls B(3001) 3. B(3001) receives the call and parks the call 4. The Park Monitoring Reversion Timer Expires while the call is still parked.

Park Status Event on B: At Step 3: Application receives the LINE_NEW_CALL event for PARKDN. At Step 3: Application receives the LINE_PARK_STATUS event with the Park Status = Parked. At Step 4: Application will receive the LINE_CALL_STATE event with the Park Status = Reminder. Application does a LineGetCallInfo. LineCallInfo will contain the following: hline : LH = 1 dwCallID : CallID dwReason :LINECALLREASON_PARKED dwRedirectingIDName :TransactionIDID = Sub1. dwBearerMode: ParkStatus = 3 dwCallerID : ParkDN = 5555 dwCallerName : ParkDNPartition = P1 dwcalled : ParkedParty = 3000 dwCalledIDName : ParkedPartyPartition = P1.

Presentation Indication

Making a Call Through Translation Pattern

Table A-43 describes the message sequences for the Presentation Indication scenario of making a call through translation pattern. In the Translation Pattern admin pages, both the callerID/Name and ConnectedID/Name get set to "Restricted".

Table A-43 Message Sequences for Making a Call Through Translation Pattern 

Action	CTI Messages	TAPI Messages	TAPI Structures
Party A goes off-hook	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct	LINE_APPNEWCALL hDevice=A dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALTONE dwParam2=UNAVAIL dwParam3=0	No change
Party A dials Party B through Translation pattern	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
Party B accepts the call	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, CallingPartyPI=Allowed, Called=B, CalledPartyPI= Restricted, OrigCalled=B, OrigCalledPI=restricted, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1= PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCallerIDName=A's Name dwCalledID=B dwCalledIDName=B's name dwConnectedID=NP dwConnectedIDName=NP dwRedirectionID=NP dwRedirectionIDName=NP dwRedirectionID=NP dwRedirectionIDName=NP
Party B accepts the call (continued)	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, CallingPI = Allowed, Called=B, CalledPI = Restricted, OrigCalled=B, OrigCalledPI = Restricted, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwRedirectionID=NP dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP
Party B answers the call	CallStateChangedEvent, CH=C1, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=A, CallingPI = Allowed, Called=B, CalledPI = Restricted, OrigCalled=B, OrigCalledPI = Restricted, LR=NP	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=ACTIVE dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCallerIDName=A's Name dwCalledID=B dwCalledIDName=B's Name dwConnectedID=A, dwConnectedIDName= A's Name, dwRedirectingID=NP dwRedirectingIDName=NP dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP
	CallStartReceptionEvent, DH=A, CH=C1	LINE_DEVSPECIFIC1 hDevice=hCall-1 dwCallBackInstance=0 dwParam1= StartReception dwParam2=IP Address dwParam3=Port	No change
	CallStartTransmissionEvent, DH=A, CH=C1	LINE_DEVSPECIFIC1 hDevice=hCall-1 dwCallBackInstance=0 dwParam1= StartTransmission dwParam2=IP Address dwParam3=Port	No change

1 LINE_DEVSPECIFIC events only get sent if the application requested them by using lineDevSpecific().

Blind Transfer Through Translation Pattern

Table A-44 describes the message sequences for the Presentation Indication scenario of Blind Transfer through Translation Pattern. In this scenario, A calls via translation pattern B, B answers, and A and B are connected.

Table A-44 Message Sequences for Blind Transfer Through Translation Pattern 

Action	CTI Messages	TAPI Messages	TAPI Structures
Party B does a lineBlindTranfser() to blind transfer call from party A to party C via translation pattern	Party A
	CallPartyInfoChangedEvent, CH=C1, CallingChanged=False, Calling=A, CallingPartyPI=Restricted, CalledChanged=True, Called=C, CalledPartyPI=Restricted, OriginalCalled=NULL, OriginalCalledPI=Restricted, LR=NULL, Cause=BlindTransfer	LINE_CALLINFO, hDevice=hCall-1, dwCallbackInstance=0, dwParam1=CONNECTEDID, REDIRECTINGID, REDIRECTIONID	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerIDFlags = LINECALLPARTYID_ BLOCKED dwCallerID=NP dwCallerIDName=NP dwCalledID=B dwCalledIDName=B's name dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwConnectedIDName=NP dwRedirectingID=B dwRedirectingIDName= B's name dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP
	Party B
	CallStateChangedEvent, CH=C2, State=Idle, Reason=Direct, Calling=A, CallingPartyPI=Restricted, Called=B, CalledPartyPI=Restricted, OriginalCalled=B, OrigCalledPartyPI=Restricted, LR=NULL	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1=IDLE dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=DIRECT dwCallerIDFlags = LINECALLPARTYID_ BLOCKED dwCallerID=NP dwCallerIDName=NP dwCalledID=B dwCalledIDName=B's name dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwConnectedIDName=NP dwRedirectingID=B dwRedirectingIDName= B's name dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP
Party B does a lineBlindTranfser() to blind transfer call from party A to party C via translation pattern (continued)	Party C
	NewCallEvent, CH=C3, origin=Internal_Inbound, Reason=BlindTransfer, Calling=A, CallingPartyPI=Restricted, Called=C, CalledPartyPI=Restricted, OriginalCalled=B, OrigCalledPartyPI=Restricted, LR=B, LastRedirectingPartyPI= Restricted	TSPI: LINE_APPNEWCALL hDevice=C dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=TRANSFER dwCallerIDFlags = LINECALLPARTYID_ BLOCKED dwCallerID=NP dwCallerIDName=NP dwCalledID=NP dwCalledIDName=NP dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwConnectedIDName=NP dwRedirectingID=B dwRedirectingIDName= B's name dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP
Party C is offering	Party A
	CallStateChangeEvent, CH=C1, State=Ringback, Reason=Direct, Calling=A, CallingPartyPI=Restricted, Called=C, CalledPartyPI=Restricted, OriginalCalled=B, OrigCalledPartyPI=Restricted, LR=B, LastRedirectingPartyPI= Restricted	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1= RINGBACK dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerIDFlags = LINECALLPARTYID_ BLOCKED dwCallerID=NP dwCallerIDName=NP dwCalledID=B dwCalledIDName=B's name dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwConnectedIDName=NP dwRedirectingID=B dwRedirectingIDName= B's name dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP
Party C is offering (continued)	Party C
	CallStateChangedEvent, CH=C3, State=Offering, Reason=BlindTransfer, Calling=A, CallingPartyPI=Restricted, Called=C, CalledPartyPI=Restricted, OriginalCalled=B, OrigCalledPartyPI=Restricted, LR=B, LastRedirectingPartyPI= Restricted	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1= OFFERING dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwCallerIDFlags = LINECALLPARTYID_ BLOCKED dwCallerID=NP dwCallerIDName=NP dwCalledID=NP dwCalledIDName=NP dwConnectedIDFlags = LINECALLPARTYID_ BLOCKED dwConnectedID=NP dwConnectedIDName=NP dwRedirectingID=B dwRedirectingIDName= B's name dwRedirectionIDFlags = LINECALLPARTYID_ BLOCKED dwRedirectionID=NP dwRedirectionIDName=NP

Redirect Set Original Called (TxToVM)

Table A-45 describes the message sequences for Redirece Set Original Called (TxToVM) feature where A calls B, B answers, and A and B are connected.

Table A-45 Message Sequences for Redirect Set Original Called (TxToVM) 

Action	CTI Messages	TAPI Messages	TAPI Structures
Party B does lineDevSpecific for REDIRECT_SET_ORIG_CALLED with DestDN = C's VMP and SetOrigCalled = C	Party A
	CallPartyInfoChangedEvent, CH=C1, CallingChanged=False, Calling=A, CalledChanged=True, Called=C, OriginalCalled=NULL, LR=NULL, Cause=Redirect	LINE_CALLINFO, hDevice=hCall-1, dwCallbackInstance=0, dwParam1=CONNECTEDID, REDIRECTINGID, REDIRECTIONID	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=C dwConnectedID=NULL dwRedirectingID=NP dwRedirectionID=NP
	Party B
	CallStateChangedEvent, CH=C2, State=Idle, reason=DIRECT, Calling=A, Called=B, OriginalCalled=B, LR=NULL	TSPI: LINE_CALLSTATE, hDevice=hCall-1, dwCallbackInstance=0, dwParam1=IDLE dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NULL dwRedirectingID=NULL dwRedirectionID=NULL
	Party C's VMP
	NewCallEvent, CH=C3, origin=Internal_Inbound, reason=Redirect, Calling=A, Called=C, OriginalCalled=C, LR=B	TSPI: LINE_APPNEWCALL hDevice=C dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	TSPI LINECALLINFO dwOrigin=INTERNAL dwReason=REDIRECT dwCallerID=A dwCalledID=C dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C's VMP
Party C is offering	Party A
	CallStateChangeEvent, CH=C1, State=Ringback, Reason=Direct, Calling=A, Called=C, OriginalCalled=C, LR=B	TSPI: LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1= RINGBACK dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C's VMP
	Party C
	CallStateChangedEvent, CH=C3, State=Offering, Reason=Redirect, Calling=A, Called=C, OriginalCalled=C, LR=B	TSPI: LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1= OFFERING dwParam2=0 dwParam3=0	TSPI LINECALLINFO dwOrigin=INTERNAL dwCallerID=A dwCalledID=C dwConnectedID=NULL dwRedirectingID=B dwRedirectionID=C

Refer and Replaces Scenarios

In-Dialog Refer - Referrer in Cisco Unified Communications Manager Cluster

Table A-46 describes the message sequences for the Refer and Replaces scenario of in-dialog refer where referer is in Cisco Unified Communications Manager cluster.

Table A-46 Message Sequences for In-Dialog Refer - Referrer in Cisco Unified Communications
Manager Cluster 

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Referrer (A), Referee (B), and Refer-to-Target (C) exist in Cisco Unified Communications Manager cluster, and CTI is monitoring those lines	A-->B has a call in connected state. The call party information at A should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin =LINECALL ORIGIN_INTERNAL	A-->B has a call in connected state. The call party information at B should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = A dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL
(A) initiates REFER (B) to (C)	A gets LINECALLSTATE_ UNKNOWN | CLDSMT_ CALL_WAITING_STATE with extended reason = REFER TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin =LINECALL ORIGIN_INTERNAL		NewCallEvent should be {calling=B, called=C, LRP=A, origCalled=C, reason=REFER} LINECALLSTATE_OFFERING TAPI CallInfo dwCallerID = B dwCalledID = C dwRedirectingID = A dwRedirectionID = C dwConnectedID = "" dwReason =LINECALL REASON_UNKNOWN with extended REFER dwOrigin = LINECALL ORIGIN_INTERNAL
C answers the call, and Refer is successful	LINECALLSTATE_IDLE with extended REFER reason	CallPartyInfoChangedEvent @ B with {calling=B, called=C, LRP=A, origCalled=C, reason=REFER} TAPI callInfo dwCallerID = B dwCalledID = B dwRedirectingID = A dwRedirectionID = C dwConnectedID = C dwReason = DIRECT dwOrigin = LINECALL ORIGIN_INTERNAL	LINECALLSTATE_CONNECTED TAPI callInfo dwCallerID = B dwCalledID = C dwRedirectingID = A dwRedirectionID = C dwConnectedID = B dwReason = LINECALL REASON_UNKNOWN with extended REFER dwOrigin = LINECALL ORIGIN_INTERNAL

In-Dialog Refer Where ReferToTarget Redirects the Call in Offering State

Table A-47 describes the message sequences for the Refer and Replaces scenario of in-dialog refer where ReferToTarget redirects the call in Offering state.

Table A-47 Message Sequences for In-Dialog Refer Where ReferToTarget Redirects the Call in
Offering State 

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Referrer (A), Referee (B), and Refer-to-Target (C) exist in Cisco Unified Communications Manager cluster, and CTI is monitoring those lines	A-->B has a call in connected state. The call party information at A should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL	A-->B has a call in connected state. The call party information at B should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = A dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL
(A) initiates REFER (B) to (C)	A gets LINECALLSTATE_ UNKNOWN | CLDSMT_ CALL_WAITING_STATE with extended reason = REFER TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL	B gets CPIC with (calling = B, called = C, ocdpn=C, LRP = A, reason = REFER, call state = Ringback) TAPI CallInfo dwCallerID = B dwCalledID = C dwRedirectingID = A dwRedirectionID = C dwConnectedID = null dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL	NewCallEvent should be {calling=B, called=C, LRP=A, origCalled=C, reason=REFER} LINECALLSTATE_OFFERING TAPI callInfo dwCallerID = B dwCalledID = C dwRedirectingID = A dwRedirectionID = C dwConnectedID = null dwReason = LINECALL REASON_UNKNOWN with extended REFER dwOrigin = LINECALL ORIGIN_INTERNAL
C Redirects the call to D in offering state, and D answers	LINECALLSTATE_IDLE with extended reason = REFER (REFER considered as successful when D answers)	CallPartyInfoChangedEvent @ B with {calling=B, called=D, LRP=C, origCalled=C, reason=Redirect} Callstate = connected TAPI callInfo dwCallerID = B dwCalledID = B dwRedirectingID = C dwRedirectionID = D dwConnectedID = D dwReason = DIRECT dwOrigin = LINECALL ORIGIN_INTERNAL	IDLE with reason = Redirect TAPI LINECALLSTATE_IDLE D will get NewCallEvent with reason = Redirect call info same as B's call info. (calling=B, called=D, ocdpn = C, LRP = C, reason = redirect) Offering/accepted/connected

In-Dialog Refer Where Refer Fails or Refer to Target is Busy

Table A-48 describes the message sequences for the Refer and Replaces scenario of in-dialog refer fails or refer to target is busy.

Table A-48 Message Sequences for In-Dialog Refer Where Refer Fails or Refer to Target is Busy 

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Referrer (A), Referee (B,) and Refer-to-Target (C) exist in Cisco Unified Communications Manager cluster, and CTI is monitoring those lines	A-->B has a call in connected state. The call party information at A should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL	A-->B has a call in connected state. The call party information at B should be {calling=A, called=B, LRP=null, origCalled=B, reason=direct} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = A dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL
(A) initiates REFER (B) to (C)	A gets LINECALLSTATE_ UNKNOWN | CLDSMT_ CALL_WAITING_STATE with extended reason = REFER TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = B dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL	No change
C is busy / C does not answer	A gets LINECALLSTATE_ CONNECTED with extended reason = REFER (REFER considered as failed)	If B goes to ringback when call is offered to C (C does not answer finally) it should also receive Connected Call State and CPIC event TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = A dwReason = Direct dwOrigin = LINECALL ORIGIN_INTERNAL

Out-of-Dialog Refer

Table A-49 describes the message sequences for the Refer and Replaces scenario of out-of-dialog refer.

Table A-49 Message Sequences for Out-of-Dialog Refer 

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Referrer (A), Referee (B), and Refer-to-Target (C) exist in Cisco Unified Communications Manager cluster, and CTI is monitoring those lines	There is no preexisting call between A and B.	There is no preexisting call between A and B.
A initiates REFER B to (C)		B should get NewCallEvent with call info as {calling=A, called=B, LRP=null, origCalled=B, reason=REFER} TAPI CallInfo dwCallerID = A dwCalledID = B dwRedirectingID = null dwRedirectionID = null dwConnectedID = A dwReason = LINECALL REASON_ UNKNOWN with extended REFER dwOrigin =LINECALL ORIGIN_EXTERNAL
B answers		Call state = connected (media does not flow between A and B when call goes to connected state) TAPI CallInfo (no change)
Cisco Unified Communications Manager redirects the call to C		CallPartyInfoChangedEvent @ B with {calling=B, called=C, LRP=A, origCalled=C, reason=REFER} TAPI callInfo dwCallerID = B dwCalledID = B dwRedirectingID = A dwRedirectionID = C dwConnectedID = C dwReason = LINECALL REASON_ UNKNOWN with extended REFER dwOrigin = LINECALL ORIGIN_EXTERNAL	NewCallEvent should be {calling=B, called=C, LRP=A, origCalled=C, reason=REFER} This info is exactly same as though caller (A) performed REDIRECT operation (except the reason is different here). TAPI callInfo dwCallerID = B dwCalledID = C dwRedirectingID = A dwRedirectionID = C dwConnectedID = B dwReason = LINECALL REASON_ UNKNOWN with extended REFER dwOrigin = LINECALL ORIGIN_INTERNAL

Invite with Replace for Confirmed Dialog

Table A-50 describes the message sequences for the Refer and Replaces scenario of invite with replace for confirmed dialog. Here, A, B, and C exist inside Cisco Unified Communications Manager. A confirmed dialog occurs between A and B. C initiates Invite to A with replace B's dialog ID.

Table A-50 Message Sequences for Invite with Replace for Confirmed Dialog

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Confirmed dialog occurs between A and B	Call State = connected, Caller=A, Called=B, Connected=B, Reason =direct, gcid = GC1	Call State = connected Caller=A, Called=B, Connected=A, Reason =direct, gcid = GC1
C Invites A by replacing B's dialog			NewCall at C gcid = GC2, reason=REPLACEs, Call state = Dialing, Caller=C, Called=null, Reason = REPLACEs
Cisco Unified Communications Manager joins A and C in a call and disconnects call leg @ B	GCID Changed to GC2, Reason = REPLACEs CPIC Caller = C, Called = A, ocdpn = A, LRP = B Reason = REPLACEs Callstate = connected TAPI callinfo caller=C, called=B, connected=C, redirecting=B, redirection=A, reason=DIRECT with extended REPLACEs, callID=GC2	Call State = IDLE, extended reason = REPLACEs	CPIC changed Caller = C, Called = A, ocdpn = A, LRP = B, Reason=REPLACEs CallState = connected TAPI callinfo Caller=C, Called=A, Connected=A, Redirecting=B, Redirection=A, reason=UNKNOWN with extended REPLACEs, callID=GC2

Refer with Replace for All in Cluster

Table A-51 describes the message sequences for the Refer and Replaces scenario of refer with replace for all in cluster. Here, a confirmed dialog exists between A and B and A and C. A initiates Refer to C with replace B's dialog ID.

Table A-51 Message Sequences for Refer with Replace for All in Cluster

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @Referree (B)	CallState/CallInfo @Refer-to-Target (C)
Dialog between A and B and dialog between A and C	Call State = onhold, GC1, Caller=A, Called=C, Connected=C, Reason =direct CallState = connected, GC2, Caller = A, Called = B, Connected=B, Reason =direct	Call State = connected Caller=A, Called=B, Connected=A, Reason =direct, gcid = GC2	Call State = connected Caller=A, Called=C, Connected=A, Reason =direct, gcid = GC1
A completes Refer to C replacing A->B's dialog (B is referred to target)	From CTI (callState = IDLE with reason = TRANSFER) TAPI call state IDLE with Reason = DIRECT with extended reason TRANSFER	GCID changed from CTI reason = TRANSFER CPIC Changed from CTI Caller=B, Called=C, Origcalled = C, LRP=A, Reason=TRANSFER TAPI callinfo Caller=B, Called=B, Connected = C, Redirecting=A, Redirection=C, Reason = DIRECT with extended reason TRANSFER. CallId=GC1	CPIC Changed from CTI with Caller=B, Called=C, Origcalled = C, LRP=A, Reason=TRANSFER TAPI callinfo caller=B, called=C, connected=B, redirecting=A, redirection=C, reason=direct with extended TRANSFER. callId=GC1

Refer with Replace for All in Cluster, Replace Dialog Belongs to Another Station

Table A-51 describes the message sequences for the Refer and Replaces scenario of refer with replace for all in cluster, where replace dialog belongs to another station. In this scenario:

A is Referrer, D is Referee, and C is Refer-to-Target.

A confirmed dialog exists between A(d1) and B & C(d2) and D.

A initiates Refer to D on (d1) with Replaces (d2).

Table A-52 Message Sequences for Refer with Replace for All in Cluster, Replace Dialog Belongs to Another Station 

Actions	CallState/CallInfo @Referrer (A)	CallState/CallInfo @B	CallState/CallInfo @Refer-to-Target (C)	CallState/CallInfo @Referree (D)
Dialog between A and B and dialog between C and D	Call State = onhold, Caller=A, Called=B, Connected=B, Reason =direct, gcid=GC1	Call State = connected Caller=A, Called=B, Connected=A, Reason =direct, gcid = GC1	Call State = connected Caller=C, Called=D, Connected=D, Reason =direct, gcid = GC2	Call State = connected Caller=C, Called=D, Connected=C, Reason =direct, gcid = GC2
A initiates Refer to D on (d1) with Replaces (d2)	From CTI (callState = IDLE with reason = REFER) TAPI call state IDLE with reason = DIRECT with extended reason = REFER	CPIC Changed from CTI Caller=B, Called=C, Origcalled = D, LRP=C, Reason=REPLACEs TAPI callinfo Caller=B, Called=B, Connected = D, Redirecting=C, Redirection=D, Reason=DIRECT with extended REPLACEs, CallId=GC1	From CTI (callState = IDLE with reason = REPLACEs.) TAPI call state IDLE with reason = DIRECT with extended reason = REPLACEs	GCID changed from CTI to GC1 CPIC Changed from CTI with Caller=B (referee), Called=D, Origcalled = D, LRP=C, Reason=REPLACEs TAPI callinfo caller=B, called=D, connected=B, redirecting=C, redirection=D, reason=DIRECT with extended REPLACEs, callId=GC1

Secure Conferencing

Conference with All Parties as Secure

The conference bridge includes security profile. MOH is not configured. A, B, and C get registered as Encrypted.

Action	CTI Messages	TAPI Messages	TAPI Structures
A calls B; B answers the call	Party A
	CallStateChangedEvent, CH=C1, GCH=G1, Calling=A, Called=B, OrigCalled=B, LR=NP, State=Connected, Origin=OutBound, Reason=Direct SecurityStaus= NotAuthenticated CtiCallSecurityStatusUpdate LH = A, CH = C1 SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=A dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = Encrypted
	Party B
	CallStateChangedEvent, CH=C2, GCH=G1, Calling=A, Called=B, OrigCalled=B, LR=NP, State=Connected, Origin=OutBound, Reason=Direct SecurityStaus=NotAuthenticated CtiCallSecurityStatusUpdate LH = B, CH = C2 SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T1 dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=A dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = Encrypted
B does lineSetUpConference	Party B
	CtiCallSecurityStatusUpdate LH = B, CH = C2 SecurityStaus= NotAuthenticated	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T1 dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=A dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = NotAuthenticated
B calls C; C answers the call	Party B
	CallStateChangedEvent, CH=C3, GCH=G2, Calling=A, Called=B, OrigCalled=B, LR=NP, State=Connected, Origin=OutBound, Reason=Direct SecurityStaus=NotAuthenticated CtiCallSecurityStatusUpdate LH = B, CH = C3 SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T2 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=B dwCalledID=C dwConnectedID=C dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = Encrypted
	Party C
	CallStateChangedEvent, CH=C4, GCH=G2, Calling=B, Called=C, OrigCalled=C, LR=NP, State=Connected, Origin=OutBound, Reason=Direct SecurityStaus= NotAuthenticated CtiCallSecurityStatusUpdate LH = C, CH = C4 SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=C dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=C dwCallID=T2 dwOrigin=INTERNAL dwReason=DIRECT dwCallerID=B dwCalledID=C dwConnectedID=B dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = Encrypted
B completes conf	Party B
	CtiCallSecurityStatusUpdate LH = B, CH = C2 SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectingID=NP Devspecific Data : CallSecurityInfo = Encrypted

Hold or Resume in Secure Conference

Conference bridge includes security profile. MOH gets configured. A, B, and C represent secure phones and exist in conference with overall call security status as secure.

Action	CTI Messages	TAPI Messages	TAPI Structures
A does lineHold	Party A
	CtiCallSecurityStatusUpdate, LH = A, CH = C1, SecurityStaus= NotAuthenticated	LINE_CALLDEVSPECIFIC hDevice=A dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = NotAuthenticated
	Party B
	CtiCallSecurityStatusUpdate, LH = B, CH = C2, SecurityStaus= NotAuthenticated	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = CtiCallSecurityStatusUpdate, LH = A, CH = C1, SecurityStaus= NotAuthenticated
	Party C
	CtiCallSecurityStatusUpdate, LH = A, CH = C1, SecurityStaus= NotAuthenticated	LINE_CALLDEVSPECIFIC hDevice=C dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine= dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = NotAuthenticated
A does lineResume	Party A
	CtiCallSecurityStatusUpdate, LH = A, CH = C1, SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=A dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = Encrypted
	Party B
	CtiCallSecurityStatusUpdate, LH = B, CH = C2, SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=B dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine=B dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = Encrypted
	Party C
	CtiCallSecurityStatusUpdate, LH = C, CH = C4, SecurityStaus= Encrypted	LINE_CALLDEVSPECIFIC hDevice=C dwCallbackInstance=0 dwParam1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA dwParam2=SLDST_CALL_SECURITY_STATUS dwParam3=0	LINECALLINFO (hCall-1) hLine= dwCallID=T1 dwOrigin=CONFERENCE dwReason=UNKNOWN dwCallerID=NP dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP Devspecific Data : CallSecurityInfo = Encrypted

Secure Monitoring and Recording

Silent Monitoring

Set up:

User is in "Allow Monitoring" Group

BIB on B is set to ON

A, A1 - Customer Phones

B, B1- Agent Phones

C, C1 - Supervisor Phones

All Lines are Opened with Ext Version - 0x000A0000

Action	Expected Result
LineInitialize. Device A,B and C is Non-Secure LineOpen on A,B and C A calls B;B answers the Call C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. LineGetCallInfo on B LineGetCallInfo on C	Silent Monitored Call is created in Non-Secure Mode Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. New call will be fired on C Line_CallDevSpecific(dwparam1 = DevSpecificData, dwparam2 = CallAttributeInfo) will be fired to B and C CallReason = LINECALLREASON_DIRECT CallAttributeInfo in devspecific part of LineCallInfo of B will contain C's info. CallAttributeType = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Not Authenticated CallReason = LINECALLREASON_DIRECT CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info Extended Call Reason = "CtiReasonSilentMonitoring" CallAttributeType = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated
Varaint 1 : Monitor Customer, Agent and Supervisor Lines after Monitoring Session is Started. Note Start Monitoring Lines from Other Application or Close Agent and Supervisor and Reopen the same. LineGetCallInfo on B	CallReason = LINECALLREASON_UNKNOWN

Basic Silent Monitoring Scenario in Secure Mode

Action

Expected Result

LineInitialize. Device A,B and C is Secure LineOpen on A,B and C A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. LineGetCallInfo on B LineGetCallInfo on C

Silent Monitored Call is created in Secure Mode Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. New call will be fired on C Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C Line_CallDevSpecific(dwparam1 = DevSpecificData, dwparam2 = SLDST_SRTP_INFO, dwParam3= MEDIA_ENCRYPT_KEYS_AVAILABLE) will be fired for the call on C. SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain C's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Encrypted SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Encrypted

Silent Monitoring Scenario on Non-Secure Call in Secure Mode

Action

Expected Result

LineInitialize. Device A is not Secure Device B and C is Secure LineOpen on A,B and C A calls B;B answers the Call A to B call is non Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. LineGetCallInfo on B LineGetCallInfo on C Variant : A is Secure Call on A is Hold and Non-Secure MOH is Inserted

Monitoring Session will be started and the Media is setup in Secure Mode Events delivered will be same as use case 8.13.6.2. Line_CallDevSpecific (dwparam1 = DevSpecifcData, dwparam2 = OverallSecurityStatus) will be fired to C. SRTP info is not Available security Indicator = MEDIA_NOT_ENCRYPTED CallAttributeInfo in devspecific part of LineCallInfo of B will contain C's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Not Authenticated SRTP info will be available security Indicator = MEDIA_ENCRYPT_KEYS_AVAILABLE CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated Same Events as above

Silent Monitoring Scenario on non-Secure Call from Supervisor which is Secure

Action	Expected Result
LineInitialize. Device A and B is not Secure Device C is Secure LineOpen on A,B and C A calls B;B answers the Call A to B call is non Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. LineGetCallInfo on C	Call between B and C will be Non-Secure No SRTP Events will be fired CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info security Indicator = MEDIA_NOT_ENCRYPTED CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated

Silent Monitoring Scenario on Secure Call from Supervisor which is Non-Secure

Action	Expected Result
LineInitialize. Device A and B is Secure Device C is Not Secure LineOpen on A,B and C A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input.	•New Call will be Fired on C. •Call on C will go to Disconnected State •Request fails with new Error Code LINEERR_SECURITY_CAPABILITIES_MISMATCH. Note Request fails as the Supervisor Security Capabilities doesn't meet or exceed the Security status of Agent (B)

Transfer of Monitored call from supervisor to other supervisor

Action	Expected Result
LineInitialize. Device A,B and C is Secure Device C1 is not Secure LineOpen on A,B,C and C1 A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. LineGetCallInfo on C lineDevSpecifc(CCiscoLineDevSpecificSetStatusMsgs) with DevSpecificStatusMsgsFlag = DEVSPECIFIC_SILENT_MONITORING_TERMINATED on C	Call between B and C will be in Secure Mode Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C SRTP info will be available security Indicator = MEDIA_ENCRYPT_KEYS_AVAILABLE CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Encrypted LINE_REPLY (dwRequestId, 0) is returned CallSecurityStatus = Encrypted
C Transfers to C1 Variant : C1 is Secure LineGetCallInfo on B LineGetCallInfo on C1	Transfer is successful and Monitoring Session will be Terminated. Call on C1 will be Disconnected with new Cause Code. Line_CallDevSpecific will be fired for B dwparam1 = SLDSMT_MONITORING_ENDED, dwparam2 = LINEDISCONNECTMODE_INCOMPATIBLE. Line_DevSpecific (dwparam1 = SLDSMT_MONITORING_TERMINATED, dwparam2 = TransactionID - xxxx, dwparam3 = LINEDISCONNECTMODE_INCOMPATIBLE) will be fired for C. Transfer is successful and Monitoring Session will not be disturbed. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C1 SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain C1's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C1's DN, Partition = C1's Partition Device Name = C1's Device Name Transaction ID = XXXX Call Security Status = Encrypted SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Encrypted

Transfer of call from one customer to other

Action

Expected Result

LineInitialize. Device A,B and C is Secure Device A1 is not Secure LineOpen on A,B,C and A1 A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input. A Transfers to A1 LineGetCallInfo on B LineGetCallInfo on C

Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C Call between B and C will be in Secure Mode Line_CallDevSpecific(dwparam1 = DevSpecificData, dwparam2 = SLDST_SRTP_INFO, dwParam3= MEDIA_ENCRYPT_KEYS_AVAILABLE) will be fired for the call on C. Transfer is successful and Monitoring Session isn't disturbed. Line_CallDevSpecific (dwparam1 = DevSpecifcData, dwparam2 = SLDST_SECURITY_STATUS_INFO) will be fired to B and C. SRTP info will not be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain C1's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Not Authenticated SRTP info will be available Security Indicator = MEDIA_ENCRYPT_KEYS_AVAILABLE CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated

Park on Supervisor

Action

Expected Result

LineInitialize Device A,B and C is Secure Device C1 non secure LineOpen on A,B and C A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input C parks the call lineDevSpecifc(CCiscoLineDevSpecificSetStatusMsgs) with DevSpecificStatusMsgsFlag = DEVSPECIFIC_SILENT_MONITORING_TERMINATED on C C1 Unparks the call Varaint : if LineDevSpecific for receiving Terminated Event is not set

Call between B and C is setup with Secure mode Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. Line_CallDevSpecific (dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C. Line_CallDevSpecific(dwparam1 = DevSpecificData, dwparam2 = SLDST_SRTP_INFO, dwParam3= MEDIA_ENCRYPT_KEYS_AVAILABLE) will be fired for the call on C. Park Operation is successful and overCallSecurity Status is degraded to Not-Authenticated LINE_REPLY (dwRequestId, 0) is returned UnPark operation is Successful and Monitoring session is terminated. Call on C1 is disconnected as C1doesn't have Secure Capabilities. Line_CallDevSpecific will be fired for B dwparam1 = SLDSMT_MONITORING_ENDED dwparam2 = LINEDISCONNECTMODE_INCOMPATIBLE Line_DevSpecific (dwparam1 = SLDSMT_MONITORING_TERMINATED, dwparam2 = TransactionID - xxxx, dwparam3 = LINEDISCONNECTMODE_INCOMPATIBLE) will be fired for C. Terminated Event is not Reported

Silent Monitoring on Conferenced Call

Action	Expected Result
LineInitialize Device A and B1 is not Secure Device C and B is Secure LineOpen on A,B,B1 and C A, B and B1 are in Conference C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input	Silent Monitoring Call between B and C is setup with Secure mode. Line_CallDevSpecific (dwparam1 = DevSpecifcData, dwparam2 = OverallSecurityStatus) will be fired to C. Call Security Status = Not Authenticated

Conference on Monitored Call

Action

Expected Result

LineInitialize. Device A, B and C is not Secure Device C1 is Secure LineOpen on A,B,C and D A calls B;B answers the Call C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input C creates conference with C1 LineGetCallInfo on B LineGetCallInfo on C LineGetCallInfo on C1

Monitoring Request is successful and the Session is started Conference is created with A , C and C1 Line_CallDevSpecific (dwparam1 = DevSpecifcData, dwparam2 = OverallSecurityStatus) will be fired to C1. Call Security Status = Not Authenticated SRTP info will not be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain CFB's info. CallAttributeTye = CallAttribute_SilentMonitorCall Call Security Status = Not Authenticated SRTP info will not be available Security Indicator = MEDIA_NOT_ENCRYPT CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated SRTP info will not be available Security Indicator = MEDIA_NOT_ENCRYPT CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated

Conference on Monitored Call

Action

Expected Result

LineInitialize Device A, B and C is Secure Device C1 is not Secure LineOpen on A,B,C and C1 A calls B;B answers the Call C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input lineDevSpecifc (CCiscoLineDevSpecificSetStatusMsgs) with DevSpecificStatusMsgsFlag = DEVSPECIFIC_SILENT_MONITORING_TERMINATED on C C creates and Completes conference with C1

Monitoring Request is successful and the Session is started Monitoring Session is ended and C and C1 will be in direct simple call. Line_CallDevSpecific will be fired for B. dwparam1 = SLDSMT_MONITORING_ENDED, dwparam2 = LINEDISCONNECTMODE_INCOMPATIBLE Line_DevSpecific (dwparam1 = SLDSMT_MONITORING_TERMINATED, dwparam2 = TransactionID - xxxx, Dwparam3 = LINEDISCONNECTMODE_INCOMPATIBLE) will be fired for C

Supervisor Holds the Call

Action

Expected Result

LineInitialize Device A, B and C is Secure Device C1 is Secure LineOpen on A,B,C and C1 C and C1 are shared lines A calls B; B answers the Call C issues LineDevSpecific (Start Monitoring) with A's permanent lineID, silent monitoring mode and NoTone as input C holds the call C1 resumes the call Variant: C1 is not Secure and DEVSPECIFIC_SILENT_MONITORING_TERMINATED filter is enabled on C

Monitoring session is started Media will be stopped Media is started.Call on C will be INACTIVE (RIU Call) Monitoring session is Terminated. Line_CallDevSpecific will be fired for B dwparam1 = SLDSMT_MONITORING_ENDED, dwparam2 = LINEDISCONNECTMODE_INCOMPATIBLE Call on C1 will be Disconnected with new Cause Code LINEDISCONNECTMODE_INCOMPATIBLE Line_DevSpecific (dwparam1 = SLDSMT_MONITORING_TERMINATED, dwparam2 = TransactionID - xxxx, dwparam3 = LINEDISCONNECTMODE_INCOMPATIBLE) will be fired for C

Recording

Set up

User is in Allow Recording group

A is Customer Device

B is Agent

C is Recording Device

BIB on B is set to on.

Recording Type on B is Application Invoked

C is configured as the recording device for B

Basic Recording Scenario

Action	Expected Result
LineInitialize Device A,B and C is not-Secure LineOpen on A and B A calls B;B answers the Call B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call LineGetCallInfo on B	Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to on B CallReason = LINECALLREASON_DIRECT Devspecific part will contain the following CallAttributeTye = `CallAttribute_RecordedCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = 0 Call Security Status = Not Authenticated
Variant 1 : Monitor the Customer and Agent Lines after the Recording Session is Started. LineGetCallInfo on B	CallReason = LINECALLREASON_UNKNOWN

Basic Recording Scenario in Secure Mode

Action

Expected Result

LineInitialize Device A,B and C is Secure LineOpen on A and B A calls B;B answers the Call A to B call is Secure B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call LineGetCallInfo on B

Recording session is started in secure mode Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired on B SRTP info will be available ( for A-B Call) Devspecific part will contain the following: CallAttributeTye = CallAttribute_RecordedCall Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = 0 Call Security Status = Encrypted

Recording Scenario on Non-Secure call in Secure Mode

Action

Expected Result

LineInitialize Device A is not Secure Device B and C is Secure LineOpen on A and B A calls B;B answers the Call A to B call is non Secure B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call LineGetCallInfo on B

Recording session is started in secure mode Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B SRTP Info is not available Devspecific part will contain the following: CallAttributeTye = CallAttribute_RecordedCall Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = 0 Call Security Status = Not Authenticated

Recording Scenario on non-Secure Call using Secure Recording Profile/Device

Action	Expected Result
LineInitialize Device A and B is Secure Device C is Not Secure LineOpen on A,B and C A calls B;B answers the Call A to B call is Secure B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call	Recording Request will Fail with existing error code LINEERR_OPERATIONFAILED Note Recording Failed as the Recording Device Security Capabilities doesn't meet or exceed the Security status of B

Recording Scenario when Agent holds the call

Action

Expected result

LineInitialize Device A and B is not Secure Device C is Secure LineOpen on A and B A calls B;B answers the Call A to B call is non Secure B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call LineHold on Call on B B resumes the Call Note Recording option - Automatic Call Recording Enabled B Resumes the Call

Recording Session is started Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B Call between B and C will be Non-Secure Media between B and C is ended Line_CallDevSpecific (dwparam1 = RecordingEnded) will be fired for B Recording Session will be started Media between B and C is started Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B Recording Session will be started

Recording and Monitoring

Both Silent Monitoring and Recording on Agent Call in Secure Mode

Action	Expected Result
LineInitialize Device A,B,C and D are Secure D is configured as Recording Device on B LineOpen on A,B and C A calls B;B answers the Call A to B call is Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input LineGetCallInfo on B LineGetCallInfo on C	Silent Monitored Call is created in Secure Mode C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as inputLine_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B. New call will be fired on C Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C Line_CallDevSpecific(dwparam1 = DevSpecificData, dwparam2 = SLDST_SRTP_INFO, dwParam3= MEDIA_ENCRYPT_KEYS_AVAILABLE) will be fired for the call on C SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain C's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Encrypted SRTP info will be available CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Encrypted
B issues LineDevSpecific (Start Recording, BothLocalAndRemote) for A-B call LineGetCallInfo on B	Recording session is started in secure mode Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for B. Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired on B SRTP info will be available (SRTP info for the call Between B and A) Devspecific part will contain the following: CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX CallAttributeTye = CallAttribute_RecordedCall Address = D's DN, Partition = D's Partition Device Name = D's Device Name Transaction ID = 0 Call Security Status = Encrypted

Recording Silent Monitored Call on Supervisor

Action	Expected Result
LineInitialize Device A and B is not Secure Device C and D is Secure D is the Recording Device D is configured as Recording on C LineOpen on A, B and C A calls B;B answers the Call A to B call is non Secure C issues LineDevSpecific (Start Monitoring) with B's permanent lineID, silent monitoring mode and NoTone as input LineGetCallInfo on B LineGetCallInfo on C C issues LineDevSpecific (Start Recording, BothLocalAndRemote) for B-C call	Line_CallDevSpecific (dwparam1 = MonitoringStarted) will be fired for B New call will be fired on C (Silent Monitoring call) Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to B and C SRTP info will not be available CallAttributeInfo in devspecific part of LineCallInfo of B will contain C's info. CallAttributeTye = `CallAttribute_SilentMonitorCall' Address = C's DN, Partition = C's Partition Device Name = C's Device Name Transaction ID = XXXX Call Security Status = Unauthenticated SRTP info will not be available Security Indicator = MEDIA_NOT_ENCRYPT CallAttributeInfo in devspecific part of LineCallInfo of C will contain B's info CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallSecurityStatus = Not Authenticated Recording Session is started Line_CallDevSpecific (dwparam1 = RecordingStarted) will be fired for C Line_CallDevSpecific(dwparam1 = DevSpecifcData, dwparam2 = CallAttributeInfo) will be fired to C
LineGetCallInfo on C	SRTP info will not be available Security Indicator = MEDIA_NOT_ENCRYPT CallAttributeTye = CallAttribute_SilentMonitorCall_Target Address = B's DN, Partition = B's Partition Device Name = B's Device Name Transaction ID = XXXX CallAttributeTye = `CallAttribute_RecordedCall' Address = D's DN, Partition = D's Partition Device Name = D's Device Name Transaction ID = 0 Call Security Status = Not Authenticated

Shared Lines-Initiating a New Call Manually

Table A-53 describes the message sequences for Shared Lines-Initiating a new call manually where Party A and Party A' represent shared line appearances. Also, Party A and Party A' are idle.

Table A-53 Message Sequences for Shared Lines-Initiating a New Call Manually 

Action	CTI Messages	TAPI Messages	TAPI Structures
1. Party A goes off-hook	NewCallEvent, CH=C1, GCH=G1, Calling=A, Called=NP, OrigCalled=NP, LR=NP, State=Dialtone, Origin=OutBound, Reason=Direct, RIU=false	LINE_APPNEWCALL hDevice=A dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-1 dwParam3=OWNER	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP, RIU=false	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALTONE dwParam2=UNAVAIL dwParam3=0	No change
	Party A'
	NewCallEvent, CH=C1, GCH=G1, Calling=A', Called=NP, OrigCalled=NP, LR=NP, S tate=Dialtone, Origin=OutBound, Reason=Direct, RIU=true	LINE_APPNEWCALL hDevice=A' dwCallbackInstance=0 dwParam1=0 dwParam2=hCall-2 dwParam3=OWNER	LINECALLINFO (hCall-2) hLine=A' dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A' dwCalledID=NP dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Dialtone, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP, RIU=true	LINE_CALLSTATE hDevice=hCall-2 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=INACTIVE dwParam3=0	No change
2. Party A dials Party B	Party A
	CallStateChangedEvent, CH=C1, State=Dialing, Cause=CauseNoError, Reason=Direct, Calling=A, Called=NP, OrigCalled=NP, LR=NP, RIU=false	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=DIALING dwParam2=0 dwParam3=0	No change
	Party A'
	None	None	None
3. Party B accepts call	Party A
	CallPartyInfoChangedEvent, CH=C1, CallingChanged=False, Calling=A, CalledChanged=true, Called=B, Reason=Direct, RIU=false	Ignored	No change
	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP, RIU=false	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=PROCEEDING dwParam2=0 dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1= CALLERID, CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP, RIU=false	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=RINGBACK dwParam2=0 dwParam3=0	No change
3. Party B accepts call (continued)	Party A'
	CallPartyInfoChangedEvent, CH=C1, CallingChanged=False, Calling=A', CalledChanged=true, Called=B, Reason=Direct, RIU=true	Ignored	No change
	CallStateChangedEvent, CH=C1, State=Proceeding, Cause=CauseNoError, Reason=Direct, Calling=A', Called=B, OrigCalled=B, LR=NP, RIU=true	LINE_CALLSTATE hDevice=hCall-2 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=INACTIVE dwParam3=0 LINE_CALLINFO hDevice=hCall-2 dwCallbackInstance=0 dwParam1= CALLERID, CALLEDID dwParam2=0 dwParam3=0	LINECALLINFO (hCall-2) hLine=A' dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A' dwCalledID=B dwConnectedID=NP dwRedirectionID=NP dwRedirectionID=NP
	CallStateChangedEvent, CH=C1, State=Ringback, Cause=CauseNoError, Reason=Direct, Calling=A', Called=B, OrigCalled=B, LR=NP, RIU=true	LINE_CALLSTATE hDevice=hCall-2 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=INACTIVE dwParam3=0	No change
4. Party B answers call	Party A
	CallStateChangedEvent, CH=C1, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=A, Called=B, OrigCalled=B, LR=NP, RIU=false	LINE_CALLSTATE hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=ACTIVE dwParam3=0 LINE_CALLINFO hDevice=hCall-1 dwCallbackInstance=0 dwParam1=CONNECTEDID dwParam2=0, dwParam3=0	LINECALLINFO (hCall-1) hLine=A dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A dwCalledID=B dwConnectedID=B dwRedirectionID=NP dwRedirectionID=NP
	Party A'
	CallStateChangedEvent, CH=C1, State=Connected, Cause=CauseNoError, Reason=Direct, Calling=A', Called=B, OrigCalled=B, LR=NP, RIU=true	LINE_CALLSTATE hDevice=hCall-2 dwCallbackInstance=0 dwParam1=CONNECTED dwParam2=INACTIVE dwParam3=0 LINE_CALLINFO hDevice=hCall-2 dwCallbackInstance=0 dwParam1=CONNECTEDID dwParam2=0, dwParam3=0	LINECALLINFO (hCall-2) hLine=A' dwCallID=T1 dwOrigin=OUTBOUND dwReason=DIRECT dwCallerID=A' dwCalledID=B dwConnectedID=B dwRedirectionID=NP dwRedirectionID=NP

SRTP

Media Terminate by Application (Open Secure CTI Port or RP)

•Negotiate version

•Sends LineOpen with extension version as 0x8007000

•Send CciscoLineDevSpecificUserSetSRTPAlgorithmID

•Send CCiscoLineDevSpecificUserControlRTPStream

•Now, the CTI port or RP gets registered as secure port

•Make call from secure IP phone to the CTI port or RP port

•Answer the call from application

•SRTP indication gets reported as LineDevSpecific event

•SRTP key information get stored in LINECALLINFO::devSpecifc for retrieval

Media Terminate by TSP Wave Driver (open secure CTI port)

•Negotiate version

•Sends LineOpen with extension version as 0x4007000

•Send CciscoLineDevSpecificUserSetSRTPAlgorithmID

•Send CciscoLineDevSpecificSendLineOpen

•Now, the CTI port gets registered as secure port

•Make call from secure IP phone to the CTI port

•Answer the call from application

•SRTP indication gets reported as LineDevSpecific event

•SRTP key information get stored in LINECALLINFO::devSpecifc for retrieval

Support for Cisco IP Phone 6900 Series

Use cases related to Cisco Unified IP Phone 6900 Series support feature are mentioned below:

Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group

Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior when User is added to new user Group.
Test Setup	A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 Phone with Roll Over Mode User is added to New User Group. Application does Line Initialize
Expected Results	Lines on the Cisco Unified IP Phone 7931 will be enumerated. Application would be able to Open Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 and it would be able to control and perform call operations on Phone.

Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior when User is added to new user Group.
Test Setup	A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode Step 1: Application does Line Initialize Step 2: User is added to New User Group.
Expected Results	Step 1: Lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 will not be enumerated Application will not be notified about the device A and it will not be able to monitor. Step 2: Application will be receiving PHONE_CREATE and LINE_CREATE events for the Device and lines on that Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode. Now Applications would be able to Monitor and control Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.

Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Transfer scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to new user Group.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers SetupTransfer on A. Variants: Application Opens only Line A on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931
Expected Results	Call on A will go to OnHold State. New call will be created on Line B. Application then has to complete Transfer using DTAL feature. Variants: Applications would not be able to Complete Transfer from Application as the Line B is not monitored.

Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is added to New User Group

Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is added to New User Group
Description	Testing Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D are two SCCP phones Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize C calls A,A answers SetupConference on A.
Expected Results	Call on A will go to OnHold State. New call will be created on Line B. Application then has to complete Conference using Join Across Lines feature.

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is added to New User Group
Description	Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 2 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers SetupTransfer on A.
Expected Results	Call on A will go to OnHoldPendingTransfer/OnHoldPendingConference. New Consult call will be created on Line A. Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants	Test the same Scenario with Conference LineCompleteTransfer with Mode as Conference to complete Conference

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - Roll Over to any Line Max Number of Calls: 2 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers SetupTransfer on A.
Expected Results	Call on A will go to OnHoldPendingTransfer/OnHoldPendingConference. New Consult call will be created on Line A. Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants	Test the same Scenario with Conference LineCompleteTransfer with Mode as Conference to complete Conference

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Lines A and B are configured with Different DN Outbound Roll Over Mode - Roll Over within same DN Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers SetupTransfer on A.
Expected Results	SetupTransfer Request will fail with error "LINEERR_CALLUNAVAIL".
Variants	Test the same Scenario with SetupConference

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Lines A and B are configured with Different DN Outbound Roll Over Mode - Roll Over within same DN Max Number of Calls: 2 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers SetupTransfer on A.
Expected Results	Call on A will go to OnHoldPendingTransfer/Conference State. New Consult call will be created on Line A. Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants	Test the same Scenario with SetupConference

LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Lines A and B are configured with Different DN Outbound Roll Over Mode - Roll Over within same DN" or "Roll Over to Any Line Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers LineMakeCall on A.
Expected Results	LineMakeCall Operation will fail with error "LINEERR_CALLUNAVAIL". Roll Over Doesn't Happen to second line as the roll over is only for Outbound Calls.

LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group

LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Lines A and B are configured with Different DN Outbound Roll Over Mode - Roll Over within same DN" or "Roll Over to Any Line Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers LineUnPark on A.( tires to retrieve the available Parked Call from Park DN)
Expected Results	LineUnPark Operation will fail with error "LINEERR_CALLUNAVAIL". Roll Over Doesn't Happen to second line as the roll over is only for Outbound Calls.

EM Login/Logout Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

EM Login/Logout Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing EM Log In/Out Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. EM Profile is logged onto the Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. Test the Use Case from UseCase#1 to UseCase#10
Expected Results	Same as the Use Case tested.

Manual Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group

Manual Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Existing Call Events on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - Roll Over to any Line Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. Step 1: From Phone C call A Step 2: Answer the Call on A Step 3: Press Transfer Button on Cisco Unified IP Phone 6900 Series and Dial D. Step 4: Answer the Call on D Step 5: Complete Transfer from Phone A Variant: Monitor Phones after Transfer is completed from Phone.
Expected Results	Step 4: Call on Line A will be in OnHold State. Call on Line B will be in Connected State. Note When consult call is created on the same Line; Call will be on ONHOLDPENDINGTRANSFER state. Step 5: Both the calls on A and B will go to IDLE state. C and D will be in Simple Call. Variant: Same as this Use Case

Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group

Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. Step 1: From Phone C call A Step 2: Answer the Call on A Step 3: Press conference Button on Cisco Unified IP Phone 6900 Series and Dial D. Step 4: Answer the Call on D Step 5: Complete Conference from Phone Variant: Monitor Phones after Conference is completed from Phone.
Expected Results	Step 4: Call on Line A will be in OnHold State. Call on Line B will be in Connected State. Note When consult call is created on the same Line; Conference Model is created as today on Non-Cisco Unified IP Phone 6900 Series. Step 5: A ,C and D will be in conference Conference model will be created on Line A. Variant: Same as this Use Case.

Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group

Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. Step 1: From Phone C call A Step 2: Answer the Call on A Step 3: Press conference Button on Cisco Unified IP Phone 6900 Series Phone and Dial D. Step 4: Answer the Call on D Step 5: Complete Conference from Phone Variant: Monitor Phones after Conference is completed from Phone.
Expected Results	Step 4: Call on Line A will be in OnHold State. Call on Line B will be in Connected State. Note When consult call is created on the same Line; Conference Model is created as today on Non-Cisco Unified IP Phone 6900 Series Phone. Step 5: A ,C and D will be in conference Conference model will be created on Line A. Variant: Same as this Use Case.

SetupConference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

SetupConference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup	User is added to New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Roll Over to any Line" Max Number of Calls: 1 Busy Trigger : 1 Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. C calls A,A answers Step 1: SetupTransfer on A. Step 2: Complete Conference From Phone.
Expected Results	Step 1: Call on Line A will be in OnHold State. Call on Line B will be in Connected State. Step 5: A ,C and D will be in conference Conference model will be created on Line A.

BWC on Cisco Unified IP Phone 7931 in Non Roll Over Mode when User is Removed from New User Group

BWC on Cisco Unified IP Phone 7931 in Non Roll Over Mode When User is removed from New User Group
Description	Testing Cisco Unified IP Phone 7931 Phone behavior in Non Roll Over Mode When User is removed from New User Group.
Test Setup	User is Removed from New User Group. A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Non-Roll Over Mode C, D is two SCCP phones. Outbound Roll Over Mode - "Non Roll Over Mode" Max Number of Calls: 1 Busy Trigger: 1 Application does Line Initialize
Expected Results	Lines on the Cisco Unified IP Phone 7931 will be enumerated. Application would be able to Open Cisco Unified IP Phone 7931 with Non-Roll Over Mode and it would be able to control and perform call operations on Phone.

Acquire Device on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group

Acquire Device on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description	Testing Behavior of Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 on Super Provider when User is added to new user Group.
Test Setup	A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode User is Added to New User Group. Step 1: Application does Line Initialize Step 2: LineDevSpecific to Acquire Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931. Step 3: User is removed from New User Group.
Expected Results	Step 2: Application will be receiving PHONE_CREATE and LINE_CREATE events for the Device and lines on that Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode. Step 3: Application will be receiving LINE_REMOVE and PHONE_REMOVE for the Cisco Unified IP Phone 7931 and Application will no longer be able to monitor or control that device.

Support for Cisco Unified IP Phone 6900 and 9900 Series Use Cases

The use cases related to Support for Cisco Unified IP Phone 6900 and 9900 Series are provided below:

Check Max Calls Information .

Action	Events, Requests, and Responses
Application calls LineInitialize Application calls LineGetDevCaps, and checks Max Calls field.	LineInitialize successful MaxCalls = 4 in LineDevCaps:DevSpecific

Check Busy Trigger I nformation

.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks busy trigger field.	LineInitialize successful BusyTrigger = 2 in LineDevCaps:DevSpecific

Check Line Instance

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks line instance field.	LineInitialize successful LineInstanceNumber = 1 in LineDevCaps:DevSpecific

Check Line Label

.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks line label field.	LineInitialize successful LineLable = label_2000 in LineDevCaps:DevSpecific

Check Voice Mail Pilot

.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks Voice Mail Pilot field.	LineInitialize successful VoiceMailPilot = 5000 in LineDevCaps:DevSpecific

Check Registered IP Address of the Device or Line

.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks IP address field.	LineInitialize successful RegisteredIPv4Address & RegisteredIPv6Address available in LineDevCaps:DevSpecific
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check IP address field.	PhoneInitialize successful RegisteredIPv4Address & RegisteredIPv6Address available in PhoneDevCaps:DevSpecific

Check Consult Rollover Information of the Line

ConsultRollOver is true for the device

.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks consult roll over field.	LineInitialize successful ConsultRollOver flag is true in LineDevCaps:DevSpecific
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.	PhoneInitialize successful ConsultRollOver flag is true in PhoneDevCaps:DevSpecific.
Variance: Phone does not support rollover Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.	PhoneInitialize successful ConsultRollOver flag is false in PhoneDevCaps:DevSpecific.

Check JAL or DTAL Information of the Line

JAL or DTAL is true for the device.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks JAT/DTAL field.	LineInitialize successful JoinAcrossLine and DirectTransferAcrossLine flag is true in LineDevCaps:DevSpecific.
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.	PhoneInitialize successful JoinAcrossLine and DirectTransferAcrossLine flag is true in PhoneDevCaps:DevSpecific.
Variance: Phone does not support jal/dtal Perform PhoneInitialize and check PhoneGetDevCpas to check JAT/DTAL field.	PhoneInitialize successful JoinAcrossLine and DirectTransferAcrossLine flag is false in PhoneDevCaps:DevSpecific.

Handle Voice Mail Pilot Change

Voice Mail Pilot number is changed to 6000.

Action	Events, Requests, and Responses
Application does LineInitialize Application calls LineGetDevCaps, and checks Voice Mail Pilot field.	LineInitialize successful VoiceMailPilot = 5000 in LineDevCaps:DevSpecific
Voice Mail Pilot number is changed to 6000.	LineDevSpecific (SLDSMT_LINE_PROPERTY_CHANGED) indicating Voice Mail Pilot is changed.
Application calls LineGetDevCaps, and checks Voice Mail Pilot field.	VoiceMailPilot = 6000 in LineDevCaps:DevSpecific
Variance: also applies to Line Label

Check IP Address when Device is Unregistered or Registered

It is assumed that phone uses static IP address (dual stack) and is already registered.

Action	Events, Requests, and Responses
Application calls LineInitialize Application calls LineGetDevCaps, and checks IP address field.	Initializesuccessful RegisteredIPv4Address & RegisteredIPv6Address available in LineDevCaps:DevSpecific, and RegisteredIPAddressMode is IPAddress_IPv4_IPv6.