ACD translations for Internet sessions 

---

The Avaya Multimedia Applications Customer Support (MACS) group inputs standard DEFINITY ECS ACD translations as part of the CentreVu Internet Solutions installation.

Important!

When adding your own VDNs, ensure that they do not exceed seven digits.

Real-time ACD translations

The DEFINITY ECS ACD standard translations for Internet sessions are as follows:

• Three standard, measured VDNs. See theDEFINITY Enterprise Communications Server Release 6 Call Vectoring/Expert Agent Selection (EAS) Issue 2 Guide (555-230-521) for a complete description. The first VDN is for Internet text chat, the second is for Internet voice (if your contact center uses this access type), and the third is for callback. A MACS engineer obtains necessary extensions from you.

• Two standard vectors. The first vector is for Internet voice (if your contact center uses this access type). This vector queues the session to the Internet skill and optionally plays a delay announcement. The second is for Internet text chat and callback requests. This is a single-step vector that contains a queue to the main skill command. Both vectors queue an Internet-initiated session to a certain skill. A MACS engineer obtains these vector numbers from you.

You are responsible for translating Internet skills, Expert Agent IDs, and agent telephones. Avaya personnel can provide this design work, as well as enhanced vector designs, as part of the Call Center Application Integration Avaya Professional Services offer. Call your account executive or Avaya Professional Services for details.

Translating VDNs and vectors

Some general guidelines to consider when translating VDNs and vectors for real-time communications include the following:

�Wait with Music� vector step

Do not use the �wait with music� vector step. It would add unnecessary processor usage to the customer's PC and traffic to the Internet circuit.

�Converse� vector step

Do not use the �converse� vector step. It is incompatible with CentreVu Internet Solutions functionality.

Digit collection

Do not use digit collection in Internet session vectors. There is currently no method to pass Dual Tone Multi Frequency (DTMF) tones (touchtones) across the Internet; therefore, there are no digits to collect.

VDN of Origin Announcements (VOAs)

VDN of Origin Announcements (VOAs) are strongly recommended. When an agent receives a text chat Internet session, there is no audio. With VOA, the agent hears an identifying message (such as �voice call� or �text chat call�) and knows whether to answer audibly or through text chat. Without VOA, the only way the agent has to identify the incoming session's media type is to note the VDN name on the terminal display. Agents' class of service must be set to receive VOAs.

Vectors for text chat and callback calls

To provide the best experience to the customer, write vectors to answer each Internet voice session with an announcement that does not exceed 5 seconds. (This is a �null� announcement since it is not heard by anyone.) Such a setup serves to establish an audio connection so that any follow-up announcements should be heard in full and, more importantly, as soon as the agent answers the session, the agent can begin speaking with the customer.

The vector could look like the following:

1. announcement 2000 (a normal delay announcement that is less than 5 seconds in length)

2. queue to main skill 10 priority m

3. wait time 10 seconds hearing silence

4. announcement 2000

5. goto step 3 if unconditional

Note that the announcement in steps 1 and 4 can be the same if it is less than 5 seconds in length.

When the customer requests an Internet voice session, the audio connection is not set up until answer supervision is returned from the DEFINITY ECS. As a result, the following may occur:

• There is a lag of approximately five seconds (on a dial-up connection) between the time the agent answers the session and the time when the agent can be heard by the customer.

• If a time-in-queue announcement is used, the customer does not hear the first 5 seconds of the announcement.

If your contact center uses an ITG for Internet voice, then the DEFINITY ECS connects to the ITG by way of an ISDN-PRI trunk group. The ISDN-PRI trunk group connecting the DEFINITY ECS and the ITG is translated as an isdn-pri trunk type, with a service type of tie and a direction of incoming. See the DEFINITY Communications System Implementation (555-230-655) document for details.

An IP600 can also connect to the DEFINITY ECS by way of an ISDN-PRI trunk group.

ISDN-PRI security

