Avoid a dial plan when routing a call directly

[rolf_b]

Hello,

I think this is a quite exotic problem, but maybe someone can help me.

We still use Genesys Engage on premise, and some departments who want to use Genesys always want to use direct phone calls ("our customers expect a dedicated contact!"). Of course, such a dedicated contact can be on vacation or otherwise unavailable. Before Genesys, they just redirected their telephone to a collegue.

With Genesys, they refused to give up the direct contact strategy, so we had to come up with a solution. I built a deputy system that uses a fat dial plan to route all incoming direct calls to a "check-for-deputy" routing point. There, I check the target state of the DN and if that agent isn't available (offline or not ready with certain not-ready reasons), I don't route the call to them, but to a configured list of deputies. This list can be empty, or all deputies might be unavailable, then I route the call to a regular service routing point.

Next thing is: We use multiple locations with several SIP servers. Some departments are decentralized and it is possible to enter a deputy who is located at another location.

To route a call to an agent, I use TRoute with RouteTypeUnknown (hat no better idea). When I route the call to an agent that is on the same location, TRoute waits while the call is ringing. Sometimes, nobody takes the call, I catch that with a NO_ANSWER_TIMEOUT value in the extensions and try the next deputy.

But when the deputy is on another location, the call isn't routed to the DN, but to the check-for-deputy routing point. This happens only when I use TRoute in my deputy strategy, it doesn't happen when I use the "RouteCall" object (the target mark) in regular service call routing.

So, it's possible. It's possible to route a call and circumvent the dial plan. But how? I cannot use the route call object, because that requires that the target agent is in "READY" state. I need to route direct calls also in "after call work" state or in some "not ready" states, like "doing paperwork". Yes, I know, it's weird. But we don't use interaction server, only telephony routing.

Maybe there's a solution where we redesign our call center completely. This WILL happen when we migrate to a cloud solution, but definitely not now. I just need an idea how to route a call from location A to location B, based on DN, Place or AgentId, to an agent that might be in not-ready state, and avoid the configured dial plan while doing that.

Is it possible at all? Maybe I just don't know the correct TRoute target syntax for using a place or agent ID. Or can I fabricate a parameter string for RouteCall that doesn't use Statistics and Priorities and also routes to not-ready agents? I am not desperate enough (yet) to start wild experiments on that ;-)

I checked the switch configuration, there is a "target type ISCC" access code definition between them.

Rolf

[Kubig]

I suppose you have to define the target location switch name within the TRoute function to proper find and access remote switch via ISCC

[rolf_b]

I think I do that. Lets say the number 1234 on Switch AAA is called and I want to transfer the call to number 6543 on Switch BBB.
Then I call [tt]TRoute['6543', 'BBBB', RouteTypeDefault, ''][/tt].
Interaction Data is correctly transferred. And in the log, I find ISCC transfer messages.

On the SIP Server for Switch BBBB, I find the call coming in on an external routing point. But then, dial plan processing for number 6543 happens, an entry is found and the redirection in the dial plan is used.

When I use a regular service line to route a call to 6543, then there is also dial plan processing, but it doesn't search for 6543, but for the ANI (the number I used to create the call). Since this is no contact center number, the search naturally fails. But as I wrote, I can't use the target block for routing, because it expects an agent to be in ready state and wants to assign a VQ.

So I think I need to change how to send the call on the AAAA switch to solve that. But how?

Rolf