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’
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
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.
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.
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
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.
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.
