Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Gururaj S on December 17, 2008, 12:45:33 PM
-
Hi Genesys Experts,
We have installed Genesys Outbound suite with Avaya pbx which has call classifier. Line used now is E1-R2.
Before we were using ISDN line and predictive was working fine with ISDN. But customer
prefers E1-R2 line for various reasons.
The Outbound campaign runs fine in preview mode. But predictive mode gives
problem. OCM shows [b][i]system error[/i][/b] for all calls in predictive mode. Tserver log shows
[b]A_NO_CLASSIFIERS[/b] error for all calls in predictive mode.
We did a lot of testing and from Avaya trace, we can make out that in predictive mode
AVAYA is not dialing the complete digits and also NO trunk seizure is happening.
Whereas in preview mode we can see complete number dialed on trace and also
trunkseizure is happening.
I would like to know if there is any successful case of predictive dialing with E1-R2 on Avaya with call
classifiers.
I have attached a sample log for the scenario and also avaya trace file.
We would be thankful if you can have a look and suggest any change.
Thanks in advance!
-
Maybe there is a difference in COR settings (especially seizing trunks) between agent extension and VDN from which your dialing. I would first look at it. If it doesn't work, I'd try to prepare calling progressive without CPD.
The obvious difference is that call made from VDN uses CPD and that made from agent extension not.
Regards
jbobinsk
-
Never work on E1-R2 trunk signal...
However, "similar" case was encountered when interfacing to some PSTN carriers.
- when making outbound call via CTI-enabled soft-phone, call was dropped
- if making outbound call manually via hard-phone, call succeeded
In Avaya trunk configuration page,
- search for an option something like "Suppress sending # (y/n)": n
- change the value to 'y' (Note: try it in non-operational hours, please!)
1. Not sure if the similar option exists in E1-R2 trunk configuration
2. it may not be the root-cause but worth to try!
As in previous post by jbobinsk, COR/COS is good point to check.
-
Hi,
my initial guess would be call - does it allow outbound calls?
-
Hi jbobinsk,
Thank you for your suggestion! :)
About the COR, both agent extension and VDN have the same COR-124. And COR 124
is allowed to do outbound calls. You have suggested about progressive dialing without CPD. We are not using
CPD server but Avaya pbx has call classifier.
I would like to know if progressive dialing is possible without using CPD or call classifier.
Thank You once again!
Hi Bcyk,
Thanks for your quick response.. :)
You have said that predictive never work on E1-R2 signal.
I would want you to be a bit more detail if possible..
Using the same E1-R2, preview mode campaign or manual dialing works perfect.
But we are facing this problem only in predictive mode..
I will try your suggestion regarding trunk option and update..
Thank You once again!
Hi victor,
We are able to do outbound calls in preview mode and it works perfect..
Also, predictive mode is working fine for internal extensions.
It is not dialing only outside numbers. I would like to know if i can use any virtual extension
and forward calls to outside number as a temporary solution.
For example: The calling list has 500 numbers. I will create 500 virtual extensions for these
numbers and activate call forward to corresponding outside numbers.
Thank You for the response! :)
This forum has given me hope in a tight situation like this.. I am thankful for that.
-
CPD - is Call Progress Detection - for example call clasifier card uses this function.
Yes - you can use predictive without Call Classifier - the only difference is that you cannot recognize answering mashine and fax, but standard call progres (busy, no answer, wrong number) go in signaling part and your switch will send it through CTI link to TServer as well. You have to only block recognizing answering machine in TServer, and OCS and use agent for checking who answered the call.
You can also try to make call as OCS do by calling TMakePredictiveCall from TLib to easily check what is happening without a need to start campaign.
Additionally try to use somebody from AVAYA administrators to monitor what is going on on trunks while you make call - because it can be that function to create predictive call doesn't make it and switch stops doing it before trunk seize.
regards
jbobinsk
-
Hi Jbobinsk,
Thank You for the info!
So what i understood is that we can do predictive dialing without using call classifier after doing
some changes in Tserver and OCS configuration settings.
Do i need to change any other settings for achieving this?
Regards,
Gururaj S
-
I'm not sure - but as I remember there is something declared on PBX that tells when use Call Classifier - maybe you have some admin of it and he could help you with switching it off.
Regards
jbobinsk
-
Hi Jbobinsk,
Thank You! :)
I would like to confirm from you once again that if predictive dialing
is possible without call classifier or CPD server. Have you seen any such
scenario working fine?
Thanks and Regards,
Gururaj S
-
Yes progressive/predictive will work without CPD or Call Classifier - I always configure it without them because level of recognizing is about fifty-fifty.
Regards
jbobinsk
-
Hi Jbobinsk,
Thank You once again for the quick turn around! :)
I will try to configure predictive without cpd and update..
Thanks and Regards,
Gururaj S
-
Hi Jbobinsk,
I verified with the Avaya person. He told me that call classifier board is placed in the pbx and is
used by the entire setup including extensions. I need your help on how to tell Genesys not to use
call classifier while dialing.
Thanks,
Gururaj S
-
You have to set two options:
in TServer application option use_am_detection=false located in TServer section
in OCS application option call_answer_type_recognition=no_am_detection in OCServer section
and it should work.
regards
jbobinsk
-
Hi Jbobinsk,
Thank You! I will update once this is tested.
Merry X'mas wishes...
Regards,
Gururaj S
-
Hi Jbobinsk,
I tested with the below options:
in TServer application option use_am_detection=false located in TServer section
in OCS application option call_answer_type_recognition=no_am_detection in OCServer section
But we still get the same error (A_NO_CLASSIFIERS)
I verified with the Avaya person about any PBX settings to be done,
to tell Genesys not to use call classifiers. But he is not sure of the PBX option to be configured.
Thanks for your time,
Gururaj S
-
Hi,
I'm really surprised that it doesn't work in this way.
Try to ask the switch through TServer how many ports of Call Classifier is available.
You need to send something like this:
11:39:16.202 Trc 04541 RequestQueryAddress received from [19] (0000018e DesktopToolkitX 10.23.105.6:1576)
message RequestQueryAddress
AttributeThisDN '8000'
AttributeAddressType 3 (Queue)
AttributeAddressInfoType 12 (AddressInfoNumberOfIdleClassifiers)
AttributeReferenceID 3
and as a result you should retrieve for example:
@11:39:16.2244 [0] 7.6.006.04 send_to_client: message EventAddressInfo
AttributeEventSequenceNumber 000000000000d91c
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 224457
AttributeTimeinSecs 1232102356 (11:39:16)
AttributeExtensions [29] 00 02 01 00..
'Idle' 8
'InUse' 0
AttributeThisDN '8000'
AttributeReferenceID 3
AttributeAddressInfoType 12 (AddressInfoNumberOfIdleClassifiers)
AttributeAddressInfoStatus 8
If you will get 0 Idle then there is something undeclared on the switch (I suppose).
Regards
jbobinsk
-
Hi Jbobinsk,
Thank You once again for coming into this thread!
You have asked to send RequestQueryAddress. We donot have Genesys SDK. But we have Activex Desktop toolkit.
Please let me know how can i send this message (RequestQueryAddress ) using the Desktop toolkit X.
Regards,
Gururaj S
-
Hi again,
I have attached Excel file which has userform with Desktop Toolkit activexes.
First you should to set:
on TConnection1
THost and TPort where your TServer exists
on TExtension1
TDN of VDN or Extension.
When you do this start makro and press button Request.
On the log screen on left side choose TConnection, o right side you will see EventAddressInfo. Inside it there is section Extensions where you will see values Idle and InUse.
Regards
jbobinsk
-
[quote author=bcyk link=topic=3676.msg15699#msg15699 date=1229543268]
Never work on E1-R2 trunk signal...
However, "similar" case was encountered when interfacing to some PSTN carriers.
- when making outbound call via CTI-enabled soft-phone, call was dropped
- if making outbound call manually via hard-phone, call succeeded
In Avaya trunk configuration page,
- search for an option something like "Suppress sending # (y/n)": n
- change the value to 'y' (Note: try it in non-operational hours, please!)
1. Not sure if the similar option exists in E1-R2 trunk configuration
2. it may not be the root-cause but worth to try!
As in previous post by jbobinsk, COR/COS is good point to check.
[/quote]
Hi Bcyk,
Actually this is my first post and I'm new here. Your answer prompted me to post this inquiry. Re: Predictive Outbound
"Never work in E1-R2 trunk signal" - Is this in general or this is specific for Avaya and Genesys combination, or Avaya alone.
Currently, I'm looking for the right system (of course with Genesys) that will do both Predictive and Preview with an ISDN or E1/R2 Trunk.
I hope to hear from you soon.
Thanks.
-
Hi DeepPurple
Sorry for the misleading phase....
"Never work in E1-R2 signal" means "I myself never work or have experience on E1-R2 signal in previous inbound/outbound call center implementation"
Some common trunk-side protocols are PRI T1/E1 and CO lines (with busy-tone detector).
Although I do not have experience using E1-R2, the protocol being around for years should work as long as voice path between PABX and PSTN is connected.
Call result classification mainly depends on what Call Progress Detection (CPD) device is being used.
Most PABXs/switches support multiple signal protocols to PSTN; it should be nothing to do with switch brand.
In the mentioned case, Avaya switch trunk group configuration sends "End-of-command" character # (pound) by default; the connected PSTN node (for some reasons that I don't know) cannot process the received digits chunk fast enough and aborts the call [b]WHEN MAKING OUTBOUND CALL VIA CTI[/b]. [u]Manual dial via hard-phone works as normal, however.[/u]
In one of previous implementations, inbound/outbound trunks were connected to two "clustered" PSTN nodes. Manual test calls showed that one of clustered nodes failed to process with "#" but the other was capable of receiving CTI-initiated outbound calls. (Instead of waiting forever for PSTN carrier to fix the issue, the "End-of-command" character was disabled in Avaya switch.)
It is [b][color=red]NOT [/color] [/b] sure how CPD device (e.g., Avaya classified board or Dialogic card) translates digital trunk signal from PSTN side to outbound application.
In PRI (Primary Rate Interface) T1 or E1, it follows Q.931 in which "cause code" indicates a list of call results.
In digital E1-R2, it follows Q.421; it is NOT sure if there is "cause code" equivalence as in Q.931 for T1/E1.
Advantage of digital trunks are to receive some call results immediately such as busy (by control data signal, not busy-tone pattern), congestion (by control data signal, not congestion tone) and unallocated number (not SIT).
No matter what PABX/switch is used, there are 3 possible configurations in Genesys.
1. PABX/switch built-in CPD device (e.g., Avaya classified board)
- Genesys CPD server is not required
- trunk-side digital control signal/reply (busy, unallocated, ...) can be passed to application
2. Line-side extension with third-party CPD device
- Genesys CPD server is required
- third-party CDP device such as Dialogic card
- analogue extensions or digitial extensions
*in digital extension such as T1/E1 (or even E1-R2 if supports!), analogue in-band signal is programmed in switch!
i.e., for T1, the 24th control channel is configured as voice channel; thus, 24 extensions per T1
- trunk-side digital control signal/reply CANNOT be passe to application
3. Genesys CPD server ASM configuration
(again, I never have experience in configuring this...yet!)
- in a server machine, two sets of digital trunks are required
- digital trunk group 1: connected to PSTN network, CPD capacity is required
- digital trunk gropu 2: connected to PABX/switch
- Genesys CPD server is required
- When an outbound is connected and classified as "Positive Voice Call",
the channel in trunk group 1 and one of channels in trunk group 2 will be bridged.
The connected call will be distributed to one of ready agents in the outobund campaign
- trunk-side digital control signal/reply (busy, unallocated, ...) can be passed to application
In short, the second line-side configuration provides the smallest call results set due to the lack of trunk-side call result information. For example, call results SIT-xxxx (xxxx = Vacant, Reorder, interrupt, ....) in Genesys campaign reports are also zero.
regards
-
Can you please post T-Server logs?
-
There are no options in OCS that can affect the way TServer makes it's predictive outbound calls. I have recently asked this question of Genesys as I wanted to turn AM Detection off for certain campaigns and on for others, it cannot be done. It can only be done by TServer option at TServer level only.
My gut tells me this is definitely switch configuration, but not being a PBX engineer I have no further help to give. I do however have a very experienced Avaya engineer that works 6 feet from my desk, I will ask him tomorrow and see if he has any clues.
-
hi Dionysis,
There [color=red][b]ARE[/b][/color] options to configure different recognition at Campaign level!
e.g.,
campaign-A = no_progress_detection
campaign-B = positive_am_detection
campaign-C = accurate_am_detection
Note: You may need to change Genesys Configuration Manager options to make [Annex] tab visible in object properties.
In Genesys Configuration Manager
-> open the "Campaigns" folder in /Configuration/Resources
-> select target campaign name
-> double-click to view campaign's [Properties]
-> click the [Annex] tab in the properties window
-> if there is empty section, create one (the New icon with blank sheet)
-> the section name is "OCServer" or the application name of your OCS server
-> click [OK] after inputting OCServer in "Section Name", in [Add Section] window
-> click into the "OCServer" section
-> OCS campaign level option names and values can be defined here
-> example for detection type:
Option Name = call_answer_type_recognition
Option Value= no_am_detection
To have different "call_answer_type_recognition" value, repeat above steps for each campaign.
If options are not defined at campaign level, options/values in OCServer application will be used.
If options are not defined in OCS application, default values will be applied.
Please do check OCS deployment and reference manuals for your current OCS version.
Above steps are also applicable to "Calling list level" and other levels; keys are to create [Annex] tab for the target object and study relevant manuals.
regards
-
As far as I know this is only if CPD server is used.
-
You are absolutely correct, cavagnaro!
call_answer_type_recognition is applicable if and only if CPD server is installed.
For switch-based CPD device, relevant options in T-server are referred.
It is wondered if these T-server options can be configured (and effective) at Campaign level in Annex tab!
It may be the time to issue Genesys SR....