OCS 71 not updating agent_id

[bogdan]

Hello,

Can someone explain why OCS doesn't update the agent_id in the database after the call completes?
I've attached the ocs log file, you can check out the call with GSW_RECORD_HANDLE      '246'

[code]52147 CallRecord Info - RecID: 246, Type: 1, AgentDBID: 1818, DN: NULL, Campaign: Campaign Auto, Group: Collection_Auto, CallList: C      ollection_Auto, ChainID: 1, ChainN: 0
52148 CampaignDBID:112 GroupDBID:847 DialLog() Handle:246 ActionCode:8
52149 CampaignDBID:112 GroupDBID:847 DialLog() Handle:246 ActionCode:11
52150 UpdateRecord Handle:246 ChainID:1 ChainNum:0
52151 19:11:16.013> CM_DBCallRecord(107-112-847): DBServer 'ocs_dbserver_p' SQL:  update collection_auto set call_result=33,call_tim      e=1259082632,record_type=2,record_status=3,attempt=1  where chain_id=1 and chain_n=0 [ReqID=286]
52152 CM_DBCampaign:112 ProcessChain ChainID=1 GroupDBID:847 Records:0 Chains:0 OnTimer:0 AtWork:0[/code]

As you can see all the other fields are updating, but not agent_id, can you please guide me.

Regards,
Bogdan

[bogdan]

I've also found this:
[code]41438        CallRecords:    RecID: 246, Type: 1, Campaign: Campaign Auto, CallList: Collection_Auto, ChainID: 1, ChainN: 0
41439 CampaignDBID:112 GroupDBID:847 DialLog() Handle:246 ActionCode:7
41440 received from 65200(buc_tserver_p_760)blum.crm.orange.intra:3200(fd=11) message EventPartyChanged
41441        AttributePreviousConnID 015201becd2814e5
41442        AttributeCallState      1
41443        AttributeCallType      3
41444        AttributeCallID 18090828
41445        AttributeConnID 015201becd2814c1
41446        attr_#141      '00K08LHHPGDF746ILG832CTAES0DD0QA'
41447        AttributeThisDN '4112'
41448        AttributeThisDNRole    2
41449        AttributeThisTrunk      20630
41450        AttributeOtherTrunk    24536
41451        AttributeOtherDNRole    2
41453        AttributeThirdPartyDN  '891007'
41454        AttributeThirdPartyDNRole      7
41455        AttributeTimeinSecs    1259082661 (19:11:01)
41456        AttributeTimeinuSecs    283758
41457        attr_#148      00000000093edde4
41458 19:11:01.289 Trc 50002 TEvent: EventPartyChanged
41459 19:11:01.289 Std 50007 Cannot find CMDN for DN = 891007
41460 Deleting AgentCall. ConnID: 015201becd2814e5, Type: 4, RecID: 246, DN: 4112
41461 Agent Info - Status: AGENT_BUSY_OUTBOUND, Background Status: AGENT_READY, BusyType: 3, BusyType Duration: 0, PersonDBID: 1818
41462        Place - Place_4112_buc, PlaceDBID: 1207
41463        Position DNs:  Number: 894109, SwitchDBID: 101, State: OnHook, Service: In
41464        Extension DNs:  Number: 4112, SwitchDBID: 101, State: OffHook, Service: In
41465        Logins:        AgentID: 8047, Queue: NULL, DN: 894109, SwitchDBID: 101
41466        Groups:        Collection_Outbound, GroupDBID: 580
41467        Collection_Auto, GroupDBID: 847
41468        Collection_Manual, GroupDBID: 828
41469        Calls:  ConnID: 015201becd2814c1, Type: 3, RecID: 0
41470        CallRecords:    RecID: 246, Type: 1, Campaign: Campaign Auto, CallList: Collection_Auto, ChainID: 1, ChainN: 0
41471 Setting BusyType 2 to Agent (DBID: 1818)[/code]

What does this mean:
41459 19:11:01.289 Std 50007 Cannot find CMDN for DN = 891007
Is this related to my problem?

Bogdan

[Fra]

Strange, I've looked through your log, but can't really find a major issue...
what I don't like is:

19:11:01.290 Trc 50002 TEvent: EventAttachedDataChanged
EventAttachedDataChanged is ignored. Reason: agent is not in BusySeized or BusyRinging status

but that should not have any impact on the agent_id update; in fact, OCS seems to be aware of who the agent is:

Agent Info - Status: AGENT_BUSY_OUTBOUND, Background Status: AGENT_READY, BusyType: 2, BusyType Duration: 0, PersonDBID: 1818
Place - Place_4112_buc, PlaceDBID: 1207
Position DNs: Number: 894109, SwitchDBID: 101, State: OnHook, Service: In
Extension DNs: Number: 4112, SwitchDBID: 101, State: OffHook, Service: In
Logins: AgentID: 8047, Queue: NULL, DN: 894109, SwitchDBID: 101
Groups: Collection_Outbound, GroupDBID: 580
Collection_Auto, GroupDBID: 847
Collection_Manual, GroupDBID: 828
Calls: ConnID: 015201becd2814c1, Type: 3, RecID: 0
CallRecords: RecID: 246, Type: 1, Campaign: Campaign Auto, CallList: Collection_Auto, ChainID: 1, ChainN: 0

