Routing strategy to target remote agents but local agent extn is logged out

[vlam]

                I have been working through a specific scenario recently that I need to get a definitive solution to. Your views would be welcomed:
1. Caller reaches an agent group and is answered by agent A
2. Caller advises they previously talked to agent  B
3. Agent B logged in remotely
4. Agent A advises they will transfer the caller to agent B
5. Agent A uses the address book or directly dials agent B’s internal extension to transfer the caller
6. Agent B is logged out of the internal extension and logged in remotely
7. Somehow we need to identify which of the remote agent T-Servers agent B is logged into, make sure they are ready and deliver the call to this DN

Current view I have:
• When any CUCM extension is logged out all calls to this extension are directed to a route point on CUCM
• Strategy on CUCM RP uses DNIS to look up the agent name and targets the agent

The above has one sticking point which is causing some contention within the team. We have a strategy we have developed that uses a list object to map CUCM extension to agent ID. DNIS is used as a index into the list object to identify the agent to target. The area of contention is that management of a list object of this size is painful. Primarily due to its length (N Agents = N entries in the list object)

I have considered other methods such as targeting either remote agent DN (as we know what it will be based on the DNIS) for example

Extension: 123456
Remote Agent DN 1: 2222123456
Remote Agent DN 2: 2222123457

However if we target a DN we cannot guarantee the agent is logged in and ready. Hence there is the possibility a PSTN line will be called that may be the agents home phone or mobile and they may not even be working at the time.

[René]

Hi vlam,

Sorry but I don't understand description of your issue. You wrote that 'agent B logged in remotely' - what does it mean? Is the agent logged in Genesys? Or in CUCM only? What device do they use to receive calls?

R.

[ldevanny]

Hi Rene,
There are 6 switches in the environment. 4 of which are Genesys SIP Servers. A pair of SIP switches share the same number range and reside in diferent data centres. These are used for queuing and routing only. No agents are connected to these. The other two are used for Remote agent functionality and one exists in each data centre. It is here we are using Genesys SIP server remote agent features. Remote agents are reachable via routing the call to a DN on one of these switches causes an outdial via a group of MGWs to the PSTN. (Configured as Trunks on the SIP Server)
The two queuing SIP servers have trunks to both remote agent SIP servers and 2 CUCM clusters. A Genesys softphone, when invoked in a specific way, will choose to login and go ready on one of the two remote agent extensions (as outlined in Vinhs post) based on 3 DNs residing in a single place. The remote agent DNs are prefixed by route codes ie

205361 - Internal Extension (CUCM)
17919000205361 - Remote Agent Extension 1
17919001205361 - Remote Agent Extension 2

The prefix is used on trunks to the remote agent SIP servers to ensure call delivery while making the DN similar enough to be recognisable.

Two remote agent SIP servers are needed as we need to cater for a data centre failure. The softphone literaly randomly chooses one of the remote agnt SIP servers when the agent invokes it, they are asked for a PSTN number what is dialed when the SIP server DN is targeted.

I have found a way to resolve the problem as follows:
Instead of attempting to look up the agent or place do the following in a route strategy:
On remote agent DNs in the Annex tab, TServer section set: reject-call-notready=true
In a routing strategy use TRoute to target 17919000+DNIS then from the red exit on this TRoute to 17919001+DNIS
If the agent is not logged in and ready the first TRoute will fail, otherwise SIP server will outdial to the MGW and connect the agent on the PSTN. If not it will attempt to TRoute to the second remote agent SIP server. If this also fails clearly the agent is not logged into Genesys and hence should not recieve a call. At this point I can send the call to voice mail etc.

[René]

Hi,

Thanks for the details. I do understand it more now. I was thinking about it for a while and your solution looks okay for me even it is not the prettiest one.

However, I have one idea - if agent application (softphone) used by remote agent can register DN on CUCM (205361) and set call forwarding to DN on SIP Server (17919000205361) the remote agent is logged to then you don't need to bother with searching for the "right" DN. However, I'm not sure if CUCM allows you to set call forwarding on non-logged phone.

If something else comes to my mind later I let you know

R.

[smile]

if i'm right understand your task, you are trying to route call on agent by their ID, isn't?
if you will use 3pcc for call initiation,i.e. t-lib function then you can dial just agent id like regular DN number. of course in your environment DNs and IDs must be in different sets. T-server automatically understand (afaik this is the default behaviour for most tservers) that there is no DN with this number and tries to search agent with same ID.