BANANA is a stand-alone application that runs on the Cisco Unity Bridge server. It is designed to assist with monitoring and troubleshooting of analog communication between the Bridge and other Octel nodes in the analog network. It also provides detail and summary information of call activity. BANANA contains an administration application called the BANANA admin that allows you to control how BANANA:

Extracts information from the call traces on the Bridge server and presents different views of the data.

Monitors the call logs for error conditions and logs warnings or errors to the Windows Event Viewer.

Generates test calls to any of the Octel systems that are networked with the Bridge server.

With the BANANA admin, you can also install and configure the BANANA service to do any or all of the above tasks at configurable intervals.

System Requirements

For full BANANA admin and service features

Install BANANA on a Cisco Unity Bridge server that meets the following requirements:

Software

Windows 2000 Server with Service Pack 3 or later.

Cisco Unity Bridge version 3.0(1) or later.

Hardware

Approved Cisco Unity Bridge server – see Cisco Unity Bridge 3.0 System Requirements, and Supported Hardware and Software.

Allow for up to 1 GB free HDD space on the drive on which BANANA will be installed.

For limited BANANA functionality

When only needed for processing and viewing of starfish log data (see Using BANANA on a non-Bridge server), install BANANA on a server that meets the following requirements:

Software

Windows 2000 Server with Service Pack 3 or later.

Hardware

Allow for up to 1 GB free HDD space on the drive on which BANANA will be installed.

Configure the Bridge call tracing level

BANANA uses the Bridge analog call traces (also referred to as ‘starfish’ logs, or ‘sf’ logs) as the source for all call and error information processing. In order for BANANA to work properly, the Bridge analog call tracing level must be set to Verbose in the System Settings page of the Cisco Unity Bridge Administration. Before using BANANA, follow these steps:

Start the Cisco Unity Bridge Administration on the Bridge server.
Select System Settings from the menu.
Set the Call Tracing Level to Verbose.
Click Save to update the setting.

Note: Upon startup of the BANANA admin or the BANANA service, if a call tracing level other than Verbose is detected, BANANA will update the Bridge call tracing level and notify you that it has done so. If the Bridge Administration System Settings page is open when BANANA attempts to update the call tracing level, the process may not succeed.

Install the BANANA administration application

Extract the BANANA installation package to a temporary folder on the Bridge server.
Disable the Cisco Security Agent if running.
Disable any anti-virus application.
Run BANANA setup.exe.
Click OK at the welcome screen.
If desired, change the directory where BANANA will be installed.
Click the large installation button.
If desired, change the program group where BANANA will appear.
Click Continue.
If prompted with the option to keep a file newer than that being copied, keep the existing file.
When installation has completed, click OK.
Enable the Cisco Security Agent if you disabled it.
Enable anti-virus application if you disabled it.

The BANANA Interface

Figure 1 BANANA admin main interface

Figure 2 BANANA options interfaces

Figure 3 BANANA data grids

Configure folder locations

Before BANANA can perform any processing a number of folder settings need to be configured.

Log Location (1)

Type in, or browse to, the folder where the Bridge analog call traces are stored. If the Bridge software was installed using the default parameters this will be the d:\bridge\starfish\log folder. This folder can be identified by the presence of files whose names begin with SFLOG.

An invalid Log Location (1) will be detected and reported when attempting to process call data, install the BANANA service or start the BANANA service. You will be prompted to update this setting and will not be allowed to proceed with the requested action until valid starfish log files are detected in the selected folder. If the folder currently specified does not exist when BANANA admin starts, the path will be cleared and you will be prompted to update the path.

Output Folder (2)

This is the folder where BANANA will generate activity logs and CSV files. You can choose any folder for this purpose. All CSV files—either requested manually via the BANANA admin or generated automatically by the BANANA service—will be written to the selected folder. Activity logs from BANANA admin (BANANAadmin_Log*) and the BANANA service (BANANAservice_Log*) will be written to a \logs subfolder in the selected folder.

An invalid Output folder (2) will be detected and reported when attempting to process call data, install the BANANA service or start the BANANA service. You will be prompted to update this setting and will not be allowed to proceed with the requested action until the specified folder is confirmed to exist. If the folder currently specified does not exist when BANANA admin starts, the path will be set to the \output folder in the folder where BANANA is installed. After changing the output folder, the BANANA admin must be exited before the new output location takes effect.

The BANANA service

Optionally, you can install and configure the BANANA service, which performs tasks automatically based on intervals that you define. You can configure the BANANA service to automatically process call data, log excessive communication problems to the Event Viewer, and generate tests calls. The BANANA service performs these activities whether or not anyone is logged on to the Bridge server and resumes processing automatically if the server is rebooted.

Installation of the BANANA service is not required if you intend to initiate all processing requests manually.

