Floor Access Control

In Lecture Mode, the room operates with a single publisher — the moderator — while all other participants join as listeners. When a participant wants to speak, they must request floor access from the moderator. The moderator can grant, deny, or revoke that access at any time. Alternatively, the moderator can proactively invite any participant to the floor without waiting for a request. Only one participant can hold floor access at a time.

This page covers the full floor access lifecycle: the APIs each role calls, the delegate methods that fire in response, and the error codes you may encounter.

There are two ways floor access can be initiated — by the participant who wants to speak, or by the moderator who wants to invite someone. Both flows end with the participant publishing their stream to the room.

Participant-Initiated Flow

This is the standard "raise your hand" pattern. The participant signals intent, and the moderator decides whether to allow it:

1. Participant calls requestFloor — the moderator receives didFloorRequestReceived: with the requester's client ID and display name.
2. Moderator calls grantFloor:(clientId) — the participant receives didGrantedFloorRequest: and may now publish their stream.
3. When the participant is done speaking, they call finishFloor — the moderator receives didFinishedFloorRequest: and the floor is free for the next request.
4. If the moderator needs to reclaim the floor before the participant finishes, they call releaseFloor:(clientId) — the participant receives didReleasedFloorRequest: and their publishing rights are revoked.

Moderator-Initiated Flow

The moderator can skip waiting for a request by directly inviting a participant to the floor. The participant then chooses to accept or decline:

1. Moderator calls inviteToFloor:(clientId) — the targeted participant receives didInvitedForFloorAccess:.
2. If the participant accepts, they call acceptInviteFloorRequest:(clientId) — all moderators in the room receive didAcceptedFloorInvite:.
3. If the participant declines, they call rejectInviteFloor:(clientId) — all moderators receive didRejectedInviteFloor:.

A participant calls requestFloor when they want to speak. This sends a floor request to the moderator, who then sees the requester's identity and can choose to grant or deny it. The participant's stream is not published at this point — publication happens only after the moderator grants access.

Delegate Methods

The delegate payload at data[0] is a dictionary with the requesting participant's identity:

// data[0] structure received by the moderator:
// {
//   "clientId": "XXXX",
//   "name": "ParticipantName"
// }

Error Codes

// Participant requests floor access
[room requestFloor];


// MARK: - Moderator receives the floor request

-(void)didFloorRequestReceived:(NSArray *)data {
    NSDictionary *requester = data[0];
    NSString *clientId = requester[@"clientId"];
    NSString *name     = requester[@"name"];

    // Present an approve / deny UI to the moderator
    NSLog(@"Floor requested by %@ (%@)", name, clientId);

    // Grant access
    [room grantFloor:clientId];

    // Or deny access
    // [room denyFloor:clientId];
}

A participant can withdraw a floor request they previously sent, as long as the moderator has not yet acted on it. This is the "lower your hand" action — useful when the participant no longer needs the floor or the topic has moved on.

Delegate Methods

Error Codes

When the moderator decides not to allow a floor request, they call denyFloor: with the requesting participant's client ID. The participant is notified of the denial and their request is cleared from the queue, making the floor available for other requests.

Delegate Methods

The denial notification received by the participant at data[0]:

// data[0] received by the denied participant:
// {
//   "result": 4117,
//   "msg": "Floor Request Denied",
//   "clientId": "XXX"
// }

Error Codes

When the moderator approves a floor request, they call grantFloor: with the participant's client ID. Once granted, the participant receives their delegate callback and may immediately publish their stream. Remember: only one participant can hold the floor at a time. If someone else already has it, you must call releaseFloor: first.

Delegate Methods

The grant notification received by the participant at data[0]:

// data[0] received by the granted participant:
// {
//   "result": 1708,
//   "msg": "Floor Granted",
//   "clientId": "XXX"
// }

Error Codes

// Moderator grants floor access
[room grantFloor:@"clientId"];


// MARK: - Participant receives floor grant

-(void)didGrantedFloorRequest:(NSArray *)data {
    // Floor access confirmed — publish the local stream now
    [room publish:localStream];
}


// MARK: - Moderator ACK

-(void)didProcessFloorRequested:(NSArray *)data {
    // Floor successfully granted to the participant
    NSLog(@"Floor granted: %@", data[0]);
}

When a participant has finished speaking, they call finishFloor to voluntarily release the floor. This signals to the moderator that the floor is free and the next pending request can be handled. The participant should also unpublish their stream at this point.

Delegate Methods

Error Codes

When the moderator needs to reclaim the floor from a participant — for example, because the participant is not responding or has overrun their time — they call releaseFloor:. This forcefully revokes the participant's publishing rights. You must also release the current floor holder before granting access to another participant.

Delegate Methods

The release notification received by the affected participant at data[0]:

// data[0] received by the participant whose floor was released:
// {
//   "result": 1712,
//   "msg": "Floor Released",
//   "clientId": "XXXX"
// }

Error Codes

If the moderator disconnects and successfully reconnects to the room, the floor request queue is not lost — EnableX preserves it in the room's metadata. After reconnecting, the moderator can read this data to restore their floor management UI exactly as it was.

Two arrays in room.roomMetaData capture the current floor state:

• raisedHands — An array of client IDs for participants who have an active, pending floor request.
• approvedHands — An array of client IDs for participants who currently hold floor access (at most one entry, since only one participant can hold the floor at a time).

// Read floor state after moderator reconnects
NSArray *raisedHands   = room.roomMetaData[@"raisedHands"];    // Pending floor requests
NSArray *approvedHands = room.roomMetaData[@"approvedHands"];  // Current floor holder(s)

// Rebuild the moderator UI
for (NSString *clientId in raisedHands) {
    // Show pending floor request badge for this participant
    [self markPendingRequest:clientId];
}

for (NSString *clientId in approvedHands) {
    // Highlight this participant as currently having the floor
    [self markFloorHolder:clientId];
}

Rather than waiting for a participant to raise their hand, the moderator can proactively invite any participant to speak. This is useful in structured sessions — for example, calling on a specific participant during a Q&A, or moving through a speaker queue in a predetermined order.

Delegate Methods

Error Codes

// Moderator invites a participant to the floor
[room inviteToFloor:@"clientId"];


// MARK: - Participant receives the floor invitation

-(void)didInvitedForFloorAccess:(NSArray *)data {
    // Show accept / reject dialog to the participant
    NSLog(@"You have been invited to speak");

    // Accept the invitation
    [room acceptInviteFloorRequest:@"clientId"];

    // Or decline the invitation
    // [room rejectInviteFloor:@"clientId"];
}

If the moderator sent an invitation but wants to withdraw it before the participant has responded — for example because the session moved on — they call cancelFloorInvite:. The invited participant's pending invitation UI is dismissed, and all moderators are notified.

Delegate Methods

Error Codes

When a participant receives a floor invitation via didInvitedForFloorAccess:, they can accept it by calling acceptInviteFloorRequest:. Accepting signals readiness to speak. All moderators in the room are notified so they can update their floor management views.

Delegate Methods

Error Codes

A participant can decline a floor invitation if they are not ready to speak or prefer not to participate at that moment. Calling rejectInviteFloor: notifies all moderators of the decision so they can invite another participant or move on.

Delegate Methods

Error Codes