Outbound Transfer fails (Alcatel VAD)

[Szimi]

Hi

I'm using Alcatel 4400 with VAD (without CPD server) and Genesys 6.5

When I starting a campaign the OCServer makes the call, but it doesn't able to transfer the call from the dialing device to the routing point. (1401 ghost Z dialing device, 1660 RSI RP)

The customer has the hold music for 1 minute and after it the call dropped.

The TServer log:
@15:35:54.0000 [0] Received from 644 (077f OCServer): message RequestMakePredictiveCall
...

@05/06/03@15:35:54.000 [UsrDeb]: DialDevice<1401>: Request DN is set to <1660>
...
@05/06/03@15:35:54.218 [CDcDeb]: cstaSwitchingEventDecode: ServiceInitiated event in progress
...
@05/06/03@15:35:54.437 [CDcDeb]: cstaSwitchingEventDecode: Originated event in progress
...
@15:35:54.4370 [0] 6.5.200.01 distribute_response: message EventDialing
...
@15:35:54.4370 [0] 6.5.200.01 distribute_event: message EventNetworkReached
...
[CDcDeb]: cstaSwitchingEventDecode: Delivered event in progress
...
@05/06/03@15:36:01.359 [CDcDeb]: cstaSwitchingEventDecode: Established event in progress
...
UsrDeb]: Originated: > refDev <1401> (cref = '1374B00')
[TMlInf]: TmParty::Activate: for party <1401> in call (a4cb) with cause (NewCall:22)
[UsrDeb]: Originated: num of conn = 1
[TMlDeb]: an internal party <1660> with role '2' is added to the call (a4cb)
[TMlInf]: TmParty::Originate: for party <1401> in call (a4cb) with cause (Null:0)
[TMlInf]: TmParty::Dial: for party <1401> in call (a4cb) with cause (Null:0)
[UsrDeb]: link (linkctrl) S>H: (0[1] requests pending)
[CDcDeb]: cstaSwitchingEventDecode: Delivered event in progress
[UsrInf]: Transaction Info:
Type/Oper. : 1 4 <Event : Delivered>
crossRef : 1374b00
ConnId[0] : (a4cb11b)<(Trunk)>
SubjDev[1] : 1660 (Private)
LocalDev[0]: 1401 (Private)
LocalDev[1]: 1660 (Private)
Cause : 42 <EnteringDistribution>
LocalInfo : 3 <Connected>
TimeStamp : <030506153555Z>
PrivateList has 1 elements:
PData : Global CallID
[UsrDeb]: Delivered: > refDev <1401> (cref = '1374B00')
[UsrDeb]: Delivered: have calls (a4cb) & (0) by GCid
[TMlInf]: TmParty::Activate: for party <1401> in call (a4cb) with cause (Null:0)
[TMlInf]: TmParty::Originate: for party <1401> in call (a4cb) with cause (NewCall:22)
[TMlInf]: TmParty::Dial: for party <1401> in call (a4cb) with cause (Null:0)
[UsrInf]: Delivered: SST simulating is set for <1401>, finish transfer to dest
[UsrInf]: Transaction Info:
Type/Oper. : 5 16 <Request : TransferCall>
hostRef : 86b9
ConnId[0] : (a4cb537)<(Unknown)>
ConnId[1] : (a4c7537)<(Unknown)>
SubjDev[0] : 1401 (Private)
[UsrDeb]: H>S 38 bytes send, invoke id 34489, 0[2] requests pending
[UsrDeb]: Delivered: dest pi is passed > call (a4cb), thisDev <1401>, dest = <1660>
[UsrDeb]: link (linkctrl) S>H: (1[2] requests pending)
[UsrInf]: Transaction Info:
Type/Oper. : 3 258 <Error : <Operations (RequestIncompatibleWithObject)>>
hostRef : 86b9
[UsrDeb]: link (linkctrl) S>H: (0[2] requests pending)
...
@05/06/03@15:36:41.578 [CDcDeb]: cstaSwitchingEventDecode: ConnectionCleared event in progress
...
[UsrDeb]: call to clean: call(a4c7:006500f95998420b:3):{1401:I537>ori:cre:rel:$80100000}{006303507233:I4011b>des:act:est:$0}
[TMlInf]: TmParty::Release: for party <006303507233> in call (a4c7) with cause (Failed:57)
[TMlWrn]: line (140) cause not compatible with target state
[TMlDeb]: party <1401> removed from call (a4c7), state = (04)
[TMlDeb]: party <006303507233> removed from call (a4c7), state = (04)
[TMlDeb]: TmCall: call (a4c7) deleted

Any idea?

Thx

Szimi

[Claeshoj]

I have experienced the same problem, but in this case a majority of the calls are OK. A few get stuck and the customer will never on the other end will never be connected to an agent. There are enough of this happening to make some customers to complain.

Would appreciate if Szimi would enter the discussion again and share if the issue was solved and if so, how.