Once the BANANA service has been installed, you can configure the settings for the service. These settings allow you to specify how often automatic processing of call and error activity will occur, including notification to the Event Viewer of warning and error threshold violations. Also, if desired, you can specify an interval at which the BANANA service places test calls to all configured Octel nodes.

The BANANA service runs as a separate process from the BANANA admin. But they both do the same processing tasks, the only difference being that processing executed by the BANANA admin is done on request and processing executed by the BANANA service is done automatically based on the configured intervals. The BANANA admin and service share the configuration settings and data stored in the BANANA database (bdgdata.mdb).

Install the BANANA service

Install Service (6)

Click on the Install Service button to install the BANANA service. After a moment, you will receive a message box indicating the service has been successfully (or unsuccessfully) installed. Once installed, the Install Service button will be disabled, and the Uninstall Service and Start Service buttons will be enabled.

Configure the BANANA service

Processing Interval (10)

Select the interval, in minutes, at which automatic processing should occur. You can select a value using the drop-down, or enter a value between 15 and 1440. This parameter cannot be modified when the service is running.

At each interval, the following will occur:

New activity since the last processing cycle will be processed and updated in the BANANA database.

Three CSV files will be created in the specified output folder (2). These files contain call and error activity for the specified retention period (12), activity summary statistics broken down per-analog-line, and activity summary statistics broken down per-Octel-Node. The previous versions of this CSV data will be overwritten.

Communication errors will be calculated per-Octel-Node for the specified monitoring period (34). Warning and/or Error messages will be logged to the Windows Event Viewer on the Bridge server as specified (32, 33).

Processing activity will be recorded in the BANANAservice_Log* in the \logs subfolder of the specified output folder (2).

Test Call Interval (11)

Select the interval, in hours, at which automatic generation of test calls should occur. You can select a value using the drop-down, or enter a value between 1 and 336.

If you wish this feature to be active, the check box for this field must be selected. Unselecting the check box indicates you do not want test calls automatically generated. This parameter cannot be modified when the service is running.

At each interval, the following will occur:

BANANA will add a mailbox entry of ‘9999999999’ in the Bridge directory for each configured Octel Node. When the administrative cycle¹ for each Octel Node occurs, the Bridge will attempt to retrieve name information for mailbox ‘9999999999’. Failure to receive name information for this mailbox is expected, but this will exercise a sufficient number of Octel analog networking stages to ensure communication between the Bridge and the Octel node is functioning properly. If the call terminates for any reason other than failure to retrieve the name info, the error will be captured in the BANANA database just as it would for any other communication error, and the retrieval will be reattempted.

Processing activity will be recorded in the BANANAservice_Log* in the \logs subfolder of the specified output folder (2).

¹Depending on the Administrative delivery schedule configured for each Octel Node in the Bridge administrator, the test calls may or may not begin immediately upon scheduling. If the test calls are not being placed when expected, check the Administrative delivery schedule configured for each Octel Node in the Bridge administrator.

Starting and stopping the service

Start Service (8)

Click on this button to start the BANANA service.

Stop Service (9)

Click on this button to stop the BANANA service.

Notes about the BANANA service:

To avoid database conflicts, the BANANA service suspends processing when the BANANA admin interface is running You must exit the BANANA admin interface in order for automatic processing of call activity to be executed by the BANANA service. If the service detects that the BANANA admin is running, it will skip the processing interval and wait for the next one.

If enabled, the BANANA service will initiate test calls at the specified interval regardless of whether the BANANA admin is running.

When the BANANA service is running, you are not allowed to modify the service processing interval or test call interval. To modify these settings, stop the BANANA service.

The BANANA service appears in the Windows Services Control Panel as “BANANAservice.exe”. It can be stopped and started from there if desired.

Uninstalling the service

Uninstall Service (7)

The BANANA service must be stopped prior to uninstalling it via the BANANA admin. Click on the Uninstall Service button to uninstall the BANANA service. After a moment, you will receive a message box indicating the service has been successfully (or unsuccessfully) uninstalled. Once uninstalled, the Uninstall Service and Start Service buttons will be disabled, and the Install Service button will be enabled.

If the Windows Services Control Panel is running when the BANANA service is uninstalled, “BANANAservice.exe” may still appear in the services list in a disabled state. Once the Services panel is closed and reopened “BANANAservice.exe” will no longer display.

The BANANA service does not need to be stopped/uninstalled prior to uninstalling the BANANA admin as long as the uninstall is initiated via the Windows Start Menu BANANA uninstall option. See Uninstalling the BANANA administration application.

Event Viewer Notification (25)

Each time call activity is processed from the starfish logs to the BANANA database—whether done manually via a BANANA admin request or automatically via the BANANA service—the number of communication errors that have occurred are calculated per Octel node, and for the most recent tracking period (34) as specified. This allows monitoring of the Event Viewer for indication of problematic communication with a particular node. This allows such situations to be identified and investigated before they become an end-user-impacting situation.

