New Resource: Phone Call Recordings, Phone Call Recording Transcripts

[Eclyocy]

(Looks to be a part of ZoomNet enhancement https://github.com/Jericho/ZoomNet/issues/22)

Hello Jericho.

We require retrieving Zoom phone call recordings and transcripts, and we'd like to continue using ZoomNet for this purpose. I intend to use these two endpoints:

• https://developers.zoom.us/docs/api/rest/reference/phone/methods/#operation/getPhoneRecordingsByCallIdOrCallLogId
• https://developers.zoom.us/docs/api/rest/reference/phone/methods/#operation/phoneDownloadRecordingTranscript

I plan on adding:

• new resources (IPhoneCallRecording interface and its implementation -- for stated above endpoints);
• several models (PhoneCallRecording and several required enumerators, as said enums are slightly different from Zoom meetings);
• a bit of tests (for checking the json parsing).

I have (mostly) implemented and tested the changes locally. If needed, I can provide screenshots from Postman.

My current concerns:

1. Some fields are documented in zoom docs, but they are not returned (e.g.: outgoing_by, accepted_by, owner.extension_status). I plan on not including them to the implementation.
2. Some fields are not documented in zoom docs, but they are returned (e.g.: file_url, recording_type, site.id, disclaimer_status). I plan on including them with a remark that these are not documented by zoom. "download_url" vs undocumented "file_url": These fields both provide links for downloading the phone call recording, but "download_url" does not include authentication token, whereas "file_url" includes it as a request path parameter. I plan on using the latter, "file_url", as I require downloading the actual .mp3 file.
3. I am also unsure regarding the integration tests, as the endpoints in question rely on actual call ID, not user ID.

In case this enhancement would be rejected, we'll have to rely on fork repository, which is not ideal. I plan on attaching the PR tomorrow.

[Jericho]

I would definitely welcome a PR to add the "Phone" resource. I attempted to do it myself some time ago but I put my effort on hold when I realized that I do not have the necessary permissions.

Regarding the new resource: my plan was to add a single resource called "Phone" to group all the phone-related methods such as GetRecordings, DownloadTranscripts, GetAllCallingPlans, AssignPhoneNumber, etc. I thought this would make the methods easier to discover than having several resources (such as "PhoneGroups", "PhoneNumbers", "CallRecordings", "PhonePlans", etc) each with their own set of methods.

Regarding the "missing but documented" and the "present but undocumented" fields: I have observed the same frustrating situation and I struggle with the decision whether to include the field in question every time. It's a judgement call on your part whether you want to include them or not. Personally, I tend to include all documented fields even when I observe scenarios where they are missing. My justification is that the API may have omitted them because they are not relevant in my particular scenario but they might be included in another scenario. The other thing to consider is that some time in the future, a developer might raise an issue to complain that they expected a given field to be modeled in ZoomNet but this field is nowhere to be found and now I will have to try to remember if there was a reason why we omitted this field or if it was a mistake on our part. At the end of the day it's a judgement call and there is no right or wrong answer. I'm going to rely on you to make that call. Two thumbs up for your idea to add a comment explaining that a given field is undocumented.

[Eclyocy]

Hello again and thank you for such a quick answer.

I will change the resource main name to a more general then. I'd like to point out that -- as I understand -- from all the zoom phone endpoints only the "get user call logs" is implemented (under https://github.com/Jericho/ZoomNet/pull/274/files#diff-5c2fc75169790db8d982aa9fe742ea33d461db0d70a31c964c7e3a4bd69ab041) -- as a separate resource though. I don't think I should move it around, though, somebody might be using it already, -- just food for future thoughts.

I see your point regarding the (un)documented missing/present fields, I'll think it over.

[Jericho]

You're right about the CallLog resource. I think it will make sense to migrate its one method to the "Phone" resource after we merge your PR but will have to take great care to minimize breaking developers code as much as possible.

[Eclyocy]

Hello again, Jericho. I am sorry it took longer than I expected. I have opened a pull-request for you.

As you suggested, I've created a dedicated resource file for ZoomPhone apis. I've also added the documented fields which I haven't been able to obtain. I haven't added any integration tests.

Please let me know if anything is amiss.

[Jericho]

Resolved by #320

[Jericho]

:tada: This issue has been resolved in version 0.67.0 :tada:

The release is available on:

• GitHub Release
• NuGet Package

Your GitReleaseManager bot :package::rocket: