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.
Table A-4 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-4 Message Sequences for Shared Lines-Initiating a New Call Manually
Table A-5 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-5 Message Sequences for Making a Call Through Translation Pattern
1LINE_DEVSPECIFIC events only get sent if the application requested them by using lineDevSpecific().
Blind Transfer Through Translation Pattern
Table A-6 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-6 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
Forced Authorization and Client Matter Code Scenarios
Manual Call to a Destination that Requires an FAC
Table A-7 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-7 Message Sequences for Manual Call to a Destination that Requires an FAC
Manual Call to a Destination that Requires both FAC and CMC
Table A-8 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-8 Message Sequences for Manual Call to a Destination that Requires both FAC and CMC
lineMakeCall to a Destination that Requires an FAC
Table A-9 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-9 Message Sequences for lineMakeCall to a Destination that Requires an FAC
lineMakeCall 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 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-10 Message Sequences for lineMakeCall to a Destination that Requires Both FAC and CMC
Table A-11 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-11 Message Sequences for Timeout Waiting for FAC or Invalid FAC
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.
Refer and Replaces Scenarios
In-Dialog Refer - Referrer in Cisco Unified Communications Manager Cluster
Table A-12 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-12 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-13 describes the message sequences for the Refer and Replaces scenario of in-dialog refer where ReferToTarget redirects the call in Offering state.
Table A-13 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-14 describes the message sequences for the Refer and Replaces scenario of in-dialog refer fails or refer to target is busy.
Table A-14 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-15 describes the message sequences for the Refer and Replaces scenario of out-of-dialog refer.
Table A-15 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-16 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-16 Message Sequences for Invite with Replace for Confirmed 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-17 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-17 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
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-17 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-18 Message Sequences for Refer with Replace for All in Cluster, Replace Dialog Belongs to Another Station
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
3XX
Application monitors B.
Table A-19 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
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
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 1:
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.
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.
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.
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
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
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
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=
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 C onfiguration 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.
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
Swap or Cancel Support
Use cases related to Swap or Cancel feature are mentioned below:
Connected Transfer
Device A, B, C where A is a Cisco Unified IP Phone (future version)..
Action
Expected Events
A ‡ C is on hold
A ‡ B is connected,
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A press transfer
For A:
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-3 DIALTONE
A picks "Active Calls"
Call-3 goes IDLE
A picks call (A‡C) and presses transfer to complete transfer
For A:
Both calls go IDLE
For B1:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected C
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = B
Connected Transfer on Phones with Shared Lines
Device A, B, C, A' where A and A' are sharedline .
Action
Expected Events
A ‡ C is on hold
A ‡ B is connected,
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
For A':
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED_INACTIVE
Caller = A, Called = B Connected B
User performs connected transfer on Cisco Unified IP phone (future version)
For A and A':
All calls go IDLE
For B1:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected C
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = B
Connected Transfer: Initiate from Phone, Complete from CTI
Device A, B, C .
Action
Expected Events
A ‡ C is on hold
A ‡ B is connected,
For A:
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
Application sends either CompleteTransfer or DirectTransfer on A
The scenario will look exactly the same when resume primary call.
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A press "Transfer" to complete transfer
For A:
Calls go IDLE
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = C
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = B
Consult Transfer on Phone: Swap Calls; CTI sends SetupTransfer on Connected Call
Action
Expected Events
A ‡ B
A setup consult transfer to C
And C answer
For A:
Call-1
LINE_CALLSTATE
param1=x100, ONHOLDPENDINGTRANSFER
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A press Swap
For A:
The scenario will look exactly the same when resume primary call.
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
Application calls LineSetupTransfer on A's connected call (A‡B) to initiate transfer
Request succeeds as phone cancels existing feature plan and allow CTI request to go through.
Consult Transfer: Swap and Cancel
Action
Expected Events
A ‡ B
A setup consult transfer to C
And C answer
For A:
Call-1
LINE_CALLSTATE
param1=x100, ONHOLDPENDINGTRANSFER
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A press Swap
For A:
The scenario will look exactly the same when resume primary call.
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A presses Cancel
No TSP event since it is handled during swap operation
RoundTable Connected Conference.
Action
Expected Events
A ‡ B
A puts call on hold
A creates new call to C, C answer
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A presses "Conference"
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, ONHOLDPENDINGCONFENRENCE
Caller = A, Called = C Connected C
Call-3
DIALTONE
A picks active call (A‡ C) on phone UI, and presses "Conference" to complete the conference
For A:
CONNECTED
CONFERENCED
Caller=A, called = B, connected = B
CONFERENCED
Caller = A, called = C, connected = C
Call-3
IDLE
For B:
For A:
CONNECTED
CONFERENCED
Caller=A, called = B, connected = B
CONFERENCED
Caller = B, called = C, connected = C
For C:
For A:
CONNECTED
CONFERENCED
Caller=A, called = C, connected = C
CONFERENCED
Caller = C, called = B, connected = B
RoundTable Connected Conference: Cancel.
Action
Expected Events
A ‡ B
A puts call on hold
A creates new call to C, C answers
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A presses "Conference"
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, CONFERENCED
Caller = A, Called = C Connected C
Call-3
LINE_CALLSTATE
param1=x100, ONHOLDPENDINGCONFENRENCE
Caller = A, Called = C Connected C
Call-4
DIALTONE
A picks "Active Calls"
For A:
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
Call-3 / Call-4
IDLE
A presses Cancel softkey
For A:
Call-1
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
Set Up Consult Conference from RT, then Swap and Complete Conference from RT.
Action
Expected Events
A ‡ B
A sets up conference to C, C answer
For A:
ONHOLDPENDINGCONF
CONFERENCED
Caller = A, called = B, connected = B
CONNECTED
Caller = A, called = C, connected = C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A presses "Swap"
For A:
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x100, HOLD
Caller = A, Called = C Connected C
A presses "Conference" to complete conference
For A:
CONNECTED
CONFERENCED
Caller=A, called = B, connected = B
CONFERENCED
Caller = A, called = C, connected = C
For B:
CONNECTED
CONFERENCED
Caller=A, called = B, connected = B
CONFERENCED
Caller = B, called = C, connected = C
For C:
For A:
CONNECTED
CONFERENCED
Caller=A, called = C, connected = C
CONFERENCED
Caller = C, called = B, connected = B
Set Up Consult Conference from RT, then Swap and Cancel from Phone with Shared Line Scenario
A and A' are shared lines..
Action
Expected Events
A ‡ B
A sets up conference to C, C answers
For A:
ONHOLDPENDINGCONF
CONFERENCED
Caller = A, called = B, connected = B
CONNECTED
Caller = A, called = C, connected = C
For A'
CONNECTED INACTIVE
Caller = A, celled = B, connected = B
CONNECTED INACTIVE
Caller = A, celled = C, connected = C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A presses "Swap"
For A:
The scenario looks the same when primary call resumes
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
A presses "Cancel"
For A:
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected = C
For A'
Call-1
LINE_CALLSTATE
CONNECTED INACTIVE
Caller = A, Called = B Connected = B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected = C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
Set Up Consult Conference from RT: Resume Primary Call (Implicit Cancel).
Action
Expected Events
A ‡ B
A sets up conference to C, C answer
For A:
ONHOLDPENDINGCONF
CONFERENCED
Caller = A, called = B, connected = B
CONNECTED
Caller = A, called = C, connected = C
For A'
CONNECTED INACTIVE
Caller = A, celled = B, connected = B
CONNECTED INACTIVE
Caller = A, celled = C, connected = C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
A resumes A‡B call
For A:
Call-1
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B Connected B
Call-2
LINE_CALLSTATE
param1=x400, HOLD
Caller = A, Called = C Connected C
For B:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = B, Connected = A
For C:
LINE_CALLSTATE
param1=x100, CONNECTED
Caller = A, Called = C, Connected = A
User is Removed from Standard Supports Connected Xfer/Conf Group.
Action
Expected Events
User is in Standard Supports Connected Xfer/Conf group
RT phone A is in user's control list
Application does LineInitialize
RT PHONE/LINE is enumerated to APP
Remove user from "Standard Supports Connected Xfer/Conf" user group
APP receives PHONE_REMOVE / LINE_REMOVE
User is Removed from Standard Supports Connected Xfer/Conf Group.
Action
Expected Events
User is in Standard Supports Connected Xfer/Conf group
RT phone A is in user's control list
Application does LineInitialize
RT PHONE/LINE is enumerated to APP
Remove user from Standard Supports Connected Xfer/Conf user group
APP receives PHONE_REMOVE / LINE_REMOVE
User is Removed from Standard Supports Connected Xfer/Conf Group while Line is Open.
Action
Expected Events
user is in "Standard Supports Connected Xfer/Conf" group
RT phone A is in user's control list
Application does LineInitialize
RT PHONE/LINE is enumerated to APP
App sends LineOpen to open line on Cisco Unified IP phone (future version) phone
Successful
Remove user from Standard Supports Connected Xfer/Conf group
TSP sends LINE_CLOSE
APP receives LINE_REMOVE
User is Added to Standard Supports Connected Xfer/Conf Group.
Action
Expected Events
user is not in "Standard Supports Connected Xfer/Conf" group
RT phone A is in user's control list
Application does LineInitialize
RT PHONE/LINE is not enumerated to APP
Add user to Standard Supports Connected Xfer/Conf group
APP receives PHONE_CREATE / LINE_CREATE
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)
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 configuered.
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 configuered 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 configuered 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.
Logical Partitioning Support
Use cases related to Logical Partitioning feature are mentioned below:
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 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.
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.
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.
Redirect Set Original Called (TxToVM)