Warning Threshold (32)

Select a value using the drop-down, or enter a value between 1 and 99. If communication errors equal to or greater than this number (but less than the Error Threshold) occur between the Bridge and an Octel node within the most recent monitoring period (34), then a Warning similar to the following will be generated in the Windows Event Viewer:

Event Type: Warning

Event Source: BANANA Service

Event Category:BANANA status

Event ID: 6

Date: <date>

Time: <time>

User: N/A

Computer: <Bridge server name>

Description:

Communication errors equal to or in excess of the Warning threshold have occurred on calls with the following Octel node serial number: <serial number>

In the above example, the event was generated due to automatic processing by the BANANA service (i.e., the Event Source is “BANANA Service”). Had it been generated due to a manual request via the BANANA admin, the Event Source would be reported as “BANANA Admin”.

Error Threshold (33)

Select a value using the drop-down, or enter a value between 1 and 99. If communication errors equal to or greater than this number occur between the Bridge and an Octel node within the most recent monitoring period (34), then an Error similar to the following will be generated in the Windows Event Viewer:

Event Type: Error

Event Source: BANANA Service

Event Category:BANANA status

Event ID: 6

Date: <date>

Time: <time>

User: N/A

Computer: <Bridge server name>

Description:

Communication errors equal to or in excess of the Error threshold have occurred on calls with the following Octel node serial number: <serial number>

Communication Error Monitoring Period (34)

Select the period (in hours) for which the Warning and Error threshold violations should be calculated. Use the drop-down, or enter a value between 1 and 336. For example, if configured for 6 hours, only communication errors occurring within the last 6 hours between the Bridge and an Octel node will count towards the threshold.

Notes:

These settings are effective at the next processing cycle of either the BANANA admin or the BANANA service.

The monitoring period is the rolling most recent period of specified length. If a problem resulting in these Event Viewer events is resolved, the events will continue to be logged at each processing period until the number of occurrences within the specified monitoring interval falls below the threshold. To reset the count for a particular Octel node, see Resetting communication error counts.

Calls whose failure occurs prior to allowing identification of the Octel Serial number will be logged with Octel Serial Number of ”Unknown”.

There may be situations where analog communication between the Bridge and one or more Octel nodes are known to be consistently problematic. When this occurs, it is handy to have a mechanism the known problematic node(s) from test call generation and/or Event Viewer threshold violation notification. BANANA allows an easy way to maintain a list of specified nodes to exclude from either of these activities.

Configure the Octel nodes to Include/Exclude from Warning/Error threshold violation Event Viewer messages (35, 36)

In the Include Node Serial Numbers and Exclude Node Serial Numbers panes you are presented with all serial numbers of Octel Nodes configured on the Bridge server, including a selection of “Unknown” for handling of calls where the Octel serial number can not be identified. On occasion, you may have reason to exclude particular serial numbers from the reporting of communication problem threshold violations to the Event Viewer.

To move selected serial numbers from one list to the other, perform any of the following:

Highlight the desired selection(s) and click the applicable single-arrow key

Highlight the desired selection(s) and press the Enter key

Highlight the desired selection(s) and double-click the mouse pointer

Click on the applicable double-arrow key to move all entries in one pane to the other

When call data processing occurs, whether manually via the BANANA admin or automatically via the BANANA service, any node serial number listed in the Exclude Node Serial Numbers pane will not have an Event Viewer warning or error generated whether or not it falls above the configured warning or error threshold for the period.

Configure data retention period for call and error activity

BANANA stores all necessary data in its bdgdata.mdb database. Although the starfish logs from which this data is extracted are retained by the Bridge for only 24 hours, as long as BANANA processes the starfish log data—either manually or automatically—at least once per 24 hours, it will retain the data for up to 14 days (configurable to the hour).

Data Retention Period (12)

Select the period, in hours, for which call and error activity should be retained. Use the drop-down, or enter a value between 1 and 336.

! Important note regarding BANANA performance:

Processing of log and database information can be very resource intensive. On Bridge servers with heavy call traffic, you may want to limit your data retention period to ease the amount of processing that takes place, and to limit the amount of space consumed by the bdgdata.mdb database. Examples of recommended settings are:

For a 24 port Bridge server processing at full analog capacity 24 hours per day, set the retention period to 96 hours or less.

For a 24 port Bridge server processing at full analog capacity 12 hours per day, set the retention period to 192 hours or less.

These are just examples, and surpassing these recommendations will not necessarily result in processing difficulties for BANANA or the Bridge. But considering these recommendations will help to keep BANANA and the Bridge performing efficiently.

To prevent inadvertent setting of a retention period that could result in excessive storage or processing issues, BANANA’s maximum Data Retention Period of 336 hours prohibits processing data more than 14 days old. But on occasion you may have a need to use BANANA for analyzing logs from a month ago, a year ago, etc. A mechanism is implemented for doing this using the following steps:

