Detecting Call Path (Ring Group vs. Direct to ext)

[FASTDEVICE]

Is there a way to determine if a call is being routed through a ring group or directly to an extension? I need to know (programmatically) if a user answered a call from their assigned ring group, or if they answered a call from their assigned DID. I may be missing it but I don't see anything in the CDR indicating such. Thanks.  

[Brian Dunne]

If you check accounts/{accountId}/cdrs/legs/{cdr-id} for a given call, you'll see the individual legs of the call. For a call that goes to a Ring All group, you'll see the attempts to each member device. The hangup_cause for each Ring All leg will be "LOSE RACE", except for the leg that answered the call.

One kind of hack that we've used to sort out which ring group delivered a particular call is the "Prepend Caller ID" feature in Calllflows. Basically, after the user selects a menu option that determines whether the call is routed to a given ring group, but before we deliver the call to that ring group, we insert one of these Prepend objects to modify the original caller's CallerID based on the function of that destination ring group:

The resulting CDR interaction will show the user's normal callerID on the initial leg, and will have TOGO-ORDER prepended on all ring group legs and beyond. 

[FASTDEVICE]

Thanks Brian. I want to avoid the prepend at all costs but need to know which ring-group. Any other thoughts on determining which ring-group since they are already named? 

[Karl Stallknecht]

I know there is a way to detect this since call forwarding can be enabled on a user based on whether the call came from a ring group or directly to that extension, but I have no idea how it's figuring that out...

[FASTDEVICE]

Probably need to test this but does anyone know if "Custom Application Variables" make their way into the CDR data or is that only for Pivot? Thinking that may be a way to avoid using pre-pended CallerID in a callflow. 

Update: I tested and CAVs are captured in the CDR. I see a lot of potential for this functionality.  

Edited October 4, 2019 by FASTDEVICE (see edit history)

[mc_]

Correct; once set they will appear on all subsequent call events for the leg (via webhook / websocket if you ingest those) as well as the CDR.

[Darren Schreiber]

Isn't the callflow ID also in the CDR?

[extremerotary]

31 minutes ago, Darren Schreiber said:

Isn't the callflow ID also in the CDR?

In my experience, the callflow ID in the CDR is the first callflow that the call followed, so if you ever branched the callflow for the telephone number to another callflow ID, the CDR won't illustrate that. 

[extremerotary]

@FASTDEVICE

James merged this PR for me a couple months back that was created specifically for your (and my) use-case.

https://github.com/2600hz/kazoo/pull/5899

This allows you to branch to the cf_set_variable callflow module, set group_id, then go to the group. Then, in the CDRs, the custom_channel_vars will contain the variable with the value you've defined. 

[Ken Rowland]

I am looking for information on how the change in the referenced commit is useful. I can add a custom variable now with an indicator of a group name and retrieve it in the CDR. The change above seems to indicate that I can have the group ID automatically inserted as a custom variable. I have tried several combinations of key/value pairs and am not having success. I've tried the following pairs:

"group_id" : "Group-Id"
"group_id" : "{Group-Id}"

I am placing the custom application variables element prior to the ring group element.

Can anyone help with the values to use to get the group id into the CDRs? 

Thanks.

[mc_]

@Ken Rowland are you looking for some kind of macro-expansion to add the group ID? I don't believe those exist for custom application vars.

Are you seeing any attempt in your KAZOO logs to set the CAV on the channel (should be in ecallmgr and FreeSWITCH logs at a minimum if KAZOO is trying).

[Ken Rowland]

@mc_ I was trying to figure out what the PR listed above did. I was hopeful that there was macro expansion. We are on the hosted platform so I am not able to view logs. 

Can you tell me exactly what the PR does? And when will it be available on the hosted platform.

Thanks

[mc_]

@Ken Rowland that particular PR was merged into the master branch (what is going to be 5.0). I'm not sure if there was a backport to the 4.3 branch so it will not be available until 5.0.

[Ken Rowland]

@mc_ I believe I may have a clearer understanding of the PR now. It is for a set variable element, not cav. So, I believe that once in production, I can add my own set variable element and have the variable show up in the CDR without having to pull full details. Is this correct?

Edited December 27, 2019 by Ken Rowland (see edit history)

[Ken Rowland]

@mc_  I'd like to get clarification on what appears to be confusion between what a CAV and Call variable element will do. 

When I add a CAV to a callflow and inspect the data sent in a channel_xx webhook event, there is a custom_application_variables object, but there is nothing there (in all legs of the call). A previous response in this thread seemed to indicate that those would appear in webhooks. Can you confirm what should happen?

For a set call variable, it appears from the PR, that only if the key matches one of the two values in the code will it appear in the CDR summary from a GET cdrs call. Is this also the case? And will that value appear in a webhook event as well? 

For the PR mentioned above, what is the time frame for this to be available in the shared hosting platform? 

Thanks.

[mc_]

@Ken Rowland it is my expectation that using the 'set_variables' callflow action with '"data":{"custom_application_vars":{"my":"secret"}}' will cause all subsequent call events for this call leg to include '{"my":"secret"}'. If you add '"export":"true"` then the bridged call leg should also carry them.

If that's not the case, please open a support ticket so we can investigate. But we do have customers that rely on these CAVs being present and, AFAIK, we have not received additional reports of missing CAVs.

[FASTDEVICE]

@mc_ custom_application_vars DO NOT appear on callflow webhooks, hook_event : channel_bridge,  hook_event : channel_create.

[FASTDEVICE]

Any movement on this? Has there been a change that allows the CAV or any custom data for that matter to be inserted into the summary CDR and not just in the details? We need custom data in the summary CDR for quickly identifying the callflow path.  

[esoare]

55 minutes ago, FASTDEVICE said:

Any movement on this? Has there been a change that allows the CAV or any custom data for that matter to be inserted into the summary CDR and not just in the details? We need custom data in the summary CDR for quickly identifying the callflow path.  

That would be super! I get asked allot for, how many calls go to the Store (option 1), Shipping (option 2), Support (option 3),,,etc...

Seems like having that data in the CDR, would allow for reporting on such metrics. 

+1

esoare

[FASTDEVICE]

@esoare What you are asking for can be done with CAV described in the CDR detail. The issue is the CAV is only inserted in the CDR details and not in the CDR summary. There is a huge difference in the amount of processing it takes to search and process the detail CDRs vs the summary.  The idea is we can detect that a customer reached a menu from the Summary and then dig deeper into the CDR detail to determine which menu option they selected. Otherwise, we need to check every leg of every call just to determine they reached a menu.  It's time consuming. Looking for a better way.

Edited March 26, 2020 by FASTDEVICE (see edit history)

[esoare]

@FASTDEVICE I see.... For us "sys-admins" that is quite a bit of info to take in! :D 

But definitely see how that would help out with how many legs you process. 

Stay safe everyone! 

esoare