Intermittently unable to find recordings by callsessionid using the call-log method

Question

question

dave-welch asked · Mar 08, 2018 at 08:22 PM

Intermittently unable to find recordings by callsessionid using the call-log method

We have successfully been downloading recordings for several years. since the latest Ring Central network outage last Friday we have been intermittently been unable to find recordings by call sessionid using the call-log method. The recordings show up on the Ring Central customer site call log and we can download them there but we cannot find them using the API. We need help to determine if the call sessionid that we are using is correct and what the solution is.

aaa

1 |1000 characters needed characters left characters exceeded

Attachments: Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Answer 1 · 2018-03-09T15:54:00Z

Phong Vu answered · Mar 09, 2018 at 03:54 PM

Hi Dave,

Can you give more details how did you read recorded calls using sessionId? According to the API reference, the sessionId query parameter cannot be specified alongside with parameters 'dateTo', 'dateFrom', 'phoneNumber', 'extensionNumber', 'type', 'transport', 'direction', 'withRecording','recordingType', so please double check if it is the cause in your case.

When you were unable to find recordings, did you get an error message or an empty response?

How soon did you try to get the recording after a call was ended? Remember that the recording is available after some 30 secs after a call ended.

Using the call-log API to read call log without the sessionId, did you get the "recording" object in the response for those calls with recording? If you get the recording block, can you read the recording using the recodingId with this endpoint /restapi/v1.0/account/~/recording/{recordingId}?

Please check and let me know further background info so I can help.

Kind regards,
Phong Vu

1 |1000 characters needed characters left characters exceeded

Attachments: Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Answer 2 · 2018-03-09T19:15:56Z

dave-welch answered · Mar 09, 2018 at 07:15 PM

1. We place the call with /restapi/v1.0/account/~/extension/~/ringout

2. We get the sessionid using /restapi/v1.0/account/~/extension/~/presence?detailedTelephonyState=true

3. We save the sessionid and the call time.

4. Once the call is completed, we get the call log with the call-log method. It is run every two minutes. The dateFrom is determined by the earliest call start time of calls completed since the last call-log attempt. The dateTo is determined by the call end time of the last call completed prior to the current call-log lookup.

Here is a sample: /restapi/v1/restapi/v1.0/account/~/call-log?perPage=1000&page=1&view=Simple&recordingType=All&dateFrom=2018-03-07T14:15:00.0000000Z&dateTo=2018-03-07T14:17:00.0000000Z.

5. We parse this response looking for the sessionid.

6. When we find the sessionid we parse the associated record for the media link;

7. We download the recording using the media link

The problem occurs in step 5. We are not finding any records with the sessionid we are looking for. It is not related to the date window. We have tried using the call-log method with times that encompass the entire day which downloads thousands of call records and have been unable to find the call by sessionid.

This is happening up to 20% of the time. This problem started this week. There have been no changes to code or RC settings for several months.

These calls have recordings attached. We can find them using the customer portal to view the call log. So either we have an incorrect sessionid or the call-log method is not working as expected. It is hard to believe that we have the wrong sessionid since during the call we get call state information using PubNub referencing that sessionid.

4

1 |1000 characters needed characters left characters exceeded

Attachments: Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Phong Vu ♦♦ · Mar 12, 2018 at 03:52 PM

Hi Dave,

checking with the engineering team and I heard that there has been some issue with the call log during the past few weeks. They are working on fixing the problem so there is no need to change your code.

I will update you as soon as I get more info about this.

Thanks for your understanding!
Phong Vu

0 ·

dave-welch · Mar 14, 2018 at 03:43 PM

Yesterday we had a good day. Very few missing recordings. Less than 1%. Today we are over a 25% failure rate. The connection to the Ring Central server has been forcibly close by the RC server 10 times this morning. This does not usually happen.

0 ·

Phong Vu ♦♦ · Mar 14, 2018 at 03:57 PM

Hi Dave,

Thanks for reporting! I will let the eng. team know about this.

Br,
Phong

0 ·

dave-welch · Mar 14, 2018 at 07:36 PM

Our failure rate is now around 30% for the day. I have noticed that the call session id is different for the failed recordings. The structure is as follows:

The ones I can recover have a call session id like 539 ###### 018. The first three numbers are 539 and the last three numbers are 018. The middle six numbers will increment with each call.

The recordings I cannot recover have call session id like 147 ####### 019 The first three numbers are 147 and the last three numbers are 019. The middle seven numbers will increment with each call.

I hypothesize that these numbers come from different servers. There is no documentation stating what the parts of the number mean but I guess the first three refer to the server and the last three refer to the client (SERVICE 800). Perhaps there is an incorrect entry on one server as an example maybe it should be 018 not 019. In any case, I am just guessing on the number components but there is a difference.

0 ·

Developer Community

Customer Community

question