1. In BANANAadmin, run the Options > Purge Event Data selection from the tool menu. This clears any newer data that would prevent older data from being processed.

2. Set the Hours of data to retain in the database value to the desired number of hours, up to a maximum of 43800 (5 years).

3. Enter Ctrl + D from the keyboard immediately before moving to the next selection.

4. Click on Process Call Data to process the data.

Each time the Hours of data to retain in the database control is selected, a value of 336 or less will be enforced unless the Ctrl + D key combination is entered.

! Be sure to restore the Hours of data to retain in the database value to an appropriate value (336 hours or below) when finished working with the old data.

Manual processing

Process Call Data (3)

To initiate a call and error activity processing cycle, click on the Process Call Data button. While the data is being processed, BANANA will display information messages and a progress indicator (5).

New activity since the last processing cycle will be processed and updated in the BANANA database.

Processing activity will be recorded in the BANANAadmin_Log* in the \logs subfolder of the specified output folder (2).

When the processing is complete, the Calls grid (22) will be populated with all call activity for the retention period. Similarly, the Errors grid (23) will be populated with all error activity for the retention period (12).

Notes:

First time processing of 24 hours of starfish logs can be time and resource intensive. After that, the more regularly the data is processed, the fewer resources are consumed for each cycle.

The BANANA admin and the BANANA service process the same data into the same database using the same methods. If the BANANA service has been processing data at regular intervals, when manual processing is initiated via the BANANA admin, only new data since the last service processing cycle requires processing.

Calls still in progress at the time of processing are reported for activity up to the time of processing, with no end time stamp. These will not be categorized as communication errors.

Calls whose failure occurs prior to allowing identification of the Octel Serial number will be logged with Octel Serial Number of ”Unknown”.

Calls that were in progress at the last processing cycle, and completed previous to this processing cycle, are updated.

Any processing error will be reported via a console message box and in the applicable BANANAadmin_*.log file in the \logs folder of the specified output folder (2).

All status messages presented in the admin interface (5) are also logged in the applicable BANANAadmin_*.log file in the \logs folder of the specified output folder (2), as well as any other significant activity initiated via the BANANA admin.

Data older than the specified retention period (12) is cleaned at the start of processing and not included in the results.

Manual processing can be initiated via the BANANA admin while the BANANA service is running. The BANANA service suspends processing of call activity while BANANA admin is running.

If the BANANA service is running when the BANANA admin interface is opened, the service may still be completing a processing cycle. If the Process Call Data button is selected in this condition, BANANA will present a message box indicating that “The BANANA service is currently processing. Please try again in a few moments”. Once the service has completed the processing cycle, manual processing will be allowed.

Dump data to CSV (4)

At any time you have the option to export all existing database information to CSV files. This makes a variety of Bridge statistics available for processing via a spreadsheet application, custom report scripts, etc. This provides flexibility in how you wish to track or summarize Bridge activity, beyond that provided via the various BANANA admin grid views.

To export the data to CSV files, click on the Dump data to CSV button. Depending on how much data is present, saving to CSV files could take a few moments. The mouse pointer will display as an hourglass to indicate BANANA is processing the request. When CSV file creation is complete, you will be provided a message box indicating successful completion.

Six separate CSV files are generated to the specified BANANA output folder. The CSV files include only the data for the specified retention period (12). The file name convention is as follows:

(MMDDYYYYhhmmss is the timestamp when the report is generated where MM=month, DD=day, YYYY=year, hh=hour, mm=minute, ss=second)

BANANA-REPORT.AllCalls.MMDDYYYYhhmmss.csv

This report is a consolidation of the data viewable in the BANANA admin Calls and Errors grids (22, 23).

This report contains the following data: octelserialnumber, timestampbegin, timestampend, callid, inbound, line, durationInSeconds, exitcode, unityserialnumber, protocollevel, msgsendattempt, msgsendsuccess, msgreceiveattempt, msgreceivesuccess, numberrecipientssent, adminnamesrequested, textnamesreceived, voicenamesreceived, adminnamerequestsrecd, textnamessent, voicenamessent, timestamperror, state, statetext, reason, reasontext, expecteddigits, receiveddigits, expectednumberdigits, receivednumberdigits

BANANA-REPORT.Events.MMDDYYYYhhmmss.csv

This report is very much the same data you would see in the starfish log files, in a slightly easier to view format. The events from the starfish logs are categorized into 5 separate fields, and sorted by line number and then timestamp to make it easier to follow activity for a particular call. This report is the same type of data you would see when viewing the Call Detail for selected call grid (19).

This report contains the following data: timestamp, milliseconds, sequence, line, data

BANANA-REPORT.LineSummary.MMDDYYYYhhmmss.csv

This report is the same type of data you would see when viewing the Line totals grid (20).

