Cisco CDR Reporting & Analytics | Docs
Search Tips
Ranges of Numbers
For a range of numbers, like extensions for a particular department, you can use a dash between two numbers to find all between the two (inclusive of the ends). The following will retrieve any call where the number is 4830, 4831 … up to and including 4836.
4830 – 4836
Wildcards
If you have a single prefix to the numbers you’d like, you can use a wildcard * to fill in for “all the rest”. This can also be used at the leading portion of a number as well, though be forewarned that leading wildcards can cause slowdowns in your searches. The following will retrieve any calls where the number either starts with 483 (so will pick up 4830, 4831…, but also picks up 48312246 and others too), or ends in 4831 (so your direct-dial number 555‑4831 and the internal number 4831 would both show up, though note you may also pick up numbers like 123‑4831 too).
483*, *4831
Multiple Numbers and Number Ranges
The three above techniques can be combined. For instance, to find calls for 4831, for any in the range of 4300 to 4314, or for any that start with 4250 you could type:
4831, 4300 – 4314, 4250*
Get familiar with how matching works for general search filters
With the find calls to/from text field, matching with one number is intuitive, and matching with two numbers will match either the first OR the second number.
However with the general search filters page, things can get a little confusing. The thing to remember is that if you have a search term like orig_device_type=jabber_desktop, that is saying “find me any calls that have at least one leg where the originating device type is jabber desktop”.
Seems simple enough right? Well now with that searchterm let’s click graph calls over time and change over time to over device_type. If you would expect to see only jabber_desktop that would actually be wrong. The “calls that have at least one leg where the originating device_type is jabber desktop” also likely have a lot of other device_types on the other party, as well as (for multileg calls) on the other call legs.
It gets stranger when you are excluding searchterms. For instance say you are in the Chart view, and you have changed over time to over device_type. You will see gateway listed as one of the values. If you add a search filter of device_type!=“gateway” this will vanish from the results. However the call counts will also drop a great deal. What you have inadvertently done is filter down the entire report to only internal calls.
In short, always remember that the search filters text field filters at the call level, and the other call legs that do not happen to match the filters will always be there
This can be confusing at first, but in a way it is what gives the app a lot of its power.
Boolean syntax and advanced search expressions
As you have seen, various interactions with the app’s elements will automatically add search terms to the “search filters” field.
If you have not already done so, note that you can edit this textfield directly. There are a number advanced things that can only be typed in by hand. Here are some examples
- greater than, lesser than
For numeric fields like MLQK or CSR_overall, or duration, you can type in searchterms like duration>0 or MLQK<=4 - Advanced matching
using two comma separated extensions in the main number field will match calls that involve either of the two extensions. When you need to see calls that involve BOTH of the extensions, add the most restrictive term to the main “number” field, and the other term to the search terms box, eg as ( callingPartyNumber=1234 OR finalCalledPartyNumber=1234 ) - Finding calls that have no value at all for a given field
the best way to do this, is to use NOT with a wildcard.
for example to match only calls that have no huntPilotDN, search for NOT huntPilotDN=* - OR’s AND’s and parentheses
Although it can be come quite difficult to understand and remember, there is no limit on the complexity of boolean search expressions.
For example ( dest_device_type=jabber_iphone call_failed=1) OR (dest_device_type=jabber* quality!=good )
will match any calls that either were to a jabber iphone AND failed, or that were to any jabber device at all but met a call quality threshold less than “good”