Table Of Contents
Message Sequence Charts
Shared Line Support
AddressInService/AddressOutofService Events
Incoming Call to Shared Address
Outgoing Call From Shared Address
Shared Address Calling Itself
Transfer and Direct Transfer
DirectTransfer/Arbitrary Transfer Scenario
Consult Transfer Scenario
Conference and Join
Join/Arbitrary Conference Scenario
Consult Conference Scenario
Barge and Privacy
Barge Feature
CBarge Feature
Privacy Changes
CallSelect and UnSelect
CallSelect and UnSelect Scenario
Dynamic CTIPort Registration Per Call
Dynamic Registrationn for CTIPort
Media Termination at Route Point
Media Termination at Route Point Scenario
Redirect Set OriginalCalledID
Scenario One
Scenario Two
Single Step Transfer
Modifying Calling Number
Scenario One
Scenario Two
AutoAccept for CTIPort and RoutePoint
Forced Authorization and Customer Matter Codes Scenarios
Scenario One
Scenario Two
Scenario Three
Scenario Four
Scenario Four
Scenario Five
Super Provider Message Flow
QSIG Path Replacement Use Cases
Device State Server Message Flow
Message Sequence Charts
This appendix contains the message sequence charts, which illustrates the message flows for the following:
•
Shared Line Support
–AddressInService/AddressOutofService Events
–Incoming Call to Shared Address
–Outgoing Call From Shared Address
–Shared Address Calling Itself
•Transfer and Direct Transfer
–DirectTransfer/Arbitrary Transfer Scenario
–Consult Transfer Scenario
•Conference and Join
–Join/Arbitrary Conference Scenario
–Consult Conference Scenario
•Barge and Privacy
–Barge Feature
–CBarge Feature
–Privacy Changes
•CallSelect and UnSelect
•Dynamic CTIPort Registration Per Call
•Media Termination at Route Point
•Redirect Set OriginalCalledID
•Single Step Transfer
•Modifying Calling Number
•AutoAccept for CTIPort and RoutePoint
•Forced Authorization and Customer Matter Codes Scenarios
•Super Provider Message Flow
•QSIG Path Replacement Use Cases
•Device State Server Message Flow
Shared Line Support
The following illustrates the message flows for Shared Line support.
AddressInService/AddressOutofService Events
Incoming Call to Shared Address
Outgoing Call From Shared Address
Shared Address Calling Itself
Transfer and Direct Transfer
The following illustrates the message flows for Transfer and Direct Transfer.
DirectTransfer/Arbitrary Transfer Scenario
Consult Transfer Scenario
Conference and Join
The following illustrates the message flows for Conference and Join.
Join/Arbitrary Conference Scenario
Consult Conference Scenario
The message flow for Consult Conference is the same as Arbitrary Conference.
Barge and Privacy
The following illustrates the message flows for Barge and Privacy.
Barge Feature
CBarge Feature
Privacy Changes
CallSelect and UnSelect
The following illustrates the message flows for CallSelect and UnSelect.
CallSelect and UnSelect Scenario
Dynamic CTIPort Registration Per Call
The following illustrates the message flows for Dynamic CTIPort Registration Per Call.
Dynamic Registrationn for CTIPort
Media Termination at Route Point
The following illustrates the message flows for Media Termination at Route Point.
Media Termination at Route Point Scenario
Redirect Set OriginalCalledID
The following illustrates the message flows for Redirect Set OriginalCalledID.
Scenario One
A, B, C are in applications controlled list.
D is not in control list.
A calls B
B redirects call to D with C as preferredOriginalCalledParty.
Application will see following events for parties A and B
Meta Event Cause
|
Call
|
Event
|
Fields
|
META_CALL_ADDING_PARTY
|
Call1
|
ConnCreatedEv for D
ConnConnectedEv for D
CallCtlConnEstablishedEv for D
|
CallingParty=A
CalledParty = B
LastRedirectedParty=C
CurrentCalledParty=D
|
META_CALL_REMOVE_PARTY
|
Call1
|
ConnDisconnectedEv for B
CallCtlConnDisconnectedEv for B
TermConnDroppedEv for B
CallCtlTermConnDroppedEv for B
CallObservationEndedEv for B
|
CallingParty=A
CalledParty = B
LastRedirectedParty=C
CurrentCalledParty=D
|
Note The specified event group may not be in the same order and might change depending on where parties are present in the cluster, on the load, and other conditions.
Scenario Two
A, B, C are not in Control list and
D is in the application control list
A calls B
B redirects call to D with C as preferredOriginalCalledParty.
Application will see following events for party D
Meta Event Cause
|
Call
|
Event
|
Fields
|
META_CALL_STARTING
|
Call1
|
CallActiveEv
ConnCreatedEv for D
ConnInProgressEv for D
CallCtlConnOfferedEv for D
ConnCreatedEv for A
CallCtlConnInitiatedEv for A
|
CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D
|
META_CALL_PROGRESS
|
Call1
|
ConnAlertingEv for D
CallCtlConnAlertingEv for D
TermConnCreatedEv for D
CallCtlTermConnRingingEv for D
ConnConnectedEv for A
CallCtlConnEstablishedEv for A
|
CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D
|
META_CALL_PROGRESS
|
Call
|
ConnConnectedEv for D
CallCtlConnEstablishedEv for D
TermConnActiveEv for D
CallCtlTermConnTalkingEv for D
|
CallingParty=A
CalledParty = D
LastRedirectedParty=C
CurrentCalledParty=D
|
Single Step Transfer
Adresses A,B and C are in control list and the call between A and B is the transferred to C with B as transfer controller. Applications will see the following events:
Action
|
Address A (5001)
Terminal CTIP1
|
Address B (5002)
Terminal CTIP2
|
Address C (5003)
Terminal CTIP3
|
Call.transfer(string)
|
ConnCreatedEv 5003 Cause: CAUSE_NORMAL
ConnInProgressEv 5003 Cause: CAUSE_NORMAL
CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL
CallControlCause: CAUSE_TRANSFER
ConnAlertingEv 5003 Cause: CAUSE_NORMAL
CallCtlConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER
|
NEW META EVENT_________META_CALL_REMOVING_PARTY
TermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL
CallCtlTermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER
ConnDisconnectedEv 5002 Cause: CAUSE_NORMAL
CallCtlConnDisconnectedEv 5002 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER
|
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv 5003 Cause: CAUSE_NORMAL
ConnInProgressEv 5003 Cause: CAUSE_NORMAL
CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER
ConnCreatedEv 5001Cause: CAUSE_NORMAL
ConnConnectedEv 5001 Cause: CAUSE_NORMAL
CallCtlConnEstablishedEv 5001Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
|
|
|
Action
|
Address A (5001)
Terminal CTIP1
|
Address B (5002)
Terminal CTIP2
|
Address C (5003)
Terminal CTIP3
|
Call.transfer(string)
(continued)
|
CiscoRTPInputStartedEv Cause: CAUSE_NORMAL
CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL
ConnConnectedEv 5003 CAUSE_NORMAL
CallCtlConnEstablishedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
|
NEW META EVENT_________META_UNKNOWN
CallObservationEndedEv Cause: CAUSE_NORMAL
|
ConnAlertingEv 5003 Cause: CAUSE_NORMALCallCtlConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv CTIP3
TermConnRingingEv CTIP3Cause: CAUSE_NORMAL
CallCtlTermConnRingingEvImpl CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
CiscoRTPInputStartedEv Cause: CAUSE_NORMAL
CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL
ConnConnectedEv 2004 Cause: CAUSE_NORMAL
CallCtlConnEstablishedEv 5003Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
|
|
|
Action
|
Address A (5001)
Terminal CTIP1
|
Address B (5002)
Terminal CTIP2
|
Address C (5003)
Terminal CTIP3
|
Call.transfer(string)
(continued)
|
|
|
TermConnActiveEv CTIP3 Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
CiscoRTPInputStoppedEv Cause: CAUSE_NORMAL
CiscoRTPOutputStoppedEv Cause: CAUSE_NORMAL
ConnDisconnectedEv 5001 Cause: CAUSE_NORMAL
CallCtlConnDisconnectedEv 5001 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL
CallCtlTermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
|
|
|
Action
|
Address A (5001)
Terminal CTIP1
|
Address B (5002)
Terminal CTIP2
|
Address C (5003)
Terminal CTIP3
|
Call.transfer(string)
(continued)
|
|
|
ConnDisconnectedEv 5003 Cause: CAUSE_NORMAL
CallCtlConnDisconnectedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
META_UNKNOWN
CallInvalidEv [#32] Cause: CAUSE_NORMAL
|
|
|
Modifying Calling Number
The following illustrates the message flows for Modifying Calling Number.
Scenario One
Application controlled device Route Point (RP) and registers RP
A and B are PNO and within CallManager cluster
A calls RP
Call arrives at RP
Action
|
Event
|
Fields
|
Call Arrives at RP
|
RouteEvent
|
State = ROUTE
getCurrentRouteAddress () = RP
getCallingAddress () = A
getCallingTerminal () = SEPA
(Terminal associated with A)
|
Application invokes
selectRoute( routeselected[],
callingsearchspace,
modifiyingcallingnumber[] ) where
routeSelected[] = C
callingSearchSpace =
CiscoRouteSession.DEFAULT_SEARCH_SPACE
|
RouteUsedEvent
|
State = ROUTE_USED
getCallingAddress () = A
getCallingTerminal () = SEPA
(Terminal associated with A)
getRouteUsed () = C
|
Application invokes
endRoute (ERROR_NONE)
|
RouteEndEvent
|
State = ROUTE_END
getRouteAddress () = RP
|
Scenario Two
Application is controlling A, B
A calls RP, which selectsRoute call to B with modified calling number as M
Action
|
Event
|
Fields
|
A calls RP, which is not in controlled list
|
NEW META EVENT_________META_CALL_
STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_
PROGRESS
CallCtlConnDialingEv A
NEW META EVENT_________META_CALL_
PROGRESS
CallCtlConnEstablishedEv A
ConnCreatedEv RP
ConnInProgressEv RP
CallCtlConnOfferedEv RP
|
getCallingAddress() = A
getCalledAddress() =
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()=
getModifiedCallingAddress()=A
getModifiedCalledAddress() =
getCallingAddress() = A
getCalledAddress() =
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()=
getModifiedCallingAddress()=A
getModifiedCalledAddress() =
getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()=
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=A
getModifiedCalledAddress() =B
|
Another application that is controlling the RP selectRoute to B with modifying calling number as M
|
NEW META EVENT_________META_CALL_
ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B
ConnDisconnectedEv RP
CallCtlConnDisconnectedEv RP
NEW META EVENT_________META_CALL_
PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B
|
getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B
getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP
|
| |
TermConnRingingEv B
CallCtlTermConnRingingEv B
|
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B
|
B answers the call
|
ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv B
CallCtlTermConnTalkingEv B
|
getCallingAddress() = A
getCalledAddress() = B
getLastRedirectedAddress ()= RP
getCurrentCallingAddress ()= A
getCurrentCalledAddress()= B
getModifiedCallingAddress()=M
getModifiedCalledAddress() =B
|
AutoAccept for CTIPort and RoutePoint
Forced Authorization and Customer Matter Codes Scenarios
Scenario One
The application is controlling A and B; B requires a forced authorization code (FAC) to extend the call.
Action
|
Event
|
A calls B using call.Connect() or A places a consult call to B using Call.Consult()
|
NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A
NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. FAC_REQUIRED
|
Application enters additional digits using CiscoConnection.addToAddress
|
NEW META EVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B
NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B
TermConnRingingEv B
CallCtlTermConnRingingEv B
ConnConnectedEv B
CallCtlConnEstablishedEv B
|
B answers the call.
|
TermConnActiveEv B
|
Scenario Two
The application is Controlling A and B; B requires both an FAC and a CMC (client matter code) to extend the call.
Action
|
Event
|
A calls B using call.Connect() or A places a consult call to B using Call.Consult()
|
NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause:
CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A
NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. FAC_CMC_REQUIRED
|
Application enters FAC code digits with # terminated using CiscoConnection.addToAddress within T302 timer
|
NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. CMC_REQUIRED
|
Application enters CMC code digits with # terminated using CiscoConnection.addToAddress within T302 timer
|
NEW META EVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B
NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv B
TermConnRingingEv B
CallCtlTermConnRingingEv B
|
B answers the call
|
ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv B
CallCtlTermConnTalkingEv B
|
Scenario Three
The application is controlling A and B;
B requires a CMC, and the application enters an invalid code.
Action
|
Event
|
A calls B using call.Connect() or A places a consult call to B using Call.Consult()
|
NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause:
CAUSE_NORMAL
CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A
NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. CMC_REQUIRED
|
The application enters the incorrect CMC digits (# terminated) using CiscoConnection.addToAddress within the T302 timer limit
The application hears reorder tone.
|
NEW META EVENT_________META_CALL_PROGRESS
ConnFailedEv A
CallCtlConnFailedEv A getCiscoCause () =
CiscoCallEv.FAC_CMC
NEW META EVENT_________META_CALL_ENDING
TermConnDroppedEv
CallCtlTermConnDropped
ConnDisconnectedEv
CallCtlConnDisconnectedEv
CallInvalidEv
CallObservationEndedEv
|
Scenario Four
The application is controlling A and B; A calls B; B redirects the call to C, which need an FAC and a CMC.
Action
|
Event
|
A calls B using call.Connect() or A places a consult call to B using Call.Consult()
|
NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A
NEW META EVENT_________META_CALL_PROGRESS
CiscoToneChangedEv
ToneType = CiscoTone.ZIPZIP
cause = CiscoCallEv.CAUSE_FAC_CMC
getWhichCodRequired =
CiscoToneChangedEv. CMC_REQUIRED
|
Application enters incorrect CMC code digits with # terminated using CiscoConnection.addToAddress within T302 timer
Application hears the reorder tone
|
NEW META EVENT_________META_CALL_PROGRESS
ConnFailedEv A
CallCtlConnFailedEv A getCiscoCause () = CiscoCallEv.FAC_CMC
NEW META EVENT_________META_CALL_ENDING
TermConnDroppedEv
CallCtlTermConnDropped
ConnDisconnectedEv
CallCtlConnDisconnectedEv
CallInvalidEv
CallObservationEndedEv
|
Scenario Four
The application is controlling both A and B; A calls B; B redirects the call to C, which both an FAC and a CMC.
Action
|
Event
|
A calls B using call.Connect() or A places a consult call to B using Call.Consult()
|
NEW META EVENT_________META_CALL_STARTING
CallActiveEv Cause: CAUSE_NEW_CALL
ConnCreatedEv A Cause: CAUSE_NORMAL
ConnConnectedEv A Cause: CAUSE_NORMAL
CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
TermConnCreatedEv SEPA Cause: Other: 0
TermConnActiveEv SEPA Cause: CAUSE_NORMAL
CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL
NEW META EVENT_________META_CALL_PROGRESS
CallCtlConnDialingEv A
NEW METAEVENT_________META_CALL_ADDITIONAL_PARTY
ConnCreatedEv B
ConnInProgressEv B
CallCtlConnOfferedEv B
NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv B
CallCtlConnAlertingEv B
TermConnCreatedEv SEPB
TermConnRingingEv SEPB
CallCtlTermConnRingingEv SEPB
ConnConnectedEv B
CallCtlConnEstablishedEv B
TermConnActiveEv SEPB
CallCtlTermConnTalkingEv SEPB
|
B issues a redirect request to C and passes in FAC and CMC code
|
NEW META EVENT_________META_CALL_REMOVING_PARTY
TermConnDroppedEv SEPB
CallCtlTermConnDroppedEv SEPB Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED
ConnDisconnectedEv B Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnDisconnectedEv B Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED
NEW META EVENT_________META_CALL_PROGRESS
ConnCreatedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
NEW META EVENT_________META_CALL_PROGRESS
ConnInProgressEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED
NEW META EVENT_________META_CALL_PROGRESS
ConnAlertingEv A Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED
NEW META EVENT_________META_CALL_PROGRESS
ConnConnectedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR
CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR
|
Scenario Five
Application controlled device Route Point (RP) and registers RP
A and B are PNO and within CallManager cluster
Action
|
Event
|
Fields
|
Call arrives at RP
|
RouteEvent
|
State = ROUTE
getCurrentRouteAddress () = RP
getCallingAddress () = A
getCallingTerminal () = SEPA (Terminal associated with A)
|
Application invokes
selectRoute( routeselected[], callingsearchspace, modifiyingcallingnumber[], preferredOriginalCdNumber[], preferredOriginalCdOption[],
facCode[],
cmcCode[] ) where
routeSelected[] = B
callingSearchSpace = CiscoRouteSession.DEFAULT_SEARCH_SPACE
modifyingCgNumber = null,
preferredOriginalCdNumber = null,
preferredOriginalCdOption = CiscoRouteSession.DONOT_RESET_ORIGINALCALLED,
facCode[] = "facCode for B"
cmcCode[] = "cmcCode for B"
|
RouteUsedEvent
|
State = ROUTE_USED
getCallingAddress () = A
getCallingTerminal () =
SEPA (Terminal associated with A)
getRouteUsed () = B
|
Application invokes
endRoute ( ERROR_NONE )
|
RouteEndEvent
|
State = ROUTE_END
getRouteAddress () = RP
|
Super Provider Message Flow
The application is trying to create Terminal for CTIPort1 that has Addresses 2000 and 2001. The following events are sent to the application.
No.
|
Action
|
Event
|
1
|
Application invokes CiscoProvider.CreateTerminal(CTIPort1
Where
CiscoProviderCapabilities.
canObserveAnyTerminal() returns TRUE.
|
JTAPI would returm CiscoTerminal object and the following events are sent
CiscoTermCreatedEv CTIPort1<------------------
CiscoAddrCreated 2000<---------------------------
CiscoAddrCreated 2001<----------------------------
|
2
|
If Application already has a terminal where 2001 address already exit i.e 2001 is a SharedLine Address.
Now Application invokes CiscoProvider.
CreateTerminal(CTIPort1)
|
JTAPI would returm CiscoTerminal object and the following events are be sent
CiscoTermCreatedEv CTIPort1<-------------------
CiscoAddrCreated 2000<---------------------------
CiscoAddrAddedToTerminalEv 2001<-----------
|
3
|
Application invokes
CiscoProvider.
CreateTerminal(CTIPortX)
Where CTIPortX does not exist in CallManager cluster.
|
JTAPI would throw an exception: InvalidArgumentException
|
4
|
Application invokes
CiscoProvider.
CreateTerminal(CTIPort1)
Where
CiscoProviderCapabilities.
canObserveAnyTerminal() returns FALSE.
|
JTAPI would throw an exception: PrivilegeViolationException
|
QSIG Path Replacement Use Cases
The following table shows the JTAPI events delivered to applications when calls between PBXs connected by Q.Signaling (QSIG) trunks are transferred and forwarded. This table also shows the events delivered to applications when the real-time path (RTP) is optimized by the QSIG Path Replacement feature.
Calls going out on a QSIG trunk may not have a connection for the far end if there is any translation pattern changing the pattern. In other words, when the application sees two calls in the trombone case, B may not be the common connection on the calls.
No.
|
Action
|
Event
|
1
|
A is registered with CM1, B is registered with CM2 and C is registered with CM3.
A calls B (GC1), B transfers the call to C. Application is monitoring C. PR feature replaces the path after the call gets connected to C.
The same applies to scenarios involving call forward at B.
(called party transfers the call)
|
These events are delivered to applications:
CallCtrlConnectionEstablishedEv A
CallCtrlConnectionDisConnectEv B
OpenLogicalChannelEvent if C is a CTI device (Dynamically registered CTIPorts and RP)
|
2
|
A is registered with CM1, B is registered with CM2 and C is registered with CM3. B calls C, C answers, B transfers the call to A. A answers. Application is monitoring only C.
(calling party transfers the call)
|
In this case both A are C are called parties when transfer is completed. After the call is answered PR replaces the path. In this case A and C are IP phones, the display will be updated as a part of PR feature operation making either A or C as calling.
JTAPI events:
GC1: CallCtlConnEstablishedEv A
GC1: CallCtlConnDisconnectedEv B
|
3
|
3. Trombone case: A is registered to CM1, B is registered to CM2 and C is registered to CM1. A calls B (GC1) , B answers and transfers the call to C(GC2). Path replacement connects A and C bypassing CM2. Application is observing both A and C.
(called party transfers the call)
|
For GC1 Call Observer :
GC1: CallCtlConnEstablishedEv C
GC1: CallCtlConnDisconnected B
Before PR feature kicks in application will see 2 calls: GC1 with connections to A and C (external) and GC2 with connections to C and A(external).
When PR feature replaces the path, either GC1 changes GC2 or GC2 changes to GC1.
Assuming A's GCID changes from GC1 to GC2:
GC1: CiscoCallChangedEv (oldGCID=GC1,newGCID=GC2 )
GC1: CallCtlConnDisconnected for A
GC1: CallCtlConnDisconnected for C
GC1: CallInValid
GC2: TermConnTalkingEvent for TerminalA cause= CAUSE_QSIG_PR
|
4
|
Trombone case: A is registered to CM1, B is registered to CM2 and C is registered to CM1. B calls A and transfers the call to C. Path replacement connects A and C bypassing CM2. Application is observing both A and C.
(calling party transfers the call)
|
Before PR feature kicks in application will see 2 calls: GC1 with connections to A and B (external) and GC2 with connections to C and B(external). In this case application will not see any transfer start events.
When PR feature kicks in it updates the display of A and C and path is replaced resulting in a GCID change. Assuming A's GCID is changed and made calling party.
JTAPI events:
GC1: CiscoCallChangedEv (GC1 to GC2)
GC1: CallCtlConnDisconnected for A
GC1: CallCtlConnDisconnected for C
GC1: CallInValid
GC2: ConnCreatedEv A
GC2: ConnConnectedEv A
GC2: TermConnTalkingEvent for TerminalA cause= CAUSE_QSIG_PR
|
5
|
.A is registered to CM1, B is registered to CM2, C is registered to CM1. A calls B, B transfers the call to C. C answers and before path replacement is completed C invokes a feature ( park, redirect etc).
|
Path replacement is abandoned.
|
6
|
In some conditions feature requests (redirect, park, transfer etc) are ignored by call processing. This happens when setup request is send out and the local CM is waiting for connect from the other end.
|
JTAPI:
Exception will be trhown from JTAPI for feature requests.
|
7
|
In some cases application could hear dead air when CM goes down when PR feature is trying to switch the RTP path. This could happen to previously connected call.
|
No events
JTAPI Apps: Hang up the call
|
Device State Server Message Flow
