User interface manual

Filters are applied by entering filter patterns into Filter fields above column names. Filters are case-insensitive, and for most data it is enough to enter any part of the string to match this string. Entering several filtering patterns separated by the space will make the system search for strings containing both patterns. (It is enough to enter just mob oran to match France MOBILE Orange).

Filters are automatically saved with each key press in the most statistical and config modules. But they are not auto-saved in the modules like CDR or Traffic collector that deal with a lot of data. The presence of the very Save filter botton is an indication that the filters for this table are not auto-saved.

This is done in order to exclude cases when previously entered heavy filters can lead to long wait times after reloading the page and cause unnecessary load to the DB.

Sometimes you want to filter by a column but don't need to display it in the table. In this case you can use Permanent filters.

Sorting is done by pressing the column name in the table header. An arrow will show up indicating the sort direction. Null values are always sorted out to the bottom. Only one column can be sorted in a table, multiple sorts are currently not fully supported, however, in most cases applying sort to one column, and then to another one should result in a 2-column sort.

You can use standard regular expressions to filter directly in a DB (see Filtering by regexp in DB).

The text entry fields above column names are used to filter data in each corresponding column. If the field contains a valid filter, it will be highlighted. Some symbols, like =, <, >=, space, ~, !~ are not considered filters in themselves, but only in combination with the values that follow. To quickly clear all filters one may press the Filter sign with red X button in the menu on top of each table. See example of the menu in Table menu. To clean just one field when the cursor is in it one may also press the Escape key.

Be default, all filter fields will be joined together for a table-wide filter pattern by the AND logical operator. In order for some filters to be joined by OR, one needs to precede the pattern with the || combination. Having || in just one field will have no effect, as this cell will not have any other cells to be joined with by OR.

Let's say you have 3 filters with the implied AND operator (no || symbols in front of the filter strings), and 4 filters with the OR operator (|| in front). First, the 4 OR patterns will be joined by OR, then this combined pattern will be joined with other 3 patters by AND.

Convenient string filtering saves a lot of time and effort when working with tables containing a large amount of data. There are several special symbols or signs used in front of filter patterns to determine their behavior.

The main rule is that if there is nothing at all, no sign in front of the filter pattern, it will work as if preceded by a like operator, meaning that the strings will not be matched strictly against the pattern. Moreover, entering several filtering patterns separated by the space will search for strings containing all patterns in succession. For example:

• MOB Oran will match France Mobile Orange
• mex mob movi will match Mexico Mobile Movistar
• mex movi mob though, won't match the above Area, as the filter parts are not entered in succession
• 521 521 will match 5217000000521, but wont 5217000000555
• 16 will match H323 | 16 | Normal call clearing
• % has the same meaning as space when connecting pattern parts, so mex%mob%movi will match Mexico Mobile Movistar as well

One may also use the following signs in front of filter pattern to change their behavior;

• ! - not like, acts like like (no sign), but will hide the matched strings
• = - equal strictly, =mexico mobile will match mexico mobile, meXIco MobilE, etc., but not mexico mobile telcel
• != - not equal, acts like =, but will hide the matched strings
• >, <, >=. <= - see Filtering numbers
• || - the logical OR operator, see Filter fields
• space or % at the beginning of patterns are just ignored

To limit matches to only beginning or end of string, ^ or $ should be used:

• ^telecom will NOT match France Telecom, but will match TELECOM Italia
• com Italia$ will match Telecom Italia and not Telecom Italia partner
• ^telecom Italia$ will give the exact match, much the same way as using just =, like =telecom Italia
• = with nothing after it will match NULLs (no data in cell)

To join filter patters within one field operators || (OR) and && (AND) may be used with no spaces around them:

• france||italia will match both France telecom and Telecom Italia
• mex&&mob&&movi will match Mexico Mobile Movistar in the same way as mex mob movi, however:
• the pattern movi mob mex won't match the above string, while movi&&mob&&mex will
• Mobile&&!Mexico will match all mobile Areas, except for ones in Mexico
• || and && may be used in long patterns combining multiple strings: mex||spain||italy&&monterr||madrid||rome&&mobile
• matching several numbers in CDRs: 14161234567||12125556677||18889990000

Objects have IDs and names, reflecting the ones in your VoIP switch configuration. In general, when filtering IDs and names, same rules as in Filtering strings apply, however, there are some specific features.

All IDs have an object-specific prefix to easily distinguish objects of different types, for instance:

• c - for Customers or Vendors
• a - for destination Areas
• b - for source Areas
• e - for Equipment
• g - for Equipment Groups
• n - for switch Nodes
• r - for Disconnect Codes (Reasons)
• f - for Flex combinations
• d - for SNMP Devices, see Config-SNMP
• p - for Poller internal stats

To filter objects, you may either enter all or part of the name (case-insensitive) in the name fields, or enter a whole or partial object ID in the ID fields. For instance, entering just a in the ID field will filter out all Areas. The system allows to add the second and third set of destination areas. Please refer to Config-Objects. In order to distinguish area IDs of the second or third set from the default set, they have a2. or a3. prefixes in their IDs. Entering a2. in the ID field will filter out all DST 2 areas. Filters on object IDs are case-sensitive, this is the only exception, all other filters are not. This is done in order to exclude system objects like cTOTAL, or disconnect code IDs (rSIP-486) when you are filtering by the initial lower-case letter. For instance, a filter like a||p would not show you the cTOTAL or any SIP codes.

