Host cannot send Closed Captioning messages via SDK, and gets 'false' for `isMeetingSupportCloseCaption`


I’m having difficulties integrating Closed Captioning support into a custom macOS app via the Zoom Client SDK.


  1. Even if I’m the meeting host/organizer and I’ve enabled Closed Captioning in my Zoom advanced settings, the ZoomSDKCloseCaptionController is returning NO for isMeetingSupportCloseCaption, and I receive NO for canSendClosedCaption
  2. If I log into the same meeting, with the same host/user, but in the Zoom desktop client, I can successfully send CC messages. Those messages are then received by the SDK in my custom app (for the same user) and reported via ZoomSDKCloseCaptionControllerDelegate onReceiveCCMessageWithString
  3. If I attempt to assign CC privileges to another user via the SDK assignCCPriviledgeTo, that works succesfully, and other users (in the Zoom Mac desktop client) can then send CC messages which the SDK receives

Which macOS Client SDK version?
5.5 (12509.0330)

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. Enable Closed Captioning support for your Zoom host in Advanced Settings
  2. Create a meeting and join as Host
  3. Retrieve the CC controller via -[ZoomSDKMeetingService getCloseCaptionController]
  4. Check the values of the controller for: isMeetingSupportCloseCaption and canSendClosedCaption. Both return NO.
  5. On a separate machine, join the same meeting with the same host account.
  6. On the Zoom desktop client, this same user can successfully enter CC messages (which the SDK receives via the ZoomSDKCloseCaptionControllerDelegate callbacks)
  7. However, as noted in step 4, the SDK reports that this exact same host user cannot send messages, and that CC is not supported for the meeting (even though the Zoom client can successfully send CC messages to this meeting)
  8. Join the meeting as a separate user in the Zoom desktop client, and via the SDK attempt to assign CC privileges to that user with assignCCPriviledgeTo
  9. Notice that this succeeds, and that user (in the Zoom desktop client) can then send CC messages successfully.

I thought perhaps as host I needed to call assignCCPriviledgeTo: with the host’s own ID, but if I attempt that I simply get a ZoomSDKError_WrongUsage.


Device (please complete the following information):

  • Device: Macbook Pro 13"
  • OS: macOS Big Sur 11.2.3

Additional context

Any help would be greatly appreciated.

The gist of the issue is that the SDK, although able to receive CC messages in the meeting from the host in the Zoom client, seems to report that the same exact user (host), in the same exact meeting, cannot send CC messages via sendClosedCaptionMessage (even though the Zoom client allows it).

Further, the SDK reports through -[ZoomSDKCloseCaptionController isMeetingSupportCloseCaption] that the meeting does not support CC, even though messages can actively be received.

The SDK allows me (as host) to assign CC privileges to another Zoom desktop client user for example, but I can’t find a way as host to send messages via - (ZoomSDKError)sendClosedCaptionMessage:(NSString*)ccString;.

Hi @matt.r.zoom, thanks for using the dev forum.

I really appreciate the detailed write-up of the issue you are facing! This will certainly help us track down the issue faster. :slightly_smiling_face:

I have tried to reproduce the behavior you are describing, but the only thing that seems to be working improperly based on my testing is that the isMeetingSupportCloseCaption property is returning an incorrect value. We will need to investigate what is causing this and identify a solution.

I have been able to successfully send closed captions programmatically through the SDK despite this issue and am seeing canSendCloseCaption return YES.

I thought perhaps as host I needed to call assignCCPriviledgeTo: with the host’s own ID, but if I attempt that I simply get a ZoomSDKError_WrongUsage .

Usually this will happen if it has already been assigned. On the first attempt of assigning this to myself, it returns success, but on subsequent attempts it is unsuccessful. Can you try calling this with a value of 0 instead of the host’s own ID and let me know if you are still receiving this error? In many instances, 0 is used to represent the current user in the SDK.

Also, what happens when you ignore the SDK’s return values and try to call sendClosedCaptionMessage?


Hi Jon,

Thanks very much for the follow-up. I think your suggestion of using assignCCPriviledgeTo: 0 has fixed several of the issues.

So after initially launching and joining a meeting as the host (where there is at least 1 other participant), these were the following results of the test code below (in sample below, cc is the closed captioning controller from -getCloseCaptionController, and the results are in the inline comments):

    BOOL isHost = [self userIsHost]; // YES
    BOOL supports = [cc isMeetingSupportCloseCaption]; // NO
    BOOL canAssign = [cc canAssignOthersToSendCC]; // YES
    BOOL canSend = [cc canSendClosedCaption]; // NO
    ZoomSDKError r1 = [cc assignCCPriviledgeTo:0]; //r1 = success, no error
    ZoomSDKError r2 = [cc sendClosedCaptionMessage:@"Test message 1"]; // error, no permission

In the above, the host is showing NO for canSendClosedCaption. Although the assign method reports success, I can’t immediately send messages.

However, after a brief delay, the message sending does start working. I’m assuming that there is some async code running in the SDK (network callback etc.) after the assign command, which has to return before messages can be sent.

In the last two tests, I’ve seen that after calling assignCCPriviledgeTo:0, I do eventually get a delegate callback onGetCCPrvilege. After that point, it looks like the canSendClosedCaption returns YES and I can send messages using sendClosedCaptionMessage.

So the only remaining issue is what you mentioned above, which is just that isMeetingSupportCloseCaption continues to report NO. But it looks like we should be able to ignore that and just rely on the other properties instead.

Thanks very much for your help,

Hi @matt.r.zoom,

I’m glad to hear things are looking better in your implementation! Upon further investigation, we determined that the reason isMeetingSupportCloseCaption's return value is inaccurate is because there were some changes made to how CC works in order to support the live interpretation feature which messed with how the SDK determines whether or not it is enabled. This should be resolved in a future release.


Hi Jon,

I seem to be hitting other issues with the Closed Captioning. In this case, I am getting a wrongUsage error when attempting to assign CC privileges to a user, even though the SDK is telling me that I can assign them.


(lldb) po sdkController.canBeAssigned(toSendCC: 16780288)

(lldb) po sdkController.assignCCPriviledge(to: 16780288)
▿ ZoomSDKError
  - rawValue : 4    // <--- WrongUsage error

The above happens both when testing directly in LLDB, as well as when using identical code in the compiled app. The basic flow I’m using for this test is fairly simple:

  1. Enable CC in Zoom settings for host
  2. Enter meeting (host user)
  3. With a separate user, enter the same meeting
  4. Check canBeAssignedToSendCC for the new user’s ID
  5. RESULT: SDK returns true
  6. Attempt to assign CC to that user, for the same ID
  7. RESULT: SDK returns error

Can you provide any insight into the mismatch here?

Hi @matt.r.zoom,

I have been able to reproduce this but haven’t found a solution yet. We will investigate this and keep you updated once more information is available.


Hi Jon,

I have been able to reproduce this but haven’t found a solution yet. We will investigate this and keep you updated once more information is available.

Thank you for the help. Do you know if there is any potential workaround for this problem?

I’m assuming an SDK fix would be necessary to correct this, but wondering if there are any alternatives we can use to allow assignCCPriviledgeTo to work.

Thanks so much

Hi @matt.r.zoom,

We have not identified any workarounds. I think you are correct in assuming that a new SDK version will be required to resolve this, but I will hold off on saying that will be the case for certain until we have identified a fix.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.