CA2233438A1 - System and method for tracing a call through a telecommunications network - Google Patents
System and method for tracing a call through a telecommunications network Download PDFInfo
- Publication number
- CA2233438A1 CA2233438A1 CA002233438A CA2233438A CA2233438A1 CA 2233438 A1 CA2233438 A1 CA 2233438A1 CA 002233438 A CA002233438 A CA 002233438A CA 2233438 A CA2233438 A CA 2233438A CA 2233438 A1 CA2233438 A1 CA 2233438A1
- Authority
- CA
- Canada
- Prior art keywords
- call
- data
- switch
- telecommunications network
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/08—Indicating faults in circuits or apparatus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
Abstract
A system and method for tracing a path of a call through a telecommunications network includes at least two switches, a database (29), a user interface device (21) and a control processor (25). Each switch has an associated adjunct processor (25) that has a memory that stores call record data. The database (29) stores call routing data for calls traversing each switch. The user interface device (21) accepts selected call parameter data related to a call having a path through the telecommunications network that is to be traced. The control processor (25) accesses the call routing data and the call record data for searching for a call having call parameter data corresponding to the selected call parameter data. The processor (25) provides report data that is related to the path through the telecommunications network of a call having call parameter data corresponding to the selected call parameter data.
Description
W O 97/12473 PCT~US96/15491 SYST~M AND METHOD FOR TRACING A CALL THROUGH
A TELECOMMUNICATIONS NETWORK
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to a system and method for tracing calls through a telecommunications network. More particularly, the present invention relates to a system and method for tracing a path of a call through a telecommunications network that corresponds to selected search parameters .
A TELECOMMUNICATIONS NETWORK
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to a system and method for tracing calls through a telecommunications network. More particularly, the present invention relates to a system and method for tracing a path of a call through a telecommunications network that corresponds to selected search parameters .
2. DescriPtion of the Related Art There is a need for the ability for conveniently tracing a path of a call through a telecommunications network so that system diagnostics can be efficiently performed or so that a call reported to have a problem can be quickly troubleshot. Typically, a long distance telecommunications network includes a plurality of switches through which calls traverse. Each switch in the network is connected to every other switch by an intermachine trunk group (IMT). Calls travel through the switches in the network via circuits.
A circuit is the physical connection between any two switches.
Usually there is only one IMT between a pair of switches. Figure 1 shows a single IMT 10 connected between exemplary switch 1 and exemplary switch 2. Each circuit in an IMT is assigned a name at each W O 97/12473 - PCT~US96/15491 switch that is based on the name of the switch from which the circuit is viewed. When a call in a switch is routed through a circuit to another switch, the circuit is considered to be made up of a terminating trunk group (TTG) leaving the first switch and an originating trunk group (OTG) arriving at the 5 second switch. As a call traverses a switch, the switch generates a call routing record for the call that includes data related to the originating trunk group, the terminating trunk group, the originating port and the terminating port of the call using circuit naming conventions that are based on the point of view of the switch.
In the situation when a call is routed from switch 1 to switch 2 through circuit 1 1 A in Figure 1, circuit 1 1 A is named 1 1 1 IMT TTG at switch 1, for example, and 2221MT OTG at switch 2, for example. When a call in switch 2 is routed through circuit 1 1 B to switch 1, circuit 1 1 B is properly thought of in the reverse as a terminating trunk group (TTG) leaving switch 2 and an originating trunk group incoming to switch 1. Although circuits 1 1 A and 1 1 B
are shown as separate circuits for clarity of call direction, they are intended to be the same physicai circuit. In the latter situation, circuit 11 B is named 2221MT TTG at switch 2, for example, and 11 1 IMT OTG at switch 1, for example. Since the trunk names 111 IMT and 2221MT are different names for 20 the same physical circuit 11 between switches 1 and 2, the respective call routing records stored at switch 1 and switch 2 for calls routed through circuit 11 identify the same circuit, but use different identifying names.
. .. .
W O 97/12473 'PCT~US96/15491Each switch of the telecommunication network also has an associated adjunct processor (AP) that accumulates call record data used for billing purposes. Periodically, the switch downloads call records to the associated AP which are subsequently accessed by a billing host processor located at a 5 remote location. The call records are divided into call detail records (CDRs), private network records (PNRs), operator service records (OSRs), and private operator service records (POSRs) and includs data related to the date/time, the switch site, the call record type, the dialed number, the automatic number identification (ANI) and the pretranslated number of a call. The call records 10 at each respective switch contain information about only the calls traversing that switch.
When a call reported to have a problem requires analysis, it is difficult to trace the path of the call through the telecommunications network because the call routing records storing data relating to each individual leg of the call 15 path must be correlated with the call record data stored at each respective adjunct processor for determining the call path. While the call record data stored by each adiunct processor is readily available from a remote location over a network, for example by the billing host processor, the call routing records are available only at each respective switch or from a separate 20 database. This results in an inconvenient and time consuming task because the call routing records and the call record data are not available together.
W O 97/12473 PCTAUS96/lS491 SUMMARY OF THE INVENTION
The present invention provides a system for conveniently and efficiently tracing a path of a call through a telecommunications network.
According to the present invention, such a system includes at least two switches, a database, a user interface device and a control processor. Each switch has an associated adjunct processor. Each adjunct processor has a memory storing call record data. The database stores call routing information for calls traversing each switch. The user interface device, which preferably provides a graphical user interface, accepts selected call parameter data 10 relating to a call having a path through the telecommunications network that is to be traced. The control processor is coupled to the user interface device, to each of the adjunct processors associated with the switches, and to the database. The control processor receives the call parameter data from the user interface device and accesses the call routing data stored in the database 15 and the call record data stored in the memory of each adjunct processor for searching for a call having call parameter data corresponding to the selected call parameter data for tracing the path of the call. The control processor provides report data to the IJser interface device that is related to the path through the telecommunications network of a call having call parameter data 20 corresponding to the selected call parameter data.
According to the invention, each adjunct processor has capability for searching the call record data stored in the memory associated with the ,_ ~
W O 97/12473 PCTAJS96/15491adjunct processor based on the seiected call parameter data. The control processor transfers the selected call parameter data to the adjunct processor and the adjunct processor generates results data related to results of a search of the call record data based on the selected call search parameters. The call 5 routing data stored in the database inciudes information related to a next switch a call traverses and control processor uses the data related to the next switch a call traverses for searching for the path of the call to be traced. The call record data preferably includes originating trunk group, terminating trunk group, originating port and terminating port data of a call traversing the 10 switch, dateltlme, switch site, call record type, dialed number, automatic number identification (ANI) data and pretranslated number data.
The present invention also provides a method for tracing a path of a call through a telecommunications network having the steps of receiving the selected call parameter data at the control processor from the user interface 15 device, accessing the call routing data stored in the database, accessing the call record data stored in the memory of each adjunct processor, identifying call routing data and call record data of a call having call parameter data corresponding to the selected call parameter data, and generating report data related to the path through the telecommunications network of the call having 20 call parameter data corresponding to the selected call parameter data. The report data is displayed at the user interface device. Preferably, the step of accessing the call record data includes the steps of transferring the selected W O 97/12473 PCTAJS96/1549i call parameter data to the adjunct processor, searching the call record stored in the memory associated with the adiunct processor based on the selected call search parameters, and generating results data at the adjunct processor related to results of a search of ~he call record data. The next switch a call 5 traverses is identified based on the call routing data.
E~RIEF DESCRIPTION OF THE DI~AWINGS
The present invention is illustrated by way of example and not limitation in the accompanying figures in which like reference numerals indicate similar elements and in which:
Figure 1 shows a schematic block diagram showing a single intermachine trunk group connected between two exemp!ary switches; and Figure 2 shows a schematic block diagram of an embodiment of a system for tracing a call through a telecommunication network according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EM~ODIMENTS
The present invention is directed to a system for tracing a call path through a telecommunications network that corresponds to selected call search parameters for conveniently performing network diagnostics or ~roubleshooting a call reported to have problems. Figure 2 shows a , W O 97/12473 PCT~US96/1~491schematic block diagram of an embodiment of a call path tracing system 20 according to the present invention.
System 20 includes a plurality of workstations 21 connected to a local area network (LAN) 22. LAN 22 is connected through a communication link 5 23 to a first operating system network 24. First operating system network 24 is connected to a plurality of adjunct processors (AP) 25. Each adjunct processor 25 is associated with a switch (Figure 1). The switch downloads call records that include irlformation related to the date/time, switch site, dialed number, ANI number and pretranslated number of calls traversing the 10 switch for storage by the ad~unct processor.
LAN 22 is also connected through a communication link 27 to a second operating system network 28. Second operating system network 28 accesses call routing data that includes information related to originating trunk group and terminating trunk group that is available from a separate 15 database. The call routing data is located in one central database 29 connected to network 28 or distributed throughout the telecommunications system, for example at each respective switch, and availabie through network 28. As should be appreciated, if the call routing data is available from a central database or a plurality of databases connected to network 24, 20 network 28 is not needed.
To trace a call path through the telecommunications network, a workstation 21 accepts call search parameters through a graphical user W O 97/12473 PCT~US96/15491interface (GUI). Workstation 21 accesses first operating system network 24 for identifying a call meeting the search parameters at a particular switch that is specified as one of the search parameters. The call search parameters that can be specified for a call search include date/time, switch site, call record 5 type, dialed number, ANI number, pretranslated number, originating trunk group, terminating trunk group, originating port, and terminating port.
According to the invention, the search parameters date/time, switch site and call record type are necessary parameters for identifying a particular call.
In the situation when only a dialed number and a call time interval is 10 known about a call that is to have its path traced, the present invention accepts the search parameters without a switch site specified, but with at least the first 6 digits of the 10 digit called number (referred to as a valid NPANXX). The present invention accesses the respective adjunct processors for determining the home switch of the dialed number, that is, the switch site 15 through which all calls to that NPANXX must pass. The search then proceeds with the home switch of the dialed number as the initially specified switch site.
When workstation 21 accesses the adjunct processor attached to the switch specified as one of the search parameters, workstation 21 logs onto 20 the adjunct processor 25 associated with the specified switch. Each adjunct processor 25 has a search function capa~ility that is activated by workstation 21. Workstation 21 transfers the search pararneters to the adjunct processor W O 97/12473 PCT~US96/15491 25 and adjunct processor 25 communicates to workstation 21 the name of the data fiie that search results will be written to, that is the call record for each call traversing the switch associated with the adjunct processor matching the search parameters. Workstation 21 periodically accesses < 5 adjunct processor 2~ to check whether the search results data file has been written. When the search results data file has been written, workstation 21 downloads the data file from adjunct processor for further processing at workstation 21.
When a cali is identified from the downloaded search results file meeting the search parameters, workstation 21 accesses the call routing information of the switch through the separate database 29 for information related to the next switch destination of the identified call. Once the call routing information is obtained, workstation 21 accesses the adjunct processor associated with the next switch the call traversed as determined by the call routing information. The process of accessing the call routing records is repeated for identifying the next switch traversed by the call.
A call path may be traced from the switch where it enters the telecommunications network to the switch where it leaves the network and vice versa. Call records satisfying the search parameters are collected from each of the adjunct processors associated with the switches that the call traversed and are compiled for display as search results by the graphical user interface at workstation 21. The search parameters can be recalled in list _9_ W O97/12473 PCT~US96/15491form, and the status of all searches in progress can be displayed. The selected parameters can be edited and resubmitted for conducting a revised call path search. The search results can subsequently be used for generating a work order for correcting hardware and/or software problems experienced 5 by the network.
The call tracing system of the present invention utilizes three processes named, for example, apdsptch.exe, cs.exe and apinter.exe, with apdsptch being the principal process. The processes are extensively threaded and communicate with each other via named pipes. Commands are sent to the 10 apdsptch process from the graphical user interface process cs via a main named pipe. Apdsptch processes the commands and, for those commands requiring access to the adjunct processors, sends the commands to the adjunct processor interface apinter via another named pipe. According to the invention, there is only one apdsptch process running for servicing a distinct 15 set of users and adjunct processor interfaces. If the present invention has a LAN configuration, apdsptch is rec~uired to run on a named server for the pipes to work. During initialization, apdsptch reads a configuration file containing various user definable parameters.
The cs process is the user interface process. It contains all of the 20 graphical dialogue t~oxes for logging onto the system, initiating call searches and displaying parameters and results. Users must first log on to the system before new searches can be submitted. In a LAN configuration, cs may run , W O 97/12473 ' PCT~US96/15491 on any workstation including the named server. The cs process communicates with apdsptch via a named pipe. CS determines whether the apdsptch process is located at a server or is local, as well as the location of a cstrack file based on parameters in a cs configuration file. The cstrack file 5 contains parameters, status, and results of all searches that have not been deleted. If the apdsptch process is not running, cs disables system log in process so that searches may not be initiated, but search parameters, status, and results are available for viewing.
The apinter process performs the adjunct processor inter~ace by 10 communicating with the adjunct processors 25 through communication link 23 (Figure 2~. Commands are sent to apinter via from apdsptch via named pipes.
When the apdsptch process initializes, a named pipe called \pipe\cs~dsp.pip, for example, is created. This named pipe is opened by all 15 other processes during a transaction, that is, when other processes request services from apdsptch. A thread in apdsptch for receiving service requests creates a new temporary pipe when a transaction is received. The name of the temporary pipe is sent through the main pipe to the requesting process so the requesting process can then open the temporary pipe. Once the new 20 temporary pipe connection is established, apdsptch queues the request to another thread for further processing thus freeing the original thread for accepting additional requests through the main pipe. The main pipe CA 02233438 l998-03-27 W O 97/12473 PCT~US96tl5491connection -is $hen ~roken for that transaction, and the two tasks conduct the remainder of their transaction through the temporary pipe, which exits for the duration of a single transaction.
The adjunct processor interface process also communicates with 5 apdsptch through a named pipe. When the apinter process initiaiizes, it registers with apdsptch by sending a transaction through the main pipe. As with any other transaction, apdsptch creates a new pipe for communicating responses, but in this case the two processes do not yet connect. Instead, apdsptch creates a new thread for communicating with apinter. The new 10 thread waits until requests are queued to it, at which time a p;pe connection is made and the command is sent to apinter. This thread waits for a response from apinter on the pipe, reads the response, then breaks the connection.
The pipe remains intact waiting for additional requests.
According to the invention, all pipes are created and owned by 15 apdsptch because pipes can only connect ~etween processes on a single workstation, or between workstation and a named server. For this reason, when the call tracing system of the present invention is configured as a LAN, apdsptch must run on a named server. Any num~er of user interfaces and adjunct processor interfaces can communicate through the named server 20 central node.
The only data store for the process of the present invention is the tracking file named cstrack and its associated result data files. The cstrack W O 97/12473 PCT~US96/15491 tracking file contains one record for each re~uest for a call search that is submitted. Each record is an instance of a ApRequestNew class and includes user specified search parameters and selected overhead data. The ApRequestNew class is defined in a header file aputil.hpp.
When a search is submitted to apdsptch, a record is added to the tracking file cstrack. A status field in the added record indicates the current status of the search. The possible values for the status field are PNDNG, INPRG, POLAP, CMPLT, CNROC, ERROR and RECVR. PNDNG indicates a new search that has not yet been submitted to apinter. INPRG indicates that a search has been submitted to apinter, but has not yet been completed.
POLAP indicates that apinter is being queried for results of the present search. CMPLT indicates a completed search with the call records found located in a separate file. CNROC indicates a completed search with no matching records found. ERROR indicates that the particular search parameters have been submitted a predetermined number of times without completion of the search. RECVR indicates that apdsptch executable is in the process of receiving records from apinter.
A results data file is created when apdsptch determines there are call details records to save. A file is generated and saved in the tracking file.
Preferably, the results file contains, for example, 100 small header records, followed by up to 100 call records, for example. The call records may be CDRs, PNRs, OSRs or POSRs, depending on the kind of search requested.
._ The tracking and result files are modified only by apdsptch, but may be read by any number of user interfsce processes from any workstation.
In addition to the tracking and result files, a lock file is created by .apdsptch for ensuring that only one apdsptch is running in a directory for 5 informing the user interface process that apdsptch is up and running and for enabling the user interface process to determine if apdsptch has restarted between search requests. Apdsptch creates the lock file at initialization and opens it for read/write access, while denying write access to the lock file for other processes. The lock file is deleted when apdsptch orderly terminates.
10 Apdsptch determines that another instance of itself is already running if the lock file already exists and it cannot be opened for write access which happens, for example, when a previous run has crashed.
The user interface process similarly determines that the apdsptch process is running if the lock file is available for read access, but write access 15 is denied. In addition, the user interface process examines the creation date of the file and time before each transaction is sent to apdsptch. If either time stamp has changed, the user interface concludes that apdsptch has been restarted, and a user is required to again log on to the system.
Data objects are transferred between processes through named pipes.
20 Each transaction consists of an ApTranslD object containing 4 data fields followed by zero or more data objects. The first data field of an ApTranslD
object, TransCode, indicates the type of transaction of the object. An W O 97/12473 PCT~US96/15491ErrorCode data field indicates a particular error code that has been sent back in response to a request. A Length data field indicates the length of the data object following a transaction object on the pipe. The last data field indicates the Type of the data object that follows the transaction on the pipe.
The transactions available include ApRegisterApi, ApUnRegisterApi, ApLogon, and ApNewSearch. The ApRegisterApi transaction is sent from apinter to apdsptch when apinter informs apdsptch that the apinter process is available. No additional data is sent with this transaction. The ApUnRegisterApi transaction is never sent down a pipe. It is queued 10 internally by apdsptch when apdsptch can no longer communicate with apinter. No additional data is sent.
The ApLogon transaction is sent by the user interface process to apdsptch for requesting a log on to the adjunct processors. The Length data field for this transaction contains the length of an ApLogon object. An 1~ ApLogon object containing the log on parameters follows the transaction down the pipe. Apdsptch forwards the ApLogon object to apinter and the ApLogon process follows. Subsequently, apinter sends an ErrorCode to apdsptch indicating any log on error. If the log on process was successful, the transaction object is send down the pipe from apinter to apdsptch 20 followed by an ApLogon object with its switch site list filled in. The ApLogon object is forwarded from apdsptch to cs and the ApLogon process follows.
W O 97/12473 PCTnUS96/15491 The ApNewSearch transaction is sent from the user interface process to apdsptch for requesting a new search. The Length f;eld of this transaction contains the length of the ApRequestNew object which follows the ApNewSearch transaction down the pipe. Apdsptch forwards this transaction 5 to apinter when it is received from the user interface. Additionally, apdsptch initiates this transaction when its timer thread determines that a requested search was never successfully submiKed to apinter. In either case, an ApRequestNew object follows the transaction down the pipe. Aplnter sends the transaction to apdsptch with the Length field containing the length of an 10 ApRequestNew object that follows the transaction down the pipe. The transaction object is forwarded from apdsptch to the user interface if the request was initiated by the user interface. The Length field is always zero and the ErrorCode field indicates any error. No ApRequestNew object is sent back to the user interface. If the request was initiated from apdsptch, no 1~ transaction is forwarded to the user interface.
The default configuration file for apinter is apinter.cfg and identifies the communication port and parameters used when communicating with the adjunct processors 25. Apinter.cfg also indicates the name of the server, if any, to ap-inter on which apdsptch will run. The parameters of apinter.cfg 20 and their acceptable values are:
C(:)MPORT The number of the asynchronous communications port.
Default value is 1.
BAlJDR~TE Baud rate (30, 1200, 2400, 4800, 9600). Default setting is 4800.
DATA The number of data bits (7 or 8). Default value is 8.
STOP The number of stop bits (O = 1 stop bit, 1--1 . 5 bits, 2 = 2 bits). Default setting is O (1 stop bit).
PARITY Type of parity (None, odd, even, mark, space). Default sett;ng is none.
SERVER The name of the server on which apdsptch is running. If this is a non-network configuration of the present invention, then all programs run on a single workstation and this parameter is omitted.
The default configuration file for the user interface process is callsrch.cfg and includes the following parameters:
LPATH The path to the directory containing the cstrack and callsrch.loc files. If LPATH is not specified, cs will look for these files in the current working directory.
SERVER The name of the server on which apdsptch is running.
This parameter is omitted in a single workstation environment where all programs run on the single workstation.
W O 97/12473 PCThUS96/15491 The default configuration file for apdsptch is apdsptch.cfg and includes the following parameters:
RANGEn POLLlNTERVALn These parameters, specified in pairs, determine the frequency with which the first operating system network is automatically polled for the results of an individual call search. Searches less than RANGE1 seconds old are polled every POLLINTERVAL1 seconds; those less than RANGE2 seconds old are polled every POLLINTERVAL2 seconds; all other searches are polled every POLLINTERVAL3 seconds.
EXPIREDAYS The number of days after which searches will be automatically deleted from the tracking file ~cstrack). ~eleted results cannot be retrieved.
While the present invention has been described in connection with the illustrated embodiments, it will t~e appreciated and understood that modifications may be made without departing from the true spirit and scope of the invention.
A circuit is the physical connection between any two switches.
Usually there is only one IMT between a pair of switches. Figure 1 shows a single IMT 10 connected between exemplary switch 1 and exemplary switch 2. Each circuit in an IMT is assigned a name at each W O 97/12473 - PCT~US96/15491 switch that is based on the name of the switch from which the circuit is viewed. When a call in a switch is routed through a circuit to another switch, the circuit is considered to be made up of a terminating trunk group (TTG) leaving the first switch and an originating trunk group (OTG) arriving at the 5 second switch. As a call traverses a switch, the switch generates a call routing record for the call that includes data related to the originating trunk group, the terminating trunk group, the originating port and the terminating port of the call using circuit naming conventions that are based on the point of view of the switch.
In the situation when a call is routed from switch 1 to switch 2 through circuit 1 1 A in Figure 1, circuit 1 1 A is named 1 1 1 IMT TTG at switch 1, for example, and 2221MT OTG at switch 2, for example. When a call in switch 2 is routed through circuit 1 1 B to switch 1, circuit 1 1 B is properly thought of in the reverse as a terminating trunk group (TTG) leaving switch 2 and an originating trunk group incoming to switch 1. Although circuits 1 1 A and 1 1 B
are shown as separate circuits for clarity of call direction, they are intended to be the same physicai circuit. In the latter situation, circuit 11 B is named 2221MT TTG at switch 2, for example, and 11 1 IMT OTG at switch 1, for example. Since the trunk names 111 IMT and 2221MT are different names for 20 the same physical circuit 11 between switches 1 and 2, the respective call routing records stored at switch 1 and switch 2 for calls routed through circuit 11 identify the same circuit, but use different identifying names.
. .. .
W O 97/12473 'PCT~US96/15491Each switch of the telecommunication network also has an associated adjunct processor (AP) that accumulates call record data used for billing purposes. Periodically, the switch downloads call records to the associated AP which are subsequently accessed by a billing host processor located at a 5 remote location. The call records are divided into call detail records (CDRs), private network records (PNRs), operator service records (OSRs), and private operator service records (POSRs) and includs data related to the date/time, the switch site, the call record type, the dialed number, the automatic number identification (ANI) and the pretranslated number of a call. The call records 10 at each respective switch contain information about only the calls traversing that switch.
When a call reported to have a problem requires analysis, it is difficult to trace the path of the call through the telecommunications network because the call routing records storing data relating to each individual leg of the call 15 path must be correlated with the call record data stored at each respective adjunct processor for determining the call path. While the call record data stored by each adiunct processor is readily available from a remote location over a network, for example by the billing host processor, the call routing records are available only at each respective switch or from a separate 20 database. This results in an inconvenient and time consuming task because the call routing records and the call record data are not available together.
W O 97/12473 PCTAUS96/lS491 SUMMARY OF THE INVENTION
The present invention provides a system for conveniently and efficiently tracing a path of a call through a telecommunications network.
According to the present invention, such a system includes at least two switches, a database, a user interface device and a control processor. Each switch has an associated adjunct processor. Each adjunct processor has a memory storing call record data. The database stores call routing information for calls traversing each switch. The user interface device, which preferably provides a graphical user interface, accepts selected call parameter data 10 relating to a call having a path through the telecommunications network that is to be traced. The control processor is coupled to the user interface device, to each of the adjunct processors associated with the switches, and to the database. The control processor receives the call parameter data from the user interface device and accesses the call routing data stored in the database 15 and the call record data stored in the memory of each adjunct processor for searching for a call having call parameter data corresponding to the selected call parameter data for tracing the path of the call. The control processor provides report data to the IJser interface device that is related to the path through the telecommunications network of a call having call parameter data 20 corresponding to the selected call parameter data.
According to the invention, each adjunct processor has capability for searching the call record data stored in the memory associated with the ,_ ~
W O 97/12473 PCTAJS96/15491adjunct processor based on the seiected call parameter data. The control processor transfers the selected call parameter data to the adjunct processor and the adjunct processor generates results data related to results of a search of the call record data based on the selected call search parameters. The call 5 routing data stored in the database inciudes information related to a next switch a call traverses and control processor uses the data related to the next switch a call traverses for searching for the path of the call to be traced. The call record data preferably includes originating trunk group, terminating trunk group, originating port and terminating port data of a call traversing the 10 switch, dateltlme, switch site, call record type, dialed number, automatic number identification (ANI) data and pretranslated number data.
The present invention also provides a method for tracing a path of a call through a telecommunications network having the steps of receiving the selected call parameter data at the control processor from the user interface 15 device, accessing the call routing data stored in the database, accessing the call record data stored in the memory of each adjunct processor, identifying call routing data and call record data of a call having call parameter data corresponding to the selected call parameter data, and generating report data related to the path through the telecommunications network of the call having 20 call parameter data corresponding to the selected call parameter data. The report data is displayed at the user interface device. Preferably, the step of accessing the call record data includes the steps of transferring the selected W O 97/12473 PCTAJS96/1549i call parameter data to the adjunct processor, searching the call record stored in the memory associated with the adiunct processor based on the selected call search parameters, and generating results data at the adjunct processor related to results of a search of ~he call record data. The next switch a call 5 traverses is identified based on the call routing data.
E~RIEF DESCRIPTION OF THE DI~AWINGS
The present invention is illustrated by way of example and not limitation in the accompanying figures in which like reference numerals indicate similar elements and in which:
Figure 1 shows a schematic block diagram showing a single intermachine trunk group connected between two exemp!ary switches; and Figure 2 shows a schematic block diagram of an embodiment of a system for tracing a call through a telecommunication network according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EM~ODIMENTS
The present invention is directed to a system for tracing a call path through a telecommunications network that corresponds to selected call search parameters for conveniently performing network diagnostics or ~roubleshooting a call reported to have problems. Figure 2 shows a , W O 97/12473 PCT~US96/1~491schematic block diagram of an embodiment of a call path tracing system 20 according to the present invention.
System 20 includes a plurality of workstations 21 connected to a local area network (LAN) 22. LAN 22 is connected through a communication link 5 23 to a first operating system network 24. First operating system network 24 is connected to a plurality of adjunct processors (AP) 25. Each adjunct processor 25 is associated with a switch (Figure 1). The switch downloads call records that include irlformation related to the date/time, switch site, dialed number, ANI number and pretranslated number of calls traversing the 10 switch for storage by the ad~unct processor.
LAN 22 is also connected through a communication link 27 to a second operating system network 28. Second operating system network 28 accesses call routing data that includes information related to originating trunk group and terminating trunk group that is available from a separate 15 database. The call routing data is located in one central database 29 connected to network 28 or distributed throughout the telecommunications system, for example at each respective switch, and availabie through network 28. As should be appreciated, if the call routing data is available from a central database or a plurality of databases connected to network 24, 20 network 28 is not needed.
To trace a call path through the telecommunications network, a workstation 21 accepts call search parameters through a graphical user W O 97/12473 PCT~US96/15491interface (GUI). Workstation 21 accesses first operating system network 24 for identifying a call meeting the search parameters at a particular switch that is specified as one of the search parameters. The call search parameters that can be specified for a call search include date/time, switch site, call record 5 type, dialed number, ANI number, pretranslated number, originating trunk group, terminating trunk group, originating port, and terminating port.
According to the invention, the search parameters date/time, switch site and call record type are necessary parameters for identifying a particular call.
In the situation when only a dialed number and a call time interval is 10 known about a call that is to have its path traced, the present invention accepts the search parameters without a switch site specified, but with at least the first 6 digits of the 10 digit called number (referred to as a valid NPANXX). The present invention accesses the respective adjunct processors for determining the home switch of the dialed number, that is, the switch site 15 through which all calls to that NPANXX must pass. The search then proceeds with the home switch of the dialed number as the initially specified switch site.
When workstation 21 accesses the adjunct processor attached to the switch specified as one of the search parameters, workstation 21 logs onto 20 the adjunct processor 25 associated with the specified switch. Each adjunct processor 25 has a search function capa~ility that is activated by workstation 21. Workstation 21 transfers the search pararneters to the adjunct processor W O 97/12473 PCT~US96/15491 25 and adjunct processor 25 communicates to workstation 21 the name of the data fiie that search results will be written to, that is the call record for each call traversing the switch associated with the adjunct processor matching the search parameters. Workstation 21 periodically accesses < 5 adjunct processor 2~ to check whether the search results data file has been written. When the search results data file has been written, workstation 21 downloads the data file from adjunct processor for further processing at workstation 21.
When a cali is identified from the downloaded search results file meeting the search parameters, workstation 21 accesses the call routing information of the switch through the separate database 29 for information related to the next switch destination of the identified call. Once the call routing information is obtained, workstation 21 accesses the adjunct processor associated with the next switch the call traversed as determined by the call routing information. The process of accessing the call routing records is repeated for identifying the next switch traversed by the call.
A call path may be traced from the switch where it enters the telecommunications network to the switch where it leaves the network and vice versa. Call records satisfying the search parameters are collected from each of the adjunct processors associated with the switches that the call traversed and are compiled for display as search results by the graphical user interface at workstation 21. The search parameters can be recalled in list _9_ W O97/12473 PCT~US96/15491form, and the status of all searches in progress can be displayed. The selected parameters can be edited and resubmitted for conducting a revised call path search. The search results can subsequently be used for generating a work order for correcting hardware and/or software problems experienced 5 by the network.
The call tracing system of the present invention utilizes three processes named, for example, apdsptch.exe, cs.exe and apinter.exe, with apdsptch being the principal process. The processes are extensively threaded and communicate with each other via named pipes. Commands are sent to the 10 apdsptch process from the graphical user interface process cs via a main named pipe. Apdsptch processes the commands and, for those commands requiring access to the adjunct processors, sends the commands to the adjunct processor interface apinter via another named pipe. According to the invention, there is only one apdsptch process running for servicing a distinct 15 set of users and adjunct processor interfaces. If the present invention has a LAN configuration, apdsptch is rec~uired to run on a named server for the pipes to work. During initialization, apdsptch reads a configuration file containing various user definable parameters.
The cs process is the user interface process. It contains all of the 20 graphical dialogue t~oxes for logging onto the system, initiating call searches and displaying parameters and results. Users must first log on to the system before new searches can be submitted. In a LAN configuration, cs may run , W O 97/12473 ' PCT~US96/15491 on any workstation including the named server. The cs process communicates with apdsptch via a named pipe. CS determines whether the apdsptch process is located at a server or is local, as well as the location of a cstrack file based on parameters in a cs configuration file. The cstrack file 5 contains parameters, status, and results of all searches that have not been deleted. If the apdsptch process is not running, cs disables system log in process so that searches may not be initiated, but search parameters, status, and results are available for viewing.
The apinter process performs the adjunct processor inter~ace by 10 communicating with the adjunct processors 25 through communication link 23 (Figure 2~. Commands are sent to apinter via from apdsptch via named pipes.
When the apdsptch process initializes, a named pipe called \pipe\cs~dsp.pip, for example, is created. This named pipe is opened by all 15 other processes during a transaction, that is, when other processes request services from apdsptch. A thread in apdsptch for receiving service requests creates a new temporary pipe when a transaction is received. The name of the temporary pipe is sent through the main pipe to the requesting process so the requesting process can then open the temporary pipe. Once the new 20 temporary pipe connection is established, apdsptch queues the request to another thread for further processing thus freeing the original thread for accepting additional requests through the main pipe. The main pipe CA 02233438 l998-03-27 W O 97/12473 PCT~US96tl5491connection -is $hen ~roken for that transaction, and the two tasks conduct the remainder of their transaction through the temporary pipe, which exits for the duration of a single transaction.
The adjunct processor interface process also communicates with 5 apdsptch through a named pipe. When the apinter process initiaiizes, it registers with apdsptch by sending a transaction through the main pipe. As with any other transaction, apdsptch creates a new pipe for communicating responses, but in this case the two processes do not yet connect. Instead, apdsptch creates a new thread for communicating with apinter. The new 10 thread waits until requests are queued to it, at which time a p;pe connection is made and the command is sent to apinter. This thread waits for a response from apinter on the pipe, reads the response, then breaks the connection.
The pipe remains intact waiting for additional requests.
According to the invention, all pipes are created and owned by 15 apdsptch because pipes can only connect ~etween processes on a single workstation, or between workstation and a named server. For this reason, when the call tracing system of the present invention is configured as a LAN, apdsptch must run on a named server. Any num~er of user interfaces and adjunct processor interfaces can communicate through the named server 20 central node.
The only data store for the process of the present invention is the tracking file named cstrack and its associated result data files. The cstrack W O 97/12473 PCT~US96/15491 tracking file contains one record for each re~uest for a call search that is submitted. Each record is an instance of a ApRequestNew class and includes user specified search parameters and selected overhead data. The ApRequestNew class is defined in a header file aputil.hpp.
When a search is submitted to apdsptch, a record is added to the tracking file cstrack. A status field in the added record indicates the current status of the search. The possible values for the status field are PNDNG, INPRG, POLAP, CMPLT, CNROC, ERROR and RECVR. PNDNG indicates a new search that has not yet been submitted to apinter. INPRG indicates that a search has been submitted to apinter, but has not yet been completed.
POLAP indicates that apinter is being queried for results of the present search. CMPLT indicates a completed search with the call records found located in a separate file. CNROC indicates a completed search with no matching records found. ERROR indicates that the particular search parameters have been submitted a predetermined number of times without completion of the search. RECVR indicates that apdsptch executable is in the process of receiving records from apinter.
A results data file is created when apdsptch determines there are call details records to save. A file is generated and saved in the tracking file.
Preferably, the results file contains, for example, 100 small header records, followed by up to 100 call records, for example. The call records may be CDRs, PNRs, OSRs or POSRs, depending on the kind of search requested.
._ The tracking and result files are modified only by apdsptch, but may be read by any number of user interfsce processes from any workstation.
In addition to the tracking and result files, a lock file is created by .apdsptch for ensuring that only one apdsptch is running in a directory for 5 informing the user interface process that apdsptch is up and running and for enabling the user interface process to determine if apdsptch has restarted between search requests. Apdsptch creates the lock file at initialization and opens it for read/write access, while denying write access to the lock file for other processes. The lock file is deleted when apdsptch orderly terminates.
10 Apdsptch determines that another instance of itself is already running if the lock file already exists and it cannot be opened for write access which happens, for example, when a previous run has crashed.
The user interface process similarly determines that the apdsptch process is running if the lock file is available for read access, but write access 15 is denied. In addition, the user interface process examines the creation date of the file and time before each transaction is sent to apdsptch. If either time stamp has changed, the user interface concludes that apdsptch has been restarted, and a user is required to again log on to the system.
Data objects are transferred between processes through named pipes.
20 Each transaction consists of an ApTranslD object containing 4 data fields followed by zero or more data objects. The first data field of an ApTranslD
object, TransCode, indicates the type of transaction of the object. An W O 97/12473 PCT~US96/15491ErrorCode data field indicates a particular error code that has been sent back in response to a request. A Length data field indicates the length of the data object following a transaction object on the pipe. The last data field indicates the Type of the data object that follows the transaction on the pipe.
The transactions available include ApRegisterApi, ApUnRegisterApi, ApLogon, and ApNewSearch. The ApRegisterApi transaction is sent from apinter to apdsptch when apinter informs apdsptch that the apinter process is available. No additional data is sent with this transaction. The ApUnRegisterApi transaction is never sent down a pipe. It is queued 10 internally by apdsptch when apdsptch can no longer communicate with apinter. No additional data is sent.
The ApLogon transaction is sent by the user interface process to apdsptch for requesting a log on to the adjunct processors. The Length data field for this transaction contains the length of an ApLogon object. An 1~ ApLogon object containing the log on parameters follows the transaction down the pipe. Apdsptch forwards the ApLogon object to apinter and the ApLogon process follows. Subsequently, apinter sends an ErrorCode to apdsptch indicating any log on error. If the log on process was successful, the transaction object is send down the pipe from apinter to apdsptch 20 followed by an ApLogon object with its switch site list filled in. The ApLogon object is forwarded from apdsptch to cs and the ApLogon process follows.
W O 97/12473 PCTnUS96/15491 The ApNewSearch transaction is sent from the user interface process to apdsptch for requesting a new search. The Length f;eld of this transaction contains the length of the ApRequestNew object which follows the ApNewSearch transaction down the pipe. Apdsptch forwards this transaction 5 to apinter when it is received from the user interface. Additionally, apdsptch initiates this transaction when its timer thread determines that a requested search was never successfully submiKed to apinter. In either case, an ApRequestNew object follows the transaction down the pipe. Aplnter sends the transaction to apdsptch with the Length field containing the length of an 10 ApRequestNew object that follows the transaction down the pipe. The transaction object is forwarded from apdsptch to the user interface if the request was initiated by the user interface. The Length field is always zero and the ErrorCode field indicates any error. No ApRequestNew object is sent back to the user interface. If the request was initiated from apdsptch, no 1~ transaction is forwarded to the user interface.
The default configuration file for apinter is apinter.cfg and identifies the communication port and parameters used when communicating with the adjunct processors 25. Apinter.cfg also indicates the name of the server, if any, to ap-inter on which apdsptch will run. The parameters of apinter.cfg 20 and their acceptable values are:
C(:)MPORT The number of the asynchronous communications port.
Default value is 1.
BAlJDR~TE Baud rate (30, 1200, 2400, 4800, 9600). Default setting is 4800.
DATA The number of data bits (7 or 8). Default value is 8.
STOP The number of stop bits (O = 1 stop bit, 1--1 . 5 bits, 2 = 2 bits). Default setting is O (1 stop bit).
PARITY Type of parity (None, odd, even, mark, space). Default sett;ng is none.
SERVER The name of the server on which apdsptch is running. If this is a non-network configuration of the present invention, then all programs run on a single workstation and this parameter is omitted.
The default configuration file for the user interface process is callsrch.cfg and includes the following parameters:
LPATH The path to the directory containing the cstrack and callsrch.loc files. If LPATH is not specified, cs will look for these files in the current working directory.
SERVER The name of the server on which apdsptch is running.
This parameter is omitted in a single workstation environment where all programs run on the single workstation.
W O 97/12473 PCThUS96/15491 The default configuration file for apdsptch is apdsptch.cfg and includes the following parameters:
RANGEn POLLlNTERVALn These parameters, specified in pairs, determine the frequency with which the first operating system network is automatically polled for the results of an individual call search. Searches less than RANGE1 seconds old are polled every POLLINTERVAL1 seconds; those less than RANGE2 seconds old are polled every POLLINTERVAL2 seconds; all other searches are polled every POLLINTERVAL3 seconds.
EXPIREDAYS The number of days after which searches will be automatically deleted from the tracking file ~cstrack). ~eleted results cannot be retrieved.
While the present invention has been described in connection with the illustrated embodiments, it will t~e appreciated and understood that modifications may be made without departing from the true spirit and scope of the invention.
Claims (23)
1. Cancelled.
2. Cancelled.
3. Cancelled.
4. Cancelled
5. Cancelled.
6. Cancelled.
7. Cancelled.
8. Cancelled.
9. Cancelled.
10. A system for tracing a path of a call through a telecommunications network, the system comprising:
a switch;
an adjunct processor, connected to said switch, having a memory that stores switchcall record data for calls traversing said switch and a search function;
a database that stores call routing data for the telecommunications network, said call routing data including trunk group data;
a parameter input means for inputting call parameter data relating to the path of the call to be traced through the telecommunications network; and a control processor coupled to said parameter input means, said adjunct processor and said database, including, means for activating said search function in said adjunct processor to identify a call record corresponding to said call parameter data, wherein said search function searches in said adjunct processor based on said call parameter data, means for accessing said call routing data stored in said database to obtain a next switch destination for the call, and means for reporting said call record and said next switch destination.
a switch;
an adjunct processor, connected to said switch, having a memory that stores switchcall record data for calls traversing said switch and a search function;
a database that stores call routing data for the telecommunications network, said call routing data including trunk group data;
a parameter input means for inputting call parameter data relating to the path of the call to be traced through the telecommunications network; and a control processor coupled to said parameter input means, said adjunct processor and said database, including, means for activating said search function in said adjunct processor to identify a call record corresponding to said call parameter data, wherein said search function searches in said adjunct processor based on said call parameter data, means for accessing said call routing data stored in said database to obtain a next switch destination for the call, and means for reporting said call record and said next switch destination.
11. The system according to claim 12, wherein said control processor relies on said next switch to continue tracing the call.
12. The system according to claim 11, wherein said parameter input means includes a graphical user interface for accepting said call parameter data.
13. The system according to claim 10, wherein said trunk group data includes originating trunk group, terminating trunk group, originating port and terminating port data, date/time, switch site, call record type, dialed number, automatic number identification data and pretranslated number data for each switch in the telecommunications network.
14. The system according to claim 10, wherein said control processor includes means for identifying said switch based on said call parameter data.
15. The system according to claim 10, wherein said control processor accesses a next switch adjunct processor connected to a next switch at said next switch destination.
16. The system according to claim 10, wherein said switch call record data includes only data relating to said switch.
17. The system according to claim 10, wherein said control processor includes means for identifying a home switch.
18. A method for tracing a path of a call through a telecommunications network, the system comprising a switch, an adjunct processor connected to the switch having a memory that stores switch call record data for calls traversing the switch and a search function, a database that stores call routing data for the telecommunications network, the call routing data including trunk group data, a parameter input means for inputting call parameter data, relating to the path of the call to be traced through the telecommunications network, and a control processor coupled to the parameter input means, the adjunct processor and the database, the control processor including means for activating the search function in the adjunct processor, means for accessing the call routing data stored in the database to obtain a next switch destination for the call, the method comprising the steps of:
(1) inputting the call parameter data into the control processor;
(2) searching the switch call record data in the adjunct processor utilizing the search function and the call parameter data;
(3) searching the call routing data in the database to determine a next switch destination;
(4) searching a next switch call record data stored in a next switch adjunct processor connected to a next switch at the next switch destination; and (5) searching the call routing data in the database and call record data for each remaining switch in the call.
(1) inputting the call parameter data into the control processor;
(2) searching the switch call record data in the adjunct processor utilizing the search function and the call parameter data;
(3) searching the call routing data in the database to determine a next switch destination;
(4) searching a next switch call record data stored in a next switch adjunct processor connected to a next switch at the next switch destination; and (5) searching the call routing data in the database and call record data for each remaining switch in the call.
19. The method according to claim 18, further comprising the step of:
generating report data related to the path through the telecommunications network.
generating report data related to the path through the telecommunications network.
20. The method according to claim 19, further comprising the step of:
displaying the report data at the parameter input means, wherein the parameter input means comprises a user interface device.
displaying the report data at the parameter input means, wherein the parameter input means comprises a user interface device.
21. The method according to claim 18, further comprising the steps of:
transferring the call parameter data to the adjunct processor from the control processor; and generating search results data at the adjunct processor.
transferring the call parameter data to the adjunct processor from the control processor; and generating search results data at the adjunct processor.
22. A method for tracing a path of a call through a telecommunications network, comprising the steps of:
(1) specifying call parameter data for the path of the call;
(2) identifying a switch to be accessed based on the call parameter data;
(3) searching call record data stored in an adjunct processor connected to the switch to identify a switch call record corresponding to the call parameter data, wherein the call record data stored in the adjunct processor includes data for calls traversing the switch;
(4) searching call routing data stored in a database based on the switch call record to determine a next switch through which the call passes, wherein the call routing data includes trunk group data;
(5) searching call record data stored in a next switch adjunct processor connected to the next switch to identify a next switch call record, wherein the call record data stored in the next switch adjunct processor includes data for calls traversing the next switch.
(1) specifying call parameter data for the path of the call;
(2) identifying a switch to be accessed based on the call parameter data;
(3) searching call record data stored in an adjunct processor connected to the switch to identify a switch call record corresponding to the call parameter data, wherein the call record data stored in the adjunct processor includes data for calls traversing the switch;
(4) searching call routing data stored in a database based on the switch call record to determine a next switch through which the call passes, wherein the call routing data includes trunk group data;
(5) searching call record data stored in a next switch adjunct processor connected to the next switch to identify a next switch call record, wherein the call record data stored in the next switch adjunct processor includes data for calls traversing the next switch.
23. A method according to claim 22, comprising the steps of:
searching the call routing data in the database and call record data for each remaining switch in the call.
searching the call routing data in the database and call record data for each remaining switch in the call.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/536,845 US5659604A (en) | 1995-09-29 | 1995-09-29 | System and method for tracing a call through a telecommunications network |
| US08/536,845 | 1995-09-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2233438A1 true CA2233438A1 (en) | 1997-04-03 |
Family
ID=24140161
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002233438A Abandoned CA2233438A1 (en) | 1995-09-29 | 1996-09-27 | System and method for tracing a call through a telecommunications network |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5659604A (en) |
| EP (1) | EP0873636A1 (en) |
| JP (1) | JPH11512905A (en) |
| CA (1) | CA2233438A1 (en) |
| WO (1) | WO1997012473A1 (en) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH09321869A (en) * | 1996-05-31 | 1997-12-12 | Nec Corp | Call information testing method and device therefor |
| US5999616A (en) * | 1998-04-17 | 1999-12-07 | Ameritech Services, Inc. | Method and system for call tracing |
| US5909682A (en) * | 1996-12-30 | 1999-06-01 | Mci Worldcom, Inc. | Real-time device data management for managing access to data in a telecommunication system |
| US6480600B1 (en) | 1997-02-10 | 2002-11-12 | Genesys Telecommunications Laboratories, Inc. | Call and data correspondence in a call-in center employing virtual restructuring for computer telephony integrated functionality |
| US7031442B1 (en) | 1997-02-10 | 2006-04-18 | Genesys Telecommunications Laboratories, Inc. | Methods and apparatus for personal routing in computer-simulated telephony |
| US6104802A (en) | 1997-02-10 | 2000-08-15 | Genesys Telecommunications Laboratories, Inc. | In-band signaling for routing |
| US6009321A (en) * | 1997-07-07 | 1999-12-28 | Northern Telecom Limited | System and method for call tracing |
| US6985943B2 (en) | 1998-09-11 | 2006-01-10 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for extended management of state and interaction of a remote knowledge worker from a contact center |
| US6711611B2 (en) | 1998-09-11 | 2004-03-23 | Genesis Telecommunications Laboratories, Inc. | Method and apparatus for data-linking a mobile knowledge worker to home communication-center infrastructure |
| US5930344A (en) * | 1997-10-14 | 1999-07-27 | At & T Corp. | Method and apparatus for tracing a specific communication |
| USRE46528E1 (en) | 1997-11-14 | 2017-08-29 | Genesys Telecommunications Laboratories, Inc. | Implementation of call-center outbound dialing capability at a telephony network level |
| US6137876A (en) * | 1997-12-04 | 2000-10-24 | Ericsson Inc | Network call trace |
| JPH11205446A (en) * | 1998-01-19 | 1999-07-30 | Fujitsu Ltd | Complaint call processor |
| US7907598B2 (en) | 1998-02-17 | 2011-03-15 | Genesys Telecommunication Laboratories, Inc. | Method for implementing and executing communication center routing strategies represented in extensible markup language |
| US6332154B2 (en) | 1998-09-11 | 2001-12-18 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing media-independent self-help modules within a multimedia communication-center customer interface |
| US6195416B1 (en) * | 1998-03-23 | 2001-02-27 | At&T Corp. | Method to trap a called number in a telecommunications network |
| USRE46153E1 (en) | 1998-09-11 | 2016-09-20 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus enabling voice-based management of state and interaction of a remote knowledge worker in a contact center environment |
| US6321087B1 (en) * | 1999-01-08 | 2001-11-20 | Lucent Technologies Inc. | Monitoring data of a selected call in a wireless telecommunication system |
| DE69937874T2 (en) | 1999-03-27 | 2009-01-08 | Jdsu Deutschland Gmbh | Method and device for searching for a call in a telecommunications network |
| KR100295832B1 (en) | 1999-04-28 | 2001-07-12 | 박종섭 | Message trace method for establishing traffic channel call |
| US7929978B2 (en) | 1999-12-01 | 2011-04-19 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing enhanced communication capability for mobile devices on a virtual private network |
| US7120782B2 (en) * | 2002-01-16 | 2006-10-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods, systems and computer program products for accessing descriptive information associated with a TDMA/GSM switch |
| US7823199B1 (en) | 2004-02-06 | 2010-10-26 | Extreme Networks | Method and system for detecting and preventing access intrusion in a network |
| US7310664B1 (en) | 2004-02-06 | 2007-12-18 | Extreme Networks | Unified, configurable, adaptive, network architecture |
| US7577996B1 (en) * | 2004-02-06 | 2009-08-18 | Extreme Networks | Apparatus, method and system for improving network security |
| US7283619B2 (en) * | 2004-06-15 | 2007-10-16 | Cisco Technology, Inc. | System and method for end-to-end communications tracing |
| US7904067B1 (en) * | 2004-12-15 | 2011-03-08 | Syniverse Icx Corporation | Method and apparatus for enabling call originator to select a notification on a telecommunications device |
| US7376395B2 (en) * | 2005-06-30 | 2008-05-20 | Microsoft Corporation | Controlling a telecommunications device |
| US9008075B2 (en) | 2005-12-22 | 2015-04-14 | Genesys Telecommunications Laboratories, Inc. | System and methods for improving interaction routing performance |
| US8019063B2 (en) * | 2006-08-24 | 2011-09-13 | Verisign, Inc. | System and method for providing high reliability network |
| US20090307304A1 (en) * | 2008-06-10 | 2009-12-10 | International Business Machines Corporation | Method for Server Side Aggregation of Asynchronous, Context - Sensitive Request Operations in an Application Server Environment |
| CN102281368A (en) * | 2010-06-12 | 2011-12-14 | 环旭电子股份有限公司 | Network voice exchange system and voice packet routing method |
| US9491282B1 (en) * | 2015-05-13 | 2016-11-08 | Cisco Technology, Inc. | End-to-end call tracing |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4464543A (en) * | 1982-12-01 | 1984-08-07 | Gte Business Communication Systems Inc. | Network control center call trace |
-
1995
- 1995-09-29 US US08/536,845 patent/US5659604A/en not_active Expired - Lifetime
-
1996
- 1996-09-27 EP EP96933922A patent/EP0873636A1/en not_active Withdrawn
- 1996-09-27 CA CA002233438A patent/CA2233438A1/en not_active Abandoned
- 1996-09-27 WO PCT/US1996/015491 patent/WO1997012473A1/en not_active Application Discontinuation
- 1996-09-27 JP JP9513662A patent/JPH11512905A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| WO1997012473A1 (en) | 1997-04-03 |
| JPH11512905A (en) | 1999-11-02 |
| EP0873636A1 (en) | 1998-10-28 |
| US5659604A (en) | 1997-08-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5659604A (en) | System and method for tracing a call through a telecommunications network | |
| WO1997012473A9 (en) | System and method for tracing a call through a telecommunications network | |
| US5793853A (en) | System and method for recording billing information for a telecommunications service request | |
| US6013107A (en) | Dynamic mapping of user id into TCP/IP address without user interaction as user signing on or singing off among workstations | |
| US5315705A (en) | Communication address management system | |
| CN1174460A (en) | System and method for selecting agent destinations and monitoring calls made to nvetwork customer | |
| US20080037524A1 (en) | Remote Control Telephone Dialing System and Method | |
| US6125108A (en) | Method and system for enhanced client identification | |
| KR100331468B1 (en) | method for translation type mapping in No.7 gateway signaling network | |
| US6697481B2 (en) | Call center system, method for receiving call, and a computer program thereof | |
| US7177302B2 (en) | System and method for transferring connecting configurations from a telephone network to a data network | |
| KR20020013240A (en) | The method of Internet telephony service using name that resembles telephone number | |
| US7599912B2 (en) | Structured query language (SQL) query via common object request broker architecture (CORBA) interface | |
| JP3505698B2 (en) | Information management device | |
| KR100489169B1 (en) | Credit status checking system for transaction processing system and checking method therefor | |
| JP3351390B2 (en) | Incoming call sorting device, call center system, and storage medium storing private branch exchange control program | |
| JP2002165013A (en) | Service control system, service control method and its recording medium | |
| MXPA98002382A (en) | System and method for tracking a call through a telecommunication network | |
| AU3087800A (en) | Subscription handler interface between a customer administrative system and database network elements of communications network | |
| JPH03101470A (en) | Service system | |
| JPH04370870A (en) | Multi-host log-on control system | |
| JPH0773193A (en) | Data base retrieving system | |
| JP3702205B2 (en) | Multiple interface management method and apparatus for facility operation | |
| JP3889638B2 (en) | Information processing apparatus and recording medium | |
| KR100380410B1 (en) | Apparatus for Call trace on communication service and method thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |