Jump to content

Recommended Posts

Posted (edited)

A couple of our client's systems are getting quite large and we are running into an issue. That issue is we frequently can't figure out how a particular call was routed to a particular phone/user/mailbox. To dig further into this we need to put a ticket in with support to have the logs pulled. This works, but it's not optimal. So, I considered putting caller ID prepends into each menu options. But, some of the menus get 3-4 deep and that's just too many prepends, users would have trouble seeing hte actual caller ID. Then it occurred to me, there's a few zero width unicode characters. I could prepend with those... But if I do that, am I going to break anything? Has anyone done this before?

I was considering using:

U+200B

U+200C

U+200D

U+200E

and

U+200F

Edited by Rick Guyton (see edit history)
Posted

There's a new option in each prepend, To either ignored the old ones or to add to the old prepends,  I'm not by a computer so I'm not sure what the options are,  but look at the prepare box, 

Posted (edited)
17 minutes ago, Tuly said:

There's a new option in each prepend, To either ignored the old ones or to add to the old prepends,  I'm not by a computer so I'm not sure what the options are,  but look at the prepare box, 

Oh, good point, I didn't think about that. That'd make the situation a lot better.

 

But, I'm still curious about those zero length unicode characters though. It'd be nice to be able to track this by looking through CDRs without it popping up on user's phones.

Edited by Rick Guyton (see edit history)
  • Administrators
Posted

There's a new callflow action, "set_variables", that you can use in Kazoo 4.2+ to set key/value pairs on the call. These will then exist on call events and the CDR under "custom_application_vars". This is probably the saner way to accomplish your goals.

Posted (edited)
49 minutes ago, mc_ said:

There's a new callflow action, "set_variables", that you can use in Kazoo 4.2+ to set key/value pairs on the call. These will then exist on call events and the CDR under "custom_application_vars". This is probably the saner way to accomplish your goals.

Man, everything I want is always in the next release. :) Not sure if that's a good or a bad thing. But, yea, that seems a lot more sane a way to address this. I'll wait. Out of curiosity, can you append to existing values? For instance could I have a key "menus" that's set to ":LocationAMainMenuOpt3", and then later append ":LocationBMainMenuOpt4" to that?  This way later, I could split on ":" and know the client originally called location A and punched a menu to go to location B and pressed option 4 there as opposed to calling Location B directly and pressing option 4?

Or maybe (even better) can I assign a key like "Menu_%Timestamp%"?

Edited by Rick Guyton (see edit history)
  • Administrators
Posted

At the moment, no, its simple key/value pairs and the old value is overwritten. You can file feature requests like above so we don't lose track of them though.

×
×
  • Create New...