Thanks in advance

Claes H

[BablaX1]

There are several things I want you to check:

can you please ensure taht this does not happen for a particular trunk, DN? My original, and usually wrong guess, is that you do not have one of your trunks setup correctly and so when it tries to complete the transfer, it is not allowed to do it.

How often does it happen? What did Genesys say?

[Gui75]

High guys,

I have same kind of problems.
One outbound call is disconnected from client (when customers picks up the call) every 15 established calls.

For failed calls,  I have EventRouteUsed on RP but no CSTA event
Type/Oper. : 1 - 4 <Event : Delivered>
Record remains in retrieved stale.

I see in logs that there is always more than 300ms for these calls between
Request to route call to agent and final message

+++ RqHandler::RequestRouteCall +++
  got message from client <7>
  [2344/2344]: check device for 'RequestRouteCall'
  2344: routing to <2056>
  *** Transaction Info:
    Type/Oper. : 5 - 33 <Request : RouteSelectRequest>
    crossRef  : 20802e3
    hostRef    : 71
    SubjDev[0] : 2344 (Private)
    LocalDev[0]: 2344 (Unknown)
    LocalDev[1]: 2056 (Unknown)
    *** PrivateList has 1 elements:
      PData : Reroute Authorisation: 3f
    userInfo  : 7, 537
  H->S 47 bytes send, invoke id 113 (x71), 0[3] requests pending
--- RqHandler::RequestRouteCall ---
+++ Rq::RouteEndRequest +++
  *** Transaction Info:
    Type/Oper. : 5 - 35 <Request : RouteEndRequest>
    crossRef  : 20802e3
    hostRef    : 18c7
  an internal party <2056> with role '1' is added to the call (3:e112:3)
  PartyRQueue[e112:e112:2344]::SetContext: ref <537:239>
  PartyRQueue::Divert: from <e112:e112:2344/queued> to <e112:e112:2056> with cause (Distributed[38])
  PartyRQueue::Release: for <e112:e112:2344/queued/Ok> with cause (Distributed[38])
  PartyRQueue::commit::deleted[1]: for <e112:e112:2344/released> with cause/rel (0:0)

Final message :

[i]08/12/08@11:15:31.660 TmPartyPDN::commit::deleted[1]: for <e112:e110:8204/released> with cause/rel (0:0)
TmPartyPDN: <e112:e110:8204> removed, state = (0-4)
context is reset
TmPartyPDN: <e111:e111:8204> removed, state = (0-4)
context is reset
Call::~Call: (e111:e111:0:0) deleted[/i]

Note that number of disconnected calls sensibly increases in case of international calls.

I am thinking of increasing PBX timer 267 to value = 150 to see if it helps.

Any idea is welcomed

[cavagnaro]

how are you dialing? using PRI or maybe IP channels on OXE?

[Gui75]

Hi, I use PRI channels

[cavagnaro]

How many ghostz you have declared with VAD option = true?
How many licenses you have for VAD?
Are you using common hardware or crystal hardware? Or a mixture?

[Gui75]

Hola,
VAD is not activated a Ghost Z level because licenses have not been installed yet.
As for hardware, I will try to get the information.

[Gui75]

Hi all,

Finally it happens that this issue is some kind of bug to the fact I am using virtual login with Alcatel OXE.
If I use RSI or CCD login, it does not happen anymore.
And as I discovered that every alcatel phone including 4004 and analogic support RSI or CCD login!!!

Thanks for your help

[cavagnaro]

No bug, OCS documentation clearly specifies it doesn't support virtual agents mode.
And why shouldn't they support RSI or CCD mode? ACD prefix is the same for both.

[Gui75]

Hi Cavagnaro,

Could you please tell me where in OCS documentation it is written that it does not support emulated login.
I opened an incident on the subject on Genesys Support specifying clearly that I used emulated login and they did not see anything wrong in it. They also confirmed that the issue was on PBX side.

As for you question : "And why shouldn't they support RSI or CCD mode? ACD prefix is the same for both".
I never said that RSI or CCD mode was not supported and I know that it is the same prefix. Maybe my english?

Thanks anyway for your answers

[cavagnaro]

Lets be clear here, when you say emulated login is the fact that you can use Genesys login/logout/ready/not ready functions on an alcatel A4400 set which is not ProACD, right? Are you sure Genesys support guys understand this clearly?
Now lets think, OCS uses data on PG (ACD Queues) for knowing which agents are logged in and then using ghostZ dialers for transfering the customer call.
Let me search my documentations to indicate where exactly I read that emulated agents are not supported. Unless...new version of OCS does...will re-read all of it.

[Gui75]

Hi cavagnaro,
Indeed, you do not need anymore to log in a ACD Queue.
You do not even need to set login-ignore-queue option that does not exist anymore.
You do not even need to configure any origination DN on agent groups to have preview or progressive mode working