Welcome to the RingCentral Community

Sorry for the hiccup on the site that your comments did not get posted. I am asking the support team to check and fix that. Thanks for reporting it.

Back to your question.

First of all, do you need to read the call log at near real-time? If the answer is yes, then you are right, you may miss call log items of active calls during the date/time range you read the call log. If the answer is no, you can alway read the call log a 24 hrs back from the current time, this would "make sure" to be out-of-range of those active calls.

For the Call log sync API, I noticed a couple of issues and am asking the team to investigate it to make sure it would work correctly. The problem is that it seems ignoring the 'dateTo' and always take the default current day. Another problem is that it returns call log items backward starting from the current date/time till the end. So calling the API with ISync using the syncToken will not getting the latest call log items.

At the moment we do not need to read the call log at near real time and a few hours delay is acceptable. Can I also have your thoughts on my other questions:

• Is the filter on the startTime (Get Company Call Log Records endpoint) by design or a bug? It makes more sense filter on the endTime...
• Is there any max duration imposed by RingCentral or a call can be active forever?

1. There is no 'startTime' filter but the 'dateFrom' means date and time and it reflects the 'startTime' on a call log item. I notice that the 'dateFrom' filter does not work as expected in the sandbox environment, but it works precisely on the production environment.

2. I don't think that we impose a max call duration.

Here is my quick test to verify the 'startTime' on the production env.

// Queries
{
  dateFrom: "2021-07-02T19:36:00.000Z",
  dateTo: "2021-07-03T16:57:59.999Z"
}

// Response
{"uri":"https://platform.ringcentral.com/restapi...",
"startTime":"2021-07-03T16:26:40.449Z",
========
...

{"uri":"https://platform.ringcentral.com/restapi...",
"startTime":"2021-07-02T19:36:36.765Z",

Change the dateFrom back one minute
// Queries
{
  dateFrom: "2021-07-02T19:37:00.000Z",
  dateTo: "2021-07-03T16:57:59.999Z"
}

// Response
{"uri":"https://platform.ringcentral.com/restapi...",
"startTime":"2021-07-03T16:26:40.449Z",
========
...

{"uri":"https://platform.ringcentral.com/restapi...",
"startTime":"2021-07-02T21:46:33.374Z",

When I was talking about the filter on the startTime, I was talking about your internal filter when you are returning the data. The example below illustrates my point:

Given the following call:

{
 "startTime":"2021-08-26T10:35:08.258Z",
 "duration":53, 
 **other fields removed**
}

Now if I execute the "Get Company Call Log Records" endpoint with the following date filters:

Execution #1:

dateFrom = "2021-08-26T10:35:08.258Z"
dateTo = "2021-08-26T10:35:08.258Z"   ---> call is returned

Execution #2

dateFrom = "2021-08-26T10:35:08.257Z"
dateTo = "2021-08-26T10:35:08.258Z"   ---> call is returned

Execution #3

dateFrom = "2021-08-26T10:35:08.259Z"
dateTo = "2021-08-26T10:35:08.260Z"   ---> call not returned

So this example allows me to assume that the filter is done on the startTime of the call, what is not the ideal scenario when you are exporting data using this endpoint. If internally the filter was done on the endTime of the call you can safely collect data (terminated calls) in near real-time without care about date offsets or duplicates.

Gotcha!

I think we execute on the startTime, not the endTime and that is by design. The call log data will not log any call data before the call ends and call recording is ready (if recorded). Let me check with the team about the reason why it filter on startTime.

Hi @Phong Vu do you have any news on this?

From my experience, the ideal design for this kind of endpoints is to use the call endDate for historic call log and the call startDate for active calls.

This approach have benefits for RingCentral and for the consumers because the consumers of the API will be able to continually get the call log data without the worry of missing call records, and using a the minimal number of requests (no need to deal with current active calls or deal with duplicates). For RingCentral perspective, this will reduce the number of traffic hammering the APIs.

I will discuss with the PM and with the engineering team. But to be honest, it will take long time.

Meanwhile, I found a solution for you with your original expectation of using the Sync and here is how it works.

1) First, call the account sync with FSync and set the recordCount to <= 250. You can ignore the dateFrom because it always starts from the current date and time.

2) Then call the account sync with ISync and set the recordCount to any number <= 250. Provide the syncToken returned from the previous FSync or ISync call.

Step 1) and 2) are called SyncDown, and it means that you are reading backward as far as you want to read or until all records in your call log database are read.

