switchvox.callLogs.search date criteria

[dwinkel]

The date/time criteria for the call log search API seems pretty straight forward.

From the docs:
start_date: Calls with a start time greater than or equal to this value will be returned.
end_date: Calls with a start time less than or equal to this value will be returned.

I am getting results that don't follow those rules and are inconsistent. Here is a subset of the data for a small time range:

Search start: 09:55:00 end: 10:00:00 returns call ids:
7224 (started at 9:57)
7226 (started at 9:56)
7218 (started at 9:54) - why?

Search start:10:00:00 end 10:05:00
7233 (started at 10:03)
7224 (started at 9:57) - why?
7223 (started at 9:43) - why? and why wasn't it included above?

Thanks in advance for any light anyone can shed on this.

[dpodolsky]

It looks like you are hitting a behavior quirk with our logs. Some developers might like this behavior, but I see this as an issue and will log it in our system. However, this is minor since there is an easy work around.

Currently the logs are aggressive in what they return. The extra log results you are seeing is because the callLogs search also return any calls that have logged any events during your time segment.

7218 (started at 9:54) - why?

You will have to verify the logs. But my guess is that the call has a hang up event past the 9:55 mark which includes it in the query.

7224 (started at 9:57) - why?
7223 (started at 9:43) - why? and why wasn't it included above?

7724. Same answer as above. Hangup event past 10:00
7223. YOu will have to verify. My guess is that the call has a hangup event around the 10:05 time. Since the call doesn't have any events from 9:55 to 10:00 it doesn't show up.

The work around here is to filter the logs after you grab them. You can just parse the logs and then if the start_time on the call tag doesn't fit in your time segment remove it for processing. I have filed the bug / request to make the callLogs less aggressive with their capturing.

[lorsungcu]

The work around? The OP's question was "Why, if the docs say this, am I getting these results?" This isn't a question of something being aggressive or not, either the documentation or the API is incorrect and needs to change. When that change is made, the documentation needs to be updated to reflect what actually happens with the API.

[dpodolsky]

I believed I answered the OP's question on why he is seeing the results and do agree this is not desired behavior. Thus my last sentence about filing this as a bug and getting it fixed.

I have filed the bug / request to make the callLogs less aggressive with their capturing.

The work around I included is because I liked to go beyond the original question and also attempt provide a solution to the problem. Which I encourage on all posts.

lorsungcu, your post comes off as hostile. These forums are a place where people come to freely exchange information and find answers to their questions. Everyone on the board does their best to answer questions to the best of their ability and keep the conversation civil. Please try to follow these guidelines.

[jrusk]

We would like to export all call logs to an external system in nearly real-time as possible.

I have a script that queries Switchvox every 5 minutes for all calls from 5 minutes ago. For example, if the time is currently 10:15 then the script requests the calls from 10:05 through 10:09. It does this using switchvox.callLogs.search and the start_date and end_date, like this:

<request method="switchvox.callLogs.search">
<parameters>
<start_date>2012-05-30 00:10:00</start_date>
<end_date>2012-05-30 23:10:09</end_date>
</parameters>
</request>

However, like the poster above, we are having problems. Like David said, switchvox.callLogs.search is quirky. For example, calls that start and/or stop outside of our range may never be pulled by our script. Is there an alternative way to reliable pull call log data? As is I think that switchvox.callLogs.search is only reliable as a historical tool to pull relatively large ranges.

What we need is a database time stamp. Thus I could pull all CDR records written between 10:05 and 10:09. Each API query could reliably pull data without concern for the particulars of the individual call events. Pulling CDR is one of the most important API features and switchvox.callLogs.search is the most important method. Right now it seems that its usefulness is unduly limited.

Or maybe there is a better way to solve the problem? Thoughts?

Thank you, Jonathan

[lorsungcu]

There is not a better way. You need to also look at the behavior of logs when calls are transferred; it does not work as you would expect.

There needs to be ODBC access to the CDRs. Unduly limited is an understatement.

[jdrusk]

David,
Is there no means to reliably and accurately pull call log records from Switchvox? The call and queue logs and reports are the MOST important methods of the API.
Thanks!
Jonathan

[dpodolsky]

Greetings,
The problem here is a misunderstanding about the goal of the call logs. The callLogs.search is not intended to be used for real-time call log processing. It is intended to be a reliable and accurate way to get historical information on calls that were "completed" in the system. If the calls have not been completed then they aren't/can't be in the call logs yet. The call logs includes all the events, talk duration, and call duration and that information is calculated and logged at call completion. Even the requested ODBC access is not a solution because the call logs doesn't exist in the database yet. Once the call is completed, and the start time is between your API request, it will reliably be in the results.

If you want realtime call or queue information, then you need to use the mechanisms in the product that are intended for this use.

1. CurrentCalls and callQueues.getCurrentStatus.

Notice, the "current" in the name. These APIs are intended to give you realtime information on calls and queues in the system.

http://developers.digium.com/switchvox/ ... rentStatus
http://developers.digium.com/switchvox/ ... ls.getList

2. Event Triggers
If you want to know realtime information on calls then use the event triggers to know exactly when a call starts and when a call ends.

I hope this helps get everyone on the same page.

[jdrusk]

I don't think it is the customer's misunderstanding, rather maybe it is Digium's misunderstanding? What we want is an accurate method to pull all CDR records from Switchvox with the option to do so as near to the records being written to the database as possible. So we don't want realtime nor current call information but we want historical CDR as soon as we can get it without missing records. I am fine using Extend API if it does what we need.

How do you recommend we programmatically export the call log to an external system? The customer would like all calls be written to their external database within minutes of the call being written to the Switchvox CDR database. But I don't think that the Extend API favors this. Perhaps we'll have to be one day late? Or maybe export longer durations much later than desired? But I still think we'll miss records.

For example, let's say my script runs every hour and pulls all calls from the previous hour. Two consecutive runs might look like this:

1st run: time right now (script run time): 2012-06-06 10:00:01
<start_date>2012-06-06 09:00:00</start_date>
<end_date>2012-06-06 09:59:59</end_date>

2nd run: time right now (script run time): 2012-06-06 11:00:01
<start_date>2012-06-06 10:00:00</start_date>
<end_date>2012-06-06 10:59:59</end_date>

What happens if a call with start_date = 2012-06-06 09:10:00 and a call end_date 2012-06-06 10:05:00? Thus the call duration was 55 minutes and 1 second but it started within the first call start_date time and ended in the second call end_date time. Or what if another call start_date = 2012-06-06 09:55:00 and a call end_date 2012-06-06 10:05:00? Will these calls never be pulled by my script? If so then the only way to not miss calls is to have a start_date and end_date that is greater than the longest call possible (which theoretically is infinite .

I guess I just need to know exactly what to expect from callLogs.search so that we can design around it or conclude that we can't reliably export CDR the way the customer wants.

[lorsungcu]

There needs to be ODBC access. There is no valid argument for putting an inflexible layer of abstraction over the CDR. Let us design applications around something standard, rather than waiting for Digium to decide how we should see CDR.

[dpodolsky]

There needs to be ODBC access.

That is a fine request, however, that does nothing for the current topic. Like I pointed out previously, the call is not/can not be in the database before the call is completed. No matter if the API request is via XML or ODBC, both can't give you something that does not exist.

[dpodolsky]

How do you recommend we programmatically export the call log to an external system? The customer would like all calls be written to their external database within minutes of the call being written to the Switchvox CDR database. But I don't think that the Extend API favors this. Perhaps we'll have to be one day late? Or maybe export longer durations much later than desired? But I still think we'll miss records.

You answered your question with your solution. Increase your range. If I wanted to accomplish your goal I would increase my query results to start from the beginning of the day (12am) and end at the current time. This would return me all the calls that had started and completed that day. I would log all these calls and be sure to write down the unique call id. I would run this query every 5 minutes and check for any new call ids that I had not seen previously and log those calls. This would make my external call reports accurate up to the 5 minute mark. Searching an entire day of call logs for a unique ID is trivial and would not cause loads on the PBX or the processing server even with thousands of calls.

Caveat of this approach: If the customer started a call the previous day late at night and went into the current day that call would be missed. However, you can evaluate if this ever happens with your customer. If you think this might occur then increase your range to the previous day. If you think your customer has a call that spans 3 days, then it sounds like a great place to work.

===

A feature improvement to the API I see would be to add a start and end parameter to the API that would allow your to query all calls that have been completed (hung up) during a timeframe. This way you would query the API every 5 minutes and get all the calls that had completed during that timeframe. This would narrow the requests to the server and save a unique ID lookup. I have entered this feature request into our system.

[jdrusk]

Okay, thank you David. This is less than what the customer wants (and many other's I'm sure too) but we'll work with it. Yes, that is a good feature request.

[rit]

Last post was Jun 7th, now it's Nov 9th.

Any news on this feature request?

The current search is unreliable or needs a reasonable amount of code to remove duplicates. The event trigger method is fine until the receiving webserver goes offline for a moment and there's no way to get that data back. Requesting by date/time that the call was completed sound like a bulletproof way of getting call records.