This report contains the following data: Line, Calls, Errors, ErrorPercent, TimeInUseInSeconds, MsgSendAttempt, MsgSendSuccess, MsgReceiveAttempt, MsgReceiveSuccess, NumberRecipientsSent, AdminNamesRequested, TextNamesReceived, VoiceNamesReceived, AdminNameRequestsRecd, TextNamesSent, VoiceNamesSent

BANANA-REPORT.OctelSummary.MMDDYYYYhhmmss.csv

This report is the same type of data you would see when viewing the Node totals grid (21).

This report contains the following data: OctelSerialNumber, Calls, Errors, ErrorPercent, CallsWithinInterval, ErrorsWithinInterval, ErrorPercentWithinInterval, TimeInUseInSeconds, MsgSendAttempt, MsgSendSuccess, MsgReceiveAttempt, MsgReceiveSuccess, NumberRecipientsSent, AdminNamesRequested, TextNamesReceived, VoiceNamesReceived, AdminNameRequestsRecd, TextNamesSent, VoiceNamesSent

BANANA-REPORT.Tasks.MMDDYYYYhhmmss.csv

This report is the same type of data you would see when viewing the Tasks for selected call grid (18).

This report contains the following data: TimestampBegin, TimestampEnd, CallID, TaskID, TaskType, DurationInSeconds, Fax, Sender, NumberOfRecipients, NameRequestFor, TextNameReceived, RecordingReceived, TextNameSent, RecordingSent

BANANA-REPORT.Recipients.MMDDYYYYhhmmss.csv

This report is the same type of data you would see when viewing the Recipients grid via the Tasks for selected call grid.

This report contains the following data: CallID, TaskID, Recipient, Rejected, TextNameConfirmFail

Test Calls (26)

With the monitoring capabilities and data collection provided by BANANA, an administrator has a greater ability to determine the state of the analog network at any point in time. While monitoring live call activity is important, it is also a benefit to have the ability to initiate call activity on request to each of the Octel nodes with which the Bridge communicates. This allows identification of network problems prior to live production deployment of the Bridge, and periodic check of the entire analog network state even if there is no live activity to particular nodes at any point in time. BANANA provides a simple mechanism for initiating such activity.

Place Test Calls (43)

To initiate the test calls, click on the Place Test Calls button. When the process of scheduling the test calls is complete, a message box is displayed indicating successful completion.

Cancel Test Calls (44)

At any time, pending test calls scheduled by BANANA can be canceled by clicking on the Cancel Test Calls button. You will be asked to confirm the action, then all Octel Node directory entries for mailbox 9999999999 will be removed from the Bridge database. This is convenient in case you have initiated test calls inadvertently, etc.

Configure the Octel nodes to Include/Exclude from test calls (41, 42)

In the Include Node Serial Numbers and Exclude Node Serial Numbers panes you are presented with all serial numbers of Octel Nodes configured on the Bridge server. On occasion, you may have reason to exclude particular serial numbers from the placement of test calls.

To move selected serial numbers from one list to the other, perform any of the following:

Highlight the desired selection(s) and click the applicable single-arrow key

Highlight the desired selection(s) and press the Enter key

Highlight the desired selection(s) and double-click the mouse pointer

Click on the applicable double-arrow key to move all entries in one pane to the other

When test calls are placed, whether manually via the BANANA admin or automatically via the BANANA service, any node serial number listed in the Exclude Node Serial Numbers pane will not have a test call placed..

Notes:

BANANA accomplishes generation of call activity by exploiting the admin name retrieval functionality of the Bridge. BANANA reads the Octel Node information in the Bridge starfish.mdb Octel Nodes table. For each Octel Node serial number, BANANA creates a new entry in the starfish.mdb Directory table for mailbox 9999999999, with a retrieval pending state (0). As designed, the Bridge detects these records as the admin window cycles around for each Octel Node, then attempts admin name retrieval for mailbox 9999999999 at each node. 9999999999 is not expected to ever exist, but the action of attempting retrieval for this mailbox takes the Bridge and Octel server through a significant number of the analog protocol stages. Failure to retrieve name info is expected and is not in itself considered a communication error. When the Octel indicates that mailbox 9999999999 does not exist, the Bridge simply removes this entry from its directory. Other than the expected non-existence of 9999999999 at the Octel node, any other communication problem or failure to connect will be detected as a communication error by BANANA, just as any live production call would be.

BANANA always checks for an existing directory entry for 9999999999 at each Octel serial number before inserting another record. So test calls will never be ‘stacked’, and no duplicate record conflicts will be introduced. If test calls from previous requests have not completed when a new set is requested, those still not completed will simply be left to execute, and new directory entries added only for those which are not already there.

When there are many Octel Nodes configured, this can generate a small flurry of admin traffic. However, the Bridge does treat admin tasks as lower priority than Normal or Urgent priority voice messages so impact to processing of live messages should be minimal.

