Recording a scheduled meeting

API and Webhooks
1

One developer brought up an issue with recording a scheduled meeting
using the ZR-CSAPI:

Regarding the ability to record meetings and also invite external
users by email not a “JID”. We have not been able to record a
“scheduled meeting” with an email as the api suggested, the last
version of the CLI API docs did mention there was some limitation. We
just need confirmation if we are doing everything correct on our
end. The Zoom Room has a google mail associated with with and we can
schedule and see the meetings correctly. The issue is recording an
active call using the CLI API.

I am going to ask one of our developers to respond here.

1 Like
2

What we found was that the ParticipantList is giving false status on the can_record

{ “ListParticipantsResult”: [
{ “audio_status state”: “AUDIO_UNMUTED”,
“audio_status type”: “AUDIO_VOIP”,
“avatar_url”: “”,
“camera_status am_i_controlling”: false,
“camera_status can_i_request_control”: false,
“camera_status can_move_camera”: false,
“camera_status can_switch_camera”: false,
“camera_status can_zoom_camera”: false,
“can_edit_closed_caption”: false,
"can_record": false,
“event”: “None”,
“hand_status”: { "is_valid: ": “off” },
“isCohost”: false,
“is_client_support_closed_caption”: false,
“is_client_support_coHost”: false,
“is_host”: true,
“is_myself”: true,
“is_recording”: false,
“is_video_can_mute_byHost”: true,
“is_video_can_unmute_byHost”: true,
“local_recording_disabled”: true,
“user_id”: 16778240,
“user_name”: “QA Zoom Room 1”,
“user_type”: “NORMAL”,
“video_status has_source”: true,
“video_status is_receiving”: false,
“video_status is_sending”: true } ],
“Status”: { “message”: “”, “state”: “OK” }, “Sync”: true, “topKey”: “ListParticipantsResult”, “type”: “zCommand”}

can_record is the state that our UI looks at to show a record button, the problem is this can_record never signifies true at even a scheduled meeting.

The only way we were able to make this true was by issuing an addtional command
zCommand Call AllowRecord Id: 16778240 Enable: on
after this we can issue the command to start or stop recording
zCommand Call Record Enable: on/off

The issue of false status comes up when we start a meet now meeting or join in a zoom meeting.
After joining a meeting we issue issuing an addtional command
zCommand Call AllowRecord Id: 16778240 Enable: on
to enable recording on our zoom.

At this point the zoom participant state will change to
“can_record” : true

but this causes an issue because when we issue the command
zCommand Call Record Enable: on/off

the response we recieve is
{ “CallRecord”: {}, “Status”: { “message”: “Result reason: “Need email address””, “state”: “Error” }, “Sync”: true, “topKey”: “CallRecord”, “type”: “zCommand”}

Our question is what is correct flow to get recording work for a zoom meeting, our approach to basing the off the participant list can_record does not seem consistent at all time. Thanks for the time.

3

Hello, for the listparticipants command please see the note given in its documentation: https://marketplace.zoom.us/docs/guides/zoom-rooms/zoom-rooms-cli/zCommands

The can_record field is unreliable/not applicable to the Host of the meeting or the Zoom Room itself. It should only be used for other non-host participants. For the Zoom Room itself, you should get a RecordingInfo event when you start the meeting which tells you whether or not the Zoom Room can record.

4

Hey Zach,

Thanks for that clarification, can you explain why we have to explicitly send out
"
The only way we were able to make this true was by issuing an addtional command
zCommand Call AllowRecord Id: 16778240 Enable: on
after this we can issue the command to start or stop recording
zCommand Call Record Enable: on/off
"

even when I am the host?

5

Hi,

Does the zCommand Call Record Enable: on/off work even when can_record for the host is false? If it does, then it is just a case of the listparticipants fields being inconsistent for the host and you should rely on RecordingInfo event instead. If zCommand Call Record: on/off does not work before issuing zCommand Call AllowRecord, then it might be a bug.