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.
The following list gives abbreviations that are used in the CTI events that are shown in each scenario:
•NP—Not Present
•LR—LastRedirectingParty
•CH—CtiCallHandle
•GCH—CtiGlobalCallHandle
•RIU—RemoteInUse flag
•DH—DeviceHandle
3XX
Application monitors B.
Table A-1 3XX
Actions
CallState/CallInfo @Referrer (A)
CallState/CallInfo @Referree (B)
CallState/CallInfo @Refer-to-Target (C)
A calls external phone that is running SIP, which has CFDUNC set to B
TSPI: LINE_APPNEWCALL
Reason = LINECALL REASON_REDIRECT
Agent Greeting
Configuration
Customer Phone—IP Phone A with DN 1001.
Agent Phone—IP Phone B with DN 1002.
Agent Phone—IP Phone C with DN 1002 (shared line)
Supervisor Phone—IP Phone D with DN 1003.
IVR1—with DN 5555
IVR2—with DN 6666
Procedure
Application monitoring all lines on all devices.
New extension is negotiated when application opens lines.
SRTP is also supported at IVR side, can be variation of following use cases.
Table A-2 StartSendMediaToBIB Success Case
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002 with 5555 and CgpnToIVR
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB by feature
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit is set
Media event sent to application (StartTransmissionEvent)
IVR1 drops call after agent greeting completes
At 1002: Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_ENDED,0,0) event
At 5555: Call goes IDLE
Table A-3 StopSendMediaToBIB Success Case
Action
Events, Requests and Responses
Agent playing is in progress...
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
At 5555: CONNECTED
Calling = 5555 Called = 5555 Connected =
Application issues CCiscoLineDevSpecificStopSendMediaToBIBRequest on 1002
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_ENDED,0,0) event
At 5555: Call goes IDLE StopTransmissionEvent
Table A-4 StartSendMediaToBIB Failure while Monitoring in Progress at Agent Side
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartCallMonitoring on 1003 to monitor active call on 1002
At 1003: CCiscoLineDevSpecificStartCallMonitoring request successful, monitoring is in session
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
At 1002: LINE_REPLY returns with LINEERR_RESOURCEUNAVAIL
Table A-5 StartSendMediaToBIB followed by Monitoring Request
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
Application issues CCiscoLineDevSpecificStartCallMonitoring on 1003 to monitor active call on 1002
At 1003: LINE_REPLY returns with LINEERR_RESOURCEUNAVAIL
Table A-6 StartSendMediaToBIB while Recording is in Session
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application sends CCiscoLineDevSpecificStartCallRecording to 1002
At 1002: CCiscoLineDevSpecificStartCallRecording will be successful and recording is in session
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
IVR1 drops call after agent greeting completes
At 1002: Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_ENDED,0,0) event
At 5555: Call goes IDLE
Table A-7 StartSendMediaToBIB followed by Recording Request
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
Application sends CCiscoLineDevSpecificStartCallRecording to 1002
At 1002: CCiscoLineDevSpecificStartCallRecording will be successful and recording is in session
Table A-8 StartSendMediaToBIB Failure while Barge in Session
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Phone C (1002) barges in
At 1002 (device C) Barge call is created.
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002 (B)
At 1002 (B): LINE_REPLY with LINEERR_RESOURCEUNAVAIL
Table A-9 StartSendMediaToBIB followed by Barge from Shared Line
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
Phone C (1002 shared line) try to barge in
Barge will fail on phone C
Table A-10 1Agent Holds Call while Agent Greeting is being Played
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
1002 put call on hold
At 1002: Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_ENDED,0,0) event Call will go on hold With StopReception and StopTransmission event
At 5555: Call goes IDLE
1002 Unhold scenario
At 1002: Call will go CONNECTED with StartTransmission and StartReception.
1Note: This behavior is also seen during consult operation.
Table A-11 Agent Redirects Call while Agent Greeting is being Played
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
Application redirects call on 1002 to 1003
At 1003: New call from 1002
At 1002: Call goes IDLE No MEDIA_TO_BIB_ENDED event
At 5555: Call goes IDLE
Table A-12 IVR1 Redirects Call to IVR2
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002
(CM feature creates server call to IVR 5555, 5555 answers call)
Server-IVR call is redirected to BIB
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
At 1002: Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_ENDED,0,0) event
At 6666: Call goes IDLE
Table A-13 Application-2 Opened Line after Agent Greeting is in Playing
Action
Events, Requests and Responses
Make call from 1001 to 1002, and 1002 answers
At 1001: CONNECTED
Calling = 1001 Called = 1002 Connected = 1002
At 1002: CONNECTED
Calling = 1001 Called = 1002 Connected = 1001
Application-1 issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002 with 5555 and CgpnToIVR
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB by feature
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
Application-2 opens agent line from another client
At 1002 (from application-2): CallAttributeBitMask SendMediaToBIB will be set to indicate agent greeting is playing on the agent line.
Application 2 opens IVR line
CallAttributeBitMask = BIBCall
Table A-14 Start Agent Greeting after Conference is Setup
Action
Events, Requests and Responses
Make call from 1001 to 1002, 1002 answers, 1002 sets up conference to 1003, 1003 answers, and 1002 completes
At 1001: CONNECTED CONFERENCED
Calling = 1001, Called = 1002, Connected=1002
CONFERENCED
Calling = 1001, Called = 1003, Connected=1003At 1002: CONNECTED CONFERENCED
Calling = 1001, Called = 1002, Connected=1001
CONFERENCED
Calling = 1002, Called = 1003, Connected=1003
At 1003: CONNECTED CONFERENCED
Calling = 1002, Called = 1003, Connected=1002
CONFERENCED
Calling = 1003, Called = 1001, Connected=1001
Application issues CCiscoLineDevSpecificStartSendMediaToBIBRequest on 1002 with 5555 and CgpnToIVR
(CM feature creates server call to IVR1 5555, 5555 answers call)
Server-IVR call is redirected to BIB by feature
IVR1 selects/plays agent's greeting
At 1002: the request is successful Application receives LineCallDevSpecific (SLDSMT_MEDIA_TO_BIB_STARTED) event
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = CgpnToIVR Called = 5555 Connected = CgpnToIVR
CallAttributeBitMask = ServerCall bit will be set
At 5555: CONNECTED, dwreason= LINECALLREASON_UNKNOWN (unknown) ExtendedCallReason= CtiReasonSendMediaToBIB
Calling = 5555 Called = 5555 Connected =
CallAttributeBitMask = ServerCall bit will be set
Media event sent to application (StartTransmissionEvent)
1001 and 1002 also hears the agent greeting
Agent Zip Tone
The devices mentioned in the use cases below also apply to SIP TNP phones.
Configuration
SCCP phones: A (Customer/Remote), B (Agent/Local).
All Lines are Opened with Ext Version - 0x000B0000
Table A-15 Application issues the Play Tone Request when the call is established between Customer and Agent. PlayToneDirection - Remote
Action
Expected Events
LineInitialize. LineOpen on A,B The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line A and B.
A calls B;B answers the Call
B issues LineDevSpecific (start PlayTone) request with Agent callid and ZIPTone as input.
Zip Tone is played at A. LINE_DEVSPECIFIC Event with dwParam1=SLDSMT_CALL_TONE_CHANGEDdwParam2= CTONE_ZIP, dwParam3= 0(local) is reported on A and alsoLINE_DEVSPECIFIC Event with dwParam1=SLDSMT_CALL_TONE_CHANGEDdwParam2= CTONE_ZIP, dwParam3= 1(Remote) is reported on B.
Table A-16 Application issues the Play Tone Request when the call is established between Customer and Agent. PlayToneDirection - Local
Action
Expected Events
LineInitialize. LineOpen on A,B The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line A and B.
A calls B;B answers the Call
B issues LineDevSpecific (start PlayTone) request with agent callid and ZIP Tone as input.
Zip Tone is played at B. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local) is fired for B indicating Zip Tone has been played on B.
Table A-17 Application issues the Play Tone Request when the call is established between Customer and Agent. PlayToneDirection - BothLocalandRemote/NoLocalOrRemote
Action
Expected Events
LineInitialize. LineOpen on A,B A calls B; B answers the Call
B issues LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input
LineDevSpecific (start PlayTone) request fails with error LINEERR_OPERATIONUNAVAIL.
Table A-18 Application issues the Play Tone Request (with Unsupported Tone) when the call is established between Customer and Agent. PlayToneDirection - Local
Action
Expected Events
LineInitialize. LineOpen on A,B A calls B; B answers the Call
B issues LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input
LineDevSpecific (start PlayTone) request fails with error LINEERR_OPERATIONFAILED.
Application issues the Play Tone request on a CTI Port with PlayToneDirection - Local/Remote
Configuration
A (Customer/Remote) is SCCP Phone.
B (Agent/local) is a CTIport/Route Point
Table A-19 Application issues the Play Tone Request on a CTI Port with PlayToneDirection - Local/Remote
Action
Expected Events
LineInitialize. LineOpen on A,B The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line A.
A calls B;B answers the Call
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input, and direction as local.
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input, and direction as remote.
LineDevSpecific (start PlayTone) request fails with error LINEERR_OPERATIONUNAVAIL.
Zip Tone is played at A. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local)) is fired for A indicating Zip Tone has been played on A And also Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 1(remote) is fired for B
Application issues the Play tone request when the call is established between customer and agent (Shared Line). PlayToneDirection - Local
Configuration
SCCP phones: A (Customer/ Remote), B, B' (Agent/Local)
Table A-20 Application issues the Play Tone Request when the call is established between Customer and Agent (Shared Line). PlayToneDirection - Local
Action
Expected Events
LineInitialize. LineOpen on A, B, B' The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B and B'.
A calls B;B and B' starts ringing; B answers the Call
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIP Tone as input.
Variants:
B' issues the LineDevSpecific (start PlayTone) request with agent callid and ZIP Tone as input direction remote.
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIP Tone as input direction remote.
A issues the LineDevSpecific (start PlayTone) request with agent callid and ZIP Tone as input direction remote.
Zip Tone is played at B. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local)) is fired for B indicating Zip Tone has been played on B.
There is no Zip Tone played at B'and no Zip tone notification on B'.
The LineDevSpecific (start PlayTone) request fails with Error LINEERR_OPERATIONFAILED
Zip Tone is played at A. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local))) will be fired for A also Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 1(remote) will be fired for B. There is no Zip Tone played at B'and no Zip tone notification on B'.
Zip Tone is played at B and B'. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local))) is fired for B and B' also Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 1(remote) is fired for A.
Table A-21 Application Issues the Play Tone Request when the call is established between Customer and Agent (Intercom Line). PlayToneDirection - Local
Action
Expected Events
LineInitialize. Phone A have 2 lines: Line1 is a normal line with X, Line2 is a intercom line (B), SpeedDial DN= D
Phone B have 2 lines: Line1 is a normal line with Y, Line2 is a intercom line (D)
LineOpen on B,D The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B, D
B calls D; D starts ringing; D answers the Call
D issues the LineDevSpecific (start PlayTone) request with agent(D) callid and ZIPTone as input.
Variant 1:
D issues the LineDevSpecific (start PlayTone) request with agent(D) callid and ZIPTone as input, and direction as remote.
The LineDevSpecific (start PlayTone) request fails with error LINEERR_OPERATIONUNAVAIL.
The LineDevSpecific (start PlayTone) request fails with error LINEERR_OPERATIONUNAVAIL.
Conference Scenario. PlayToneDirection - local.
Configuration
A, B, and C are SCCP Phones.
Table A-22 Conference Scenario. PlayToneDirection - Local
Action
Expected Events
LineInitialize. LineOpen on A, B, and C The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B.
A calls B;B answers the call; B sets up the conference with C; B completes the conference.
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input.
Variant 1:
B issues the LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input and direction as Remote
Zip Tone is played at B. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local)) is fired for B indicating Zip Tone has been played on B.
The LineDevSpecific (start PlayTone) request will be Success. But there will be no Tone played on the Coneference members. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 1(remote)) is fired for B
Application issues the Play Tone request when the call is established between customer and agent, Agent puts the call on Hold. PlayToneDirection - Remote.
Configuration
A and B are SCCP Phones.
Table A-23 Application issues the Play Tone Request when the call is established between Customer and Agent, Agent puts the call on Hold. PlayToneDirection - Remote
Action
Expected Events
LineInitialize. LineOpen on A,B The CallToneChangedEvent message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B.
A calls B;B answers the Call; B puts the Call on hold
A issues the LineDevSpecific (start PlayTone) request with agent callid and ZIPTone as input.
Zip Tone is played at B. Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 1(remote)) is fired for A also Line_DevSpecific (dwparam1 = SLDSMT_CALL_TONE_CHANGED, dwParam2=CTONE_ZIP, dwParam3= 0(local) is fired for B.
Blind Transfer
Table A-24 describes the message sequences for Blind Transfer when A calls B, B answers, and A and B are connected.
Table A-24 Message Sequences for Blind Transfer
Action
CTI Messages
TAPI Messages
TAPI Structures
Party B does a lineBlindTranfser() to blind transfer call from party A to party C
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW
A receives CPIC and CallStateChangeEvent (Ringback/connected)
Provide TSPI_LinegetcallInfo on A connected with B
Provide TSPI_linegetcallinfo on the Disconnected call
dwParam1 = 0x00004000(LINECALLSTATE_DISCONNECTED)
dwParam2 = 0x00200000(LINEDISCONNECTMODE_SAFCCD)
dwParam3 = 0x00000004
LINECALLINFO.dwCallID = 0x00400BCF
LINECALLINFO.dwOrigin = 0x00000001
LINECALLINFO.dwReason = 0x00000001
LINECALLINFO.dwCallerID = 1900
LINECALLINFO.dwCallerIDName =
LINECALLINFO.dwCalledID = 10XX:
LINECALLINFO.dwCalledIDName = CCD Pattern
LINECALLINFO.dwConnectedID =
LINECALLINFO.dwConnectedIDName =
LINECALLINFO.dwRedirectionID = 1000:
LINECALLINFO.dwRedirectionIDName = CCD Pattern
LINECALLINFO.dwRedirectingID = 1000:
LINECALLINFO.dwRedirectingIDName = CCD Pattern
ExtendCallReason = CtiReasonSAF_CCD_PSTNFailover
Basic Call Initiated from TAPI from Phone A(1900) and B(1901) on Cluster 1, B Redirects to Phone C(1000) on Cluster2 with PSTN Failover Rule Set
Configuration
SCCP phone A and B are registered to cluster A.
Phones A and B are associated with the end-user cluster1.
SCCP phone C(1000) registered to cluster B.
Phones C are associated with the end-user cluster2.
CUCM learns a pattern 10XX, plus PSTN failover rule as 0:1408972 from SAF network.
Procedure
Application monitors A and B.
Application sends a lineMakeCall at A to call B
Table A-25 Basic Call Initiated from TAPI from Phone A(1900) and B(1901) on Cluster 1, B Redirects to Phone C(1000) on Cluster2 with PSTN Failover Rule Set
Action
CTI Messages
TAPI Messages
A dials B
A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing/Proceeding /ringback/connected).
B receives NewCallEvent and CallStateChangeEvent (offering/ringing/ connected).
B setsupconference, consult call to C(1000), this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk
SIP trunk rejects this call due to no more bandwidth available
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, i.e. 14089721000. Call is sent out to a PSTN GW
TSPI_linegetcallinfo on the consult call between B and C.
This call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk
SIP trunk rejects this call due to no more bandwidth available
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, i.e. 14089721000. Call is sent out to a PSTN GW.
B setsupconference, consult call to C(1000), this call first will be intercepted by CCD Requesting Feature, and CCD Requesting feature will extend this call to SIP trunk
SIP trunk rejects this call due to no more bandwidth available
CCD Requesting feature will start PSTN failover by directing this caller to 1000's PSTN failover number, that is, 14089721000. Call is sent out to a PSTN GW
TSPI_linegetcallinfo on the consult call between B and C
This section describes the CallFwdAll Notification usecases.
Application Pressed CFwdAll on TAPI Monitored Device
Application opens the line with new ExtVersion 0x000A0000. User presses CFwdAll softkey on A when device is in on-hook condition.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
User presses CFwdAll softkey
NewCallEvent received for A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask 0x00000040
TAPI Monitored Device Goes Off Hook
Application opens the line with new ExtVersion 0x000A0000. Device goes off hook.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
A goes off-hook
NewCallEvent received for A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000
Application Monitors Off Hook Device
Device goes off hook. Application does a LineInitialize and opens line A with new ExtVersion 0x000A0000
Action
CTI Events
Expected Results
Device goes offhook
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
ExistingCallEvent received at A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallType 00000000
Application Monitors Device after User Presses CFwdAll
User presses CFwdAll softkey on the device. Application does a LineInitialize and opens line A with new ExtVersion 0x000A0000.
Action
CTI Events
Expected Results
User presses CFwdAll softkey on the device
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
ExistingCallEvent received for A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
User Presses CFwdAll Softkey after Device is Off Hook
TAPI application does a LineInitialize and opens line A with new ExtVersion 0x000A0000. Device goes off hook and user presses CFwdAll softkey.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
ExistingCallEvent received for A
A goes off-hook
User presses CFwdAll softkey
NewCallEvent received for A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000
User Presses CFwdAll Softkey on a Multiline Device
TAPI application does LineInitialize and opens all lines- A1 and A2 for the device with new ExtVersion 0x000A0000. User presses the CFwdAll softkey.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A1,
LineOPen on A2 with new ExtVesrion 0x000A0000
User presses CFwdAll softkey
NewCallEvent received for A1
LineGetCallInfo on A1
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
User Presses CFwdAll on a Multiline Device by Selecting a Line
TAPI application does a LineInitialize and opens all lines- A1 and A2 for the device with new ExtVersion 0x000A0000. User selects line A2 and presses CFwdAll softkey.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A1,
LineOPen on A2 with new ExtVesrion 0x000A0000
User selects line A2 and presses CFwdAll softkey
NewCallEvent received for A1
LineGetCallInfo on A2
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000
Shared Line Scenario on Pressing CFwdAll Softkey
TAPI application does a LineInitialize and opens a shared line A with new ExtVersion 0x000A0000 on devices P and Q. User presses CFwdAll softkey on device P.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A
LineOpen on A' with new ExtVesrion 0x000A0000
On device P, user presses `CFwdAll' softkey
NewCallEvent received at A
NewCallEvent received at A' for RIU call
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000000
Cancellation of CFwdAll
TAPI application does a LineInitialize and open line A with new ExtVersion 0x000A0000. User sets CFwdAll for line A by pressing CFwdAll softkey followed by CallFwdAll destination number.
Later, user presses `CFwdAll' softkey again to cancel CFwdAll setting.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A with new ExtVesrion 0x000A0000
User presses CFwdAll and enters FwdAll destination
NewCallEvent received for A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000040
User again presses `CFwdAll' softkey
NewCallEvent received for A
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain CallAttributeBitMask : 0x00000080
Calling Party IP Address
Basic Call
TAPI application monitors party B
Party A represents an IP phone
A calls B
IP Address of A is available to TAPI application that is monitoring party B
Consultation Transfer
TAPI application monitors party C
Party B represents an IP phone
A talks to B
B initiates a consultation transfer call to C
IP Address of B is available to TAPI application that is monitoring party C.
B Completes the transfer
Calling IP address of A is not available to TAPI application that is monitoring party C (not a supported scenario).
Consultation Conference
TAPI application monitors party C
Party B represents an IP phone
A talks to B
B initiates a consultation conference call to C
IP Address of B is available to TAPI application that is monitoring party C.
B Completes the conference
Calling IP address of A and B is not available to TAPI application that is monitoring party C (not a supported scenario)
Redirect
TAPI application monitors party B and party C
Party A represents an IP phone
A calls B
IP Address of A is available to TAPI application that is monitoring party B
Party A redirects B to party C
Calling IP address is not available to TAPI application that is monitoring party B (not a supported scenario)
Calling IP address B is available to TAPI application that is monitoring party C
Calling Party Normalization
Incoming Call from PSTN to End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a PSTN number 5551212/<SUBSCRIBER> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=5551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=5551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=5551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=SUBSCRIBER, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Incoming Call from National PSTN to CTI-Observed End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a Dallas PSTN number 5551212/<NATIONAL> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=9725551212, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=9725551212, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=9725551212, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=NATIONAL, Called Party Number Type= UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Incoming Call from International PSTN to CTI-Observed End Point
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets offered from a PSTN number in India 22221111/<INTERNATIONAL> through a San Jose gateway to a CCM end point 2000
CallStateChangedEvent, UnModified Calling Party=011914422221111, UnModified Called Party=2000, UnModified Original Called Party=2000, Modified Calling Party=011914422221111, Modified Called Party=2000, Modified Original Called Party=2000, Globalized Calling party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type=UNKNOWN, Original Called Party Number Type,=UNKNOWN State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=011914422221111, Displayed Called Party=2000, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=INTERNATIONAL, Called Party Number Type = UNKNOWN, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number 5551212/<NATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=5551212, UnModified Original Called Party=5551212, Modified Calling Party=2000, Modified Called Party=5551212, Modified Original Called Party=5551212, Globalized Calling party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=SUBSCRIBER, Original Called Party Number Type,=SUBSCRIBER State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=5551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +14085551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= SUBSCRIBER, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to National PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a Dallas PSTN number 9725551212/<NATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=9725551212, UnModified Original Called Party=9725551212, Modified Calling Party=2000, Modified Called Party=9725551212, Modified Original Called Party=9725551212, Globalized Calling party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type=NATIONAL, Original Called Party Number Type,=NATIONAL State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=9725551212, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +19725551212, Calling Party Number Type=UNKNOWN, Called Party Number Type= NATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=
Outgoing Call from CTI-Observed End Point to International PSTN Number
Action
CTI Messages
TAPI Messages
TAPI Structures
A Call gets initiated from a CCM end point 2000 through a San Jose gateway to a PSTN number in India 914422221111/<INTERNATIONAL>
CallStateChangedEvent, UnModified Calling Party=2000, UnModified Called Party=011914422221111, UnModified Original Called Party=011914422221111, Modified Calling Party=2000, Modified Called Party=011914422221111, Modified Original Called Party=011914422221111, Globalized Calling party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type=INTERNATIONAL, Original Called Party Number Type,=INTERNATIONAL State=Connected, Origin=OutBound, Reason = Direct
LINE_CALLSTATE = CONNECTED
LINECALLINFO
Displayed Calling Party=2000, Displayed Called Party=011914422221111, Displayed Redirection Party=, Displayed Redirected Party=, Globalized Calling Party = +914422221111, Calling Party Number Type=UNKNOWN, Called Party Number Type = INTERNATIONAL, Redirection Party Number Type=, Redirecting Party Number Type=
Call PickUp
Registering CallPickUpGroup for Notification
Configuration
Service parameter "Auto Call Pickup Enabled" is enabled.
Devices/Lines: 1000:P1,1001:P1.1002:P1,4000:P1 and 4001:P1
Pickup group P1:1111 is configured
P1:1000, P1:1001, P1:1002 are all in pickup group P1:1111
Action
Expected Events
LineIntialize
OpenLines - 1000:P1
Line Open Successful
LineGetDevCaps with Extension Version - 000A0000
CallPickUp Group DN and Partition Information will be sent to application
Application sends CciscoLineDevSpecificRegisterCallPickupGroupForNotification with DN and Partition info of PickUpGroup P1:1111
Line_Reply with success.
LINE_CREATE event will sent to Application for P1:1111
LineOpen for P1:1111
LineOpenSuccessful
LineInService Event as well
LineInfo
DN and Partition information will be pickup Group DN and partition.
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)
Early Offer
The following section describes how the application dynamically registers for various port with Early Offer Support.
Application Dynamically Registers CTI Port with Early Offer Support
Configuration
A - CTI Port in Cluster1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application Data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
Line_Reply with Success LineInserviceEvent reports to Application Line_LineDevState dwParam1 = x040, InService
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster2
Call is being routed through the SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
LINE_DEVSPECIFIC dwParam1 = SLDSMT_RTP_GET_IP_PORT dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 1 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy (8 bits) - IPAddressing Mode
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Info
Line_Reply with Success
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
LINE_DEVSPECIFIC dwParam1 = compressionType & SLDSMT_OPEN_LOGICAL_CHANNEL dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 0 - SetRTP ( 1- App has to set RTP / 0 - App need not set RTP) yy (8 bits) - IPAddressing Mode
LINE_DEVSPECIFIC dwParam1 = compressionType & SLDSMT_OPEN_LOGICAL_CHANNEL dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 1 - SetRTP ( 1- App has to set RTP / 0 - App need not set RTP) yy (8 bits) - IPAddressing Mode
*** Applications have to set the RTP info as the SetRTP flag is set.
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Info
Line_Reply with Success
Media will be set and Media events will be reported
*** Application should not set the RTP Info Again
Variant 1:
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Info
Line_Reply with Error LINEERR_OPERATIONUNAVAIL
But the Media is setup with the RTP information provided at the SLDSMT_RTP_GET_IP_PORT information request
Variant 2:
Application does not set the Filter to receive new Notification using lineDevSpecific (CCiscoLineDevSpecificSetStatusMsgs) and Application does not Set RTP at Proceeding State as there is no Notification
Or
Application does not set RTP info on New Notification
New Notification not reported to Application
Call goes to Disconnect State with cause as LINEDISCONNECTMODE_UNKNOWN
Variant 3: A - CTI Port is Registered Secure
Behavior should be same
Variant 4: Application tried to disable the Early Offer support on the CTI Port that is Dynamically Registered with the Early Offer support
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000000
Line_Devspecific fails with Error LINEERR_OPERATIONUNAVAIL
Application Dynamically Registers CTI Port with out Early Offer Support
Configuration
A - CTI Port in Cluster1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Delayed Offer
Action
TSP Message to Application data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
Line_Reply with Success LineInserviceEvent reports to Application Line_LineDevState Dwparam1 = x040, InService
Application calls LineMakeCall() on A dialing a Party in Cluster2
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
LINE_DEVSPECIFIC dwParam1 = compressionType & SLDSMT_OPEN_LOGICAL_CHANNEL dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 1 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy (8 bits) - IPAddressingMode
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Inf0
Line_Reply with Success
Media will be Setup
Variant 1: A - SCCP/SIP Phone
Behavior is same and new SLDSMT_RTP_GET_IP_PORT Notification will not be fired to application.
Application Dynamically Registers IPV6 CTI Port with Early Offer Support
Configuration
A - CTI Port; CDC - IPV6 Only
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
Application sends lineDevSpecific(CciscoLineDevSpecificSetIPv6AddressAndMode) with MediaCaps Info
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
Line_Reply with Success
Line_Reply with Success
LineInserviceEvent will be repored to Application Line_LineDevState Dwparam1 = x040, InService
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster2
Call is routed through SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
Note SLDSMT_RTP_GET_IP_PORT Notification for IPV6 CTI Port is not supported.
Application has to set the RTP info after OpenLogicalChannel Notification.
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
LINE_DEVSPECIFIC dwParam1 = compressionType & SLDSMT_OPEN_LOGICAL_CHANNEL dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 1 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy (8 bits )- IPAddressingMode
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCallIPv6) with IPAddress and Port Info
•App1 - Dynamically Registers CTI Port/RP with Early Offer Support
•App2 - Dynamically Registers CTI Port/RP without Early Offer Support
*** App1 and App2 are running on Different Client Machines.
Action
TSP Message to Application data
App1 and App2:
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
App1 and App2:
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
App1 and App2:
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
App1:
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
App1:
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
Line_Reply with Success
LineInserviceEvent reports to the application.
App2:
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
Line_Devspecific fails with Error LINEERR_REGISTER_GETPORT_SUPPORT_MISMATCH
Multiple Applications Dynamically Register CTI Port/RP with Early Offer Support
Configuration
A - CTI Port in Cluster1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Applications:
•App1 - Dynamically Registers CTI Port/RP with Early Offer Support
•App2 - Dynamically Registers CTI Port/RP with Early Offer Support
*** App1 and App2 are running on Different Client Machines.
Action
TSP Message to Application data
App1 and App2:
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
App1 and App2:
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
App1 and App2:
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
App1 and App2:
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
App1 and App2:
Application sends lineDevSpecific(CciscoLineDevSpecificPortRegistrationPerCall) with MediaCaps Info
*** Both Applications set with same Capabilities
Line_Reply with Success
LineInserviceEvent reports to Application.
App1:
Application calls LineMakeCall() on A dialing a Party in Cluster2
Call is being routed through the SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
App1 and App2: LINE_DEVSPECIFIC dwParam1 = SLDSMT_RTP_GET_IP_PORT dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 1 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) uy (8 bits) - IPAddressing Mode
App1:
Application sends lineDevSpecific(CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Info
Line_Reply with Success
App2:
Application sends LineDevSpecific (CciscoLineDevSpecificSetRTPParamsForCall) with IPAddress and Port Info different from the Info App1 has set.
Line_Reply with error LINEERR_OPERATIONUNAVAIL
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
LINE_DEVSPECIFIC dwParam1 = compressionType & SLDSMT_OPEN_LOGICAL_CHANNEL dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 0 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy (8 bits) - IPAddressingMode
Application Statically Registers CTI Port with Early Offer Support and then Disable the Early Offer Support
Configuration
A - CTI Port in Cluster1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
Application sends lineDevSpecific(CCiscoLineDevSpecificUserControlRTPStream) with MediaCaps Info
Line_Reply with Success LineInserviceEvent reports to Application Line_LineDevState dwParam1 = x040, InService
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster 2
Call is being routed through the SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
LINE_DEVSPECIFIC dwParam1 = SLDSMT_RTP_GET_IP_PORT dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 0 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy - IPAddressing Mode
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
*** Disconnect the Existing Call
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability -0x00000000 - to disable the Early Offer support
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster 2
Call is being routed through the SIP trunk with Early Offer Enabled
Application Statically Registers CTI Port with out Early Offer Support and then Enables Early Offer Support
Configuration
A - CTI Port in Cluster1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
Application sends lineDevSpecific(CCiscoLineDevSpecificUserControlRTPStream) with MediaCaps Info
Line_Reply with Success LineInserviceEvent reports to Application Line_LineDevState Dwparam1 = x040, InService
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001 - to enable the Early Offer support
Line_Reply with Success
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster2
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
LINE_DEVSPECIFIC dwParam1 = SLDSMT_RTP_GET_IP_PORT dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 0 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy - IPAddressing Mode
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
Media will be set and Media Events will be Reported to Application
Variant 1: A - SCCP/SIP Phone
Behavior is same and new SLDSMT_RTP_GET_IP_PORT Notification will not be fired to application.
Application registers CTI Port with Legacy Wave Driver and enables Early Offer Support
Configuration
A - CTI Port;
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application data
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x000B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
LineInserviceEvent reports to Application Line_LineDevState
Dwparam1 = x040, InService
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Devspecific fails with error LINEERR_OPERATIONUNAVAIL
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster2
Call is routed through SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
Media will be set and Media Events will be reported to Application
Application Registers CTI Port with new Cisco Wave Driver and enables Early Offer Support
Configuration
A - CTI Port;
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Action
TSP Message to Application data
During Installation of CiscoTSP User has to select New Wave Driver.
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
lineOpen() with Extversion - 0x000B0000 for Line A
Line_Open successful
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
LineInserviceEvent reports to Application Line_LineDevState
Dwparam1 = x040, InService
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
Application sends lineDevSpecific(CCiscoLineDevSpecificSetStatusMsgs) with m_DevSpecificStatusMsgsFlag = DEVSPECIFIC_GET_IP_PORT - 0x00000400
Line_Reply with Success
Application calls LineMakeCall() on A dialing a Party in Cluster2
Call is routed through SIP trunk with Early Offer Enabled
A: LINE_CALLSTATE (LINECALLSTATE_PROCEEDING)
LINE_DEVSPECIFIC dwParam1 = SLDSMT_RTP_GET_IP_PORT dwParam2 = 0x00000xyy x (ninth Bit from LSB) - 0 - SetRTP (1- App has to set RTP / 0 - App need not set RTP) yy - IPAddressing Mode
Note On this new Notification, applications has to Open the Port.
Other Party answers the Call
A: LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
Media will be set and Media Events will be reported to Application
Mutiple Applications Statically Register CTI Port
Configuration
A - CTI Port in Cluster 1
Cluster1 and Cluster2 connected via SIP trunk
SIP trunk Supports Early Offer
Applications:
•App1 - Statically Registers CTI Port/RP with Early Offer Support
•App2 - Statically Registers CTI Port/RP without Early Offer Support
*** App1 and App2 are running on Different Client Machines.
Action
TSP Message to Application data
App1 and App2: Both Connecting to same CTI Manager
lineInitialize
Line_reply with Success Lines will be Enumerated to Application.
App1 and App2:
lineOpen() with Extversion - 0x800B0000 for Line A
Line_Open successful
App1 and App2:
LineSetStatusMessages() - with dwLinestates - 0xcc
LineSetStatusMessages returns Success
App1:
Application sends lineDevSpecific(CciscoLineDevSpecificEnableFeatureSupport) with m_Feature - 0x00000001, m_Feature_Capability - 0x00000001
Line_Reply with Success
App1:
Application sends lineDevSpecific(CCiscoLineDevSpecificUserControlRTPStream) with MediaCaps Info to Register A
Line_Reply with Success LineInserviceEvent reports to Application.
App2:
Application sends lineDevSpecific(CCiscoLineDevSpecificUserControlRTPStream) with MediaCaps Info to Register A
Line_Devspecific fails with Error LINEERR_REGISTER_GETPORT_SUPPORT_MISMATCH
Variant: App1 and App2 connecting to different Cti Managers
App2: (After App1 has already registered CtiPort - A)
Application sends lineDevSpecific(CCiscoLineDevSpecificUserControlRTPStream) with MediaCaps Info to register CtiPort A
LineReply - success
LINE_CLOSE for the CTI Port
End-To-End Call Trace
Direct Call Scenario: Variation 1
Application does a LineInitializ. Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Direct Call Scenario: Variation 2
A calls B and B answers the call. Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000.
Action
CTI Events
Expected Results
A calls B. B answers the call
LineInitialize
LineOpen on A, LineOpen on B with new ExtVesrion 0x000A0000
ExistingCallEvent received for A
ExistingCallEvent received for A
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Consult Transfer Scenario: Variation 1
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up transfer to C, C answers the call, and B completes the transfer. A is connected to C.
Action
CTI Event
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on B
(Consultation call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C
(Consultation call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes transfer.
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A
(Call between A and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C2
(Consultation call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Consult Transfer Scenario: Variation 2
A calls B and B answers the call. B sets up transfer to C. Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. Application completes the transfer. A is connected to C.
Action
CTI Events
Expecte Results
A calls B and B answers the call. B setups transfer to C and C answers the call
LineInitialize
LineOpen on A , LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
ExistingCallEvent received for A (Primary Call between A and B)
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
ExistingCallEvent received for B (Primary Call between A and B)
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
ExistingCallEvent received for B (Consultation Call between B and C)
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
ExistingCallEvent received for C (Consultation Call between B and C)
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
(Primary Call between A and B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
(Primary Call between A and B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Applications completes Transfer
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Blind Transfer Scenario
Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B does lineBlindTransfer to C. A is connected to C.
Action
CTI Event
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B lineBlindTransfer to C
NewCallEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Redirect Scenario
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application redirects B to C; A is connected to C.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A , LineOpen on B with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B redirects call to C.C answers the call
NewCallEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Shared Line Scenario
Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000. A calls B, B'. B answers the call.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A , LineOpen on B,
LineOpen on B' with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
NewCallEvent received for B'
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B'
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B'
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Shared Line Scenario with Barge
Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B, B'. B answers the call.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A , LineOpen on B,
LineOpen on B' with new ExtVesrion 0x000A0000
A calls B, B'answers the call
NewCallEvent received for A
NewCallEvent received for B
NewCallEvent received for B'
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B'
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on B'
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B' barges in
NewCallEvent received for B
NewCallEvent received for B'
CallGlobalCallHandleChangedEvent received for B
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
For B'
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
CallGlobalCallHandleChangedEvent received for B'
For B'
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
LineGetCallInfo on B'
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B3
Call Park Scenario: Variation 1
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application initiates a CallPark on B. A is parked on parkedDn. C calls parkDn and C is connected to A
Service Parameter Preserve globalcallid For Parked Calls set to False
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Application initiates linepark on B
C dials parkDn
NewCallEvent received for C
CallGlobalCallHandleChangedEvent received for A
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A2
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A2
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Call Park Scenario: Variation 2
Application does a LineInitialize.Application opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. Application initiates a CallPark on B. A is parked on parkedDn. C calls parkDn and C is connected to A
Service Parameter Preserve globalcallid For Parked Calls set to True
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Application initiates linepark on B
C dials parkDn
NewCallEvent received for C
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
3- Party Conference Call Scenario
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up conference to C, C answers the call, and B completes conference. A, B and C are in conference.
Note For all conference scenarios, conference call leg's Unique Call Reference ID is 0.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A , LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B setupConference to C
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
LineGetCallInfo on B
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallnfo on C
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes conference
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Three-party Conference Drop Down to Two-party Call Scenario
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A calls B and B answers the call. B sets up conference with C, C answers the call, and B completes conference. A,B and C in conference. C drops from the conference.A connected to B.
Action
CTI Events
Expected Results
LineInitialize
Call lineNegotiateVersion with
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B setupConference to C
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on B
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallnfo on C
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call. B completes conference
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
C drops from conference
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
Conference Chaining Scenario using Join
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A, B and C are in Conference1. C, D and E are in another Conference2. Application sends CallJoinRequest to join both the conference calls.
E drops from the conference.
Action
CTI Events
Expected Results
A, B and C are in conference
For A
Unique Call Reference ID = ID1
For B
Unique Call Reference ID = ID2
For C
Unique Call Reference ID = ID3
C, D and E are in conference
For C
Unique Call Reference ID = ID4
For D
Unique Call Reference ID = ID5
For E
Unique Call Reference ID = ID6
Application Joins two confeences
No change in Unique Call Reference ID after join
E drops from Conference
CallGlobalCallHandleChanged received for D
For D
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID1
LineGetCallnfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID
LineGetCallnfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID3
LineGetCallInfo on D
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference ID7
Transfer Call Scenario via QSIP without Path Replacement
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A in Cluster 1 calls B in Cluster 2, B answers the call, and B sets up transfer to C in Cluster 1. C answers the call and B completes the transfer. A connected to C.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on B
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call.B completes transfer.
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Transfer Call Scenario via QSIP with Path Replacement
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000. A in Cluster 1 calls B in Cluster 2, B answers the call and sets up transfer with C in Cluster 1. C answers the call amd B completes the transfer. A connected to C.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
B SetupTransfer to C
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on B
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B2
LineGetCallInfo on C
(Consultation Call between B and C)
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
C answers the call.B completes transfer
CallGlobalCallHandleChangedEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Hunt List Scenario
LineGroup LG1,LG2 and LG3 configured with A,B and C. HuntList "Hunt_List" configured with Line Groups LG1,LG2 and LG3. Hunt Pilot "99999" configured with this "Hunt"List".
Application does a LineInitialize. Application opens all lines with new ExtVersion 0x000A0000. D calls "99999". Call is routed through A, B and C.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A , LineOpen on B,
LineOpen on C,
LineOpen on D
with new ExtVesrion 0x000A0000
D calls Hunt Pilot DN.Call is first offered to Phone A, followed by B and then C.
NewCallEvent received for D
NewCallEvent received for A
For D
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
NewCallEvent received for B
NewCallEvent received for C
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on D
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference D1
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on B
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference B1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C1
Call Pickup Scenario: Variation 1
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000.
B and C in same Call Pickup Group. Service Parameter, Auto Call Pickup Enabled, is set to False. A calls B and C presses the NewCall softkey followed by Call Pickup softkey. Call is redirected to C.
Same Behaviour for Group Pickup.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C
with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
C presses NewCall softkey followed by Call Pickup softkey
NewCallEvent received for C
NewCallEvent received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Call Pickup Scenario: Variation 2
Application does a LineInitialize and opens all lines with new ExtVersion 0x000A0000.
B and C are in the same Call Pickup Group. Service Parameter Auto Call Pickup Enabled is set to True. A calls B, C presses NewCall softkey followed by Call Pickup softkey, and call is redirected to C.
Same Behaviour for Group Pickup.
Action
CTI Events
Expected Results
LineInitialize
LineOpen on A, LineOpen on B,
LineOpen on C
with new ExtVesrion 0x000A0000
A calls B
NewCallEvent received for A
NewCallEvent received for B
For A
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For B
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
C presses NewCall softkey followed by Call Pickup softkey
NewCallEvent received for C
CallGlobalCallHandleChanged received for C
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
For C
LINE_CALLDEVSPECIFIC event is received
dwParam1 = SLDSMT_LINECALLINFO_DEVSPECIFICDATA
dwParam2 = SLDST_UNIQUE_CALL_REF_ID_INFO
dwParam3 = 0
LineGetCallInfo on A
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference A1
LineGetCallInfo on C
LINECALLINFO::DEVSPECIFIC would contain Unique Call Reference C2
Extension Mobility Cross Cluster
Common Configuration
•User A has a device profile EM_Profile1 configured with Line1 in Cluster1 (home cluster)
•CiscoTSP uses CTIManager on Cluster1 (home cluster) in order to open provider
TAPI Application does LineInitializeEx and EMCC User Logs into a Device
Title
EMCC user logs in to a device
Description
Testing the scenario where TAPI Application does LineInitializeEx and EMCCUserLogin to a Device
Test Setup
EM_Profile1 is included in application control list
DeviceH is not in application control list
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to DeviceH on Cluster1.
Expected Results
Step 2:
Application receives LINE_CREATE for Line1
TAPI Application does LineInitializeEx and EMCCUser Logs Out of a Device
Title
EMCC user logs out of a device
Description
Testing the scenario where TAPI Application does LineInitializeEx and EMCCUserLogs out of a Device
Test Setup
EM_Profile1 is included in application control list
DeviceH is not in application control list
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM logout of a device DeviceH on Cluster1.
Expected Results
Step 2:
Application receives LINE_REMOVE for Line1
Application does PhoneInitializeEx and EMCC User Logs in to a Device
Title
EMCC user logs in to a device
Description
Testing the scenario where TAPI Application does PhoneInitializeEx and EMCCUserLogin to a Device
Test Setup
EM_Profile1 is included in application control list
DeviceH is not in application control list
Step 1 Step1: Open the TAPI Application with User A and do PhoneInitializeEx.
Step 2 Step2: User A EM login to DeviceH on Cluster1.
Expected Results
Step 2:
Application receives PHONE_CREATE for Line1
TAPI Application does PhoneInitializeEx and EMCC User Logs out of a Device
Title
EMCC user logs out of a device
Description
Testing the scenario where TAPI Application does PhoneInitializeEx and EMCCUserLogs out of a Device
Test Setup
EM_Profile1 is included in application control list
DeviceH is not in application control list
Step 1 Step1: Open the TAPI Application with User A and do PhoneInitializeEx.
Step 2 Step2: User A EM logout of a device DeviceH on Cluster1.
Expected Results
Step 2:
Application receives PHONE _REMOVE for Line1
EMCC User Logs in to a Device from Cluster 2 (Visiting Cluster)
Title
EMCC user logs in to a device from cluster 2 (visiting cluster)
Description
Testing the scenario where EMCCUser Login to a Device from cluster 2 (visiting cluster)
Test Setup
EM_Profile1 is included in application control list.
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A goes to the Cluster 2(visiting Cluster) and EM login to a device DeviceV.
Expected Results
Step 2:
Application receives LINE_CREATE for Line1
EMCC User Logs out of a Device from Cluster 2 (Visiting Cluster)
Title
EMCC user logs out of a device from cluster 2 (visiting cluster)
Description
Testing the scenario where EMCCUser LogOut of a Device from cluster 2 (visiting cluster)
Test Setup
EM_Profile1 is included in application control list.
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 After the Execution of the above usecase User A EM logout of a device DeviceV.
Expected Results
Step 2:
Application receives LINE_REMOVE for Line1
EMCC User Logs in to a Device with LineH Configured
Title
EMCC user logs in to a device with LineH configured
Description
Testing the scenario where EMCCUserLogin to a Device with LineH configured
Test Setup
EM_Profile1 is included in application control list
DeviceH is included in application control list with LineH configured
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to a device DeviceH on Cluster1.
Expected Results
Step 2:
•Application receives LINE_REMOVE for LineH
•Application receives LINE_CREATE for Line1
EMCC User Logs out of a Device with LineH Configured
Title
EMCC user logs out of a device
Description
Testing the scenario where EMCCUserLogs out of a Device
Test Setup
EM_Profile1 is included in application control list
DeviceH is included in application control list with LineH configured
Step 1 After the Execution of the above usecase User A EM logout of a device DeviceH on Cluster1.
Expected Results
Step 2:
•Application receives LINE_REMOVE for Line1
•Application receives LINE_CREATE for LineH
EMCC User Logs in to a DeviceH Configured for Multiple Lines (LineH)
Title
EMCC user logs in to a DeviceH
Description
Testing the scenario where EMCCUser Login to a DeviceH which is configured for multiple lines
Test Setup
EM_Profile1 is included in application control list
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A goes to the Cluster 2(visiting Cluster) and EM login to a device DeviceH(A device with multiple lines (LineH)).
Expected Results
Step 2:
•Application receives 2 LINE_REMOVE for LineH
•Application receives LINE_CREATE for Line1
EMCC User Logs in to a Device with LineH Configured and Administrator Removes the Device from Application Control list
Title
EMCC user logs in to a device with LineH configured and the administrator removes the device from the Application Control list
Description
Testing the scenario where EMCCUserLogin to a device with LineH configured and administrator removes the device from the Application Control list
Test Setup
EM_Profile1 is included in application control list
DeviceH is included in application control list with LineH configured
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to a device DeviceH on Cluster1.
Step 3 Administrator removes the DeviceH from application control list.
Expected Results
Step 2:
•Application receives LINE_REMOVE for LineH
•Application receives LINE_CREATE for Line1
Step3:
•Application will not receive any events.
EMCC User Logs in and out of a Device with LineH Configured and Administrator Removes the Device from Application Control List
Title
EMCC user logs in and logs out of a device with LineH configured and Administrator removes the device from the Application Control List
Description
Testing the scenario where EMCCUserLogin to a Device with LineH configured and Administrator removes the device from the Application Control List
Test Setup
EM_Profile1 is included in application control list
DeviceH is included in application control list with LineH configured
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to a device DeviceH on Cluster1.
Step 3 User A EM logout of the device DeviceH on Cluster1.
Step 4 Administrator removes the DeviceH from application control list.
Expected Results
Step 2:
•Application receives LINE_REMOVE for LineH
•Application receives LINE_CREATE for Line1
Step3:
•Application receives LINE_REMOVE for Line1
•Application receives LINE_CREATE for LineH
Step4:
•Application receives LINE_REMOVE for LineH
EMCC User Logs in to a Device with LineH Configured and EM_Profile not Included in Application Control List
Title
EMCC user logs in to a device with LineH configured and administrator removes the device from the Application Control list
Description
Testing the scenario where EMCCUserLogin to a device with LineH configured and administrator removes the device from the Application Control list
Test Setup
EM_Profile1 is not included in Application Control list
DeviceH is included in Application Control list with LineH configured
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to a device DeviceH on Cluster1.
Step 3 Administrator removes the DeviceH from application control list.
Step 4 User A EM logout of the device DeviceH on Cluster1.
Expected Results
Step 2:
•Application receives LINE_REMOVE for LineH
•Application receives LINE_CREATE for Line1
Step3:
•Application receives no events since EM_Profile1 is not in control list.
Step4:
•Application receives LINE_REMOVE for LineH
EMCC User Logs in to a DeviceV and EM_Profile is Removed by Administrator from Application Control List
Title
EMCC user logs in to a DeviceV and administrator removes the EM_Profile from the Application Control list
Description
Testing the scenario where EMCCUserLogin to a DeviceV and administrator removes the EM_Profile from Application Control list
Test Setup
EM_Profile1 is included in Application Control list.
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User A EM login to a DeviceV (Visiting Device).
Step 3 Administrator removes the EM_Profile1 from application control list.
Expected Results
Step 2:
•Application receives LINE_CREATE for Line1
Step3:
•Application receives LINE_REMOVE for Line1
EMCC User Logs in to a Device then Application does Provider Open
Title
EMCC user logs in to a DeviceV
Description
Testing the scenario where EMCCUserLogin to a DeviceV(cluster2). Then the application does Provider Open
Test Setup
EM_Profile1 is included in Application Control list
DeviceH is not in Application Control list
Step 1 User A EM login to DeviceV on Cluster2.
Step 2 Open the TAPI Application with User A and do LineInitializeEx.
Expected Results
Step2:
•DeviceV/Line1 will be included in TAPI device/line enumeration
EMCC User Log in to a DeviceV in Visiting Cluster and Administrator Adds the EM_Profile to Application Control List
Title
EMCC user logs in to a DeviceV in Visiting cluster and administrator adds the EM_Profile to the Application Control List
Description
Testing the scenario where EMCCUserLogin to a DeviceV in Visiting cluster and Administrator adds the EM_Profile to the Application Control list
Test Setup
EM_Profile1 is not included in Application Control list
Step 1 Open the TAPI Application with User A and do LineInitializeEx.
Step 2 User B EM login to a DeviceV on Cluster2.
Step 3 Administrator Adds the EM_Profile1 to the application control list.
Expected Results
Step 2:
•Application will not receive any events as EM_Profile1 not in the Application Control list.
Step3:
•Application receives LINE_CREATE for Line1
Extension Mobility Memory Optimization Option
The following section describes common configuration and use cases for Early Offer Support.
Common Configuration
The message flow in Figure A-1 is described below:
•IP Phone_A is configured in DB with lines Line_A1 and LineA2
•User1 has a device profile EM_Profile1 configured with Line_P11
•User2 has a device profile EM_Profile2 configured with lines Line_P21 and Line_P22
Figure A-1 EM Memory Optimization Scenario 1
The message flow in Figure A-2 is described below:
•Application uses Line_N to receive other-device state notifications
Figure A-2 EM Memory Optimization Scenario 2
Use Cases
Use cases related to the EM Memory Optimization Option feature are mentioned below:
•Use Case 1
1. Line_A1 and Line_A2 are not opened
2. EM user with Profile_P1 logs in
3. EM user with Profile_P1 logs out
4. EM user with Profile_P1 logs in
The message flow in Figure A-3 is described in steps 1 to 4.
Figure A-3 EM Memory Optimization Option feature Use case 1
•Use Case 2
1. Line_A1 and Line_A2 has been opened
2. EM user with Profile_P1 logs in
3. Application opens Line_P11
4. EM user with Profile_P1 logs out
5. Application opens Line_A1
The message flow in Figure A-4 is described in steps 1 to 5.
Figure A-4 EM Memory Optimization Option feature Use case 2
•Use Case 3
1. Line_A1 and Line_A2 are not opened
2. EM user with Profile_P1 logs in
3. EM user with Profile_P1 logs out
4. EM user with Profile_P2 logs in
5. EM user with Profile_P2 logs out
The message flow in Figure A-5 is described in steps 1 to 5.
Figure A-5 EM Memory Optimization Option feature Use case 3
•Use Case 4
1. EM user with Profile_P1 logs in
2. Operation request failed on inactive Line_A1
3. EM user with Profile_P1 logs out
4. Operation request failed on inactive Line_P11 with ... error code ...
The message flow in Figure A-6 is described in steps 1 to 4.
Figure A-6 EM Memory Optimization Option feature Use case 4
External Call Control
Basic Call Initiated from TAPI with External Call Control on Translation Pattern and CEPM Returns Reject
Configuration
Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.
Procedure
Application sends a lineMakeCall at A to call B.
Result
Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns Reject.
Party
TSP Message to App data
A initiates Call to B
A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)
Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Divert with Modified Calling and Called Parties
Configuration
Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.
Procedure
Application sends a lineMakeCall at A to call B.
Result
Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.
CEPM returns divertTo=C, with ModifiedCalling= MA and ModifiedCalled = MB
Call will be extended to C (modified calling and modified called in divert to routing directive, overrides the calling and called number transformation configured for translation pattern and the call is diverted to C)
Party
TSP Message to App data
A initiates call to B
A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)
Basic Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties
Configuration
Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled.
Procedure
Application sends a lineMakeCall at A to call B.
Result
Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.
CEPM returns continue with ModifiedCalling= MA and ModifiedCalled = MB
Call will be extended to MB (modified calling and modified called in continue routing directive, overrides the calling & called number transformation configured for translation pattern)
Party
TSP Message to App Data
A initiates Call to B
A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)
Conference Call Initiated from TAPI Using External Call Control on Translation Pattern and CEPM Returns Continue with Modified Calling and Called Parties in the Consult Call
Configuration
Phone A, B, C are in cluster devices.
C matches the translation pattern CXXX which has calling and called party transformation defined to transform B to A1 and C to C1 and External Call Control is also enabled.
Procedure
Application sends a lineMakeCall at A to call B. Application sends a lineSetupConference/lineAddToconference to B to consult conference the call to C.
Result
Dialed number C matches the translation pattern CXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B.
CEPM returns continue with ModifiedCalling= MB and ModifiedCalled = MC
Call will be extended to "MC" (modified calling and modified called in continue routing directive, overrides the calling & called number transformation configured for translation pattern)
After conference is complete, the correct number of CONFERENCE calls are see at all the participants.
Party
TSP Message to App Data
A and B receives Connected Call state
A:
LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
CallerID = A / CalledID = B / ConnectedID = B
mod Calling = A / mod Called = B /
mod Connected = B
B:
LINE_CALLSTATE (LINECALLSTATE_CONNECTED)
CallerID = A / CalledID = B / ConnectedID = A
mod Calling = A / mod Called = B /
mod Connected = A
B does a lineSetupConference / lineDial to call C.
Call is Redirected to a Hunt List of Chaperones and Chaperone Enables Call Recording and Conferences in the Called Party
Configuration
Phone A, C1, D are in cluster devices. B matches the translation pattern BXXX where External Call Control is enabled. Application sends a lineMakeCall at A to call B.
CEPM determines this calls need to have a chaperone's supervise. CEPM returns the permit decision with the obligation <divert>, destination HuntPilot C, which is a hunt pilot of chaperones, and a reason string "chaperone".
CUCM redirects the call to the hunt pilot C, and the chaperone member C1 answers the call.
After talking to A briefly and discovered that A intended to talk to D, the chaperone C1 starts to establish a conference to D. C1 presses the conference softkey and dials D.
CUCM queries CEPM for the call, with calling user C1 with DN C1, and called user D with DN D.
CEPM returns the response with permit decision with <continue> call routing directive, since the policy server detects that the caller is the chaperone.
CUCM rings D's phone and D answers the call.
C1 presses the conference softkey again, and the conference is established.
The chaperone C1 presses the "record" softkey. This triggers the call recording being setup from C1's IP phone to the recorder.
When the call recording is eablished successfully, the recording warning tone is playing to the C1's phone. The recording warning tone is enabled by setting service parameter Play Recording Notification Tone To Observed Target to True.
A and D starts to talk under the supervision of the chaperone.
Party
TSP Message to App Data
A initiates Call to B
A receives NewCallEvent and CallStateChangeEvent (Dialtone/Dialing)
Forced Authorization and Client Matter Code Scenarios
Manual Call to a Destination that Requires an FAC
Table A-31 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-31 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-32 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-32 Message Sequences for Manual Call to a Destination that Requires both FAC and CMC
lineMakeCall to a Destination that Requires an FAC
Table A-33 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-33 Message Sequences for lineMakeCall to a Destination that Requires an FAC
lineMakeCall to a Destination that Requires Both FAC and CMC
Table A-34 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-34 Message Sequences for lineMakeCall to a Destination that Requires Both FAC and CMC
Table A-35 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-35 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.
Hunt List
Phones - A, B, C and X
Hunt Pilots: HP1
Member LG1, LG2, LG3
HP2.
Member LG11, LG12, LG13 are CTI port
Pickup Group1 : has LG1, lG2, LG3, X
Pickup Group2: has HP1, X
TSP app opens all lines, otherwise will be stated in use case.
Basic Hunt List Call
Table A-36 Message Sequence for Basic Hunt List Call
Action
Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1
HuntPilot = HP1
LG1 answers the call
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG2 answers the call
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG2
HuntPilot = HP1
At LG2:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Variance : perform the test with all HuntList algorithm
Top-Down algorithm
Circular algorithm
Longest Idle Time algorithm
Hunt List Call Moved to Next Member
Table A-37 Message Sequence for Hunt List Call Moved to Next Member
Action
Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
Called Name = HP1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call moves from LG1 to LG2
Call at LG1 goes IDLE
At LG2:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
LG2 answers the call
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG2
HuntPilot = HP1
At LG2:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Hunt List Calls FWNA and FWNA is not Configured on HuntPilot
Table A-38 Message Sequence for Hunt List Calls FWNA and FWNA is not Configured on HuntPilot
Action
Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call moves from LG1 to LG2
Call at LG1 goes IDLE
At LG2:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call moves from LG2 to LG3
Call at LG2 goes IDLE
At LG3:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call is aborted since LG3 does not answer the call.
At A: call will go IDLE
LINEDISCONNECTMODE_NOANSWER?
At LG3: call will go IDLE
LINEDISCONNECTMODE_NOANSWER ?
Hunt List Call FWNA with FWNA to B
Table A-39 Message Sequence for Hunt List Call FWNA with FWNA to B
Action
Events, Requests and Responses
App initiates call from A to HP1 and call is offered to LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call moves from LG1 to LG2
Call at LG1 goes IDLE
At LG2:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call moves from LG2 to LG3
Call at LG2 goes IDLE
At LG3:
LINE_CALLSTATE - ACCEPTED
Caller = A,
Called = HP1,
HuntPilot = HP1
Call is FWNA to B, and B answer
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connectedid = B
At LG3: call will go IDLE
At B:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Redirecting = HP1
Redirection = B
Hunt List Call Dropped when Hunt List is Busy and FWB is not Configured
Table A-40 Message Sequence for Hunt List Call Dropped when Hunt List is Busy and FWB is not Configured
Action
Events, Requests and Responses
Make LG1, LG2, LG3 busy
App initiates call from A to HP1
At A:
Call disconnected after it is initiated.
LINEDISCONNECTMODE_BUSY
Hunt List Call is Forwarded when Hunt List is Busy and FWB is Configured to B
Table A-41 Message Sequence for Hunt List Call is Forwarded when Hunt List is Busy and FWB is Configured to B
Action
Events, Requests and Responses
Make LG1, LG2, LG3 busy
App initiates call from A to HP1 and the call is forwarded to B
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
Called Name = HP1
HuntPilot = HP1
At B:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
Redirecting = HP1
Redirection = B
HuntList Call Redirected when in ACCEPT State
Table A-42 Message Sequence for HuntList Call Redirected when in ACCEPT State
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
LG1 redirects call to B
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1: Call goes IDLE
At B:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
RedirectingID = HP1
RedirectionID = B
Hunt List Call Redirected when in Connected State
Table A-43 Message Sequence for Hunt List Call Redirected when in Connected State
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
LG1 answers the call
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 redirects call to B
At A :
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
RedirectingID = LG1
RedirectionID = B
At LG1: Call goes IDLE
At B:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
RedirectingID = LG1
RedirectionID = B
Hunt List Call - Member is CTI or RP Port
Table A-44 Message Sequence for Hunt List Call - Member is CTI or RP Port
Action
Events, Requests and Responses
Same as 8.1, but with CTI port
Similar expectation
Hunt List Call Moved to Different Line Group Members and Answered by CTI Port
Table A-45 Message Sequence for Hunt List Call Moved to Different Line Group Members and Answered by CTI Port
Action
Events, Requests and Responses
Same as 8.2, but with CTI port
Similar expectation
Hunt List Call is Redirected to Another Hunt List
Table A-46 Message Sequence for Hunt List Call is Redirected to Another Hunt List
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
A redirects the call to HP2 and call offered to LG11
At A: Call goes IDLE
At LG1:
LINE_CALLSTATE - RINGBACK
Caller = LG1
HuntPilot = HP1
Called = HP1
HuntPilot = HP1
RedirectionID = HP2
RedirectingID = A
At LG11:
LINE_CALLSTATE - ACCEPTED
Caller = LG1
HuntPilot = HP1
Called = HP2,
HuntPilot = HP2
RedirectionID = HP2
RedirectingID = A
LG11 answers the call
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = LG1
HuntPilot = HP1
Called = HP1
HuntPilot = HP1
Connected = LG11
HuntPilot = HP2
RedirectingID = A
RedirectionID =HP2
At LG11:
LINE_CALLSTATE - OFFERING
Caller = LG1
HuntPilot = HP1
Called = HP2,
HuntPilot = HP2
Connected = LG1
HuntPilot = HP1
RedirectionID = HP2
RedirectingID = A
Hunt List Call is Consult Transferred to Another Line
Table A-47 Message Sequence for Hunt List Call is Consult Transferred to Another Line
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup transfer to B, B answer
At LG1
Call-1 is put on HOLD
Call-2
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = LG1
LG1 completes transfer
At A :
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = B
RedirectionID = B
RedirectingID = LG1
At LG1: both call goes IDLE
At B:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = B
Connected = A
RedirectionID = B
RedirectingID = LG1
Hunt List Call Direct Transferred to Another Line
Table A-48 Message Sequence for Hunt List Call Direct Transferred to Another Line
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
LG1 calls to B, B answer
At LG1
Call-1 is put on HOLD
Call-2
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
LG1 performs Direct Transfer
At A :
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = B
RedirectionID = B
RedirectingID = LG1
At LG1: both call goes IDLE
At B:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = B
Connected = A
RedirectionID = B
RedirectingID = LG1
Hunt List Call is Conferenced to Another Line
Table A-49 Message Sequence for Hunt List Call is Conferenced to Another Line
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to B, B answers the call
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONNECTED
Caller = LG1
Called = B
Connected = B
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = B
Connected = B
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
At B:
CONNECTED
CONFERENCED
Caller = LG1
Called = B
Connected = LG1
CONFERECED
Caller = B
Called = A
Connected = A
Hunt List Call is Joined to Another Line
Table A-50 Message Sequence for Hunt List Call is Joined to Another Line
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 calls B, B answers the call
At LG1
Call-1: ONHOLD
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Call-2: CONNECTED
Caller = LG1
Called = B
Connected = B
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
LG1 performs Join
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = B
Connected = B
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
At B:
CONNECTED
CONFERENCED
Caller = LG1
Called = B
Connected = LG1
CONFERECED
Caller = B
Called = A
Connected = A
Hunt List Call is Conferenced to Another Hunt List after LG11 Answers
Table A-51 Message Sequence for Hunt List Call is Conferenced to Another Hunt List after LG11 Answers
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
At LG11:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG1
HuntPilot = HG1
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = HP2 ->LG11
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
At LG11:
CONNECTED
CONFERECED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG1
HuntPilot = HG1
HP name =- empty
CONFERECED
Caller = LG11
Called = A
Connected = A
Hunt List Call Conferenced to the Same Hunt List and Completes Conference Before Hunt List Agent Answers
Table A-52 Message Sequence for Hunt List Call Conferenced to the Same Hunt List and Completes Conference Before Hunt List Agent Answers
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to HG1, where alerting on LG2,
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
RINGBACK
Caller = LG1
Called = HP1
HuntPilot = HP1
At LG2:
LINE_CALLSTATE - ACCEPTED
Caller = LG1
Called = HP2
HuntPilot = HP2
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = HP1
HuntPilot = HP1
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = HP1
HuntPilot = HP1
Connected = HP1
HuntPilot = HP1
At LG2:
ACCEPTED
CONFERECED
Caller = LG1
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HG1
CONFERECED
Caller = LG2
Called = A
Connected = A
LG2 answers the call
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
Called Name = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG2
ConnectedName = LG2
HuntPilot = HP1
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = HP1
HuntPilot = HP1
Connected = LG2
HuntPilot = HP1
Called = A
Connected = A
At LG2:
CONNECTED
CONFERECED
Caller = LG1
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HG1
CONFERECED
Caller = LG11
Hunt List Basic Call with SharedLine
LG1' is sharedline with LG1
Table A-53 Message Sequence for Hunt List Basic Call with SharedLine
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
At LG1':
LINE_CALLSTATE - CONNECTED INACTIVE
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Hunt List Basic Call with DND-R Configured on LG1
Table A-54 Message Sequence for Hunt List Basic Call with DND-R Configured on LG1
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG2 since LG1 has DND enabled.. Then LG2 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG2
HuntPilot = HP1
At LG2:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Hunt List Call Put in Conference via Join Operation
Table A-55 Message Sequence for Hunt List Call Put in Conference via Join Operation
Action
Events, Requests and Responses
B calls A, A answer
At A:
Call-1
LINE_CALLSTATE - CONNECTED
Caller = B
Called = A
Connected = B
At G:
LINE_CALLSTATE - CONNECTED
Caller = B
Called = A
Connected = A
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
Call-1 is on HOLD
Call-2
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
Application initiates JOIN calls on A with final call as call-1
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = B
Called = A
Connected = B
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
At B:
CONNECTED
CONFERENCED
Caller = B
Called = A
Connected = A
CONFERECED
Caller = B
Called = LG1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
Hunt List Call is Picked up from Pickup Group - G-Pickup, Auto Pick Pp is Enabled
Table A-56 Message Sequence for Hunt List Call is Picked up from Pickup Group - G-Pickup, Auto Pick Pp is Enabled
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
Line X got notification of the call
Got call pickup notification of call offering at LG1
Line X does group pick from LG1
At A:
LINE_CALLSTATE - CONNECTED
Caller = X
Called = HP1,
HuntPilot = HP1
ConnectedID = X
At X:
LINE_CALLSTATE - PROCEEDING
Caller = X
Called = PickGroup#
LINE_CALLSTATE - CONNECTED
Caller = X
Called = PickGroup#,
ConnectedID = A
Hunt List Call is Picked Up from Pickup Group when LG1 is in Pickup Group 1 - Auto Pickup Disabled
Table A-57 Message Sequence for Hunt List Call is Picked Up from Pickup Group when LG1 is in Pickup Group 1 - Auto Pickup Disabled
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
Line X got notification of the call
Got call pickup notification of call offering at LG1
Line X does group pick from LG1
Original pickup call goes IDLE
X got server call about the pickup call
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1,
HuntPilot = HP1
ConnectedID = X
At X: new call offered at X from server, and answer
LINE_CALLSTATE - CONNECTED
Caller = A
Called = X
ConnectedID = A
Hunt List Call is Picked Up from Pickup Group when HP2 is in Pickup Group 2 - Auto Pick Up Enabled
Table A-58 Message Sequence for Hunt List Call is Picked Up from Pickup Group when HP2 is in Pickup Group 2 - Auto Pick Up Enabled
Action
Events, Requests and Responses
App initiates call from A to HP2 and the call is offered at LG11
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP2,
HuntPilot = HP2
At LG11:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP2,
HuntPilot = HP2
Line X got notification of the call
Got call pickup notification of call offering at HP2
Line X does group pick from HP2
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP2,
HuntPilot = HP2
ConnectedID = X
At X:
LINE_CALLSTATE - CONNECTED
Caller = X
Called = PickGroup#,
ConnectedID = A
Conferenced Hunt List Call Becomes Two-party Call
Table A-59 Message Sequence for Conferenced Hunt List Call Becomes Two-party Call
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
Called Name = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = LG11
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
At LG11:
CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
CONFERECED
Caller = LG11
Called = A
Connected = A
LG11 drops call
At A:
Conf Parent call goes IDLE
CONFERENCED call to LG11 goes IDLE
CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
Conf Parent call goes IDLE
CONFERENCED call to LG11 goes IDLE
CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
At LG11:
Calls go IDLE
Hunt List Broadcast Scenario (Broadcast Option is Configured on HP1)
Table A-60 Message Sequence for Hunt List Broadcast Scenario (Broadcast Option is Configured on HP1)
Action
Events, Requests and Responses
App initiates call from A to HP1, and call is offered at LG1, LG2 and LG3
At A:
LINE_CALLSTATE - RINGBACK
Caller = A
Called = HP1,
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
At LG2:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
At LG3:
LINE_CALLSTATE - ACCEPTED
Caller = A
Called = HP1,
HuntPilot = HP1
Note HP Broadcast is not supported when interacting with Call PickUp feature.
Hunt List Call is Involved in c-Barge Conference
LG1' is sharedline with LG1
Table A-61 Message Sequence for Hunt List Call is Involved in c-Barge Conference
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
At LG1':
LINE_CALLSTATE - CONNECTED INACTIVE
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to B, B answers the call
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONNECTED
Caller = LG1
Called = B
Connected = B
At LG1':
LINE_CALLSTATE - CONNECTED INACTIVE
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LINE_CALLSTATE - CONNECTED INACTIVE
CONNECTED
Caller = LG1
Called = B
Connected = B
At B:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = B
Connected = B
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = B
Called Name = B
Connected = B
Called Name = B
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
At LG1':
CONNECTED INACTIVE
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
At B:
CONNECTED
CONFERENCED
Caller = LG1
Called = B
Connected = LG1
CONFERECED
Caller = B
Called = A
Connected = A
LG1' cBarges in
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = B
Connected = B
CONFERENCED
Caller = A
Called = LG1'
Connected = LG1'
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = LG1
Called = B
Connected = B
CONFERENCED
Caller = LG1
Called = LG1'
Connected = LG1'
CONNECTED INACTIVE
CONFERECED
Caller = LG1'
Called = LG1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = LG1'
Called = B
Connected = B
CONFERENCED
Caller = LG1'
Called = A
Connected = A
At LG1':
CONNECTED
CONFERECED
Caller = LG1'
Called = LG1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = LG1'
Called = B
Connected = B
CONFERENCED
Caller = LG1'
Called = A
Connected = A
CONNECTED INACTIVE
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERENCED
Caller = LG1
Called = B
Connected = B
CONFERENCED
Caller = LG1
Called = LG1'
Connected = LG1'
At B:
CONNECTED
CONFERENCED
Caller = LG1
Called = B
Connected = LG1
CONFERECED
Caller = B
Called = A
Connected = A
CONFERENCED
Caller = B
Called = LG1'
Connected = LG1'
Hunt List Feature Interact with Four-Party Conference
Table A-62 Message Sequence for Hunt List Feature Interact with Four-Party Conference
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
LG1 setup conference to HG2, where alerting on LG11, LG11 answers the call
At LG1
ONHOLDPENDINGCONF
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONNECTED
Caller = LG1
Called = LG11
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
At LG11:
LINE_CALLSTATE - CONNECTED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG1
HuntPilot = HG1
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = HG2
Connected = LG11
HuntPilot = HP2
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERECED
Caller = LG1
Called = HP2
Connected = LG11
HuntPilot = HP2
At LG11:
CONNECTED
CONFERECED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG2
CONFERECED
Caller = LG11
Called = A
Connected = A
LG1 setup conference to X, X answers the call
At LG1:
ONHOLDPENDINGCONFERENCE
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERECED
Caller = LG1
Called = HP2
Connected = LG11
HuntPilot = HP2
CONNECTED
Caller = LG1
Called = X
Connected = X
At X:
CONNECTED
Caller = LG1
Called = X
Connected = LG1
LG1 completes conference
At A:
CONNECTED
CONFERENCED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
CONFERENCED
Caller = A
Called = LG11
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
CONFERENCED
Caller = A
Called = X
Connected = X
At LG1:
CONNECTED
CONFERECED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
CONFERECED
Caller = LG1
Called = HP2
Connected = LG11
HuntPilot = HP2
CONFERENCED
Caller = LG1
Called = X
Connected = X
At LG11:
CONNECTED
CONFERECED
Caller = LG1
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HG1
CONFERECED
Caller = LG11
Called = A
Connected = A
CONFERENCED
Caller = LG11
Called = X
Connected = X
Caller Consult Transfer Call to Another Hunt List
Table A-63 Message Sequence for Caller Consult Transfer Call to Another Hunt List
Action
Events, Requests and Responses
App initiates call from A to HP1 and the call is offered at LG1 , and LG1 answers
At A:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = LG1
HuntPilot = HP1
At LG1:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP1
HuntPilot = HP1
Connected = A
A setup transfer to HP2, offered at LG11, LG11 anwser
At A
Call-1 is put on HOLD
Call-2
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP2
HuntPilot = HP2
Connected = LG11
HuntPilot = HP2
At LG11:
LINE_CALLSTATE - CONNECTED
Caller = A
Called = HP2
HuntPilot = HP2
Connected = A
A completes transfer
At LG1 :
LINE_CALLSTATE - CONNECTED
Caller = LG1
HuntPilot = HP1
Called = HP1
HuntPilot = HP1
Connected = LG11
HuntPilot = HP2
RedirectionID = LG11
RedirectingID = A
At A: both call goes IDLE
At LG11:
LINE_CALLSTATE - CONNECTED
Caller = LG1
HuntPilot = HP1
Called = HP2
HuntPilot = HP2
Connected = LG1
HuntPilot = HP1
RedirectionID = LG11
RedirectingID = A
Intercom
This configuration gets used for all the following use cases:
1. IPPhone A has two lines, line1 (1000) and line2 (5000). Line2 represents an intercom line. Speeddial to 5001 with label ìAssistant_1î gets configured.
2. IPPhone B has three lines, line1 (1001), line2 (5001), and Line3 (5002). Line2 and Line3 represent intercom lines. Speeddial to 5000 with label ìManager_1î gets configured on line2. Line 3 does not have Speeddial configured for it.
3. IPPhone C has two lines, line1 (1002) and line2 (5003). 5003 represents an intercom line that is configured with Speeddial to 5002 with label ìAssistant_5002î.
4. IPPhone D has one line (5004). 5004 represnts an intercom line.
5. CTIPort X has two lines, line1 (2000) and line2 (5555). Line2 represents an intercom line. Speedial to 5001 gets configured with label ìAssistant_1î.
6. Intercom lines (5000 to 5003) exists in same partition = Intercom_Group_1 and they remain reachable from each other. 5004 exists in Intercom_Group_2.
7. Application monitoring all lines on all devices.
Assumption: Application initialized and CTI provided the details on speeddial and lines with intercom line on all the devices. Behavior should act the same for phones that are running SCCP, and those that are running SIP.
Application Invoking Speeddial
Action
Events
LineOpen on 5000 & 5001
Initiate InterCom Call on 5000
For 5000
receive LINE_CALLSTATE
cbInst=x0
param1=x03000000
param2=x1, ACTIVE
param3=x0,
Receive StartTransmission event
For 5001
receive LINE_CALLSTATE
cbInst=x0
param1= x03000000
param2=x1, ACTIVE
param3=x0,
Receive StartReception event
Receive zipzip tone with reason as intercom
Agent Invokes Talkback
Table 2:
Action
Events
Continuing from the previous use case, 5001 initiates LineTalkBack from application on the InterCom call
For 5000
receive LINE_CALLSTATE
device=x10218
param1=x100, CONNECTED
param2=x1, ACTIVE
param3=x0,
Receive StartReception event
For 5001
receive LINE_CALLSTATE
device=x101f6
cbInst=x0
param1=x100, CONNECTED
param2=x1, ACTIVE
param3=x0,
Receive StartTransmission event
Change the SpeedDial
Action
Events
Open line 5000
LineChangeSpeeddial request (speeddial to 5003, label = "Assistant_5003")
The new speed dial and label is successfully set for the intercom line
Receive LineSpeeddialChangeEvent from CTI
Send LINE_DEVSPECIFIC to indicate that speeddial and label changed
Application issues LIneGetDevCaps to retrieve speeddial/label that is set on the line
TAPI returns configured speeddial/label that is configured on the line.
IPv6 Use Cases
The use cases related to IPv6 are provided below:
Register CTI Port with IPv4 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4 .
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4 only on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv4. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is able to register CTI Port with IPv4 address.
Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv6.
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv6 only on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL
Register CTI Port with IPv6 when Unified CM is IPv6 Disabled and Common Device Configuration is IPv4_v6.
Steps
Expected Result
1. Enterprise parameter for IPv6 is disabled. IP addressing mode for CTI Port = IPv4_v6 on common device config page.
2. Open provider and do a LineNegotiateExtensionVersion with the higher bit set on both dwExtLowVersion and dwExtHighVersion
3. Application does a LineOpen with new Ext ver. The lineopen will be delayed till user specifies the Addressing mode
4. Application uses CCiscoLineDevSpecificSetIPAddressMode to set the addressing mode as IPv6. Application uses CciscoLineDevSpecificSendLineOpen to trigger Lineopen.
Application is not able to register CTI Port. TSP returns error LINEERR_OPERATIONUNAVAIL
IPv6 Phone A calls IPv6 Phone B
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv6 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: Blank
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of B.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of A.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv4_v6 Phone calls IPv6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv4_v6 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: IPv4 address of A
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of B.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of A.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv4 Phone Calls IPv6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv4 calls Phone B which is IPv6
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress: IPv4 address of A
FarEndIPAddressIpv6:
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv4 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv4 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of B.
IPv6 Phone Calls IPv4 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Open two lines A and B
3. Phone A which is IPv6 only calls Phone B which is IPv4
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
FireCallState = Offering, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress:
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo will contain the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv4 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv4 address of B.
IPv6 Phone Calls IPv4_v6 Phone.
Steps
Expected Result
1. Enterprise parameter for IPv6 is enabled.
2. Phone A which is IPv6 only calls Phone B which is IPv4_v6 only.
3. Open lines A and B
4. Events at Phone B
5. While Media is established:
•Events on phone A
•Event on phone B
Existing Call, Do a GetlineCallInfo.
LineCallInfo contains the following in devspecific part,
FarEndIPAddress:
FarEndIPAddressIpv6: IPv6 address of A
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of MTP Resource.
ReceptionRTPDestinationAddress = IPv6 address of A.
Do a GetLinecallInfo,
LineCallInfo contains the following in devspecific part,
TransmissionRTPDestinationAddress = IPv6 address of Phone A.
ReceptionRTPDestinationAddress = IPv6 address of B.
Common Device Configuration Device Mode Changes from IPv4_v6 to IPv4.
Steps
Expected Result
User changes the device configuration on common device configuration from IPv4_v6 to IPv4 only
Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv6 get a LINE_CLOSE Event. Application can then re-register these lines later.
Common Device Configuration Device Mode Changes from IPv4 to IPv6 .
Steps
Expected Result
User changes the device configuration on common device configuration from IPv4 only to IPv6 only
Application receives LineDevSpecific for the opened CTI Ports/RP in the device config indicating that Addressing mode has changed. All lines registered as IPv4 get a LINE_CLOSE Event. Application can then re-register these lines later.
Join Across Lines
Setup
Line A on device A
Line B1 and B2 on device B
Line C on device C
Line D on device D
Line B1' on device B1', B1' is a shared line with B1
Join Two Calls from Different Lines to B1
Action
Expected Events
A ‡ B1 is HOLD
For A
C ‡ B2 is connected
LINE_CALLSTATE param1=x100, CONNECTED Caller = A, Called = B1 Connected B1
For B1: LINE_CALLSTATE param1=x100, HOLD Caller = A, Called = B1, Connected = A
For B2: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2 , Connected = C
For C: LINE_CALLSTATE param1=x100, CONNECTED Caller = C, Called = B2, Connected = B2
For B1': LINE_CALLSTATE param1=x100, CONNECTED, INACTIVE Caller = A, Called = B1, Connected = A
Application issues lineDevSpecific(SLDST_JOIN) with the call on B1 as survival call
For A
CONNECTED
CONFERENCED Caller=A, Called=B1, Connected=B1
CONFERENCED Caller=A Called=C, Connected=C
For B1
CONNECTED
CONFERENCED Caller=A, Called=B1, Connected=A
CONFERENCED Caller=B1 Called=C, Connected=C
For B2
Call will go IDLE
For C
CONNECTED
CONFERENCED Caller=C, Called=B2, Connected=B1 (or A)
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-64 describes the message sequences for Manual Outbound Call when party A is idle.
Table A-64 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 configured.
3. A(3000) calls B(3001)
4. B(3001) receives the call and parks the call
5. The Park Monitoring Reversion Timer Expires while the call is still parked
6. The Park Monitoring Forward No Retrieve timer expires and the call is forwarded to the Parkers line.
Park Status Event on B
At Step 4:
Application will receive the LINE_CALLSTATE event with the Park Status = Parked.
At Step 5:
Application will receive the LINE_CALLSTATE event with the Park Status = Reminder.
At Step 6:
Application will receive the LINE_CALLSTATE event with the Park Status = Forwarded.
Application will receive the LINE_CALLSTATE event with callstate IDLE.
Application does a LineGetCallInfo.
LineCallInfo will contain the following:
hline: LH = 1
dwCallID: CallID
dwReason: LINECALLREASON_PARKED
dwRedirectingIDName: TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 6
dwCallerID: ParkDN = 5555
dwCallerName: ParkDNPartition = P1
dwcalled: ParkedParty = 3000
dwCalledIDName: ParkedPartyPartition = P1.
Scenario 7:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. The Park Monitoring Forward No retrieve destination configured as self(Parkers Line)
3. A(3000) calls B(3001)
4. B(3001) receives the call and parks the call
5. The Park Monitoring Reversion Timer Expires while the call is still parked
6. The Park Monitoring Reversion Timer Expires while the call is still parked
7. The Park Monitoring Forward No Retrieve timer expires and the call is forwarded to the Parkers line.
Park Status Event on B
At Step 5:
Application will receive the LINE_CALLSTATE event with the Park Status = Parked.
At Step 6:
Application will receive the LINE_CALLSTATE event with the Park Status = Reminder.
At Step 7:
Application will receive the LINE_CALLSTATE event with the Park Status = Forwarded.
Application will receive the LINE_CALLSTATE event with callstate IDLE.
Application does a LineGetCallInfo.
LineCallInfo will contain the following:
hline: LH = 1
dwCallID: CallID
dwReason: LINECALLREASON_PARKED
dwRedirectingIDName: TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 6
dwCallerID: ParkDN = 5555
dwCallerName: ParkDNPartition = P1
dwcalled : ParkedParty = 3000
dwCalledIDName : ParkedPartyPartition = P1.
Parked Call Exists
Setup:
Cisco Unified IP Phones (future version) running SIP: A(3000), B(3001).
B is not monitered by TSP.
Action
Expected Events
Scenario 1:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. A(3000) calls B(3001)
3. B(3001) receives the call and parks the call
4. Now the Line B(3001) is monitered by TSP
Park Status Event on B:
At Step 4:
Application will be notified about the Parked call through LINE_NEWCALL event.when ever cisco TSP recives the LINE_PARK_STATUS event for already parked call.
Application does a LineGetCallInfo.
LineCallInfo will contain the following:
hline : LH = 1
dwCallID : CallID
dwReason :LINECALLREASON_PARKED
dwRedirectingIDName TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 2
dwCallerID : ParkDN = 5555
dwCallerName : ParkDNPartition = P1
dwcalled : ParkedParty = 3000
dwCalledIDName : ParkedPartyPartition = P1.
Shared Line Scenario
Setup:
A(3000) ,D(3003) are Cisco Unified IP Phones (future version) running SIP
B(3001) and B'(3001) are shared lines for Cisco Unified IP Phones (future version) running SIP
C(3002) and C'(3002) are shared lines where C is a Cisco Unified IP Phone (future version) running SIP and C' is a Cisco Unified IP Phone 7900 Series running SIP .
For the shared lines the events will be delivered to the phone which parks the call .Events will not be delivered to the other phone though the line is shared.
Action
Expected Events
Scenario 1:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. A(3000) calls B(3001)
3. B(3001) and B'(3001) starts ringing. B(3001) receives the call and parks the call
4. Park Monitoring reversion timer expires while the call is still parked.
5. D(3003) retrieves the call
Park Status Event on B:
At Step 3:
Application will receive the LINE_CALLSTATE event with the Park Status = Parked.
At Step 4:
Application will receive the LINE_CALLSTATE event with the Park Status = Reminder.
At Step 5:
Application will receive the LINE_CALLSTATE event with the Park Status = Retrieved
Application will receive the LINE_CALLSTATE event with callstate IDLE.
Application does a LineGetCallInfo.
hline : LH = 1
dwCallID : CallID
dwReason :LINECALLREASON_PARKED
dwRedirectingIDName :TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 5
dwCallerID : ParkDN = 5555
dwCallerName : ParkDNPartition = P1
dwcalled : ParkedParty = 3000
dwCalledIDName : ParkedPartyPartition = P1.
Scenario 2:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. The Park Monitoring Forward No retrieve destination configured as B(3001)
3. A(3000) calls B(3001)
4. B(3001) and B'(3001) starts ringing. B(3001)receives the call and parks the call
5. The Park Monitoring Reversion Timer Expires while the call is still parked.
6. The Park Monitoring Forward No Retrieve timer expires and call is forwarded to B(3001).Both B(3001) and B'(3001) starts ringing as they are shared lines.
Park Status Event will be sent only to B not B'.
At Step 4:
Application will receive the LINE_CALLSTATE event with the Park Status = Parked.
At Step 5:
Application receives the LINE_CALLSTATE event with the Park Status = Reminder.
At Step 6:
Application receives the LINE_CALLSTATE event with the Park Status = Forwarded.
Application receive the LINE_CALLSTATE event with callstate IDLE.
Application does a LineGetCallInfo.
LineCallInfo contains the following:
hline : LH = 1
dwCallID : CallID
dwReason :LINECALLREASON_PARKED
dwRedirectingIDName : TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 6
dwCallerID : ParkDN = 5555
dwCallerName : ParkDNPartition = P1
dwcalled : ParkedParty = 3000
dwCalledIDName : ParkedPartyPartition = P1.
Scenario 3:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. A(3000) calls C(3002)
3. C(3002) and C'(3002) starts ringing. C'(3002) receives the call and parks the call
4. D(3003) retrieves the call
Park Status Event on C'.
At Step 3:
Application is notified about the New Parked call through LINE_NEWCALL event as the call is parked by the Normal TNP phone.
Park Monitoring Feature Disabled
Setup:
The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for line B(3001).
A(3000), D(3003) is a Cisco Unified IP Phones (future version)
Application invokes the Line_open () API on provider to monitor ParkDN
.
Action
Expected Events
Scenario 1:
1. The Park Monitoring message flag is Enabled using SLDST_SET_STATUS_MESSAGES request for Line B(3001).
2. A(3000) calls B(3001)
3. B(3001) receives the call and parks the call
4. The Park Monitoring Reversion Timer Expires while the call is still parked.
Park Status Event on B:
At Step 3:
Application receives the LINE_NEW_CALL event for PARKDN.
At Step 3:
Application receives the LINE_PARK_STATUS event with the Park Status = Parked.
At Step 4:
Application will receive the LINE_CALL_STATE event with the Park Status = Reminder.
Application does a LineGetCallInfo.
LineCallInfo will contain the following:
hline : LH = 1
dwCallID : CallID
dwReason :LINECALLREASON_PARKED
dwRedirectingIDName :TransactionIDID = Sub1.
dwBearerMode: ParkStatus = 3
dwCallerID : ParkDN = 5555
dwCallerName : ParkDNPartition = P1
dwcalled : ParkedParty = 3000
dwCalledIDName : ParkedPartyPartition = P1.
Presentation Indication
Making a Call Through Translation Pattern
Table A-65 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-65 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-66 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-66 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-68 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-68 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-69 describes the message sequences for the Refer and Replaces scenario of in-dialog refer where ReferToTarget redirects the call in Offering state.
Table A-69 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-70 describes the message sequences for the Refer and Replaces scenario of in-dialog refer fails or refer to target is busy.
Table A-70 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-71 describes the message sequences for the Refer and Replaces scenario of out-of-dialog refer.
Table A-71 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-72 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-72 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-73 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-73 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-73 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-74 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.
Feedback
3XX
