A customer recently ask why the Call Log times differ from the Agent Activity times. The particular system is used for predictive dialing, and agents are connected via virtual extensions to another PBX. The extensions are set for auto-answer, but the agents are not pre-connected to Teleplex.
The tTotal field in the Call Log table is the total call duration in seconds from the time that the call was answered until the call has been completely released. The following should be noted:
- A dialer call can be connected to a customer for up to two seconds before it is transferred to an agent. (This is part of the prediction algorithm, and if no agent is available after two seconds the call will be abandoned.)
- tTotal also includes the time required to connect the customer side of the call to the agent. Transfer of a pre-connected call is instantaneous, whereas in this case, a new call must be made each time. This call setup requires a few hundred milliseconds.
The tTalk field in Call Log is the time that an agent is actually talking to the customer, and excludes hold time.
The Agent Activity table contains a number of fields such as “BusyACD”, and “BusyOutbound”. These fields contain agent state times, and are distinct from call times in the Call Log.
For dialer calls, the flow and timings are as follows:
- When the dialer has a call for an agent, Teleplex automatically puts the agent into the “busy outbound” state.
- Next, Teleplex calls the agent. As mentioned above, this requires a few hundred milliseconds, during which time tTotal and BuyOutbound are increasing.
- If the application does not answer the call immediately (e.g., it first accesses a database), tTotal and the BusyOutbound values will increase, but not the tTalk value because the agent cannot talk yet. (For maximum performance and minimum delay, applications should use Teleplex’s screen pop feature to pre-fetch the required customer data in advance of making the call.)
- When the application answers the call Teleplex connects the customer to the agent, thus beginning the tTalk period.
Agent State times are therefore never equal to the tTotal or tTalk times. The tTalk values should be close to the agent state times, but will always be slightly less because they indicate entirely different things.
Note: As of Teleplex 3.64, various times in the Call Log table are now stored as floating point values. Therefore, some of the values will now be closer to the Agent Activity values, but as mentioned above will never be exactly the same.
If you want to disable Caller ID display for outbound calls you can create an LCR rule as illustrated in the screen below. This example is for NTT (Japan):
When a digit string (“[0-9]“) of length 9 to 11 digits (“{9,11}”) is dialed for a regular outbound call, Teleplex adds “184″ to the original dialed number. This enables NTT’s “iyayo” feature, which suppresses Caller ID display for the current call. (“Iyayo” is a word play on an alternate pronunciation of 1-8-4 that roughly means “That’s gross. No way!”) . To enable this behavior for Predictive Dialer calls, you must also enable “Use LCR” in the Campaign Manager screen for campaigns where you wish to apply this behavior.
For other countries you can achieve the same thing by adjusting the the Dial Pattern and the “Translates To” settings. To block Caller ID In the United States, first dial “*67″ (instead of “184″ above). Similarly, to block Caller ID in the United Kingdom and Ireland, first dial “141″.
A good reason for wanting to block the Caller ID on outbound system is so people won’t call back into a predictive dialer line. However, In the United States (and perhaps other places) it is illegal for telemarketers to block or provide false Caller ID information. Therefore, a better way of dealing with this is to set the “Display Address” in the LCR setting to so that the Caller ID shows the number of your inbound lines.
For more information on LCR rules, please refer to the “Teleplex System Manager Guide“.
A change to the Windows TCP/IP stack (actually, a complete rewrite) breaks some IPv4 Multicast application including TPXMDIView on Windows Vista and Windows 2008.
The default address used by Teleplex and TPXMDIView is “225.0.0.1″. Apparently, the system ignores multicast packets where the lowest part of the address is “1″. In fact, you can’t even see the packets with Wireshark (Ethereal).
However, if you change the multicast address to any other valid, non-reserved multicast address, it works.
We have changed the default multicast address in Teleplex and TPXMDIView to “225.0.0.225″. However, if you want to use TPXMDIView in an existing installation on one or more Vista systems, you must change the current settings in Teleplex and all of the client machines that run TPXMDIView so that they match. Also, if you have a router for a multi-subnet LAN and must pass TPXMDIData between subnets, you must enable Multicast pass-through fon the router or the new address.
Why this is so is still under investigation.
Many of our customers use Microsoft SQL Server, and recently, we have been using Microsoft SQL Server 2005 Express at sites where the advanced features of the full product are not required. The Express edition is great for IVR systems, small call centers, and for small web sites, but it also has some limitations including (1) it will never use more than 1GB of memory, and (2) the maximum database size is 4GB. (The maximum database size was increased to 10GB in SQL Server Express 2008 R2.)
Generally speaking, these limitations have no effect on us because the main thing that we do is save call detail and agent activity data. (The database isn’t used for processing millions of online orders, so we don’t need petabyte databases with hyper-performance.) However, the question “What happens if the database fills up?” sometimes arises, and the related question “How big is my database now?”
The answer to the first question is:
- Teleplex will keep running, and will write the data to a text file (provided that the disk isn’t actually full), and
- You will start getting supervisory Alerts, along with error messages like this:
| 2008-06-29,17:36:22.805,ERROR. In CDBObject::Process() for Call Log from LogCall-1: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not allocate space for object ‘dbo.CallLog’.'PK_CallLog’ in database ‘Teleplex’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.> [42000], NativeError=1105. |
The portion shown in yellow is from SQL Server, and the “NativeError” is the actual SQL Server error code.
The answer to the second question can be found by one of the following methods:
- In Microsoft SQL Server Management Studio (“SSMS”) right-click on the database in question to reveal its properties. On the “General” property page you can see the “Size” and the “Space Available”. The Size is the allocated size on disk, which is not necessarily how much space is actually in use inside the database. Space Available indicates the amount of free space within the allocated space, not within the maximum space allowed. Therefore, these numbers do not necessarily show whether you have hit the 4GB limit or not because the allocated size might show 4GB, but there might actually be unused space within that 4GB. (Of course, you are probably reading this article because you are running out of space.)Furthermore, SSMS seems to display the sum of sizes of the “.MDF” (Master Data File) and “.LDF” (transaction log) files (which is confusing), so the magic number you are really looking for is a total Size of around 5GB.
- Look directly at the size of “.MDF” file. With a default installation, data files will be in “C:\Program Files\Micrsoft SQL Server\MSSQL.1\MSSQL\Data”. If the “.MDF” file is around 4GB, you are probably near the limit.
Note that in the SSMS Database Properties “Files” page, you can also see under the “Autogrowth” column how the database is configured to grow. The default settings allows a database to grow automatically to an unlimited size (although the Express server, as mentioned, has a maximum limit of 4GB). You may want to confirm that someone didn’t actually limit the size. (If so, you can change the configuration by clicking on the button in the Autogrowth column.)
When the database appears to be full, you should do the following:
- Check the obvious: Are you actually almost out of disk space? If so, delete some unnecessary files. You can probably quickly free up some disk space by deleting the contents of the Teleplex “Logs” subdirectory, deleting Internet Explorer temporary files, and by deleting files in any of your “temp” directories.
- If you still have plenty of disk space, check the database size as described above. If you are nearing your configured limit, increase the limit.
- If, however, you have reached the 4GB limit of SQL Server Express, you have no choice but to delete some old data (or upgrade to the full version of SQL Server). You easily delete old data from the “Manage Database” screen in Teleplex, and probably the best place to start is with the Call Log, which will get you back to a normal running state in short order.
Of course you should always do the following anway:
- Make regular backups.
- Monitor your disk space.
- Delete old data.
- If you are low on disk space, use SMSS to shrink the database (or use the DBCC SHRINKDATABASE command). You might also want to consider moving the database to a larger drive or partition.
What do the error messages “Unable to accept call in the current state” and “Unable to answer call in the current state” mean?
There are three computers involved: The PSTN-side switch (i.e., the telephone company), the CPU on the Dialogic ISDN board inside the Teleplex server, and the CPU running Teleplex.
A simplified typical inbound call flow is shown below.
| PSTN |
ISDN Board |
Teleplex |
| (1) Set ISDN Setup message (“here is a new call”) |
|
|
| |
(2) Catch the Setup message, send to the application. |
|
| |
|
(3) Catch the Setup message. |
| |
|
(4) If we want to handle the call, send Accept message, otherwise reject it with a Disconnect message. |
| |
(5) Catch Accept message, send to PSTN. |
|
| (6) Catch Accept message. |
|
|
| |
|
(7) Send Answer message. |
| |
(8) Catch Answer message, send to PSTN. |
|
|
(9) Connect calls.
|
The tricky part, and the source of the error occurs in the middle column. Suppose, for example, that the caller hangs up sometime during steps (3) or (4). (This really means, because everything is so fast, that the caller dialed the number and immediately hung up-even before the first ring.) The board knows that the caller wants to disconnect, and may have even informed the Dialogic driver. However, Teleplex is still waiting, in parallel, for the Accept function to return. So when the Accept message arrives at the board from the application in Step (5), the board says “No silly!! Unable to accept call in the current state”. (Sorry. How was I to know?)
On the Teleplex-side, the function to Accept the call returns an error code, and Teleplex displays an error message.
You can ignore these “error” messages, which are not really errors at all.
Finally, we changed Teleplex from Version 3.51.0.8 so it will display an informational rather than an error for this case.
Teleplex CallBrowser installation is straightforward, but can be tedious if you are installing it on a large number of machines in a call center.
To simplify this, you can pass a number of default settings to use in CallBrowser’s login profiles via Setup.exe’s command line. Possible parameters are:
- SERVER=teleplex_server. Sets the default Teleplex server name or IP address.
- EXTENSION=extension_number. Sets the extension number to use.
- PROTOCOL=protocol_name. Sets the RPC (Remote Procedure Call) protocol to use, This is typically “ncacn_ip_tcp”, indicating TCP/IP protocol.
- ENDPOINT=endpoint. This is a protocol-specific parameter. For “ncacn_ip_tcp”, you typically set the endpoint to “7100”, which is a TCP/IP port.
- FTPPROFILENAME=profile_name. Call Centers typically set up the ACDs and Dialer campaigns agents can login to in single data file, so the possibilities don’t need to be set on every machine. This parameter sets the name of the file containing those profiles.
- FTPPROFILESERVER=ftp_server. If you are loading login profiles from an FTP server this specifies
the name or IP address of the FTP server.
The best way to use these command lines settings is to create a batch file in a shared directory, and run Setup.exe from the batch file. The batch file might contain a line something like this (the line is split below for readability):
Setup SERVER=Teleplex1
EXTENSION=Site.%1
PROTOCOL=ncacn_ip_tcp
ENDPOINT=7100 FTPPROFILENAME=Profiles.dat
FTPPROFILESERVER=ftpserver
Notice the “%1”. This is a parameter to the batch file itself, and should be set to the extension number. If the batch file name is, for example, “go.bat”, you would install CallBrowser for the machine at extension “2703” with the following command:
\\share\go 2703
You can then quickly finish the installation simply by pressing Enter several times.