Genesys Outbound not dialing

I have such a problem. I’ve installed and configured Genesys Outbound which interfaces with AVAYA Definity G3 software version 9.5. When I start a campaign, records in the Call Lista are updated (their status changes from Ready to Updated) but Avaya PBX does not dial these numbers from Call List. My Avaya PBX does have CPD boards TN744 D so, there is no need to use any external CPD Servers with for instance Dialogic boards. I’ve not found any problems reported in the TServer log (and OC Server log).

What could cause the problem ?

I’ve attached the proprer piece of TServer log below.

Please, help me suggest me the problem resolution analysing this piece of log.

8/06/02 15:35:06.843 Trace ctptwpl2 TServerAVAYA GCTI04541 Message RequestMakePredictiveCall received from 704

( regular OCServer )

@15:35:06.8430 [0] Received from 704 (OCServer): message RequestMakePredictiveCall

AttributeThisDN	'7929'

AttributeOtherDN	'00604644381'

AttributeTimeout	120

AttributeUserData	[202] 00 08 00 00..

	'GSW_PHONE'	'00604644381'

	'GSW_TZ_OFFSET'	'3600'

	'GSW_CALLING_LIST'	'OCCalllist'

	'GSW_CAMPAIGN_NAME'	'CAMPAIGN1'

	'GSW_APPLICATION_ID'	174

	'GSW_RECORD_HANDLE'	'18'

	'GSW_CHAIN_ID'	'4'

	'GSW_CALL_RESULT'	'14'

AttributeExtensions	[2] 00 00..

AttributeReferenceID	2330

** ts6.1.011.01[1] ** 15:35:06.8590

08 00 00 4C 08 02 02 24 64 96 1C 44 91 A1 41 02 01 6D 02 01 83 40 39 6C 05 80 37 39 32 39 70 0C 80 30 30 36 30 35 36 35 35 33

36 31 7E 0F 04 47 43 54 49 2F 52 65 66 3A 20 32 33 33 30 96 4B 02 81 8F 4B 02 82 81 4B 01 8C 4B 02 8E 81 4E 01 81

=== parsed message ===

prot_discr = 8

CRV = 224

MsgType = 100 (REGISTER)

Facility: serv_discr = 17(q932_suppl) fac_ie = component_tag = A1(INVOKE)

invoke_id tag: 02, value = 109

operation tag: 02, value = 131(TP_MakeCall)

params = q931_tag = 40

list =

Calling_Party_Number: type_plan = 0(unknown) address = 7929

Called_Party_Number: type_plan = 0(unknown) address = 00604644381

User_User_Info: prot_discr = 4(IA5_chars) user_info = [14] 47 43 54 49 2F 52 65 66 3A 20 32 33 33 30 ‘GCTI/Ref: 2330’

Call_Options: # elems = 4

option = 1(num_rings) value = 15

option = 2(alert_order _0_calling_1st__1_called_1st) value = 1

option = 12(return_ACK) value = 1

option = 14(ans_mach_treat _0_admin__1_drop__64_answer) value = 1

Service_Circuit: type = 1(call_classif tone_detect)

** link[1] ** 15:35:06.9210

08 02 82 24 62 96 1C 13 91 A1 10 02 01 02 02 01 BD 40 08 10 02 02 29 96 44 01 81

=== parsed message ===

prot_discr = 8

CRV = 8224

MsgType = 98 (FACILITY)

Facility: serv_discr = 17(q932_suppl) fac_ie = component_tag = A1(INVOKE)

invoke_id tag: 02, value = 2

operation tag: 02, value = 189(Proceed)

params = q931_tag = 40

list =

Call_Id: call_id = 553

Party_Id: party_id = 1

send_to_all_backup_servers:

message RequestSetCallInfo

AttributeCallType	0

AttributeConnID	006700e496803034

AttributeCallID	553

sent to 600 (TServerAVAYABackup)

@15:35:06.9210 [0] 6.1.011.01 distribute_response: message EventDialing

AttributeTimeinuSecs	921000