If a large number of Octel Nodes are configured on the Bridge, and availability of lines to handle inbound live traffic is a concern, you can consider using the Bridge Line Status page to dedicate the desired number of lines for incoming calls only.

Depending on the Administrative delivery schedule configured for each Octel Node in the Bridge administrator, the test calls may or may not begin immediately upon scheduling. If the test calls are not being placed when expected, check the Administrative delivery schedule configured for each Octel Node in the Bridge administrator.

Viewing data in the BANANA admin interface

After manual processing of call and error activity data via the BANANA admin, there are a number of ways the data can be viewed. Any grid can be sorted by any field by clicking on the column heading. Clicking more than once on a heading will toggle the sort as ascending or descending.

Notable column explanations:

callid

A unique identifier for a particular call. Used within the database to associate records in other tables with this particular call. It is comprised of the call start time and date, including milliseconds and sequence, and the Bridge analog line on which the call occurred.

taskid

A unique identifier for a particular task that occurred on a call. Used within the database to associate records in the recipients table with this particular task. It is comprised of the task start time and date, including milliseconds and sequence, and the Bridge analog line on which the call occurred.

milliseconds

The data processed by BANANA is extracted from the Bridge starfish logs, aka analog call traces. Many events occur within one clock second, so the exact millisecond of each event is also recorded to ensure the events are maintained in the proper chronological order.

sequence

In many cases events in the Bridge analog call traces occur simultaneously to the millisecond. When BANANA processes the log data a sequence number is assigned to each event ensure the events are maintained in the proper chronological order.

Calls grid (22)

In the Calls grid, you can view a record of each separate call that was taken or placed by the Bridge during the specified data retention period. Each call is assigned a unique CallId which is used to associate data in the other grids that pertain to this call.

Errors grid (23)

For each call in the Calls grid that encountered a communication error (i.e., a call that was not successfully connected, or ended in any state other than a clean end of session) a record exists in the Errors grid. This record provides specific details regarding the condition under which the call was terminated, including the state of the protocol that was in process, and the reason why the call could not be completed.

Notes regarding Calls and Errors grids:

Clicking on any record, or pressing the Enter key when the desired record is selected, in the Calls table with an exit code other than ‘OK’ automatically displays and highlights the associated record for that call in the Errors table.

Clicking on any record, or pressing the Enter key when the desired record is selected, in the Errors table automatically displays and highlights the associated record for that call in the Calls table.

Calls whose failure occurs prior to allowing identification of the Octel Serial number will be logged with Octel Serial Number of ”Unknown”.

Filter Call and Error grids (14, 15, 16, 17)

By default, the Calls and Errors grids present all data for the specified data retention period. This group of controls allows filtering the data to a more specific time period. Select the start and end times for the data you wish to view and click on the Apply button. To restore Calls and Errors grids to a view of all data for the specified retention period, click on the Show All button.

Tasks for selected call (18)

Click on any record in the Calls grid, then click on the Tasks for selected call button. A new window will appear displaying detail about all tasks performed on the selected call.

Likewise, when viewing the Tasks grid, if the task is a voice or fax message, you can click on the View Recipients button to view details for each recipient of the message.

Call Detail for selected call (19)

Click on any record in the Calls grid, then click on the Call Detail for selected call button. A new window will appear displaying very much the same data you would see in the starfish log files, in a slightly easier to view format.

Notes regarding Call Detail grid:

The grid will include only activity for the analog line on which the select call took place.

When the Call Details grid appears, the selected record is that for the first event of the selected call, and the grid is automatically scrolled to this position. This same record is also back highlighted in yellow, so if you scroll away from this record you will still be able to easily identify where the selected call starts.

Line totals (20)

Click on the Line totals button to view a summary of call and error activity over the data retention period, calculated per analog line on the Bridge. This can be helpful to identify trends where communication problems may be isolated to issues with a particular line.

Node totals (21)

Click on the Node totals button to view a summary of call and error activity over the data retention period, calculated per Octel Node that the Bridge has communicated with. This can be helpful to identify trends where communication problems may be isolated to issues with a particular node.

Save to file

Any grid can be saved to a CSV file by clicking the Save to file button. The grid is saved with the same sorting as whatever the user has set for viewing. The file is saved to the output folder specified in the File Locations section of the BANANA admin, as filename <grid name>_YYMMDD_hh_mm_ss.csv.

Clearing the BANANA database

Options > Purge Event Data (28)

Select Options and Purge event data from the menu bar of the BANANA admin to purge all activity data from the BANANA database.

Notes:

When selecting this action, you will be prompted with a request to confirm that you want to proceed.

Once the activity data has been purged from the BANANA database, the data available for the next processing cycle will be limited to that in the existing starfish logs.

All tables in the database are cleared of data, except for the application configuration settings.

Resetting communication error counts (27)

