Jump to content

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


FASTDEVICE

Recommended Posts

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.  

Link to comment
Share on other sites

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:
image.png.09c3d015799f2a5d25547004cdc57f94.png

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. 

Link to comment
Share on other sites

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 by FASTDEVICE (see edit history)
Link to comment
Share on other sites

@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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2600Hz Employees

@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).

Link to comment
Share on other sites

  • 2 months later...

@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 by Ken Rowland (see edit history)
Link to comment
Share on other sites

  • 2 weeks later...

@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.

Link to comment
Share on other sites

  • 2600Hz Employees

@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.

Link to comment
Share on other sites

  • 2 months later...
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

Link to comment
Share on other sites

@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 by FASTDEVICE (see edit history)
Link to comment
Share on other sites

×
×
  • Create New...