You must address ISDN-PRI trunk group security. Because the extension number used to launch an Internet session is actually submitted by a browser, there is the risk that a hacker may attempt to submit a false dial string in order to compromise your contact center's security. Therefore, the ISDN-PRI trunks must be restricted from placing outbound calls. Unless so restricted, the vdn_ext parameter submitted by a customer's browser could be changed to dial a long distance number through the DEFINITY ECS. Additionally, to limit other malicious activities, the ISDN-PRI trunks should be restricted from destinations in the DEFINITY ECS that are not intended for Internet sessions (such as individual agent stations, non-Internet VDNs, and so on).

Methods to secure the ISDN-PRI trunk group

There are two mutually supporting methods to secure an ISDN-PRI trunk group:

• within the gateway, denying fraudulent sessions before they are placed to the DEFINITY ECS.

• within the DEFINITY ECS, denying sessions to locations other than those specified as valid endpoints.

How to secure the ISDN-PRI trunk group

The DEFINITY ECS is secured using Classes of Restriction (CORs) to restrict destinations from the gateway trunk group. The COR for this trunk group specifies, among other things, what connections the trunk group is able to complete. In this way, you can restrict the ISDN-PRI trunk group from making any outbound (off the DEFINITY ECS) connections and you can restrict the ISDN-PRI trunk group to connect only to a resource with a COR that is used uniquely for Internet destinations.

Example

As an example, the ISDN-PRI trunk group to the gateway could be assigned a COR of 49, which is outward restricted, and limited to only connecting to COR 48 (assuming both 48 and 49 are previously unused CORs). COR 48 is then used for any VDN extension expected to receive Internet traffic. If a session comes across the ISDN-PRI trunk group destined for any other extension, that session is denied by the DEFINITY ECS (assuming that the destination extension is assigned a COR other than 48). The permissions assigned to COR 48 should reflect the security that the contact center would normally assign to VDNs.

Naturally, as Internet sessions are blended with telephone calls, the CORs discussed above may need to be modified to reflect all the requirements of the contact center. When establishing CORs, you should thoroughly review Class of Restriction instructions and guidelines found in theDEFINITY Communications System Generic 3 Feature Description document (555-230-204), theDEFINITY Communications System Implementation manual (555-230-655), and theBCS Product Security Handbook (555-025-600).

Service Observing allows a specified user, such as a supervisor, to observe agent and customer transactions (such as text chat, escorted browsing, and Internet voice).

DEFINITY ECS Administration

You must administer your DEFINITY ECS to allow the use of the Service Observing feature. The following forms must be administered on the DEFINITY ECS:

• System-Parameters Customer-Options�set both the Service Observing (Basic) field and the Service Observing (Remote/By FAC) field to Yes.

• Class of Restriction (COR)�if you want to allow the extension to be observed, enter y in the Can be Serviced Observed field. If you want to allow the extension to be a service observer, enter y in the Can be Service Observer field.

• Feature-Related System Parameters�if you want warning tones to be given to the agent and customer whenever their session is being monitored, then set the Service Observing Warning Tones field to y.

• Feature Access Codes�enter the code that must be dialed to allow a station with Service Observing permission (COR) to observe agent and customer transactions without being heard, or enter the code that must be dialed to allow a station with Service Observing permission (COR) to observe and be heard during agent and customer transactions.

How to use Service Observing

Important!

The DEFINITY ECS must be administered to support Service Observing before you can use the Service Observing feature of CentreVu Internet Solutions.

To observe an agent and customer transaction, do the following:

1. Log in to CentreVu Internet Solutions.

2. From your voice terminal, open a new line and enter the Service Observing Feature Access Code (FAC) followed by the extension of the agent that you want to observe. You will hear a confirmation tone (three short bursts) to indicate that the Service Observing feature is activated. At this point, you can observe all agent and customer transactions (text chat, escorted browsing, and Internet voice).

   Text chat transactions are preceded with caller: for customer-entered text and agent1: for agent-entered text.

Agent-initiated callback during Service Observing

If the agent initiates a callback during an observed session, the observer will not see the Callback window and will be temporarily dropped from the session. The observer will be reconnected when the agent-initiated callback connects.