Article ID: 51204 - Last Review: October 31, 2013
![]()
IQ ports should be programmed on the same Gateway as the Queues
When a call is transferred from a port on one gateway to a queue on a second gateway, some call details are lost due to a MiTAI limitation. Most commonly we see ANI and DNIS being changed. In order to prevent this, it is recommended to have the IQ Ports and Queues on the same Gateway.
INFORMATION
Here are the best practices for the configuration of Screenpop.Enabling prairieFyre MiTAI event logging
If enabled, the prairieFyre Enterprise service will log every single MiTAI event that it receives from the collector service. Events are logged in the DataDirectory\ CallControlEventLog sub-folder under the main installation directory. The main advantage of these logs is that the Enterprise service logs all events across all nodes on one file, and the events are also timestamped based on arrival time. This helps immensely in troubleshooting MiTAI linking issues. In this file, the call details that arrive from IQ also get logged, e.g. the ANI, DNIS, VerifiedCollectedDigits or other custom fields. To enable this log:- Browse to the Services\EnterpriseServer subfolder under the CCM installation directory
- Open the file prairieFyre.Services.EnterpriseServer.exe.config in a text editor
- Find the key LogCallTrackingMiTAIEvents. If not present, create it. Set its value to true. The config line would look like:
<add key="LogCallTrackingMiTAIEvents" value="true" />
- Verify that there is a DataDirectory\CallControlEventLog folder with MiTAIEvents*.txt in it. Here is an example of what the events would look like:
All relevant devices must be programmed successfully monitored
This includes queues and extensions (or hotdesking agents in a hotdesking or resilient environment). These devices should be either Telephone System Synchronized or manually programmed if there were synchronization problems. The Advanced Realtime option must be turned on, for otherwise the system will not set MiTAI monitors on them. Even if the devices are all programmed correctly, we must also ensure that monitors were successfully set. The best place to verify this is in the prairieFyre collector service logs, ensuring there are no MiTAI errors (SXERR_* type of errors). The main point is that badly configured devices and/or the absence of monitors result in missing MiTAI events, which in turn means that the MiTAI linker might not able to link IQ port events with path events and agent events, resulting in missing data and no screenpops.- Note: On the IQ side, ports must all be configured and monitored properly. Problems due to IQ port monitoring are more apparent than screenpop; the call flow would not execute properly
IQ ports should not be programmed as regular voice extensions
IQ ports get automatically written into the CCM database by the IQ messaging service as special extensions, mainly for smart choice layer and exit code reporting purposes. If programmed manually – using the website or the YSE – and enabled for real-time and advanced real-time monitoring, the MiTAI linker will produce linking errors and as such screenpop will not produce correct results, esp. in a network ACD environment.IQ ports should be programmed on the same Gateway as the Queues
When a call is transferred from a port on one gateway to a queue on a second gateway, some call details are lost due to a MiTAI limitation. Most commonly we see ANI and DNIS being changed. In order to prevent this, it is recommended to have the IQ Ports and Queues on the same Gateway.
What to do when UPiQ and/or callbacks are present?
As far as screenpop, and in order to reduce the MiTAI linking overhead, it is best for MiTAI events arriving on UPiQ ports and callback capture ports be ignored. Here is how the MiTAI linker in the Enterprise service ignores UPiQ and callback capture ports:- Browse to the Services\EnterpriseServer subfolder under the CCM installation directory
- Open the file prairieFyre.Services.EnterpriseServer.exe.config in a text editor
- Find the key named MitaiLinkerPortIgnoreList. If not present, add it. Set its value to a comma delimited list of ports or port ranges. Example:
<add key="MitaiLinkerPortIgnoreList" value="2230 , 2250-2260, 2270" />
DNIS Linkage
Preserving the dialed digits is necessary when Screenpop is configured to utilize the DNIS field when popping. In many situations, esp. in a clustered Network ACD environment, the MiTAI events that arrive on the path (PathRequestACD) and on the end device (CallReceived events) may not have the original dialed digits. The best place where the dialed digits are obtained is when captured at the IQ port. In order for the system to preserve those and not replace them, it is recommended that the DNIS be programmed in the CCM databaseTime spent in the IVR
In a high load environment where the system processes thousands of calls per hour, MiTAI call IDs recycle very fast, sometimes in a matter of minutes. It is important that the MiTAI linker not keep track of stale calls and to dispose them ASAP. Once such way is to configure the time a call spends in IQ (or any IVR) before it gets transferred to a path or an end device. For example, if the IVR call flow is a simple one where callers typically spend no more than, say, 2 minutes before they are transferred, then it would be a good idea to have the MiTAI linker dispose such stale calls within 3 minutes. Here is how to do it:- Browse to the Services\EnterpriseServer subfolder under the CCM installation directory
- Open the file prairieFyre.Services.EnterpriseServer.exe.config in a text editor
- Find the key named MitaiLinkerMaxTimeInSecsInIVRBeforeRouting. If not present, add it. Set its value to the desired time in seconds. The config line would look like:
<add key="MitaiLinkerMaxTimeInSecsInIVRBeforeRouting" value="180" />
Time until the MiTAI linker disposes a finished call from its memory
This is just another option that would allow the system to recycle calls faster. If there are no special requirements (e.g. a pro-serv component that taps into the call long after it finishes), there is no need for the system to keep tracking calls for longer than 15 seconds after they are finished. Here is how to configure this option:- Browse to the Services\EnterpriseServer subfolder under the CCM installation directory
- Open the file prairieFyre.Services.EnterpriseServer.exe.config in a text editor
- Find the key named MitaiLinkerMaxTimeInSecsToRecycleAfterCallCleared. If not present, add it. Set its value to the desired time in seconds. Example
<add key="MitaiLinkerMaxTimeInSecsToRecycleAfterCallCleared" value="15" />
Required fields on the client to prevent blank or duplicate pop-ups
In many cases, esp. in a clustered network environment, screenpop would be configured to pop on more than just one field. A field in this context is one of PFANI, PFDNIS, PFCollectedDigits, PFVerifiedCollectedDigits, or any other custom field. Due to a) the speed at which the PBXs deliver events (agent controllers are typically faster machines than queuing gateways), and b) the order in which the events arrive, the MiTAI linker in the Enterpise service may not have yet received and linked all required events at the time when a call rings at an end device. This means that the client would receive the necessary data in more than one batch. In order for the client to not invoke Screenpop with incomplete data which would end in blank pop-ups, one can configure a list of ‘required’ fields. Here is how to do it:- On the client machine, browse to the Applications\ContactCenterClient sub-folder under the client installation directory
- Edit the file ContactCenterClient.exe.config in a text editor
- Find the key WebPopRequires. If not present, add it. Set its value to a comma delimited list of fields. This ensures that the the Screenpop application (or URL) will not be invoked until all fields arrive. The fields are not case sensitive. Here is an example of how that config line would look like:
<add key="WebPopRequires" value="PFDNIS, PFVERIFIEDCOLLECTEDDIGITS"/>