Customer Answered calls marked stale by OCS

[Ansh]

Hey Everyone,

We have a problem where OCS is marking calls 'stale' even after customer answers the call and agent makes a sale.
This is happening for random calls and it started somewhere in March 2013. Our campaigns are running the same way since 2005 without any modifications/config changes.
Few examples we investigated back in March showed 'Recordprocessed' event was not being received by OCS (from Agent softphone, which is Amdocs provided) and because of some business agreement issues with Amdocs we were unable to investigate that from softphone side.
As a workaround we changed record_processed option to 'False'. The issue is still not resolved but looks like its now for a different reason as from the TServer logs I can see

[color=red][b]11:43:44.328 Trc 04541 RequestDeleteUserData received from 5124 (a4bd )[/b][/color]

message RequestDeleteUserData

AttributeThisDN '25541'

AttributeConnID 00ec023200277e57

AttributeReferenceID 96

11:43:44.328 Int 04543 Interaction message "RequestDeleteUserData" received from 5124 ("")

@11:43:44.3280 Call [00ec023200277e57]: urid 000400ec

@11:43:44.3280 [0] 7.2.008.01 distribute_response: message EventAttachedDataChanged

Looks like some anonymous TServer client is requesting to delete GSW UserData.

Is there any workaround to resolve this? Any way to identify this anonymous client? In 7.2 version of T-server the IP address does not get printed in the logs. Anyone else faced such problem?

Thanks,
Ansh

[cavagnaro]

Stale means your agent received the call but then he lost the link with it. Check if RecordProcessed option is available. Follow the full call including post call agent actions.

[Fra]

[quote author=Ansh link=topic=8040.msg35358#msg35358 date=1381765100]
We have a problem where OCS is marking calls 'stale' even after customer answers the call and agent makes a sale.
This is happening for random calls and it started somewhere in March 2013. Our campaigns are running the same way since 2005 without any modifications/config changes.
Few examples we investigated back in March showed 'Recordprocessed' event was not being received by OCS (from Agent softphone, which is Amdocs provided) and because of some business agreement issues with Amdocs we were unable to investigate that from softphone side.
As a workaround we changed record_processed option to 'False'.
[/quote]
If the solution has been working since 2005 without any mofications/changes, as you stated, why would you expect the issue to be fixed by changing a key option as record_processed? If record_processed was set to 'True' and you believe it wasn't changed lately, it indicates that OCS expects a RecordProcessed event to be sent from the softphone. Get some old OCS log files and verify what OCS did when & if RecordProcessed was received.

[quote author=Ansh link=topic=8040.msg35358#msg35358 date=1381765100]
The issue is still not resolved but looks like its now for a different reason as from the TServer logs I can see

[color=red][b]11:43:44.328 Trc 04541 RequestDeleteUserData received from 5124 (a4bd )[/b][/color]

message RequestDeleteUserData

AttributeThisDN '25541'

AttributeConnID 00ec023200277e57

AttributeReferenceID 96

11:43:44.328 Int 04543 Interaction message "RequestDeleteUserData" received from 5124 ("")

@11:43:44.3280 Call [00ec023200277e57]: urid 000400ec

@11:43:44.3280 [0] 7.2.008.01 distribute_response: message EventAttachedDataChanged

Looks like some anonymous TServer client is requesting to delete GSW UserData.
[/quote]
Why do you believe that deleting some UserData affects the way OCS processes / doesn't wrap up records?

[quote author=Ansh link=topic=8040.msg35358#msg35358 date=1381765100]
Is there any workaround to resolve this?
[/quote]
Not without a full record trace.

[quote author=Ansh link=topic=8040.msg35358#msg35358 date=1381765100]
Any way to identify this anonymous client? In 7.2 version of T-server the IP address does not get printed in the logs.
[/quote]
You can try to verify after OCS start-up which clients connect to T-Server / OCS and are authorized - it may well be that further details are printed out in the logs.

Fra

[Ansh]

Thanks Cav and Fra and I am so sorry if my post was confusing.

@Cav - Call is actually not stale, agent speaks to customer, properly closed the call as he does for all other calls, but instead of marking it 'answered' in the DB, OCS marks it stale.

@Fra - We had problem where OCS was not receiving RecordProcessed event from softphone, so we changed the option Record_processed to False so that OCS does not expect/Wait for this event and process the record as soon as EventReleased is received. We were not happy to change the value of this option but as we cant investigate from the softphone side as to why this event is not being sent for some calls, we had to change the option value.
OCS was working as expected in both the cases (When RecordProcessed event is received and when it is not received).
But as we did not know why softphone is not sending this event to OCS for random calls, we took the RecordProcessed thingy completely out.

Its not just some Userdata , its the GSW data which is mandatory for OCS to identify the record. Without this OCS could not recognise the record.

Data deletion request is actually being received by TServer, so I am not sure OCS startup logs can help identify TServer clients?

Thanks and regards,
Ansh

[cavagnaro]

So it is your softphone...but has to be something else because if was true when agent sets ready again the record should just close, that is an equivalent of sending RecordProcess command...
Again, check the full log of your agent on TServer, OCS, URS and your software.

The stale is very clear, OCS loses track of the agents end process and does mark it when the related timer expires.