Nortel Phone-Genesys skill routing issue

Hi,

Currently In Queue based scenario, call are sent to an ACD queue at each site. Agents are logged into a queue and receive the call. Before the call being presented to Agents, they receive a beep (which is an indication that there is a client call) and the call gets Auto-Answered.

Now in Agent based (Skills) routing, the call is being presented to an extension, where the Auto-Answer is lost and the beep is heard on the phone but not on the head-set (on Nortel Phones). We tried various options, but were out-of luck.

Thanks,
linalf

You probably have ‘extension’ as the ‘use_dn_type’ in your URS. This is normal in a skills based scenario.

The reason you don’t have auto-answer is that this is controlled at the ACD queue level on the pbx. With Genesys the calls are being routed to an agent DN based on skill assignment and pbx queue logic will not be involved. If you use an Agent Desktop application you can configure this to auto-answer the calls.

Also seen this at another site, they had to use an additional piece of hardware connected between the headset and PC soundcard to produce the beep…

If you have a small call center (less than 100 agents), this might be an option (Disclaimer: I have not tried this myself, as our call center was too big; also, I am not that masochistic)

In one of the Genesys docs (I forget which one, but I think it was TServer for Nortel or URS), it refers to creating an ACD queue for each agent, then routing the call to the ACD queue once that agent is available. I believe the example was more related for Statistics gathering, but…

• If you wait until the agent is available to drop the call into the ACD, you should be able to control who gets the call
• Since you’re dropping the call into the ACD, the ACD will route the call, and you should still receive the beep.

Regarding the Auto-Answer, we route to the extension, but we had to code the agent desktop application to look for a specific KV Pair, that indicated it was a queue call. If that pair exists, the desktop application will auto-answer the call on the extension. If the KVP does not exist, the agent has the opportunity to manually answer the call.

If you are using the M3905 phones, you can configure the phone to ring in the headset.

On the physical phone - not in the PBX
Select Options
Select Headset port external alerter
set to on for alert or set to off for no alert.

For the auto answer option, we built our own softphone that auto answers on the Ringing event.

You could write a strategy that answers the call and load this on every DN. On the Annex tab of the DN you will need to add the following:

Section:
Option event_arrive=
Option strategy0x65=

Example:
Section: URS
Option event_arrive=ringing
Option strategy0x65=dnForceAnswer

There are a few drawbacks to this approach.

1. URS is controlling all of the DNs - may need more memory and CPU
2. The call will be automatically answered even if the phone is logged out.
3. Every time you add a new DN, you will need to add the strategy to the Annex tab of the DN.

Are we talking about Nortel Meridian/CS1k or DMS100/CS2k here?

If it’s the latter, why don’t you set the ‘use_dn_type’ in your URS to ‘position’. Then Genesys will route the call to this DN and you will get the ACD beep.
You will need to ensure that both the extn and the postion are configured in the place. It would also be a good idea to configure “Not Ready on Secondary DN” in the switch, so that if an agent makes or recieves a call on the extension, Genesys doesn’t attempt to route to the position.

I’m not sure if Meridian works in the same way.

Steve

I run a meridian and we have that option set to extension.

I can run a test for you on Monday if you like, and see what happens when I route a call to a skill. We usually don’t run SBR on this switch though. We only have about 100 seats left on it as it is being gradually replaced by an Alcatel system instead.

Many moons ago we ran a multi-channel skills based setup on this switch and I don’t remember there being any issues like this.

I’ve been where you are and felt your pain, with Nortel Meridian. One thing, don’t bother setting the use-dn-type to position in the URS options. This is not allowed on a Nortel. The only piece of hardware or software that can put a call on the Nortel ACD Position is the Nortel ACD via an ACD queue. So that won’t work. You are stuck with using the extension, I’m afraid. But there is a way to get the extension DN to auto answer, and it’s not as masochisitc as creating an ACD DN for every single agent (you’ll run out of ACDs pretty quickly on the Nortel if you tried that).

No there is a much simpler way, it just takes a bit of monkey work to put it in place. You create a simple strategy, call it “auto-answer” or something like that. The strategy contains only one function: “AnswerCall”. Then, on the Annex tab of the Extension DNs in CME, you create a section with the name of your URS application in CME. Inside the section, you create two options, so your Annex tab looks something like this:

[URS]
strategy = “auto-answer”
event_arrive = “EventRinging”

If you create a config file just like this, you can import the config file onto the Annex tab of the Extension DNs. This is analogous to loading a strategy on a Route Point, except you can’t load strategies on Extensions through IRD. You have to do it through the Annex tab of the DN in CME.

So now whenever TServer receives an EventRinging for one of these Extension DNs, it knows that URS is monitoring that DN, and URS knows to run the auto-answer strategy, which in turn tells TServer to answer this call. Voila!

I’ve used this in production in a 700+ seat call center. The hardest part is just the time it takes to load the options on each DN. But trust me - this works!

Sorry, minor correction to the DN Annex options. The value for event_arrive should be “ringing”, not “EventRinging”. Like so:

[URS]
strategy = “auto-answer”
event_arrive = “ringing”