AttributeTimeinSecs	1028640906 (15:35:06)

AttributeReferenceID	2330

AttributeOtherDNRole	2

AttributeOtherDN	'00604644381'

AttributeThisDNRole	1

AttributeThisDN	'7929'

AttributeCustomerID	'Resources'

AttributeUserData	[202] 00 08 00 00..

	'GSW_PHONE'	'00604644381'

	'GSW_TZ_OFFSET'	'3600'

	'GSW_CALLING_LIST'	'OCCalllist'

	'GSW_CAMPAIGN_NAME'	'CAMPAIGN1'

	'GSW_APPLICATION_ID'	174

	'GSW_RECORD_HANDLE'	'18'

	'GSW_CHAIN_ID'	'4'

	'GSW_CALL_RESULT'	'14'

AttributeConnID	006700e496803034

AttributeCallID	553

AttributeCallType	0

08/06/02 15:35:06.937 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventDialing sent to 704 ( regular OCServer

)

sent to 704 (OCServer)

08/06/02 15:35:06.937 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventDialing sent to 672 ( regular Stat

Server )

sent to 672 (Stat Server)

08/06/02 15:35:06.937 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventDialing sent to 640 ( regular Stat

Server Backup )

sent to 640 (Stat Server Backup)

08/06/02 15:35:06.937 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventDialing sent to 624 ( regular

Universal Routing Server )

sent to 624 (Universal Routing Server)

08/06/02 15:35:06.937 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventDialing sent to 616 ( regular

Universal Routing Server Backup )

sent to 616 (Universal Routing Server Backup)

send_to_all_backup_servers:

message EventDialing

AttributeTimeinuSecs	921000

AttributeTimeinSecs	1028640906 (15:35:06)

AttributeOtherDNRole	2

AttributeOtherDN	'00604644381'

AttributeThisDNRole	1

AttributeThisDN	'7929'

AttributeCustomerID	'Resources'

AttributeUserData	[202] 00 08 00 00..

	'GSW_PHONE'	'00604644381'

	'GSW_TZ_OFFSET'	'3600'

	'GSW_CALLING_LIST'	'OCCalllist'

	'GSW_CAMPAIGN_NAME'	'CAMPAIGN1'

	'GSW_APPLICATION_ID'	174

	'GSW_RECORD_HANDLE'	'18'

	'GSW_CHAIN_ID'	'4'

	'GSW_CALL_RESULT'	'14'

AttributeConnID	006700e496803034

AttributeCallID	553

AttributeCallType	0

sent to 600 (TServerAVAYABackup)

** link[1] ** 15:35:06.9370

08 02 82 24 5A 96 1C 13 91 A1 10 02 01 02 02 01 BB 40 08 08 02 81 9F 10 02 02 29

=== parsed message ===

prot_discr = 8

CRV = 8224

MsgType = 90 (RELEASE COMPLETE)

Facility: serv_discr = 17(q932_suppl) fac_ie = component_tag = A1(INVOKE)

invoke_id tag: 02, value = 2

operation tag: 02, value = 187(TP_CallEnded)

params = q931_tag = 40

list =

Cause: code_std_loc = 1(CCITT_PubNetLocUsr) cause = 31(C_NORMAL_UNSPECIF C_FORWARD_ALL)

Call_Id: call_id = 553

@15:35:06.9530 [0] 6.1.011.01 distribute_event: message EventReleased

AttributeTimeinuSecs	953000

AttributeTimeinSecs	1028640906 (15:35:06)

AttributeCallState	14

AttributeThisDNRole	1

AttributeThisDN	'7929'

AttributeCustomerID	'Resources'

AttributeUserData	[202] 00 08 00 00..

	'GSW_PHONE'	'00604644381'

	'GSW_TZ_OFFSET'	'3600'

	'GSW_CALLING_LIST'	'OCCalllist'

	'GSW_CAMPAIGN_NAME'	'CAMPAIGN1'

	'GSW_APPLICATION_ID'	174

	'GSW_RECORD_HANDLE'	'18'

	'GSW_CHAIN_ID'	'4'

	'GSW_CALL_RESULT'	'14'

