outbound dialling and calls taken over by the switch

[Luk]

Hi Genesys experts,

I'd like to get some advice on the behaviour we are seeing and how to fix it. It is around outbound dialling and calls taken over by the switch (Alcatel, non IP).
The situation when the behaviour occurs is the following:
[list type=decimal]
[li]an agent is available[/li]
[li]OCS initiates an outbound call[/li]
[li]the agent is not available for some reason[/li]
[li]URS cannot route the call and generates EventError[/li]
[li]after 15s the call is taken over by the switch (and answered by the person at the reception)[/li]
[/list]

We would like such calls being dropped.
I've tried changing the option 'on_route_error' to 'try_other', 'reroute', 'strategy_error' but it didn't impact the behaviour. Calls were still taken over by the switch.
Also increasing the 'transition_time' to for example 40 didn't take effect. Still just 15s untill call was taken over by the switch.
Do I need to do something to activate these options?

I can provide log files tomorrow (back onsite) and even test things on request and provide the log files of those tests.

Hope someone has seen this in the past and was able to fix it.
Thanks,
Luk.

[cavagnaro]

Without OCS, when you dial the RSI does it routes to the agent? If not then there is something missing on your configuration with the OXE

[René]

Luk,

I would review your routing strategy as it should handle situation when no agent is available by e.g. playing kind of "we're sorry" message.

R.

[cavagnaro]

the 15 seconds sounds more to me like RSI overflow rather than waiting for object.

[Luk]

[quote author=cavagnaro link=topic=6975.msg30271#msg30271 date=1330985165]
Without OCS, when you dial the RSI does it routes to the agent? If not then there is something missing on your configuration with the OXE
[/quote]

Yes, we can route calls to agents (if one is available of course), no problem. 
I believe step 3 in my description causes some confusion. What we do is make the agent unavailable on purpose. This way we want to test what happens with an outbound call that was initiated, but at the time it should be routed, there is no agent available to handle the call.

We would like such calls to be dropped, but at the moment they are taken over by the switch and that's not what we want.

[Luk]

[quote author=cavagnaro link=topic=6975.msg30280#msg30280 date=1331033573]
the 15 seconds sounds more to me like RSI overflow rather than waiting for object.
[/quote]

How can we prevent this overflow? In case we cannot prevent it, how can we increase the 15 seconds?

[Luk]

Hello,

I'm trying to attach some log files but get error "The upload folder is full. Please try a smaller file and/or contact an administrator". I tried with 1 file of 726KB !? How can I attach log files?

Luk

[cavagnaro]

Attach was disabled because of hackers, try uploading to some free upload website

[cavagnaro]

[quote author=Luk link=topic=6975.msg30283#msg30283 date=1331040488]
[quote author=cavagnaro link=topic=6975.msg30280#msg30280 date=1331033573]
the 15 seconds sounds more to me like RSI overflow rather than waiting for object.
[/quote]

How can we prevent this overflow? In case we cannot prevent it, how can we increase the 15 seconds?
[/quote]
This only happens when URS/TServer can't monitor/Control the RSI object on the PBX. Increase the time on the OXE and define the overflow address.

[cavagnaro]

[quote author=Luk link=topic=6975.msg30282#msg30282 date=1331040385]
[quote author=cavagnaro link=topic=6975.msg30271#msg30271 date=1330985165]
Without OCS, when you dial the RSI does it routes to the agent? If not then there is something missing on your configuration with the OXE
[/quote]

Yes, we can route calls to agents (if one is available of course), no problem. 
I believe step 3 in my description causes some confusion. What we do is make the agent unavailable on purpose. This way we want to test what happens with an outbound call that was initiated, but at the time it should be routed, there is no agent available to handle the call.

We would like such calls to be dropped, but at the moment they are taken over by the switch and that's not what we want.
[/quote]

For this to happen you can try to add a HangUp call object (the phone with an X) so OXE will cut down the call.
Other option is to send the call to another RP and indicate to URS/OCS that this RP will be considered as a dropped call. Read the OCS Deployment guide and then go to the Overflow DN description/configuration.

[Luk]

[quote author=cavagnaro link=topic=6975.msg30287#msg30287 date=1331044287]
[quote author=Luk link=topic=6975.msg30283#msg30283 date=1331040488]
[quote author=cavagnaro link=topic=6975.msg30280#msg30280 date=1331033573]
the 15 seconds sounds more to me like RSI overflow rather than waiting for object.
[/quote]

How can we prevent this overflow? In case we cannot prevent it, how can we increase the 15 seconds?
[/quote]
This only happens when URS/TServer can't monitor/Control the RSI object on the PBX. Increase the time on the OXE and define the overflow address.
[/quote]

The Voice Transfer Destination has option 'monitor_calls' set to 'true'. Do I need to do more?
I need to speak to a colleague regarding the OXE config.

[Luk]

[quote author=cavagnaro link=topic=6975.msg30288#msg30288 date=1331044771]
[quote author=Luk link=topic=6975.msg30282#msg30282 date=1331040385]
[quote author=cavagnaro link=topic=6975.msg30271#msg30271 date=1330985165]
Without OCS, when you dial the RSI does it routes to the agent? If not then there is something missing on your configuration with the OXE
[/quote]

Yes, we can route calls to agents (if one is available of course), no problem. 
I believe step 3 in my description causes some confusion. What we do is make the agent unavailable on purpose. This way we want to test what happens with an outbound call that was initiated, but at the time it should be routed, there is no agent available to handle the call.

We would like such calls to be dropped, but at the moment they are taken over by the switch and that's not what we want.
[/quote]

For this to happen you can try to add a HangUp call object (the phone with an X) so OXE will cut down the call.
Other option is to send the call to another RP and indicate to URS/OCS that this RP will be considered as a dropped call. Read the OCS Deployment guide and then go to the Overflow DN description/configuration.
[/quote]

Hi cavagnaro,

I updated the routing strategy to timeout after 5seconds in the Selection block. I can see it exiting the red port (IRD trace view and print statements in log file) and going through the Cancel call block. However, the actual call is still answered by the person at the reception. (so routed by the switch)

[cavagnaro]

Hum...strange...on my OXE it does cut the calls...
Can you post your TServer config options here?

[Luk]

[quote author=cavagnaro link=topic=6975.msg30292#msg30292 date=1331054970]
Hum...strange...on my OXE it does cut the calls...
Can you post your TServer config options here?
[/quote]
Fixed... by adding a print function after the CancelCall block!!
I wanted to debug the behaviour above so added a print message behind the green port saying 'green port' and similar for the red port. Retesting resulted in calls being dropped after 5seconds timeout. The log file did not contain one of the print statements I added after the CancelCall block. Also, the Trace View of routing strategy shows calls 'disappearing' at the CancelCall block.

Surprised, but happy!

[cavagnaro]

[quote author=Luk link=topic=6975.msg30293#msg30293 date=1331059739]
[quote author=cavagnaro link=topic=6975.msg30292#msg30292 date=1331054970]
Hum...strange...on my OXE it does cut the calls...
Can you post your TServer config options here?
[/quote]
Fixed... by adding a print function after the CancelCall block!!
I wanted to debug the behaviour above so added a print message behind the green port saying 'green port' and similar for the red port. Retesting resulted in calls being dropped after 5seconds timeout. The log file did not contain one of the print statements I added after the CancelCall block. Also, the Trace View of routing strategy shows calls 'disappearing' at the CancelCall block.

Surprised, but happy!
[/quote]

Instead of print try the End (red arrow) block...maybe that is why