When BANANA generates Event Viewer communication error threshold violation Warnings and Errors, the monitoring period is the rolling most recent period of specified length. If a problem resulting in these Event Viewer events is resolved for a particular Octel node, the events will continue to be logged at each processing period until the number of occurrences within the specified monitoring interval falls below the threshold. BANANA provides a means of resetting the communication error count for a specified node. This way, if you continue to see Event Viewer Warnings or Errors for a node after resetting it, you will know these problems have occurred subsequent to when the problem was believed resolved.

In the left pane (48) of the Reset Error Counts window you are presented with all serial numbers currently configured as Octel Node profiles in the Bridge starfish.mdb database, including a selection of “Unknown” for handling of calls where the Octel serial number can not be identified.

To reset the error count for any desired node, perform any of the following:

Highlight the desired selection and click the Reset (49) button

Highlight the desired selection and press the Enter key

Double-click the mouse pointer on the desired selection.

Click on the Reset All (50) button, to reset the error count for all nodes listed

1. Once any of these actions has been taken, the selection is removed from the list, and the count is immediately reset to zero.

Each time you re-open the Reset Error counts window, the left pane (48) will include the full list of all serial numbers configured as Octel Nodes on the Bridge.

BANANA activity logs

Processing activity performed by the BANANA admin and service is written to the \logs subfolder in the specified output folder (2).

Logs generated by the BANANA admin and service are named ‘BANANAadmin_YYMMDD_hh_mm_ss.log’ and ‘BANANAservice_YYMMDD_hh_mm_ss.log’ respectively (where YY=year, MM=month, DD=day, hh=hour, mm=minute and ss=second when the log was initially created).

A new admin log is created when the admin is run, and the log is completed when that session ends. A new log is created when the next session occurs.

A new service log is created when the service is started, and the log is completed when the service is stopped. A new log is created when the service is next started. When the service runs past midnight, the first log activity of the new day results in closure of the current log and creation of a new log, i.e. a new log is created every 24 hours.

The BANANA service deletes any logs older than 10 days.

Uninstalling the BANANA administration application

1. Disable the Cisco Security Agent if running.

2. Disable any anti-virus application.

3. Run BANANA uninstall from the Windows Start Menu.

4. If BANANAadmin is running, you will be prompted that it must be exited prior to uninstalling.

5. The uninstall will check to see if the BANANA service is running and/or installed. If it is, you will be prompted and given the opportunity to have the service stopped/uninstalled at this time.

6. At this point the uninstall will check to see if the Windows Event Viewer is running. If it is, you will be prompted that to close it before continuing. This allows successful removal of BANANA files used for logging Windows events.

7. At this point, the removal of the BANANA admin application begins, and you will be asked to confirm the action. Canceling here will leave the BANANA admin application intact. If BANANA service has been removed earlier in the process it will not be re-installed at this point. If you desire, you can do so via the BANANA admin.

8. If you confirm the removal of BANANA admin the process completes.

9. Enable the Cisco Security Agent if you disabled it.

10. Enable anti-virus application if you disabled it.

Notes regarding BANANA admin uninstall:

You may be prompted during the uninstall to select whether you want to remove a file considered ‘shared’. Respond ‘No’ to any such event.

Using BANANA on a non-Bridge server

Sometimes it is handy to install and use BANANA on a server other than the Bridge itself. For instance, someone has sent you starfish logs from the Bridge and you wish to use BANANA to process and view the activity. To run BANANA on a non-Bridge server:

1. Install on a server meeting the system requirements as described in System Requirements, For limited BANANA functionality.

2. When you first run BANANA admin from the Windows Start Menu, you will receive a message box indicating “The Cisco Unity Bridge application is not installed on this server. BANANA functionality will be limited to processing of starfish logs. Continue?”

3. Click OK at this warning message.

4. The BANANA admin interface will appear.

5. Features that require access to the Bridge database, such as configuration of the BANANA service, BANANA test calls and BANANA Event Viewer notification will not be visible.

6. All other controls will be visible.

7. Follow the instructions in the applicable section of this document for use of the visible features.

Revision History

Version 1.0.1 – 01/27/2004

Initial release

Version 1.0.2 – 05/07/2004

Enhanced usability for configuration of Event Viewer Notification

Enhanced usability for configuration of Test Calls

Added support for installation on non-Bridge server (manual processing only)

Error percentage Line and Node summary totals

Version 1.0.3 – 06/03/2004

Removed most standard Windows DLL files from installation to avoid installation conflicts on servers without the most recent patches.

Version 1.0.4 – 06/14/2004

In some rare cases, successful recipients on inbound calls were displaying with a rejection reason in the Recipient Info field. This was due to failure to re-initialize a variable. Fixed in this release.

Version 1.0.5 – 7/21/2004

Added handling for starfish log event messages longer than 255 characters. MS Access database (bdgdata.mdb) has max text field length of 255. BANANA will now truncate starfish event messages longer than 255 characters to 254 characters.

