How to configure IVR Driver for HA solutions?

The Primary/Backup Config Server configuration is absolutely transparent for all client applications. When a client connects to Primary Config Server, it requests information if there is a Backup instance configured. If there is, the client (here IVR Driver) gets all necessary attributes, like Host and Port. When the Primary config server fails the client will be trying to reconnect to Primary, then to Backup, until succeeds.

Actually, the same rule could be applied for Primary/Backup pairs of any Genesys servers – (they are transparent for their clients)

The bottom line is that as long as one config server of the pri/back pair is up and running there will be no problem getting the IVR Driver up and connected. If it cannot connect to either one, then there will be a problem. Otherwise it will be fine. Also, once it starts running you can take both config servers down and have no issues…it is just on start-up where it is key to get the config parameters.

Note: Got this info for Genesys support and really helped me to talk to Nortel IVR Engineers..

How to load strategies in Extension?

To load strategies in extension, you need to configure strategy details manually for DN. Let URS_01 is our UR Server, 5001 is our DN and we would like to run our strategy ‘Sample’ on ‘ringing’ event. Here are the details for the same

• Open DN 5001 and go to ‘Annex’ Tab
• Create a section named ‘URS_01′ (same as UR Server name)
• Create options ‘event_arrive’ with value as ‘ringing’
• Create option ’strategy’ with value as ’sample’ (name of the strategy)
• Create option ’strategy0×65′ with value as ’sample’ (name of the strategy)

Simple..isn’t it

What is the best means to report on Voice Mails?

Regarding our conversation on monitoring and tracking your environment for voice mail calls, the most common approach is to place a virtual queue in front of VM target in strategy. When the interaction passes through the virtual queue to the VM DN, the event which takes place is EventDiverted. EventDiverted occurs immediately prior to the Target establishing on an interaction. Placing a VQ on the Target will then will permit you to identify how many calls hit that particular target- be it an Agent Group, Place Group, or Voice Mail DN.

You can track this real time, and create a historical view of same, in CCPulse (6.5+). Simply create a template which tracks on the "Virtual Queue" object under the Switch folder. Your template will likely track on "TotalNumber", say CallsEntered (for the Virtual Queue). Ensure when you create the template that in the "Pre-defined Statistics" dialog, where you move the "Available Statistics" over to the "Requested Statistics" column, once you move "CallsEntered" over, you double click it to expose its definition. There you will see 2 tabs, "Properties" and "Historical Association". As per our conversation, you mentioned you would like this to be both real-time and historical, so in this definition make sure to make an association with a statistic (likely N_ENTERED). Later, this will enable you to apply this template for real-time OR historical use (otherwise, CCPulse won’t allow you to track it HISTORICALLY).

Once the template is created, in the left hand panel of CCPulse, right click the appropriate VQ you want to track and then "Create Real-Time View" or "Create Historical View".

"Create Real-Time View"

This permits you to view the number of calls passing through this particular VQ real-time throughout a business day. This would enable your users to view how many calls were being directed to voicemail at any given point in the day.

"Create Historical View"

This permits you to view the number of calls passing through this particular VQ on a historical basis (Daily/Weekly/Monthly). For example, you can specify you want to track how many interactions went to voicemail for the last 7 days, or the last month (as examples). You can tweak this to your business requirements.

Note: I don’t know the source of this info. It was in my archive and posted here for reference

URS option on_route_error.. what it really does?

Option on_route_error defines what to do when an attempt to route a call resulted in an error, which is thrown by the Tserver to URS. If you are used to logs, you will find the EventError after RequestRouteCall.

Possible choices include:
default – Route the call to default destination
ignore – Ignore the error
delete – Delete the call from URS memory
reroute – Repeat the request
try_other – Find another target

Cheers!!
Gururaj S