TCD - Peripheral Call Type 9 & 10 Strange Behaviour

[Neil Ambrosen]

Hi all,

I'm trying to get to the bottom of what causes ICM/UCCE to label a TCD record with Peripheral Call Type 9 or 10.

9 = Out

10 = Agent Inside

These values are used to populate the interval tables with ExternalOut and InternalOut

I'm seeing strange behaviour in that external calls are being classified PCT 10. Its worse on 1 pg pair and cucm cluster than the other (both pims agent ext length is 4 if this has any bearing).

From Europe PG and CUCM, most ExtOut calls are correctly classified as 9 (about 95%), but there are some 10:

DateTime	PeripheralCallType	DigitsDialed	CallDisposition	CallDispositionFlag
18/02/2013 15:10:08	9	00415824xxxxx	10	4
18/02/2013 15:10:34	10	00415824xxxxx	10	4

But for Asia PG and CUCM, most ExtOut calls are classified as 10 (about 98%), but again there are some with the correct 9:

DateTime	PeripheralCallType	DigitsDialed	CallDisposition	CallDispositionFlag
18/02/2013 11:54:14	10	0080346xxxxx	14	1
18/02/2013 12:09:59	9	0080302xxxxx	14	1

For info I also see external calls with dispostion 10 and 4 in Asia as Agent Inside so it doesn't seem to tie up with that.

Any thoughts on what could be the cause, I'm kind of thinking along the lines of CUCM on net/off net or soemthing like that?

Thanks

Neil

[Gergely Szabo]

Hi,

can you please post all database rows (with the same RouterCallKeyDay and RouterCallKey) for the calls above.

Thanks.

G.

[Neil Ambrosen]

Attached the full length TCD record.

Also found a pdf document id 67988 External Calls Appear as Internal in IPCC Statistics which says:

Cause

This problem occurs due to a change in Cisco JTAPI version. In earlier versions of Cisco JTAPI, when a

caller calls an address outside the cluster, Cisco CallManager delivers the CallCtlConnNetworkReachedEv

and CallCtlConnNetworkAlertingEv events for the far−end address.

Cisco CallManager version 4.0 and later do not deliver these events. In these versions, the CallCtlConnection

for the far−end address goes to the ESTABLISHED state from the OFFERED state. The application receives

the CallCtlConnOfferedEv and CallCtlConnEstablishedEv events for the far−end address. The application

does not receive the CallCtlConnNetworkReachedEv and CallCtlConnNetworkAlertingEv events.

In order to receive the network events, you must turn on the "Allow overlap sending" flag on the route pattern

configured for the gateway. A new jtapi.ini parameter called "AllowNetworkEventsAfterOffered" is

introduced to allow the application to control the delivery of these events. Applications that need the network

events but cannot turn on this flag can use this new ini parameter to receive network events for outgoing calls.

They are having a PG/CUCM upgrade in a few weeks so its quite possible this may sort it.

[Gergely Szabo]

Hi,

I don't see the attachment, but anyway, do you see any difference between the calls with PeripheralCallType 9 and 10 before actually getting to the agent?

G.

[Neil Ambrosen]

Coming up virus detected on the xlsx, but checks out my end

Its not calls getting to the agent, its the agent making calls out to customers from their ipcc ext......

[Gergely Szabo]

Hi,

CSV would be easier and guarranteed virus free :-)

Anyhow, all calls go through the same gateway?

G.