A couple of notes:
- which switch are you using? I see that a position and an extension are defined for that agent;
- could you verify that the position adn the extension are correctly monitored by OCS?
- does this happen to every call?

Fra

[bogdan]

Hello,
- switch: Nortel Meridian 1000 SCCS/MLS
- I can't seen any errors on agents configuration or DNs (all seems monitored ok)
- yes, everytime but only in progressive mode, in preview all is ok

When I've launched this project, and during development and testing the agentid was populated correctly, but now is not updating, and I don't know why... I think I've misconfigured something

this is the configuration of the ocs:
[OCServer]
stale_clean_timeout=30
internal_answer_action=soft_answer
predictive_callback=true
outbound_release_action=soft_previous
outbound_answer_action=soft_answer
login_ignore_queue=true
login_action=soft_not_ready
internal_release_action=soft_previous
stale_clean_interval=15
inbound_release_action=soft_call_work
agent_preview_mode_start=true
call_answer_type_recognition=positive_am_detection
record_processed=false
management-port=5201
call_timeguard_timout=0
call_transfer_type=two_step
call_wait_agent_connected_timeout=6
call_wait_connected_timeout=30
call_wait_in_queue_timeout=30
call_wait_original_establish_timeout=4
desktop_version=6
engaged_release_action=soft_previous
inbound_answer_action=soft_answer
ocs_group=true
record_save_intermediate_results=true
min_record_buf_size=0
opt_record_buf_size=0
check_dnc_call=false
ivr_group=true
ivr_update_on_release=true
dialing_rate_limit=2
log_call_stats=false
dial_log_delimiter=,
dial_log_destination=/gcti/logs/ocs/
remote_release_action=abandoned
force_unload_timeout=20

Best Regards,
Bogdan

[Fra]

The other thing I noticed is that the call was transferred by another agent; what happens if the call is processed by the agent who first received it?

Fra

[bogdan]

no, it's only one agent implicated - the log that i've attached is a test call made by me

[bogdan]

Hello guys,

I've solved my problem, when the call was released i found out that an "invalid connection id[56]" was generated, and I've changed call_transfer_type from two_step to one_step, and now the agentid is populated.

[code] 33491 CallRecord Info - RecID: 6816, Type: 1, AgentDBID: 1818, DN: 4112, Campaign: Campaign Auto, Group: Collection_Auto, CallList:        Collection_Auto, ChainID: 1, ChainN: 0
33492 CampaignDBID:112 GroupDBID:847 DialLog() Handle:6816 ActionCode:8
33493 CampaignDBID:112 GroupDBID:847 DialLog() Handle:6816 ActionCode:11
33494 UpdateRecord Handle:6816 ChainID:1 ChainNum:0
33495 13:34:07.198> CM_DBCallRecord(107-112-847): DBServer 'ocs_dbserver_p' SQL:  update collection_auto set call_result=33,agent_i      d='8047',call_time=1259148808,record_type=2,record_status=3,attempt=1  where chain_id=1 and chain_n=0 [ReqID=47589][/code]

I don't know why this happens, but I will raise a ticket to genesys - to give me an answer

Best Regards,
Bogdan

[Fra]

sorry, I assumed it was another agent transferring, whereas it was obvious that CPD was transferring the call. 
So yes, my point was related exactly to the transfer, the 2-steps probably confuses somehow OCS..
I'd be curious to know what happens if you set the URS route_consult_call to false and use the 2-steps transfer.

F

[bogdan]

setting route_consult_call to false might have a big inpact on agents, and I'm scarred to modify this parameter. I'm not feeling lucky today
Thanks Fra for your support

Regards

[Fra]

lol 
of course, I didn't mean to disrupt your call centre, just wondering what it'd happen  - maybe you can test it in dev 

[El gato]

La PBX Nortel, no soporta transferencia en 2 pasos, ese es el problema.


Saludos

[Fra]

[quote author=El gato link=topic=4938.msg22015#msg22015 date=1259243909]
La PBX Nortel, no soporta transferencia en 2 pasos, ese es el problema
[/quote]

That's quite interesting. So was that a phantom call?

F

[Dionysis]

Interesting, the Nortel PABX I used to work with only supported 2 step transfers, we were unable to do 2 step.

One thing to be careful of, check your dropped call results if switching from 2 to 1 step transfer.  It's quite likely that you wont be correctly marking dropped / abandoned calls.

[bogdan]

I'm 99.9% sure that i do not have dropped calls

[Dionysis]

Are you running in preview mode, or queueing outbound calls for a long time?

If you are, then you can be sure you don't have dropped calls.  On the other hand, running predictive or progressive modes, you can be sure that you do. 

The only way to test this is to run a test campaign with only 1 agent, use your own number in the dialling list, wait until your phone starts to ring, then make your agent Not Ready.  The call result should be dropped, if it isn't, you have a problem.



I've been caught by this before, in a very short space of time you will start receiving complaints... and contact centre managers don't like that much. :p