📄 callcentoverview.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><! FRAMESET COLS="120%,*"><HTML><HEAD> <TITLE>Call Center Overview</TITLE> <META NAME="Author" CONTENT=""> <META NAME="GENERATOR" CONTENT="Mozilla/3.0Gold (WinNT; I) [Netscape]"></HEAD><BODY><BODY BGCOLOR=#ffffff><IMG SRC="images/jtapi-1.1.logo.gif" ALIGN="left"><BR><BR><BR><BR><H1><CENTER>Java Telephony API<BR>Call Center Extension Package</CENTER></H1><HR><CENTER><H3>Revision 1.1 <BR> Jan 31, 1997</H3></CENTER><BR><BR><BR><BR><BR><P><H2>Introduction</H2><HR>This document is an overview of the Call Center Extension Package to the JavaTelephony API. The Call Center Package extends the Core API by supportingthe following key Call Center features: <A HREF="CallCentOverview.html#Routing"> Routing </A>, <A HREF="CallCentOverview.html#ACD"> Automatic Call Distribution (ACD) </A>, <A HREF="CallCentOverview.html#PredCalling"> Predictive Calling </A>, <A HREF="CallCentOverview.html#AppData"> Application Data </A>.</P>More detailed information on the Call Center Extension Package can be found in <A HREF="Package-telephony.callcenter.html">The Java Telephony Call Center Package Specification</A>.<A NAME="Routing"><H2>Routing</H2><HR><P>Routing is a call center feature that gives applications theability to route calls to their final destinations. It gives applications the power to apply routing heuristics unique to their domains.</P><P>Before performing any routing functions, an application must first register with the switching domain to route calls fora specific Address. The switching domain may perform security checks toverify that the application has permission to route calls for that Address.An application can indicate that it wants to route calls for all Addresseswithin the Provider's domain by invoking registration methods on a RouteAddresscreated with a special valid Address "AllRouteAddress". The RouteAddress call centerinterface extends the core Address interface with methods for routingregistration. </P><P>When a call is made to an Address, the switching domain sends an event(or request) to the application, which then should respond with a destination Addressor with a "no destination". Application can chooseamong alternate destinations based on, forexample, origin of the call (calling number), number dialed to placethe call (called number), hour of day or availability of agents to handlethe call. This is the basic request/response scenario for routing. </P><P>If the switch gets a response from the application, tries the Address returnedand fails, it could ask the application for another destination. The applicationmust know that this is not a new route request, but a request for a newdestination from a previous request. Multiple calls may be placed to thesame Address at the same time. Thus, applications must track each request/responsesession. This tracking is facilitated by a route session. The first routerequest for a new call to the Address starts a new route session. All furthercommunication between the application and the switch for this call (re-routes,route ended, etc) is done within this session. A new RouteSession objectrepresents an outstanding route request. </P><P>The RouteCallback interface provides an interface to handle routingevents. An application implements the RouteCallback interface in order to getcalled back when its provider wants the application to route a call.The getRouteableAddresss method on CallCenterProvider returns thelist of Addresss that an application on this provider can register to routecalls for.</P><p>The RouteSession object is at the heart of all routing. Below is a statediagram that illustrates the transitions possible on RouteSession.<HR><CENTER><H3>RouteSession Object States</H3><P><IMG SRC="images/Rtestat.gif" HEIGHT=300 WIDTH=350></P></CENTER><P><IMG SRC="images/cyan-ball.gif">ROUTE: The RouteSession object enters the ROUTE state when the providerrequests the application to route a call</p><P><IMG SRC="images/cyan-ball.gif">ROUTE_USED: The RouteSession object enters the ROUTE_USED state when theprovider gives the application the destination for a successfully completedroute request.</P><p><IMG SRC="images/cyan-ball.gif">ROUTE_END: The RouteSession object enters the ROUTE_END state when the provider informs the application that a route session has ended.</p><p><IMG SRC="images/cyan-ball.gif">RE_ROUTE: The RouteSession object enters the REROUTE state whenthe provider requests the application to choose another call route.</p><IMG SRC="images/cyan-ball.gif">ROUTE_CALLBACK_ENDED: The RouteSession object enters the ROUTE_CALLBACK_ENDEDstate when the provider informs the application of the termination of apreviously registered route callback.</p><HR><p><CENTER><H3>Routing Code Examples</H3></CENTER><BR><BR></p><H3>RouteTest Java Source</H3><PRE>import java.applet.*;import java.lang.*;import java.util.*;import telephony.*;import telephony.callcenter.*;import telephony.callcenter.events.*;public class RouteTest extends Applet { Provider myProvider; Address myAddress; RouteAddress myRouteAddress; MyRouteCallback myRouteCallback; public void init() { /* * Create a provider by first obtaining the default implementation of * JTAPI and then the default provider of that implementation. */ Provider myprovider = null; try { JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null); myprovider = peer.getProvider(null); } catch (Exception excp) { System.out.println("Can't get Provider: " + excp.toString()); System.exit(0); } } public void start() { // if Device returned does not implement RouteDN return if (!(myAddress instanceof RouteAddress)) return; myRouteAddress = (RouteAddress)myAddress; try { // register callback to route calls for myRouteAddress myRouteAddress.registerRouteCallback(myRouteCallback); } catch (Exception e) { System.out.println("exception occured"); return; } } public void stop() { if (myRouteAddress != null) { // cancel previous registration to route calls for try { // myRouteAddress myRouteAddress.cancelRouteCallback(myRouteCallback); } catch (Exception e) { System.out.println("exception occured"); return; } } }}class MyRouteCallback implements RouteCallback{ // for simplification this code is in the callback thread // probably we should spawn off one thread per session public void routeEvent(RouteEvent event) { // call function todetermine a destination String[] routeSelected = new String[1]; routeSelected[0] = new String(getRoute((Terminal)event.getCallingTerminal(), (Address)event.getCurrentRouteAddress())); try { event.getRouteSession().selectRoute(routeSelected); } catch (Exception e) { System.out.println("exception occured"); return; } return; } public void reRouteEvent(RouteSessionEvent event) { // previous routeSelected did not work, ok // just pick some default route, audix "77777" String[] routeSelected = new String[1]; routeSelected[0] = new String("77777"); try { event.getRouteSession().selectRoute(routeSelected); } catch (Exception e) { System.out.println("exception occured"); return; } } public void routeUsedEvent(RouteUsedEvent event) { // do something } public void routeEndEvent(RouteEndEvent event) { // session is over, clear up any objects, data, threads // associated with this session } public void routeCallbackEndedEvent(RouteCallbackEndedEvent event) { // callback has been terminated, clear up any objects, data, // threads associated with this callback } public String getRoute(Terminal callingTerminal, Address currentRouteAddress) { // look up some database to determine a destination // based on callingTerminal and currentRouteAddress // for now return a default "12345" return ("12345"); }}</PRE><BR><BR><HR><CENTER><H3>RouteTest Application Objects</H3></CENTER><P><IMG SRC="images/Rtetest.gif" HEIGHT=370 WIDTH=500></P><HR><BR><BR><BR><BR><A NAME="ACD"><H2>ACD</H2><HR><H3>ACD Address</H3><P>Automatic Call Distribution (ACD) is a Call Center feature that definesan ACD Group as zero or more Agent extensions that service calls coming tothe Group. An incoming call can, for example, either sent to an available Agent or queuedwhen no Agents are available. </P><P>The primary interface for the ACD feature is the ACD Address which is an extension of the CallCenterAddress. This is a specialization of Address that distributes calls to a dynamic set of Terminals. In addition, ACD Address is not directly associated with a Terminal because it is a logical entity within the Provider and as such does not have any physical attributes. <HR><p><CENTER><h3>ACD Address Model</h3></CENTER></a><center><img src="images/ACDAddr.gif"></center><HR></p>Calls that are presented to an ACD Address may be processed in several different ways. For example, the call may be queued at the ACD Address before being distributed, the call may be delivered to one of the available Agent Terminals, or the call may be redirected to another ACD Address. The Connection interface which represents the relationship between the ACD Address and the Call is known as ACD Connection.<p> The dynamic association between the ACD Address and a given Terminal is represent by the Agent class. The Agent object represents an AgentTerminal's relationship to an ACDAddress. You can think of the Agent object as representing a person acting as an agent in the simplest case where the person is logged into only one ACD Address. If the person were logged into several ACD Addresses these scenarios would be represented as several Agent objects. This Agent has a set of state transitions to represent its association. For example, when a Terminal creates an association with a given ACD Address (i.e.Agent Logged In), or when the Terminal is associated with a given ACD Address and is ready to process a call from the ACD Address (i.e. Agent Ready). For more details, on the states, see the Agent State Diagram below. A Terminal that can be associated with ACD Addresses is represented by the AgentTerminal which is an extension of the Terminal interface. <p></P>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -