Am I required to fetch call log data by SessionId to get ALL call details?

I have a routine that extracts data from the call log and injects it into an analytics engine. I cam across a record yesterday that confuses me, because not all the data appears to be there. This is the record:

This was brought to my attention because the duration here shows 0. The client was complaining that he wasn't getting credit for the correct amount of time on the call. He insisted he was on the call for at least 3 minutes. So I did some digging. I didn't find anything else in the call logs (via api) when I did a search on date range and/or extension. However, I know that sometimes transferring a call in various ways can affect the session that the call is in. When I fetched data from the call log api using the session id (shown above in the data), I get an entirely different result, shown here:

As you can see, there is much more information in here, including the correct duration (over 3 minutes). So my question is: Do I need to look up the records by SessionID every time, to ensure that I am getting all the data necessary? For my purposes, I don't care about "linking" these calls together. I just need to extract the extension, the date, and the duration of the call. So if the transfers (shown in the second, longer record) show up as separate calls in the call log (when searching by date only), that's fine. However, that additional information does not show up in the call log when I do a search by date (and not session). It appears to me that the only way I can get this additional information (and in this case, the correct call duration) is to do an additional fetch to the call log api using the sessionId that I get from the first call. Is this expected behavior? Or am I missing something? If I have to do that, then I am going to be making thousands of more calls to the api to ensure I am extracting all the necessary data, and I'm probably going to start getting throttled. Plus, that just seems unnecessary to satisfy a small number of fringe cases like this.

Just to give some additional info: This instance is the exception to the rule. Most calls have the correct duration in the call log without using the sessionId. Also, in this case, this was a call that was transferred to a soft phone, and answered using the RC app. And from what we can tell, all other calls that are not answered by the app (but answered by a desk phone) give us the information we need without any additional api call. So I think the transfer (and usage of the app) has something to do with it.

Hi Phong, in looking at this again, I found something interesting. I AM getting ALL the data I need, even when I search by date range (not sessionId). But all the data was not there the first time I pulled the record (that first record above is a snapshot of the very first time we pulled data from it). So this appears to be a timing issue, not a sessionId issue. I think what's happening is that the call is showing up in the call log (via the api) before the call is actually complete. And that would make sense, because the new record shows a lastModifiedTime around 4 minutes after the startTime. And the duration of the call is around 3.5 minutes.

So it appears that the record is getting updated after it shows up in the log. I'll probably post a new question, since I didn't fully understand what was going on here. But, do you know if there is some way I can look at the record the first time we pulled it (showing a duration of 0, above), and determine that I need to look at it again, because the call may be getting transferred? I noticed that it has an action of "FindMe" and a result of "Busy". Is that any kind of indication?

My first guess was also about the timing and that was why I was asking how you called the API. Normally it takes about 20-30 secs for the system to update the call log. The delay could be longer if a call has multiple legs and call recording enabled. No, the action FindMe is not an indication of the readyness of the call data.

For archiving, I recommend you to sync or read the call log periodically with at longer delay (let's say a few hrs or a day) to make sure the system has sync completely all call data for that period . If you need the data instantly for real time or near real time analytics, you can use the active call API to get the call log data.