Cisco JTAPI Developer Guide for Cisco CallManager 4.1(2)
Message Sequence Charts
Downloads: This chapterpdf (PDF - 620.0KB) The complete bookPDF (PDF - 9.56MB) | Feedback

Message Sequence Charts

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