Author Topic: Desktop UserEvent not fowarding to OCS (Read 9182 times)

dmonast · « **on:** May 22, 2008, 06:25:32 PM »

Hello All,

Question:
I have researched the Outbound Reference Guide and found nowhere does it say Agent Softphone must be connected to the TServer where the Voice Transfer Destination resides. Can the Agent Softphone connect to any TServer and still send UserEvents to OCS?

We are upgrading from 7.0 to 7.6 and we noticed our test Agent's UserEvent for "UpdateCallCompletionStats" and "RecordProcess" is not forwarding to OCS from TServer.

Here is our architecture:
Siemens HiPath (Switch A)
Cisco ICM (Switch B)

Our Genesys Campaign is configured with a Voice Transfer Destination (VTD) on Switch B. The strategy on the VTD is routing via ISCC to an Agent on Switch A. Softphone is sending UserEvent UpdateCallCompletionStats from desktop to tserver and tserver is not forwarding this event to the Outbound Contact Server.

In Genesys TServer 7.0 and OCS 7.0 we have no problems.
With Genesys TServer 7.6 and OCS 7.6 we have a problem.

[b]Example Logs Snippets (TServer 7.6 - Development Environment):[/b]
[tt]16:20:28.183 Trc 04541 RequestDistributeUserEvent received from [536] (00000009 FA343792_GenesysLink 172.21.157.48:1320)
message RequestDistributeUserEvent
AttributeCommunicationDN '30804'
AttributeUserData [193] 00 07 00 00..
'GSW_AGENT_REQ_TYPE' 'UpdateCallCompletionStats'
'GSW_APPLICATION_ID' 156
'GSW_CAMPAIGN_NAME' 'ISD_WDL'
'GSW_RECORD_HANDLE' 1
'DISPOSITION' 'FL'
'LAN_ID' 'a497214'
'DISPOSITION_SUB' ''
16:20:28.183 Int 04543 Interaction message "RequestDistributeUserEvent" received from 536 ("FA343792_GenesysLink")
-- Absent ThisDN, 30804 was used
@16:20:28.1830 [0] 7.6.007.01 send_to_client: message EventACK
AttributeEventSequenceNumber 0000000000001fb6
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 183000
AttributeTimeinSecs 1211404828 (16:20:28)
AttributeThisDN '30804'
AttributeUserEvent RequestDistributeUserEvent
16:20:28.183 Trc 04542 EventACK sent to [536] (00000009 FA343792_GenesysLink 172.21.157.48:1320)
@16:20:28.1830 [0] 7.6.007.01 distribute_user_event: message EventUserEvent
AttributeEventSequenceNumber 0000000000001fb7
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 183000
AttributeTimeinSecs 1211404828 (16:20:28)
AttributeUserEvent EventUserEvent
AttributeUserData [193] 00 07 00 00..
'GSW_AGENT_REQ_TYPE' 'UpdateCallCompletionStats'
'GSW_APPLICATION_ID' 156
'GSW_CAMPAIGN_NAME' 'ISD_WDL'
'GSW_RECORD_HANDLE' 1
'DISPOSITION' 'FL'
'LAN_ID' 'a497214'
'DISPOSITION_SUB' ''
AttributeThisDN '30804'
16:20:28.183 Trc 04542 EventUserEvent sent to [464] (00000003 CALL_CONCENTRATOR 192.0.2.25:3869)
16:20:28.183 Trc 04542 EventUserEvent sent to [488] (00000005 ROUTING_STAT_SERVER 167.138.64.95:3041)
16:20:28.183 Trc 04542 EventUserEvent sent to [500] (00000006 CCPULSE1_STAT_SERVER 167.138.64.96:4236)
16:20:28.183 Trc 04542 EventUserEvent sent to [476] (00000004 REPORTING_STAT_SERVER 167.138.64.79:3259)[/tt]