Let's say you want to read all records. Keep calling 2) until it returns no more records. Then

3) Call the account sync with ISync and omit the recordCount. Provide the syncToken returned from the previous ISync call.

Step 3) is call SyncUp. It means that it will read only new records since your last sync. Call step 3) and 2) until no more records then schedule to repeat step 3).

@Phong Vu thanks for your reply. I would also prefer to use the call-lo endpoint, but the reason why I was looking to the sync mechanism was to take advantage of the sync token and remove the responsibility to calculate the data differences from my system :) . Using the call-log endpoint I need to use the date-from and date-to filters to get new calls and I need to handle the scenario where I have active calls that start in a date windows but did not end on the same date window.

E.g.:

Call #1 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-01T00:00:00.000Z and dateto: 2021-08-01T23:59:59.999Z

Call #2 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-02T00:00:00.000Z and dateto: 2021-08-02T23:59:59.999Z

With these 2 queries I will miss all the calls that have started before 2021-08-01T23:59:59.999Z but ended after 2021-08-01T23:59:59.999Z. And If change the 2 call to use an offset of for instance 2h and change the datefrom to 2021-08-01T22:00:00.000Z I will need to handle duplications.

Is there any max duration imposed by RingCentral or a call can be active forever? Do you have any advice how to deal with this scenarios to ensure no data is missed? From my reading about the sync approach I also got the impression that a call data can change after its end, is that the case? Or is the call-log data for a call immutable as soon as it ends?

@Phong Vu thanks for your reply. I would also prefer to use the call-lo endpoint, but the reason why I was looking to the sync mechanism was to take advantage of the sync token and remove the responsibility to calculate the data differences from my system :) . Using the call-log endpoint I need to use the date-from and date-to filters to get new calls and I need to handle the scenario where I have active calls that start in a date windows but did not end on the same date window.

E.g.:

Call #1 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-01T00:00:00.000Z and dateto: 2021-08-01T23:59:59.999Z

Call #2 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-02T00:00:00.000Z and dateto: 2021-08-02T23:59:59.999Z

With these 2 queries I will miss all the calls that have started before 2021-08-01T23:59:59.999Z but ended after 2021-08-01T23:59:59.999Z. And If change the 2 call to use an offset of for instance 2h and change the datefrom to 2021-08-01T22:00:00.000Z I will need to handle duplications.

Is there any max duration imposed by RingCentral or a call can be active forever? Do you have any advice how to deal with this scenarios to ensure no data is missed? From my reading about the sync approach I also got the impression that a call data can change after its end, is that the case? Or is the call-log data for a call immutable as soon as it ends?

@Phong Vu thanks for your reply. I would also prefer to use the call-lo endpoint, but the reason why I was looking to the sync mechanism was to take advantage of the sync token and remove the responsibility to calculate the data differences from my system :) . Using the call-log endpoint I need to use the date-from and date-to filters to get new calls and I need to handle the scenario where I have active calls that start in a date windows but did not end on the same date window.

E.g.:

Call #1 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-01T00:00:00.000Z and dateto: 2021-08-01T23:59:59.999Z

Call #2 - GetCompanyCallLogRecords endpoint with datefrom: 2021-08-02T00:00:00.000Z and dateto: 2021-08-02T23:59:59.999Z

With these 2 queries I will miss all the calls that have started before 2021-08-01T23:59:59.999Z but ended after 2021-08-01T23:59:59.999Z. And If change the 2 call to use an offset of for instance 2h and change the datefrom to 2021-08-01T22:00:00.000Z I will need to handle duplications.

Is there any max duration imposed by RingCentral or a call can be active forever? Do you have any advice how to deal with this scenarios to ensure no data is missed? From my reading about the sync approach I also got the impression that a call data can change after its end, is that the case? Or is the call-log data for a call immutable as soon as it ends?