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.
IP Address of A is available to TAPI application that is monitoring party B
Consultation Transfer
TAPI application monitors party C
Party B represents an IP phone
A talks to B
B intiates a consultation transfer call to C
IP Address of B is available to TAPI application that is monitoring party C.
B Completes the transfer
Calling IP address of A is not available to TAPI application that is monitoring party C (not a supported scenario).
Consultation Conference
TAPI application monitors party C
Party B represents an IP phone
A talks to B
B initiates a consultation conference call to C
IP Address of B is available to TAPI application that is monitoring party C.
B Completes the conference
Calling IP address of A and B is not available to TAPI application that is monitoring party C (not a supported scenario)
Redirect
TAPI application monitors party B and party C
Party A represents an IP phone
A calls B
IP Address of A is available to TAPI application that is monitoring party B
Party A redirects B to party C
Calling IP address is not available to TAPI application that is monitoring party B (not a supported scenario)
Calling IP address B is available to TAPI application that is monitoring party C
Calling Party Normalization
Incoming Call from PSTN to End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a PSTN number 5551212/<SUBSCRIBER> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=5551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=5551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=5551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Incoming Call from National PSTN to CTI-Observed End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a Dallas PSTN number 5551212/<NATIONAL> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=9725551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=9725551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=9725551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Incoming Call from International PSTN to CTI-Observed End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a PSTN number in India 22221111/<INTERNATIONAL> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=011914422221111, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=011914422221111, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=011914422221111, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type = UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number 5551212/<NATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=5551212, UnModified Original Called Party=5551212, Modified Calling Party=2000, Modified Called Party=5551212, Modified Original Called Party=5551212, Globalized Calling party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=SUBSCRIBER, Original Called Party Number Type,=SUBSCRIBER State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=5551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= SUBSCRIBER, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to National PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a Dallas PSTN number 9725551212/<NATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=9725551212, UnModified Original Called Party=9725551212, Modified Calling Party=2000, Modified Called Party=9725551212, Modified Original Called Party=9725551212, Globalized Calling party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=NATIONAL, Original Called Party Number Type,=NATIONAL State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=9725551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= NATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to International PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number in India 914422221111/<INTERNATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=011914422221111, UnModified Original Called Party=011914422221111, Modified Calling Party=2000, Modified Called Party=011914422221111, Modified Original Called Party=011914422221111, Globalized Calling party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type=INTERNATIONAL, Original Called Party Number Type,=INTERNATIONAL State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=011914422221111, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type = INTERNATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=
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
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)
Forced Authorization and Client Matter Code Scenarios
Manual Call to a Destination that Requires an FAC
Table A-3 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-3 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-4 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-4 Message Sequences for Manual Call to a Destination that Requires both FAC and CMC
lineMakeCall to a Destination that Requires an FAC
Table A-5 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-5 Message Sequences for lineMakeCall to a Destination that Requires an FAC
lineMakeCall to a Destination that Requires Both FAC and CMC
Table A-6 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-6 Message Sequences for lineMakeCall to a Destination that Requires Both FAC and CMC
Table A-7 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-7 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.
Intercom
This configuration gets used for all the following use cases:
1. IPPhone A has two lines, line1 (1000) and line2 (5000). Line2 represents an intercom line. Speeddial to 5001 with label ìAssistant_1î gets configured.
2. IPPhone B has three lines, line1 (1001), line2 (5001), and Line3 (5002). Line2 and Line3 represent intercom lines. Speeddial to 5000 with label ìManager_1î gets configured on line2. Line 3 does not have Speeddial configured for it.
3. IPPhone C has two lines, line1 (1002) and line2 (5003). 5003 represents an intercom line that is configured with Speeddial to 5002 with label ìAssistant_5002î.
4. IPPhone D has one line (5004). 5004 represnts an intercom line.
5. CTIPort X has two lines, line1 (2000) and line2 (5555). Line2 represents an intercom line. Speedial to 5001 gets configured with label ìAssistant_1î.
6. Intercom lines (5000 to 5003) exists in same partition = Intercom_Group_1 and they remain reachable from each other. 5004 exists in Intercom_Group_2.
7. Application monitoring all lines on all devices.
Assumption: Application initialized and CTI provided the details on speeddial and lines with intercom line on all the devices. Behavior should act the same for phones that are running SCCP, and those that are running SIP.
Application Invoking Speeddial
Action
Events
LineOpen on 5000 & 5001
Initiate InterCom Call on 5000
For 5000
receive LINE_CALLSTATE
cbInst=x0
param1=x03000000
param2=x1, ACTIVE
param3=x0,
Receive StartTransmission event
For 5001
receive LINE_CALLSTATE
cbInst=x0
param1= x03000000
param2=x1, ACTIVE
param3=x0,
Receive StartReception event
Receive zipzip tone with reason as intercom
Agent Invokes Talkback
Table 2:
Action
Events
Continuing from the previous use case, 5001 initiates LineTalkBack from application on the InterCom call
For 5000
receive LINE_CALLSTATE
device=x10218
param1=x100, CONNECTED
param2=x1, ACTIVE
param3=x0,
Receive StartReception event
For 5001
receive LINE_CALLSTATE
device=x101f6
cbInst=x0
param1=x100, CONNECTED
param2=x1, ACTIVE
param3=x0,
Receive StartTransmission event
Change the SpeedDial
Action
Events
Open line 5000
LineChangeSpeeddial request (speeddial to 5003, label = "Assistant_5003")
The new speed dial and label is successfully set for the intercom line
Receive LineSpeeddialChangeEvent from CTI
Send LINE_DEVSPECIFIC to indicate that speeddial and label changed
Application issues LIneGetDevCaps to retrieve speeddial/label that is set on the line
TAPI returns configured speeddial/label that is configured on the line.
IPv6 Use Cases
The use cases related to IPv6 are provided below:
Register CTI Port with IPv4 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4 .
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4 only on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv4. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is able to register CTI Port with IPv4 address.
Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv6.
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv6 only on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL
Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4_v6.
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4_v6 on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL
IPv6 Phone A calls IPv6 Phone B
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv6 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: Blank
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of B.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of A.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv4_v6 Phone calls IPv6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv4_v6 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: IPv4 address of A
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of B.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of A.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv4 Phone Calls IPv6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv4 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: IPv4 address of A
FarEndIPAddressIpv6:
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv4 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv4 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv6 Phone Calls IPv4 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv6 only calls Phone B which is IPv4
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress:
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo will contain the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv4 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv4 address of B.
IPv6 Phone Calls IPv4_v6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Phone A which is IPv6 only calls Phone B which is IPv4_v6 only.
3. Open lines A and B
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
Existing Call, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress:
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of Phone A.
ReceptionRTPDestinationAddress = IPv6 address of B.
Common Device Configuration Device Mode Changes from IPv4_v6 to IPv4.
Steps
Expected Result
User changes the device configuration on common device configuration from IPv4_v6 to IPv4 only
Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv6 get a LINE_CLOSE Event. Application can then re-register these lines later.
Common Device Configuration Device Mode Changes from IPv4 to IPv6 .
Steps
Expected Result
User changes the device configuration on common device configuration from IPv4 only to IPv6 only
Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv4 get a LINE_CLOSE Event. Application can then re-register these lines later.
Join Across Lines
Setup
Line A on device A
Line B1 and B2 on device B
Line C on device C
Line D on device D
Line B1' on device B1', B1' is a shared line with B1
Join Two Calls from Different Lines to B1
Action
Expected Events
A ‡ B1 is HOLD
For A
C ‡ B2 is connected
LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
For B1: LINE_CALLSTATE param1=x100, HOLD Caller = A, Called = B1, Connected = A
For B2: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
For B1': LINE_CALLSTATE param1=x100, CONNECTED, INACTIVE Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call
For A
CONNECTED
CONFERENCED Caller=A, Called=B1, Connected=B1
CONFERENCED Caller=A Called=C, Connected=C
For B1
CONNECTED
CONFERENCED Caller=A, Called=B1, Connected=A
CONFERENCED Caller=B1 Called=C, Connected=C
For B2
Call will go IDLE
For C
CONNECTED
CONFERENCED Caller=C, Called=B2, Connected=B1 (or A)
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.
Manual Outbound Call
Table A-8 describes the message sequences for Manual Outbound Call when party A is idle.
Table A-8 Message Sequences for Manual Outbound Call
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.
Presentation Indication
Making a Call Through Translation Pattern
Table A-9 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-9 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-10 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-10 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
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
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.
Table A-19 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-19 Message Sequences for Shared Lines-Initiating a New Call Manually
Media Terminate by Application (Open Secure CTI Port or RP)
•Negotiate version
•Sends LineOpen with extension version as 0x8007000
•Send CciscoLineDevSpecificUserSetSRTPAlgorithmID
•Send CCiscoLineDevSpecificUserControlRTPStream
•Now, the CTI port or RP gets registered as secure port
•Make call from secure IP phone to the CTI port or RP port
•Answer the call from application
•SRTP indication gets reported as LineDevSpecific event
•SRTP key information get stored in LINECALLINFO::devSpecifc for retrieval
Media Terminate by TSP Wave Driver (open secure CTI port)
•Negotiate version
•Sends LineOpen with extension version as 0x4007000
•Send CciscoLineDevSpecificUserSetSRTPAlgorithmID
•Send CciscoLineDevSpecificSendLineOpen
•Now, the CTI port gets registered as secure port
•Make call from secure IP phone to the CTI port
•Answer the call from application
•SRTP indication gets reported as LineDevSpecific event
•SRTP key information get stored in LINECALLINFO::devSpecifc for retrieval
Support for Cisco IP Phone 6900 Series
Use cases related to Cisco Unified IP Phone 6900 Series support feature are mentioned below:
Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group
Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior when User is added to new user Group.
Test Setup
A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 Phone with Roll Over Mode
User is added to New User Group.
Application does Line Initialize
Expected Results
Lines on the Cisco Unified IP Phone 7931 will be enumerated.
Application would be able to Open Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 and it would be able to control and perform call operations on Phone.
Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Monitoring Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior when User is added to new user Group.
Test Setup
A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
Step 1: Application does Line Initialize
Step 2: User is added to New User Group.
Expected Results
Step 1: Lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 will not be enumerated
Application will not be notified about the device A and it will not be able to monitor.
Step 2: Application will be receiving PHONE_CREATE and LINE_CREATE events for the Device and lines on that Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode.
Now Applications would be able to Monitor and control Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Transfer scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to new user Group.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
SetupTransfer on A.
Variants: Application Opens only Line A on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931
Expected Results
Call on A will go to OnHold State.
New call will be created on Line B.
Application then has to complete Transfer using DTAL feature.
Variants: Applications would not be able to Complete Transfer from Application as the Line B is not monitored.
Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is added to New User Group
Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is added to New User Group
Description
Testing Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D are two SCCP phones
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize
C calls A,A answers
SetupConference on A.
Expected Results
Call on A will go to OnHold State.
New call will be created on Line B.
Application then has to complete Conference using Join Across Lines feature.
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is added to New User Group
Description
Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 2
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
SetupTransfer on A.
Expected Results
Call on A will go to OnHoldPendingTransfer/OnHoldPendingConference.
New Consult call will be created on Line A.
Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants
Test the same Scenario with Conference
LineCompleteTransfer with Mode as Conference to complete Conference
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - Roll Over to any Line
Max Number of Calls: 2
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
SetupTransfer on A.
Expected Results
Call on A will go to OnHoldPendingTransfer/OnHoldPendingConference.
New Consult call will be created on Line A.
Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants
Test the same Scenario with Conference
LineCompleteTransfer with Mode as Conference to complete Conference
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Lines A and B are configured with Different DN
Outbound Roll Over Mode - Roll Over within same DN
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
SetupTransfer on A.
Expected Results
SetupTransfer Request will fail with error "LINEERR_CALLUNAVAIL".
Variants
Test the same Scenario with SetupConference
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Transfer/Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Transfer/Conference Scenario on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Lines A and B are configured with Different DN
Outbound Roll Over Mode - Roll Over within same DN
Max Number of Calls: 2
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
SetupTransfer on A.
Expected Results
Call on A will go to OnHoldPendingTransfer/Conference State.
New Consult call will be created on Line A.
Application then has to complete Transfer using CompleteTransfer or DTAL feature.
Variants
Test the same Scenario with SetupConference
LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing LineMakeCall Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Lines A and B are configured with Different DN
Outbound Roll Over Mode - Roll Over within same DN" or "Roll Over to Any Line
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
LineMakeCall on A.
Expected Results
LineMakeCall Operation will fail with error "LINEERR_CALLUNAVAIL".
Roll Over Doesn't Happen to second line as the roll over is only for Outbound Calls.
LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll over Mode when User is Added to New User Group
LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing LineUnPark Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Lines A and B are configured with Different DN
Outbound Roll Over Mode - Roll Over within same DN" or "Roll Over to Any Line
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
LineUnPark on A.( tires to retrieve the available Parked Call from Park DN)
Expected Results
LineUnPark Operation will fail with error "LINEERR_CALLUNAVAIL".
Roll Over Doesn't Happen to second line as the roll over is only for Outbound Calls.
EM Login/Logout Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
EM Login/Logout Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing EM Log In/Out Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
EM Profile is logged onto the Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Test the Use Case from UseCase#1 to UseCase#10
Expected Results
Same as the Use Case tested.
Manual Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group
Manual Transfer Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Existing Call Events on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 when User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - Roll Over to any Line
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Step 1: From Phone C call A
Step 2: Answer the Call on A
Step 3: Press Transfer Button on Cisco Unified IP Phone 6900 Series and Dial D.
Step 4: Answer the Call on D
Step 5: Complete Transfer from Phone A
Variant: Monitor Phones after Transfer is completed from Phone.
Expected Results
Step 4:
Call on Line A will be in OnHold State.
Call on Line B will be in Connected State.
Note When consult call is created on the same Line; Call will be on ONHOLDPENDINGTRANSFER state.
Step 5:
Both the calls on A and B will go to IDLE state.
C and D will be in Simple Call.
Variant: Same as this Use Case
Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group
Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Step 1: From Phone C call A
Step 2: Answer the Call on A
Step 3: Press conference Button on Cisco Unified IP Phone 6900 Series and Dial D.
Step 4: Answer the Call on D
Step 5: Complete Conference from Phone
Variant: Monitor Phones after Conference is completed from Phone.
Expected Results
Step 4:
Call on Line A will be in OnHold State.
Call on Line B will be in Connected State.
Note When consult call is created on the same Line; Conference Model is created as today on Non-Cisco Unified IP Phone 6900 Series.
Step 5: A ,C and D will be in conference
Conference model will be created on Line A.
Variant: Same as this Use Case.
Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is A dded to New User Group
Manual Conference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Step 1: From Phone C call A
Step 2: Answer the Call on A
Step 3: Press conference Button on Cisco Unified IP Phone 6900 Series Phone and Dial D.
Step 4: Answer the Call on D
Step 5: Complete Conference from Phone
Variant: Monitor Phones after Conference is completed from Phone.
Expected Results
Step 4:
Call on Line A will be in OnHold State.
Call on Line B will be in Connected State.
Note When consult call is created on the same Line; Conference Model is created as today on Non-Cisco Unified IP Phone 6900 Series Phone.
Step 5: A ,C and D will be in conference
Conference model will be created on Line A.
Variant: Same as this Use Case.
SetupConference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
SetupConference Operation on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 behavior When User is added to New User Group and different Roll Over Mode.
Test Setup
User is added to New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Roll Over to any Line"
Max Number of Calls: 1
Busy Trigger : 1
Application does Line Initialize; Application opens all the lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
C calls A,A answers
Step 1: SetupTransfer on A.
Step 2: Complete Conference From Phone.
Expected Results
Step 1:
Call on Line A will be in OnHold State.
Call on Line B will be in Connected State.
Step 5: A ,C and D will be in conference
Conference model will be created on Line A.
BWC on Cisco Unified IP Phone 7931 in Non Roll Over Mode when User is Removed from New User Group
BWC on Cisco Unified IP Phone 7931 in Non Roll Over Mode When User is removed from New User Group
Description
Testing Cisco Unified IP Phone 7931 Phone behavior in Non Roll Over Mode When User is removed from New User Group.
Test Setup
User is Removed from New User Group.
A,B are two lines on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Non-Roll Over Mode
C, D is two SCCP phones.
Outbound Roll Over Mode - "Non Roll Over Mode"
Max Number of Calls: 1
Busy Trigger: 1
Application does Line Initialize
Expected Results
Lines on the Cisco Unified IP Phone 7931 will be enumerated.
Application would be able to Open Cisco Unified IP Phone 7931 with Non-Roll Over Mode and it would be able to control and perform call operations on Phone.
Acquire Device on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode when User is Added to New User Group
Acquire Device on Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode When User is added to New User Group
Description
Testing Behavior of Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 on Super Provider when User is added to new user Group.
Test Setup
A - Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 with Roll Over Mode
User is Added to New User Group.
Step 1: Application does Line Initialize
Step 2: LineDevSpecific to Acquire Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931.
Step 3: User is removed from New User Group.
Expected Results
Step 2: Application will be receiving PHONE_CREATE and LINE_CREATE events for the Device and lines on that Cisco Unified IP Phone 6900 Series/Cisco Unified IP Phone 7931 in Roll Over Mode.
Step 3: Application will be receiving LINE_REMOVE and PHONE_REMOVE for the Cisco Unified IP Phone 7931 and Application will no longer be able to monitor or control that device.
Support for Cisco Unified IP Phone 6900 Series Use Cases
The use cases related to Support for Cisco Unified IP Phone 6900 Series are provided below:
Check Max Calls Information .
Action
Events, Requests, and Responses
Application calls LineInitialize
Application calls LineGetDevCaps, and checks Max Calls field.
LineInitialize successful
MaxCalls = 4 in LineDevCaps:DevSpecific
Check Busy Trigger I nformation
.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks busy trigger field.
LineInitialize successful
BusyTrigger = 2 in LineDevCaps:DevSpecific
Check Line Instance
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks line instance field.
LineInitialize successful
LineInstanceNumber = 1 in LineDevCaps:DevSpecific
Check Line Label
.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks line label field.
LineInitialize successful
LineLable = label_2000 in LineDevCaps:DevSpecific
Check Voice Mail Pilot
.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks Voice Mail Pilot field.
LineInitialize successful
VoiceMailPilot = 5000 in LineDevCaps:DevSpecific
Check Registered IP Address of the Device or Line
.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks IP address field.
LineInitialize successful
RegisteredIPv4Address & RegisteredIPv6Address available in LineDevCaps:DevSpecific
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check IP address field.
PhoneInitialize successful
RegisteredIPv4Address & RegisteredIPv6Address available in PhoneDevCaps:DevSpecific
Check Consult Rollover Information of the Line
ConsultRollOver is true for the device
.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks consult roll over field.
LineInitialize successful
ConsultRollOver flag is true in LineDevCaps:DevSpecific
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.
PhoneInitialize successful
ConsultRollOver flag is true in PhoneDevCaps:DevSpecific.
Variance: Phone does not support rollover
Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.
PhoneInitialize successful
ConsultRollOver flag is false in PhoneDevCaps:DevSpecific.
Check JAL or DTAL Information of the Line
JAL or DTAL is true for the device.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks JAT/DTAL field.
LineInitialize successful
JoinAcrossLine and DirectTransferAcrossLine flag is true in LineDevCaps:DevSpecific.
Variance: Perform PhoneInitialize and check PhoneGetDevCpas to check consult roll over field.
PhoneInitialize successful
JoinAcrossLine and DirectTransferAcrossLine flag is true in PhoneDevCaps:DevSpecific.
Variance: Phone does not support jal/dtal
Perform PhoneInitialize and check PhoneGetDevCpas to check JAT/DTAL field.
PhoneInitialize successful
JoinAcrossLine and DirectTransferAcrossLine flag is false in PhoneDevCaps:DevSpecific.
Handle Voice Mail Pilot Change
Voice Mail Pilot number is changed to 6000.
Action
Events, Requests, and Responses
Application does LineInitialize
Application calls LineGetDevCaps, and checks Voice Mail Pilot field.
LineInitialize successful
VoiceMailPilot = 5000 in LineDevCaps:DevSpecific
Voice Mail Pilot number is changed to 6000.
LineDevSpecific (SLDSMT_LINE_PROPERTY_CHANGED) indicating Voice Mail Pilot is changed.
Application calls LineGetDevCaps, and checks Voice Mail Pilot field.
VoiceMailPilot = 6000 in LineDevCaps:DevSpecific
Variance: also applies to Line Label
Check IP Address when Device is Unregistered or Registered
It is assumed that phone uses static IP address (dual stack) and is already registered.
Action
Events, Requests, and Responses
Application calls LineInitialize
Application calls LineGetDevCaps, and checks IP address field.
Initializesuccessful
RegisteredIPv4Address & RegisteredIPv6Address available in LineDevCaps:DevSpecific, and RegisteredIPAddressMode is IPAddress_IPv4_IPv6.
Reset device
Phone or line goes out of service.
LineDevSpecific (SLDSMT_LINE_PROPERTY_CHANGED) indicating registered IP address information is changed.
Application calls LineGetDevCaps, and checks IP address field.
The same RegisteredIPv4Address & RegisteredIPv6Address available in LineDevCaps:DevSpecific, but RegisteredIPAddressMode is IPAddress_Unknown.
Device re-registered with CUCM.
Phone or line back in service.
LineDevSpecific (SLDSMT_LINE_PROPERTY_CHANGED) indicating registered IP address information is changed.
Application calls LineGetDevCaps, and checks IP address field.
The same RegisteredIPv4Address and RegisteredIPv6Address available in LineDevCaps:DevSpecific, but RegisteredIPAddressMode is set to IPAddress_IPv4_IPv6.
Variance: Phone uses DHCP and new IP address is obtained for registering.
LineDevSpecific (SLDSMT_LINE_PROPERTY_CHANGED) indicating registered IP address is changed
New IPAddress will be in devSpecific when application queries LineGetDevCap. .
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
Feedback
3XX