[b]Example Logs Snippets (TServer 7.0 - Production Environment):[/b]
[tt]13:05:58.232 Trc 04541 RequestDistributeUserEvent received from 1280 (136f FA296362_DesktopToolkitX)
message RequestDistributeUserEvent
AttributeCommunicationDN '30850'
AttributeUserData [222] 00 08 00 00..
'GSW_AGENT_REQ_TYPE' 'UpdateCallCompletionStats'
'DISPOSITION' 'B'
'DN_SWITCH_DBID' 101
'LAN_ID' 'A587791'
'GSW_APPLICATION_ID' 140
'GSW_CALLING_LIST' 'LNS_COL_D1'
'GSW_CAMPAIGN_NAME' 'CLB'
'GSW_RECORD_HANDLE' 353529
13:05:58.232 Int 04543 Interaction message "RequestDistributeUserEvent" received from 1280 ("FA296362_DesktopToolkitX")
-- Absent ThisDN, 30850 was used
@13:05:58.2320 [0] 7.0.200.04 send_to_client: message EventACK
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 232000
AttributeTimeinSecs 1211479558 (13:05:58)
AttributeThisDN '30850'
AttributeUserEvent RequestDistributeUserEvent
13:05:58.232 Trc 04542 EventACK sent to 1280 (136f FA296362_DesktopToolkitX)
@13:05:58.2320 [0] 7.0.200.04 distribute_user_event: message EventUserEvent
AttributeCustomerID 'Resources'
AttributeTimeinuSecs 232000
AttributeTimeinSecs 1211479558 (13:05:58)
AttributeThisDN '30850'
AttributeUserData [222] 00 08 00 00..
'GSW_AGENT_REQ_TYPE' 'UpdateCallCompletionStats'
'DISPOSITION' 'B'
'DN_SWITCH_DBID' 101
'LAN_ID' 'A587791'
'GSW_APPLICATION_ID' 140
'GSW_CALLING_LIST' 'LNS_COL_D1'
'GSW_CAMPAIGN_NAME' 'CLB'
'GSW_RECORD_HANDLE' 353529
13:05:58.232 Trc 04542 EventUserEvent sent to 780 (1050 CCPULSE1_STAT_SERVER)
13:05:58.232 Trc 04542 EventUserEvent sent to 524 (104f REPORTING_STAT_SERVER)
13:05:58.232 Trc 04542 EventUserEvent sent to 1624 (104e ROUTING_STAT_SERVER)
13:05:58.232 Trc 04542 EventUserEvent sent to 588 (1055 OCS) [/tt][b][color=red]It works in 7.0[/color][/b][tt]
13:05:58.232 Trc 04542 EventUserEvent sent to 564 (0006 CALL_CONCENTRATOR)
[/tt]

René · « **Reply #1 on:** May 22, 2008, 07:27:09 PM »

David,

Based on provided log snipes I would say that OCS 7.6 doesn't register agent's DN on switch A. In that case TServer won't send any event to OCS. Please check following using CME and OCS logs:

- Connection between OCS and TServer for switch A is configured in Genesys configuration
- OCS is able to establish connection to TServer for switch A
- OCS is able to register successfully agent's DN on switch A

Hope it helps you
René

victor · « **Reply #2 on:** May 27, 2008, 03:26:00 AM »

David,

I am pretty certain that as Rene (e with ALT-233) has suggested your OCS is not connected to that T-Server. UserEvents are sent to all servers that are registered for that DN...So, you either do not have OCS connected to that T-Server or... I am not sure if this is correct or not, but would T-Server send a UserEvent to OCS if OCS has not registered that DN with T-Server?

Usually, you would have some sort of Communication DN that OCS would register with each T-Server to receive UserEvents...I am looking through my code for the softphone and I see that I am using COMDN as TDN in my TExtension, thus I am using CommunicationDN for this events. I think there is a way to do update without use of Communication DN, but I think this only works when OCS is actually tracking that DN. If you are sending the update from a T-Server where OCS is not tracking this DN, I don't see a reason for T-Server to event notify OCS of the event.

