Cisco CDR
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:
That’s a two-leg call. Simple, right?
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 –
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!
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.
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.
deviceName=X
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*
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!
Now that we have our searches, let’s build some leg types!
device_type="unityvm" on_hook_party="caller" duration<=5
Now, build the “left_voicemail” version.
device_type="unityvm" on_hook_party="caller" duration>5
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!
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.
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 | leg_type="*" |
A leg_type of “voicemail_left_message” | leg_type="voicemail_left_message" |
A leg_type starting with “voicemail…” | leg_type="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.
This is by no means complete, but some random thoughts on leg types:
There are many possibilities for building and using these and we’d love to see the system you come up with!
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.