Genesys CTI User Forum
Genesys CTI User Forum => Genesys-related Development => Topic started by: dln on March 04, 2016, 12:40:25 PM
-
Hi
I'm currently building an outbound call center solution based on Genesys T-Server and I am having some trouble performing predictive calls.
I have the following setup:
- Alcatel A4400 PBX
- Genesys T-Server 8.1
- Java Application using the Genesys Java Platform SDK
According to the PBX operator, the Ghost-Z devices have been configured as described in the following document, p. 394 (Section "Configuring virtual Z dialing devices in the PBX without VAD"): https://docs.genesys.com/Special:Repository/80fr_dep-ts_a4400.pdf?id=d2f683c9-14eb-46aa-8230-406485fea7cf
The Genesys operator has configured the Ghost-Z devices as described on p. 395 of that same document (Section "Configuring devices for predictive dialing in Configuration Layer").
I have already implemented and tested most regular CTI-Operations (makeCall, transferCall, etc.), however I can't perform a predictive outbound call. When I perform a RequestMakePredictiveCall-Request using the following parameters, all I get is a "Request incompatible with object (1141) error":
thisDN: Agent's DN
otherDN: Callee's Number
timeout: 45 (seconds)
The corresponding T-Server log provided by the operator shows the following:
[code]10:45:45.836 Trc 04541 RequestMakePredictiveCall received from [636] (0000006c [applicationName] 10.0.0.44:44575)
message RequestMakePredictiveCall
AttributeOtherDN '00041417441128'
AttributeExtensions [24] 00 01 00 00..
'CPNDigits' '0800112133'
AttributeThisDN '2211'
AttributeTimeout 45
AttributeReferenceID 5
10:45:45.836 Int 04543 Interaction message "RequestMakePredictiveCall" received from 636 ("[applicationName]")
10:45:45.836 -- created: CRequest@2bf77a0 RequestMakePredictiveCall-[applicationName][636]/5
10:45:45.836 +++ CIFace::Request +++
-- new invoke
-- replace substitution with real device
Parsed: RequestMakePredictiveCall/RequestMakeCall
From: [applicationName][636]/5
Numbers: +<19920299> -<00041417441128>
Status: parsed:1 queued:0 sent:0 acked:0 preevent:0 event:0 context:0 transferred:0
Timers: dest. 45, agn: 0
-----
-- validate
CIFace: request not valid
10:45:45.836 Trc 36002 Request rejected: error code 1141(Request incompatible with object)
@10:45:45.8360 [0] 8.1.003.05 send_to_client: message EventError
(Request incompatible with object)
AttributeEventSequenceNumber 000000000000231e
AttributeTimeinuSecs 836000
AttributeTimeinSecs 1456998345 (10:45:45)
AttributeErrorCode 1141
AttributeErrorMessage 'Request incompatible with object'
AttributeReferenceID 5
AttributeTimeout 45
AttributeThisDN '2211'
AttributeExtensions [24] 00 01 00 00..
'CPNDigits' '0800112133'
AttributeOtherDN '00041417441128'
AttributeClientID 108
10:45:45.836 Int 04545 Interaction message "EventError" sent to 636 ("[applicationName]")
10:45:45.836 Trc 04542 EventError sent to [636] (0000006c [applicationName] 10.0.0.44:44575)
-- m_globalCnt reset
10:45:45.836 --- CIFace::Request ---
10:45:45.836 -- deleted: CRequest@2bf77a0 RequestMakeCall-[applicationName][636]/5
GLM_EV(op=1,res=0,ud=1)[/code]
19920299 is one of the configured Ghost-Z devices.
Is there something wrong with the RequestMakePredictiveCall-Invocation on the T-Server? Or is this a configuration issue?
-
The one who makes the call is the ghost Z, not the agent.
You have gpa2 boards enabled?
Can you dial from them doing substitution on the pbx?
-
Can you double-check that the DN 19920299 is set with Switch-specific Type = 4, just to rule this out?
-
Thank you for the quick replies!
@cavagnaro: I'll check with the PBX operator whether the gpa2 boards are enabled and whether it's possible to dial from them.
Regarding the Ghost Z: You are right of course. What confuses me however: the linked documentation contains passages like
[quote](Chapter 14, Introduction) These virtual Zs are available as a pool for T-Server to use for predictive dialing. They are not associated with any specific origination DN (Pilot or Routing Point) or outbound campaign.
...
(p. 395, section "Configuration Options") Defines the maximum time (in seconds) that T-Server waits for a free dialing resource to become available before rejecting a TMakePredictiveCall request. [/quote]
Doesn't that imply that T-Server manages the Ghost Z-Devices? And if I read the log correctly, T-Server already replaced ThisDN with a Ghost Z device (look in the log for 19920299), without ever specifying that DN in the call.
@hsujdik: The Genesys operator confirms that, yes. Unfortunately I don't have a way to verify that.
-
After trying around for a while it turns out that RequestMakePredictiveCall can only be invoked with thisDN of a RoutingPoint (RSI) and the Routing Point needs to load a strategy to route the call to a free agent.