Like I said, I am not sure about this, so I would check my connection first. If it is intact, I would then check out CommunicationDN

Luk · « **Reply #3 on:** May 27, 2008, 09:38:28 PM »

Hi Dmonast,

altough I cannot answer your question, I would like to react on this thread because we have a similar problem. For us it's the other way around: we don't see any messages from OCS appear in Agent Desktop...

Even the campaigns that are started don't show up in Agent Desktop and if we play with starting and stopping campaigns, we don't get any messages about it.

Our configuration is as follows:
OCS 7.5
T-server 6.5
Switch = Avaya

I checked the connections tab for OCS and it has a connection to T-server.

About OCS registering agent DN's on the switch, I'm not sure (and I don't know if this has anything to do with it): The Voice Transfer Destination for the Campaign Groups is set to a queue/VDN on the Avaya. Will it monitor it? What do I have to pay attention for?

Could the fact that OCS and T-server have a completely different version case this malfunctioning?

I did not yet get the log files, so I was unable to check them or post them here.

Hope we can get to a solution for both of us

Best regards,
Luk

cavagnaro · « **Reply #4 on:** May 27, 2008, 10:14:08 PM »

Yours seems more easy. Have you created the DN object Communication DN on CME? It can be with name COMMDN for example, it is a dummy object that only works for sending TEvents to OCS

tschoi · « **Reply #5 on:** May 27, 2008, 10:58:06 PM »

Hi,

Let me explain the way OCS uses UserEvents.

It can be said that there are two kinds of UserEvents used by OCS. One is not related to a particular agent and OCS uses Communication DN to send and receive it. These kinds of UserEvents are used by OCS to send statistic information to StatServer, also receive campaign control messages and to receive DoNotCall information. BTW, OCS uses ComDN located with the same switch as Voice Transfer Destination.

Another type is agent related ones, like campaign status notifications to agent and call record processing. OCS uses the DN that agent logs on to send/receive those UserEvents and as such should register all DNs to Tservers that it connects to.

One design feature (at least up to 7.2) is OCS registers all DNs of type Position and Extension, only if they are associated with a Place.

My suggestion is:

1) Check Tserver is in connections tab of OCS

2) Check the extensions are associated with a Place

If both is true and OCS is not still registering those DNs, you may need to contact Genesys Technical Support.

Regards,
Taisuk

Luk · « **Reply #6 on:** May 28, 2008, 10:17:46 AM »

[quote author=cavagnaro link=topic=3003.msg12186#msg12186 date=1211926448]
Yours seems more easy. Have you created the DN object Communication DN on CME? It can be with name COMMDN for example, it is a dummy object that only works for sending TEvents to OCS
[/quote]

Hi cavagnaro,

This DN object Communication DN is present in CME, in the same folder as the DNs I use in the Voice Transfer Destination box of the Campaign Group object.
The DNs I use are of type ACD Queue. Is that ok for the registration of the DNs? How to check that?

Thanks, Luk

Luk · « **Reply #7 on:** May 28, 2008, 10:21:31 AM »

[quote author=Taisuk link=topic=3003.msg12187#msg12187 date=1211929086]
Hi,

Let me explain the way OCS uses UserEvents.

It can be said that there are two kinds of UserEvents used by OCS. One is not related to a particular agent and OCS uses Communication DN to send and receive it. These kinds of UserEvents are used by OCS to send statistic information to StatServer, also receive campaign control messages and to receive DoNotCall information. BTW, OCS uses ComDN located with the same switch as Voice Transfer Destination.

Another type is agent related ones, like campaign status notifications to agent and call record processing. OCS uses the DN that agent logs on to send/receive those UserEvents and as such should register all DNs to Tservers that it connects to.

One design feature (at least up to 7.2) is OCS registers all DNs of type Position and Extension, only if they are associated with a Place.

My suggestion is:

1) Check Tserver is in connections tab of OCS

2) Check the extensions are associated with a Place