There are also 2 useful features to filter by the ID field of the Table and Report modules, as well as all config tables:

• #1, #2, etc. will filter for all objects, contained in the Object groups of the User rules module (Config: User -> Object groups). Format: # + object group ID. This allows you to create filters of any complexity. For instance, if you only want to see certain 15 areas on a screen and nothing else.

• @1, @2, etc. will filter for color highlight. 1 is red, 2 - green, 3 - blue, 4 - magenta and 5 - yellow, as listed in the right-click table menu. Additionally, it is possible to filter CDR tables in the CDR ID columns. You may, for instance, choose 5 CDRs you want to closely examine by highlighting them in yellow, and then quickly sort out only these 5 CDRs.

Objects are organized in a hierarchy of up to 3 levels deep for VoIP stats (the deepest being Customers->Areas->Vendors, see Objects), or even deeper for External DB stats. In order to filter child objects a "::" separator sign is used, so filtering by c::a in the ID field will bring all Customers->Areas combinations, but will hide Customers->Vendors or Customers->Disconnect codes. You may also quickly hide or show specific object combinations in a Table via the Combinations strip.

Likewise, the pattern arbinet::mobile::telmex will only bring successive parent-child related objects like Arbinet->Mexico Mobile Movistar->Telmex.

Just entering a number in a filter field will match any data having such digit combinations in it. Effectively, this is just the string matching, as described in Filtering strings above:

• 25 will match 25, 1255, 5.625
• =25 will only match 25
• !25 will match anything not containing 25
• !=25 will match everything, but 25

To make it real number filtering you should use the following operators: >, <, >=. <=:

• >=25 will match 25, 255, but not -25

Some values are too big and long to be shown gracefully in the limited table cells, so they may be shown with the appended K for thousands or M for millions. You may also use same letters to quickly filter for large numbers:

• >=0.8k will match 800, 2K, 0.125M
• <1M will match anything below 1 million

Combining conditions via || or && is also possible:

• >=100&&<1K is matching 100, 900, 0.9k
• 22||<10 is matching 22, 1221, 9

Most of the time, entering specific filters for the date fields in the CDR, Alerts and Traffic collector modules is not needed, as rows are automatically filtered by CDR date, Raised at and Capture time accordingly via the Intervals you choose for the fetches.

If you still need more control over which rows will be shown, you may filter dates in CDR, Calls, Alerts and Traffic collector tables. Filtering dates have slightly different rules from filtering common strings. Please refer to Filtering strings for a basic description. The differences are:

1. Since space is an integral part of the date/time string, spaces are not treated as joining elements for 2 separate parts of the string, so when you enter 2011-09-25 10:00:00 the filter will not bring up all strings containing both 2011-09-25 and 10:00:00, it will look for the exact pattern of 2011-09-25 10:00:00. Same is true of all call IDs fields that may have spaces.

It is possible to enter only part of the date string to filter a specific date range, for instance, 2011-09-25 10 will filter all CDRs happened in the hour of 10am, or even simpler: 09-25 10, as there will be no CDRs of other years that you would be able to access through the web interface.

2. Numeric comparison operators like ">" work well with dates (while with arbitrary strings the behavior may be unpredictable).

Here are some examples:

• Getting the exact date: =2011-09-25 10:00:00 or just 2011-09-25 10:00:00
• Getting the date range: >=2011-09-25 10:00:00&&<2011-09-25 12:00:00 (no spaces are allowed before and after &&)
• Getting the date range for the whole day: 2011-09-25
• Getting all date/times except for a specific hour: !2011-09-25 15:

Tip: if you don't have enough length of the Filter fields to enter your patterns, you may always expand it by dragging the gray bar at the column border.

When bringing CDRs from the VoIP switch or internal DB (when replication is working), 5gVision is not requesting the Objects names every time, but keeps them in cache to provide higher performance. Thus, when you are filtering names of Disconnect codes, Area, Customers, Customer GWs, Vendors, or Vendor GWs, you actually are filtering the cached table with the names first, and when the object IDs are determined, they are sent to the DB for query.

Working with object names in CDRs is much like working with common strings, and most of the time you will see no difference, unless you enter a filter that will bring no objects at all. In such cases the system will warn you and ask to change filters, rather than sending a query to the CDR DB that will eventually return nothing.

There is one other specific case of "names" for fields like Call state or Disconnect initiator (Disc. init.). These fields have both the numeric values stored in the DB and the description, separated by :, like 8: reject for a call state. The filter sent to the DB only works for the numeric part, not the description. So to filter by Call state connected calls you need to enter: 3, and this will bring 3: conn, and to filter by Disconnect initiator - enter: 2, and this will bring 2: dst.

Most of config tables have a Status field, represented by an icon, to enable or disable a record. You may filter for only enabled records by applying filter "1" or only disabled by applying "0".

Table filtering allows to send regular expressions to a DB via prefixing your filters with ~ or !~ (not matching). For instance, you may choose certain number ranges by filtering number fields in CDRs like this: ~^1416[0-5][7-9].

If you prefix your column filter with PERM:, the filter will still be active even if you remove this column. For instance, you may filter out only Customers/Vendors with the c filter: And then hide the ID column and still see only Customer/Vendor objects in the table. Permanent filters are not cleared with the Remove all filters button, however, a Ctrl-click will clear them as well.