AttributeConnID	006700e496803034

AttributeCallID	553

AttributeCallType	0

08/06/02 15:35:06.968 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventReleased sent to 704 ( regular

OCServer )

sent to 704 (OCServer)

08/06/02 15:35:06.968 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventReleased sent to 672 ( regular Stat

Server )

sent to 672 (Stat Server)

08/06/02 15:35:06.968 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventReleased sent to 640 ( regular Stat

Server Backup )

sent to 640 (Stat Server Backup)

08/06/02 15:35:06.968 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventReleased sent to 624 ( regular

Universal Routing Server )

sent to 624 (Universal Routing Server)

08/06/02 15:35:06.968 Trace ctptwpl2 TServerAVAYA GCTI04542 Message EventReleased sent to 616 ( regular

Universal Routing Server Backup )

sent to 616 (Universal Routing Server Backup)

TEP: delete local call (localid ‘006700e496803034’)

08/06/02 15:35:07.015 Trace ctptwpl2 TServerAVAYA GCTI04541 Message RequestDistributeUserEvent received from

704 ( regular OCServer )

Andrew,

From the call result it looks like you are not getting any dial tone. Not sure about the Avaya environment but may be worth checking that side of things as the rest looks like it is operating correctly.

Rory

I have found several things in the log you should look at:

First of all, your calltype of eventdialing is …0!

This is CallTypeUnknown. I have never seen it before.

Also, can you check that you can call 00604644381 from that DN and connect to somewhere?

As you have noticed, you ARE dialing and PBX drops the call right after you dial EventReleased for your call has a cause 31:

Cause: code_std_loc = 1(CCITT_PubNetLocUsr) cause = 31(C_NORMAL_UNSPECIF C_FORWARD_ALL)

Have your PBX people chech the error code.

Also what is your TServer version. You will need 6.1.024.02 or above to make sure that it will work.

Vic

Hello,

Thank you very much for your suggestion. I have another question. What element in the PBX Avaya physically makes dialling for OCS. Is it TN744D board ? And how it is doing that ?

Thank you very much for your answer. Could you suggest me where and how to setup CallType (because of that CallTypeUnknown) on the PBX or Genesys parms, please ?

What calltype of eventdialing value is mostly visible in logs for OCS calls ?

Sorry, Never played with the Avaya only Meridian so I’m not sure what component is actually doing your dialling.

Rory

Andrew, CallType is returned by PBX, so this does not seem to be a Genesys problem.

Usually, with an outbound, your calltype would be 3.

Since you are getting 0, your PBX is probably is confused.

What TServer version are you using?

Where you able to dial from that DN to the that 006xxx number MANUALLY?

If yes, then, next, see if you can dial out using PRogressive plan instead of predictive.

Have you tried turning amdetection off?

Here is what I think the problem might be from very higly to unlikely:

You cannot dial that number from that DN

you are using a bad TServer version

PBX settings are wrong

The fact that this is a predictive call messes things up

amdetection

What does Genesys support say?

Currently I have installed TServer version 6.1.011.01. Does this mean that this vesion could cause my “not dialling” problem ? Have you heard about similar problem caused by wrong TServer version ?

I remember hearing somewhere that TServer version 6.1.024.02 or above is necessary to get it to properly working. I will try to find where it says that…

In the meantime, were you able to solve the problem?

I’ve installed and used Dialogic board and CPD Server. Now it everything works fine. But we are using external dialing mechanism, not PBX dialing …

About the CallType in the EventDialing you should check the TServer documentation for the Definity G3. If you do a find on ‘setcall ypeondialing’ you will see that if the parameter is set to false you will always have CallType 0 in the EventDialing.

You should also check your call_connected_timeout option in the TServer configuration.

Thanks for the info!

Silly question, but in his log, it sure seems like PBX is actually dropping the call not Genesys…am I wrong?

I don’t know it’s hard to say without seeing the TServer log file for the same call.