If both is true and OCS is not still registering those DNs, you may need to contact Genesys Technical Support.

Regards,
Taisuk
[/quote]

Hi Taisuk,

1) Yes, T-Server in connections tab of OCS
2) How to check this?

Thanks for your help, Luk.

cavagnaro · « **Reply #8 on:** May 28, 2008, 02:22:15 PM »

[quote author=Luk link=topic=3003.msg12191#msg12191 date=1211969866]
[quote author=cavagnaro link=topic=3003.msg12186#msg12186 date=1211926448]
Yours seems more easy. Have you created the DN object Communication DN on CME? It can be with name COMMDN for example, it is a dummy object that only works for sending TEvents to OCS
[/quote]

Hi cavagnaro,

This DN object Communication DN is present in CME, in the same folder as the DNs I use in the Voice Transfer Destination box of the Campaign Group object.
The DNs I use are of type ACD Queue. Is that ok for the registration of the DNs? How to check that?

Thanks, Luk
[/quote]

REstart TServer and cjheck detailed (all) logs, you will see how it goes and starts to register and request monitoring for each DN, if something is wrong you will see a warn there.

Luk · « **Reply #9 on:** May 28, 2008, 04:20:37 PM »

[quote author=cavagnaro link=topic=3003.msg12197#msg12197 date=1211984535]
REstart TServer and cjheck detailed (all) logs, you will see how it goes and starts to register and request monitoring for each DN, if something is wrong you will see a warn there.
[/quote]

Believe it or not Cavagnaro, but restarting Tserver is not really possible as it is part of a production environment! I've asked the sys admin to restart OCS and I'm about to get log files from that. I hope searching for GSW_USER_EVENT and CampaignStarted returns me something...
Is there something of the registration of DNs in the OCS log file?

Thanks a lot,
Luk.

Luk · « **Reply #10 on:** May 28, 2008, 04:47:08 PM »

Just an idea,
Could it not be the T-server option "acd-register-mode" which is set to "eas" that is stopping the messages from being sent to the Desktop?

Thx, Luk

cavagnaro · « **Reply #11 on:** May 28, 2008, 05:18:30 PM »

[quote author=Luk link=topic=3003.msg12200#msg12200 date=1211991637]
[quote author=cavagnaro link=topic=3003.msg12197#msg12197 date=1211984535]
REstart TServer and cjheck detailed (all) logs, you will see how it goes and starts to register and request monitoring for each DN, if something is wrong you will see a warn there.
[/quote]

Believe it or not Cavagnaro, but restarting Tserver is not really possible as it is part of a production environment! I've asked the sys admin to restart OCS and I'm about to get log files from that. I hope searching for GSW_USER_EVENT and CampaignStarted returns me something...
Is there something of the registration of DNs in the OCS log file?

Thanks a lot,
Luk.
[/quote]

Uh, production already...maybe at midnight? $:-\$ Usually that is what I do.

Genesys CTI User Forum

News:

Author Topic: Desktop UserEvent not fowarding to OCS (Read 9182 times)

dmonast

Desktop UserEvent not fowarding to OCS

René

Re: Desktop UserEvent not fowarding to OCS

victor

Re: Desktop UserEvent not fowarding to OCS

Luk

Re: Desktop UserEvent not fowarding to OCS

cavagnaro

Re: Desktop UserEvent not fowarding to OCS

tschoi

Re: Desktop UserEvent not fowarding to OCS

Luk

Re: Desktop UserEvent not fowarding to OCS

Luk

Re: Desktop UserEvent not fowarding to OCS

cavagnaro

Re: Desktop UserEvent not fowarding to OCS

Luk

Re: Desktop UserEvent not fowarding to OCS

Luk

Re: Desktop UserEvent not fowarding to OCS

cavagnaro

Re: Desktop UserEvent not fowarding to OCS