Exporting Live Calls - Event Trigger vs. API

Talk with others about developing applications for Switchvox

Moderators: bmdhacks, dpodolsky, tristand, jwitt, joshuas

Exporting Live Calls - Event Trigger vs. API

Postby abelincoln » Wed Oct 21, 2015 3:08 pm

I was trying to post to the SwitchVox developer forum, but trying to add a 'new topic' directed me here.

Goal:
We're attempting to export call records to a website in real-time so we can append metadata to them (while on the call) and integrate them with other activities. We had hoped to be able to do so with event triggers (POST being so much less resource intensive for capturing 'live' calls than repeated API calls).

Problem:
It appears events do not have any universal ID for the call they relate to, which means we're effectively creating 3+ unrelated phone records per actual phone call (incoming call events being triggered even when a call is transferred within SwitchVox, and similar behavior with other event triggers).

Digium support told me "Unfortunately that’s how our system logs the calls, each time the call is transferred to another queue or phone it [creates] another JOB_ID and there is no way around this at this time" and then suggested I look here.

Is there any way to reliably relate events together that are part of the same call or to otherwise capture live data without having to hammer the API?

Solutions?:
1. Use the API (as it seems to have a common ID per phone call) if we want 'active' calls to appear - we'll have to live with sending multiple requests per minute, which is going to be a performance hound. Perhaps telling the API to check only when an event triggers would be a viable option? (i.e. check for new live calls on 'incoming' events and check for call complete on 'hang up' events, though we're certain to get at least 50% false alarms.
2. Use the API but only export completed calls (pull data retroactively) - the downside here is it would be ideal to allow users to add data/notes while the call is live. This is also still more intensive than POST.
3. Somehow figure out how to string individual events together - possibly based on when one event ends and another begins related to the same user... Of course, this is almost certainly fraught with complexities and pitfalls.
4. Abandon Switchvox if we want to accomplish our goal.
5. Other suggestions?
abelincoln
Newsterisk
 
Posts: 1
Joined: Wed Oct 21, 2015 2:40 pm

Return to Switchvox Developers

Who is online

Users browsing this forum: No registered users and 3 guests