Routing to a DN

Hello,

I need to improve a service that allows agents to redirect their calls when they are busy with other work or absent from their place. YES, I know, that’s what routing is made for, but I have a lot of users who claim that they need to receive direct calls as part of a special customer experience. So, routing is not an option. Sorry.

Currently, we use a dial plan to redirect all non-routed calls to a special routing point. In the strategy, we query a SQL table to check if redirection for the failed-number (or original-dialplan-digits) is enabled, and what the redirection target is. The client application for our agents controls the entries in that table. Redirection targets can be internal phone numbers (agent or backoffice), external numbers (i.e. mobile) or routing point aliases.

This works - in a way. Routing point aliases are routed with RouteCall, so I can keep attached data even if I need to change the current switch (we use 5). But all other numbers are configured as plain numbers, that’s something I cannot change for now, and I can only route them with TRoute.

Now, I want to improve the situation by detecting if the redirection target is an agent phone number. When I know this, I can use RouteCall instead of TRoute and keep the attached data for the call. Big Problem is: I need to know the location to use RouteCall.

One solution is to use the FindConfigObject function in the routing strategy and query for all five switches. But I think that’s ugly, and probably slow.

Can I query, somehow, what the location for a specific DN is? And can I query if an agent is logged in there?

We use Genesys 8 with Siemens HiPath 8000 Switches.

Thanks for your ideas
Rolf

DN number is not unique property of DN - switch is required. Very unlikely something out of box can be found to get DN based on its number only. Either switch part should be stored in SQL table together with number (or somewhere else), or all these agent DN to be equipped with aliases too or some run time discovery to be done (FindConfigObject). In last case once found the result can be stored/cashed in GLOBAL list inside URS and discovery need to be done only the very first time when some DN is used.

Once number and switch are known then to get login status - plain SData can be used - open “isloggedin” statistic for object “[email removed]”. Or FindConfigObject can be used to get place based on DN and after that use function TargetStateEx[place, 1] for that place to get status of place DNs.

Thank you for your advice, Terry. I was on vacation, then sick and then QUITE busy, so I am coming back only now.

Creating aliases for all DNs is not easily done, so I will have to resort to run time discovery. Caching it in a global list would create quite a big list (about 4000 agents), I think I want to check the impact of this first.

I will checkout the values that I get by TargetState. But did you misspell “TargetStateEx”? Neither I or docs.genesys.com can find it…

What I am missing now is a method to get the not-ready REASON for an agent. I could create a statistic with a filter for a specific notready reason, but how can I get the reason itself without checking them one-by-one with a statistic (and please don’t tell me now I could use interval bisection ;))

Rolf

Basically I meant TargetStateEx[target, 1]. (TargetState[target] if used turns into TargetStateEx[target, 0]).
Second parameter if 1 will result provided extended data about target (is agent logged on one or another DN or not, etc, in up to date URS it might include even reasons of state).

Using multiple statistics for reasons (if reasons are needed for analyzing situation) up to my understanding is no so bad ( if anyway you will need to compare reason with specific values and decide what to do based on that).

Ok thanks, so then I will use my statistics.

TargetStateEx still hides from me, and my IRD 8.1.300.22 refuses it as an unknown function - which IRD Version do I need to use it? Or is it an ECMAScript Function in Composer? (the migration to Orchestration Server / Composer is planned here, but will not happen for some months). But it’s not a problem, currently, I can live with TargetState.

And because I’ve just got the attention of an expert… do you have any idea why this function sequence ignores my timeout setting? In the SIP Server manual, they write that after-routing-timeout is overridable with this Extension. divert-on-ringing should be false for this timeout to work, so I added it after my first tries went wrong (but the option is set to false in SIP Server application anyway…). The log shows me that the call is not diverted before ringing, so this setting is ok.

ExtensionUpdate['divert-on-ringing', 'false']
ExtensionUpdate['after-routing-timeout',7]
TRoute[var_directTarget,var_directLocation,RouteTypeUnknown,'']

But it doesn’t work, my TRoute receives the timeout after 20s, which is the SIP Server application setting. I also tried RouteTypeDefault, with no effect. Any idea what I am missing?

Admittedly, nas-private is false on SIP Server application level, but I set it to true for my agent login and for my DN. Even for the Routingpoint where the strategy runs (ok, that was silly). But nas-private shouldn’t matter, because the strategy runs on a routing point and on entry, I see the Extension BusinessCall=1. And when I answer and release the call, the agent is set to after-call-work, which should be proof that the call is considered as business call.

Obviously, I am missing something. But what?
SIP Server is Version 8.1.102.55, Switch is Open Scape Voice from Siemens (or Unify) - but that’s a SIP Server extension, so the switch shouldn’t matter.

Ah yes, one addition: I could use divert-on-ringing=true and set the NO-ANSWER- Extensions, which works. For a given value of “works”. Because I can get the SIP Server to do nothing (that is: the call stays where it’s been routed), release the call (kicking the caller out) or to requeue it to my routingpoint (causing my strategy to start over). Starting over means that I need to detect this, and cache some computation values in attached data. This is a complication that I’d like to avoid. And I don’t know what InfoMart makes of those requeuings.

Thanks for any insights.

Rolf

Found it via Knowledge Search ;D.

after-routing-timeout needs to be set as a value of type ‘digits’, so the key in ExtensionUpdate must be prefixed with {d}.

This works (divert-on-ringing = false is still necessary, but is SIP Server application default at my location).

ExtensionUpdate['{d}after-routing-timeout', 7]
TRoute[var_directTarget,var_directLocation,RouteTypeUnknown,'']

Geetings
Rolf

I am reviving this thread because there is a problem in my solution and after 2 years, the customer thinks it must be removed.

When an agent is talking, and an external caller tries to call his number, I set SIP status code 486 and terminate the call, as posted 2 years ago. The caller hears a busy signal. Fine.

When I call the number from an internal phone, with the phone (First party call control), I also hear busy. Fine.

But when I do this with 3rd party call control (our agent software), the call is just terminated. This is not done by the agent software, I checked the logs, there is no Request, only Events. I see my RequestRouteCall with RouteTypeReject, then EventDiverted and EventCallPartyDeleted from the routing point that controls the redirection logic. And then, the caller party is dropped, too.

When I compare the manually dialled call, and the 3pcc call, this behaviour is consistent. In both cases, both parties are dropped. But with 1pcc, I hear the busy signal, with 3pcc, I don’t.

How can I solve this? Generally, I don’t want to play a busy signal via MCP, because this would establish a connection and the caller has to pay for a busy signal. I already tried a Delay[5000] after TRoute-ing, but that had no effect. The call is dropped on TRoute. Is there any other way to signal Busy?

Rolf