Cisco CDR

Using Leg Types to Make Your Life Easier

August 15th, 2018

First, a quick chat about call legs vs. calls. We all know what a call is – that period of time from when you pick up a phone until you put it back down again. In modern systems each call is comprised of one or more call legs, with each leg being a single source/​destination combination. So if you try to call Sally, you could see the following legs:

  • Leg 1: You dialed Sally’s extension. It rings. No answer.
  • Leg 2: Your call gets forwarded to voicemail. You leave a message. You hang up.

That’s a two-leg call. Simple, right?

Introducing Leg Types

Leg types are a way to add a reusable, human readable tag” to the individual legs to make both searching and seeing call flow easier and better.

For instance, you could define leg types for Abandoned at voicemail” to catch those legs where the caller went to voicemail and just hung up on it. Another could be Left voicemail”, which is just like before except that they actually left a voicemail. Maybe even jumped out of voicemail” to tag legs that went to voicemail but then transferred themselves out again. This is a little more tricky – these legs should be ones that went to voicemail, but which there is no on hook” party – i.e. no one actually hung up at that leg.

There are two things to be aware of –

  1. Make sure that each call leg is matched to only one leg type.
  2. These are leg types, not call types. They operate on individual legs, not on what you or I think of as calls”.

For the former: there should be no overlap on an individual leg, that gets weird and may very well behave incorrectly or break something. We do try to test for such overlaps in the Health Check page (under Setup”), but it’s easier to just make sure they don’t overlap in the first place. This means you shouldn’t have a generic went to voicemail” leg and also a went to voicemail and left message” leg – because a leg that went to voicemail and left a message would pick up *both* legs. In that case, just redefine the more general one to be not what that more specific one is”, so went to voicemail” becomes went to voicemail and didn’t leave a message”. (This is in the example below, so if that sounds confusing perhaps continuing on will clear it up!)

For the latter: We hope to implement a call types feature on top of leg types and other functionality in the future, but baby steps.., so stay tuned.

Now that we understand what they’re about, let’s jump in to a short example!

Voicemail calls example

Let’s build a leg type for calls that ended in voice mail, and another for calls that ended up getting hung up on when they went to voice mail.

Step 1: Find your voicemail calls

Step 1.1: Define what a voicemail call is.

The first task is to define what it means to end in voice mail”. This is dependent on how your calls get routed and thus varies from place to place, but we’ve found several common threads in most people’s environment which I’ve outlined below:


If you used the default voicemail naming scheme, you should be able to see voicemail by looking for device_​type of unityvm”. This is the most commonly needed search for finding voicemails.


A leg which has the on_​hook_​party set as the caller means this is the leg where the caller hung up and thus terminated the call. This helps determine if they *ended* at voicemail or if they then hopped elsewhere via some menu option.


Underneath our created device_​type” is an assumption that the default voicemail naming convention was followed, specifically that voicemail devices are named like CiscoUM-VI*.” If device_​type” never says unityvm” even though it should, this is probably the issue. The resolution is to just use the deviceName(s) that you configured, perhaps with wildcards, like deviceName = MyVoiceMailSystem*

Step 1.2: Construct and validate the search

In our example, let’s assume that when the device type is the default unityvm” and the calling party hangs up, the call is one we want tagged as voicemail_​left_​message or voicemail_​abandoned.

To test this, let’s open up Browse Calls, then in the field other search terms” type in device_type="unityvm" on_hook_party="caller"

Review that list, make sure it looks right!

Now we have to decide on a duration to use – I’m going to pretend 5 seconds is our cutoff. If the person was in voicemail for more than 5 seconds, they left a message. If 5 seconds or under, they hung up right away. Your own threshold may be different, but it seems between 5 and 60 seconds is the most common ranges used. Something like 45 seconds may be useful here if they have 40 seconds of message to listen to before they can leave a message.

This gives us two non-overlapping cases:
When they hung up” on the voicemail – device_type="unityvm" on_hook_party="caller" duration<=5
When they left a voicemail – device_type="unityvm" on_hook_party="caller" duration>5