Version 1.0.6 – 8/25/2004

Tag of “[Incomplete]” will be added to any task that was in-process during a call failure so it’s obvious from the Tasks form that it was not successfully completed.

Version 1.0.7 – 10/24/2004

For CSCef60867 Bridge defect – updated modProcessCalls.processIncomingCall to allow 19 digit line sync if first three digits are '812'.

For CSCef21474 Bridge defect – confirmed case of receiving non-# dtmf on inbound voice message audio before # is handled properly.

CSCef64483 – updated SESSIONHEADER_RECEIVED_OK state in modProcessCalls.processIncomingCall so that datatype.RECEIVEDNINE is treated same along with datatype.RECEIVEDDTMF instead of falling into the 'else' case. This is very specific treatment for receiving the dtmf 9 twice on an inbound message.

CSCef72640 – Implemented auto-shutdown feature – shuts down in 30 minutes, after 120 second warning; user can resume at any time during 120 second warning and it gets reset for another 30 minutes; timer stops when call processing is executed and restarts with new 30 minutes when call processing complete

CSCef74710 – Added handling for the Bridge playing out an 8 digit dtmf admin response sequence if we don’t have a voice name to send but we sent an admin alias response prior to sending the admin text name response.

CSCef75631 – We now use 'Call Status = '... as an indicator of end-of-call if we encounter it while processing an outbound call after we've received it the first time. If we encounter 'Call Status = '... while not in the middle of processing a call, we use it as the start-of-call indicator.

Version 1.1.1 – 4/18/2005

Added support for Bridge 3.0(6) Accept Remote Push feature.

CSCef22653 – A. In the View Tasks form, tasks that were in progress when a call abnormally terminated are now tagged with "[Incomplete]" in the TaskType column. For voice messages, this may indicate an entire message transmission failing, or that all recipients for a message were not successfully transmitted. In the latter case, the voice message may have been successfully delivered to some recipients before the call terminated. So the TaskType will be "Voice Message [Incomplete]" instead of "Voice Message", "Admin [Incomplete]" instead of "Admin", etc. B. On inbound calls, if message header for mailbox is successfully received but error occurs during text name confirmation, the RecipientInfo field of Recipients grid will specify “Protocol error during recipient name confirmation”. C. On inbound and outbound calls, if an error occurs between accepting the first recipient (and text name if applicable) and saving the message recording the RecipientInfo field of Recipients grid will specify “Message transmission unsuccessful”. D. On inbound calls, if an error occurs after the message has been successfully saved for the first recipient but fails during reception of additional recipients, this message will be included in the msgreceiveesuccess field of the Calls grid for this call (in earlier versions we were not including a message in the count unless all recipients were successfully transmitted). The TaskType in the Tasks grid for such a message will be listed as “Voice Message [Incomplete]”.

Contents

Overview

System Requirements

For full BANANA admin and service features

Software

Hardware

For limited BANANA functionality

Software

Hardware

Configure the Bridge call tracing level

Install the BANANA administration application

The BANANA Interface

Configure folder locations

Log Location (1)

Output Folder (2)

The BANANA service

Install the BANANA service

Install Service (6)

Configure the BANANA service

Processing Interval (10)

Test Call Interval (11)

Starting and stopping the service

Start Service (8)

Stop Service (9)

Uninstalling the service

Uninstall Service (7)

Event Viewer Notification (25)

Warning Threshold (32)

Error Threshold (33)

Communication Error Monitoring Period (34)

Configure the Octel nodes to Include/Exclude from Warning/Error threshold violation Event Viewer messages (35, 36)

Configure data retention period for call and error activity

Data Retention Period (12)

Manual processing

Process Call Data (3)

Dump data to CSV (4)

BANANA-REPORT.AllCalls.MMDDYYYYhhmmss.csv

BANANA-REPORT.Events.MMDDYYYYhhmmss.csv

BANANA-REPORT.LineSummary.MMDDYYYYhhmmss.csv

BANANA-REPORT.OctelSummary.MMDDYYYYhhmmss.csv

BANANA-REPORT.Tasks.MMDDYYYYhhmmss.csv

BANANA-REPORT.Recipients.MMDDYYYYhhmmss.csv

Test Calls (26)

Place Test Calls (43)

Cancel Test Calls (44)

Configure the Octel nodes to Include/Exclude from test calls (41, 42)

Viewing data in the BANANA admin interface

Calls grid (22)

Errors grid (23)

Filter Call and Error grids (14, 15, 16, 17)

Tasks for selected call (18)

Call Detail for selected call (19)

Line totals (20)

Node totals (21)

Save to file

Clearing the BANANA database

Options > Purge Event Data (28)

Resetting communication error counts (27)

BANANA activity logs

Uninstalling the BANANA administration application

Using BANANA on a non-Bridge server

Revision History