1. Overview
  2. Server-side Muting/Unmuting
  3. Admin Muting
  4. Mute All
  5. Raise Hand
  6. Auto Muting on entry
  7. Backward Compatibility
  8. API Routes
  9. Socket Events

1. Overview

This guide provides information about the Raise hands/Mute all features. In other sections information regarding each feature, backward compatibility, API endpoints, and socket events. It is recommended to check the API reference section for more in-depth information on how to use API routes.

2. Server-side Muting/Unmuting

The server have more control over the media states of clients. Previously, the clients were changing their local device states to change their media state. Now, the client can make a REST API call to server to change their media state. The server will in turn change client’s audio/video stream state on MPAAS. When muting, the client will first change its local device state and then make a REST API call to server, so the server state is also updated. When unmuting, the client will first make a REST API call to server and, on receiving success response, it will change its local state.

3. Admin Muting

When admin mutes a participant, the admin client will hit the Media State Route and server will change the stream state on MPAAS before sending a request.tracksstatus.change event to client telling it to change its local state to synch with server state

4. Mute All

Mute All feature gives admins the ability to mute everyone in the meeting in one go. When admin initiates mute all, Spaces uses MPAAS mute all feature to mute everyone in the space (except the admin who initiated mute all) and then shoots two events to clients. The first event is thrown when mute all operation starts and it is called app.event.all.parties.muting. The second event is thrown when mute all operation has finished and it is called app.event.all.parties.muted. The app.event.all.parties.muted event has an exclusion list in its body. The exclusion list contains an array of attendees who have retained their media state i.e. the attendees who were not touched by mute all operation. On their local roster, the client can set everyone’s mute state to false except the attendees in exclusion list

5. Raise Hand

Raise Hand feature gives admins the ability to prevent unmuting in the space. This means that all non-admin participants can’t unmute their mic and have to raise hand to seek admin’s permissions. Once the permission is granted, the participant can unmute their mic. When a participant raises hand, it hits the Raised Hands route. The server processes the request and throws app.event.meeting.permission.requested event. This event is a signal for admin client to show raised hand against the participant’s entry in roster. Admin can then accept or lower the hand by hitting the Accept Raise Hand or Lower Raise Hand routes respectively. In both cases, the server will process the request and throw app.event.meeting.permission.updated event. Client can also lower their own raised hand.

6. Auto Muting on entry

This setting will let admins mute users on entry. It can be enabled from Edit Space -> Meeting tab. The client will receive a request.tracksstatus.change event if their stream is muted on entry.

7. Backward Compatibility

Each of the aforementioned features is backward compatible i.e. existing clients can participate in meetings which have these features enabled.

6.1. Versioning

Spaces has now introduced versioning in the APIs and socket events. All clients using the current Spaces production are considered version 1.0 compatible. The new clients that will implement the features discussed above will become version 1.1 compatible. The version will be passed in the request headers of all API calls. The name of the header is accept-version. The version will also be passed in all socket events thrown by client. The name of the field in socket events is version. SIP clients will pass a header named spacesVersion. The value for new clients will be 1.1. All existing clients without support for Server-side Muting, Mute All and Raised Hands will be assigned version 1.0 by default.

6.2. Server-side Muting/Unmuting

Currently, when a client mutes or unmutes, it changes its local state and then sends out a tracksstatus event. Spaces server will check the version on these socket events. If no version is passed, it will assume that the client is legacy and will synch the server-side media state with the state provided in event payload. If it is successful, it will let the event pass. If not, it will block the event and instead send a request.tracksstatus.change event back to the client telling it to synch its local state with server-side media state.

6.3. Admin Muting

Admin muting works exactly like self-muting/unmuting. The admin sends a request.tracksstatus.change event to participant telling it to mute itself. The participant responds to the event, mutes itself and then sends out tracksstatus. The flow from here on will be similar to Server-side Muting/Unmuting. Server will intercept the event and try to synch the state with server.

6.4. Mute All

When admin mutes all, the legacy client will have no way to show their local state to the user. To deal with this, the server will send individual request.tracksstatus.change events to legacy clients so their local state is synched with server and the user can see it on the UI.

6.5. Raise Hand

Legacy clients do not recognize this feature and do not know how to raise hands in a meeting with prevent unmuting enabled. To deal with this, the server will raise hand on legacy client’s behalf when legacy client tries to unmute itself. If admin accepts the raised hand, the server will also unmute the legacy client by first unmuting the MPAAS stream and then by sending request.tracksstatus.change event to legacy client so it can reflect the unmuted state on UI.

8. API Routes

DescriptionRoute
Media State RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/:attendeeType/:attendeeId/mediastate
Mute All RoutePOST /api/spaces/:spaceId/meetings/:meetingId/muteall
Raise Hand RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/raisedhands
Accept Raise Hands RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/raisedhands/accept
Lower Raise Hands RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/raisedhands/lower
Active Meeting Route (Available to legacy clients)GET /api/spaces/:spaceId/activemeeting
Meeting Permission Request RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/meetingpermissions
Meeting Permission Allow RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/meetingpermissions/allow
Mute Request Rejected RoutePOST /api/spaces/:spaceId/meetings/:meetingId/attendees/meetingpermissions/deny

More detailed information about each route can be found at API reference tab.

9. Socket Events

DescriptionEvent
All Parties Muting Eventapp.event.all.parties.muted
Meeting Permission Requested Eventapp.event.meeting.permission.requested
Meeting Permission Updated Eventapp.event.meeting.permission.updated
Track Status Event (Available to legacy clients)tracksstatus
Request Track Status Change Event (Available to legacy clients)video.request.tracksstatus.change

More detailed information about each route can be found at Socket API tab.