Again, test both of those using search, make sure they look correct. You might have to leave yourself a few voicemails – and abandon a few – to see how the duration should be set. I recommend testing with some coworker who happens to not be at their desk. Most folks feel loved when they come back from a break and find someone left them a few voicemails!

Step 2: Building leg types

Now that we have our searches, let’s build some leg types!

  • Click Settings, then Event Types.
    • We are going to assume you have no leg types already – if you did, search for them by typing leg_​type” in the search box and pressing enter, then review what you have to make sure we aren’t duplicating legs.
  • Click the green New Event Type” in the upper right. Fill it in as such:
    • Name: leg_​type_​voicemail_​abandoned
    • Search: device_type="unityvm" on_hook_party="caller" duration<=5
    • (Note the initial leg_​type_​…” in the name is important, it’s how our app knows these are for it!)
  • Click Save

Now, build the left_​voicemail” version.

  • Click Settings, then Event Types.
  • Click the green New Event Type” in the upper right. Fill it in as such:
    • Name: leg_​type_​voicemail_​left_​message
    • Search: device_type="unityvm" on_hook_party="caller" duration>5
    • (Note the initial leg_​type_​…” in the name is important, it’s how our app knows these are for it!)
  • Click Save

Notice that I named them both leg_type_voicemail_(something)? I did that on purpose, now we can search for leg_type=voicemail_* to get all voicemail legs!

Step 3: Testing

Click back in your browser a few times to get back to your search, or reselect the Cisco CDR Reporting and Analytics app then go to Browse Calls.

If you do not see the field leg_​types”, click Fields” in the upper right, search for leg_​type” on the left and add it into the right pane. Then obviously click Save in the field selector.

As long as any calls matching the search we built above are in the results, you should see leg_​type populated. Fiddle with your timeframe a bit if you need to.

Step 4: Using Leg Types

Now that we have leg types defined for a few cases, we can search for those using the other search terms’ field.

Rather than bore you with prose, how about I just make a little table with some examples and see how that looks?

To see all calls that have:Search this:
Any leg_​type defined
A leg_​type of voicemail_​left_​message”
A leg_​type starting with voicemail…”

The neat part is that though these are defined on individual call legs, those legs roll up into calls and keep their call legs as part of them. Searching for leg types of X means the app returns your *calls* that include legs of those types.

Additional possibilities:

This is by no means complete, but some random thoughts on leg types:

  • tagging legs that were placed to your call center as perhaps call_​center_​received”
    • split that into call_​center_​received”, call_​center_​abandoned” and call_​center_​no_​answer”
  • tagging a certain DID block with incoming_​sales_​took_​call”
    • NOTE that OR” is OK, but put parentheses around them, like “(finalCalledPartyNumber=7344 OR finalCalledPartyNumber=7345) duration>=15 on_​hook_​party=*”, which would tag legs that were to either 7344 or 7345, lasted more than 15 seconds, and where someone hung up without transferring (so they didn’t get transferred away).

There are many possibilities for building and using these and we’d love to see the system you come up with!


Cisco CDR

Great software ultimately has to empower you to achieve more in less time. This extends to the company behind it -- we have to remember to always use your time as efficiently as we can.

And here I am happy to say that we shortened our Product Overview video dramatically. The new one is only 4 minutes long, vs 11 for the old one. You can see it here:

NOTE: the old one showed more of the product and was definitely more complete. In fact this was deliberate because we used it both for new users and also to be a deeper onboarding video for everyday users. However it was a bit too long for anyone who just wanted the short version and didnt want to spend 11 minutes of their day.

February 1st, 2024

Cisco CDR

December 14th, 2023

Cisco CDR

December 8th, 2022

Download a 90-day free trial & work with your own live data

Start My Free Trial

*indicates required field

By submitting this form, I agree to Sideview's Trial Internal Use License Agreement and Privacy Policy.