I'm looking to get the full call ID key from the short call ID for better reporting purposes (the source of the short call ID is call attribute Eic_ConferenceMembers). Does anyone know of a build in method that might accomplish this, or failing that the least resource intensive way to harvest such?

The Eic_CallIdKey attribute holds that value for a call (there is no equivalent for a ConferenceId) So, in the CustomCallDisconnect handler you can access the Eic_CallId, Eic_CallIdKey, and Eic_ConferenceId attributes. Another attribute you would probably find useful is the CallLog attribute. It contains an entry that shows when the call is added to a conference, including the ConferenceId. Parse that attribute to find each occurrence of "conference" and pull out the 10 characters following the space after conference. [ATTACH]805[/ATTACH]

Originally posted by GGanahl;35046
The Eic_CallIdKey attribute holds that value for a call (there is no equivalent for a ConferenceId) So, in the CustomCallDisconnect handler you can access the Eic_CallId, Eic_CallIdKey, and Eic_ConferenceId attributes. Another attribute you would probably find useful is the CallLog attribute. It contains an entry that shows when the call is added to a conference, including the ConferenceId. [ATTACH]805[/ATTACH]

Thanks George. I know about and use those attributes already, too :) I thought I'd just list the source of where I'm getting the IDs from for completeness' sake but it seems to have muddied the waters. All I'm really looking for is a quick and easy way to get the full call id key from the call id via something built in such as a toolstep or subroutine, or if someone knows of a quick and easy way to do so if not.

Ok...what I would do is pull the Eic_ConferenceMembers attribute, parse out each of the Eic_CallIds from it, use the "Convert String to CallID" tool to convert to the CallID, then use the Get Attribute toolstep to get the Eic_CallIdKey. You have to do that before the calls deallocate from the system (about 2 minutes after disconnect) so that the CallIds are still valid.

Originally posted by GGanahl;35048
Ok...what I would do is pull the Eic_ConferenceMembers attribute, parse out each of the Eic_CallIds from it, use the "Convert String to CallID" tool to convert to the CallID, then use the Get Attribute toolstep to get the Eic_CallIdKey. You have to do that before the calls deallocate from the system (about 2 minutes after disconnect) so that the CallIds are still valid.

Yah, that was my preliminary thought too, but I was worried about missing that allocation window and/or it taking up a lot of resources to do so - any ideas on how much of a system resources hit it is to instantiate 4 or 5 call objects at once, for instance? We have a 1200 person contact centre, so the potential load is not inconsiderable.

I'm asking around...

Before you go too far down the custom path...have you looked at Interaction Tracker? It already has reports which allow you to see conference calls and the parties involved, grouped by IC User. Tracker Interaction Segment Summary by IC User, and Tracker Interaction Segment Detail by IC User

Originally posted by GGanahl;35051
Before you go too far down the custom path...have you looked at Interaction Tracker? It already has reports which allow you to see conference calls and the parties involved, grouped by IC User. Tracker Interaction Segment Summary by IC User, and Tracker Interaction Segment Detail by IC User

Yes, unfortunately Interaction Tracker won't solve the issue we're trying to address with this report :/ Good suggestion tho, thanks!

Bummer. I haven't had a response on the resource usage yet.

Originally posted by GGanahl;35054
Bummer. I haven't had a response on the resource usage yet.

No worries. Thanks for taking up the flag! If someone does get back to you, I'd certainly like to know :)

Per Dev: "...if it’s just pulling attributes off of existing interactions that shouldn’t be too expensive. IP already has the attributes cached, so there wouldn’t be a round trip to QM to get them. It seems like the worst case is that it would tie up a thread in IP for longer than usual."

Originally posted by GGanahl;35059
Per Dev: "...if it’s just pulling attributes off of existing interactions that shouldn’t be too expensive. IP already has the attributes cached, so there wouldn’t be a round trip to QM to get them. It seems like the worst case is that it would tie up a thread in IP for longer than usual."

Many thanks! So it sounds like it is reasonable to assume it won't be a big resource hit then.