1. Home
3. Reference Docs
5. Daily JS
7. Events
9. Meeting Events

Meeting Events

These events all happen during a meeting. They tend to be emitted as responses to either what a participant does in a meeting (like sending a message), or updates to the meeting itself (e.g. a live stream starts).

loading

Emitted when the JavaScript bundle responsible for the call begins loading. This is the first event in the join() sequence (or the load() sequence, if you invoke that method directly).

loaded

Emitted when the JavaScript bundle responsible for the call has finished loading. This occurs right before the joining-meeting event in the join() sequence (or as the last step of the load() sequence, if you invoke that method directly).

load-attempt-failed

Emitted when a single attempt at loading the JavaScript bundle responsible for the call has failed. A few attempts are made before loading is considered to have failed altogether (resulting in an error event).

A load-attempt-failed can happen during the join() sequence if a network error occurs, for example. It can also happen in the load() sequence, if you invoke that method directly.

started-camera

Emitted when a participant's camera starts during call loading. This can happen as part of the standard onboarding flow, or when explicitly calling startCamera() for more granular control.

camera-error

Emitted when a camera error occurs. Details can be found in the error object included in the event payload. This object will always include type and msg. type categorizes the error into a general subset of issues (e.g. permissions vs missing device). msg is a human-readable message describing the specific error. Some types include extra information about the error.

The supported types are:

• "not-found": camera and/or mic are not detected. Check the missingMedia field for which devices were not found.

  Copy to clipboard

• "cam-in-use"/"mic-in-use"/"cam-mic-in-use": on Windows, the camera (and sometimes mic) cannot be accessed in multiple applications at once. When a device is inaccessible for this reason, we emit one of these error types depending on which devices are inaccessible.

  Copy to clipboard

• "permissions": the user has blocked access to the camera and/or mic, or the browser itself has not been granted permissions. Check the blockedBy field to know whether it is due to "user" or "browser".

  Copy to clipboard

• "constraints": getUserMedia() was provided with either invalid constraints or empty constraints. Check the reason field to know which one was the case.

  Copy to clipboard

• "undefined-mediadevices": This indicates that window.navigator.mediaDevices is undefined and a getUserMedia() call is not possible. This most commonly is a result of accessing the call via a non-secure http url.

  Copy to clipboard

• "unknown": While we have done our best to handle and normalize all possible errors across browsers and common device issues, we were unable to categorize this error. All unknown errors will be reported as this type. The original error thrown by getUserMedia() will be included in the msg string.

  Copy to clipboard

joining-meeting

Triggered when the call is in the process of loading, meaning the join() method is called, and the call is connecting. This occurs after a loaded event in a successful join() sequence.

This event could be used to monitor whether a call is fully loaded in the console, or to hide certain displays while the participant is joining the meeting, among other things.

joined-meeting

Emitted once the local participant has joined the call. At this point, the call is considered connected.

The joined-meeting event object returns the "action" type and information about the local participant who joined, like their "user_id", "audio", "video", and "screen" state, and any media stream tracks.

left-meeting

Fires once the local participant has left the call. From the local user's perspective, this means the call has disconnected.

You could watch for this event to change the UI once a user has left a call, for example, changing a button that read "Leave call" to display "Join call" (we do something similar in our Daily Prebuilt demo).

call-instance-destroyed

Fires when destroy() has been called after all resources have been freed and isDestroyed() will return true.

You might watch for this event if you store the call instance in multiple places, to ensure all copies are reset.

meeting-session-updated

A meeting session is a set of one or more people in a room together during a specific time window (learn more about meeting sessions).

'meeting-session-updated' fires when the meeting session changes. One meeting session ends and another begins, for example, when you've been sitting alone in a room for 10 minutes.

test-completed

Fires when a prejoin test has been completed. The event includes the test results and specifies which test they are for. The test property will be one of: "call-quality", "p2p-call-quality", "network-connectivity", or "websocket-connectivity". The results will include the test results matching the return types of the corresponding test.

Learn more about the various prejoin tests:

• testCallQuality
• testPeerToPeerCallQuality
• testNetworkConnectivity
• testWebsocketConnectivity

fullscreen

Fires when the call iframe enters browser fullscreen mode, usually when a local user clicks a button that calls our requestFullscreen() method.

You might listen to this event to modify other parts of the UI accordingly, e.g. shrinking or hiding a participants list temporarily.

exited-fullscreen

When a user closes fullscreen, the exited-fullscreen event fires. This can be useful to listen for if there are UI elements you'd like to reappear once a user returns to their default view.

active-speaker-change

Our Daily Prebuilt Active Speaker feature highlights the person currently talking (check out our blog post for more).

The active-speaker-change event fires when the person currently talking has changed. While Active Speaker is only available for calls making use of Daily Prebuilt, you could still listen for active-speaker-change to build your own custom UI.

One use case would be to listen for it to alter the UI for the person currently speaking, or to temporarily mute other microphones.

Daily determines the active speaker based on whose audio input is currently the loudest. The active speaker is displayed prominently, while everyone else is displayed smaller. Active speaker mode only applies to the local participant, so changing the mode only changes the view locally.

Note: the peerId value is the same as the session_id in the participants object.

active-speaker-mode-change

The Daily Active Speaker mode only exists by default for calls using Daily Prebuilt. When Active Speaker mode is enabled, the participant that is currently speaking is displayed prominently, while others are displayed smaller (check out our blog post for more).

The active-speaker-mode-change event fires when Active Speaker mode is toggled either through a button in the default UI or programmatically using setActiveSpeakerMode().

If you're using the Daily Prebuilt, then you can listen for this event to see if Active Speaker mode has been properly set.

However, if you've built your own custom UI to emulate Active Speaker, the active-speaker-mode-change will not fire. Its related methods activeSpeakerMode() and setActiveSpeakerMode() will have no effect.

access-state-updated

This event fires when accessState() has changed in some way—either the current access has changed (accessState().access) or an access request has been made or has been resolved (accessState().awaitingAccess).

Payload object:

• action
• accessState: see accessState() for object format

error

The error event fires when an an unrecoverable call error, like a total disconnection, occurs.

The event's errorMsg property will contain a string with additional information. It can be useful to listen for and log error events for debugging and troubleshooting, for example.

If a call is in progress when the error is thrown, a left-meeting event should be emitted immediately after the error event.

theme-updated

Emitted when a theme is applied, via setTheme(), for example. The event's object looks like:

receive-settings-updated

Fires when media receive settings have changed (see updateReceiveSettings() for details). This occurs once upon join—at which point the base receive settings come in—and once each time receive settings are changed via a call to updateReceiveSettings().

send-settings-updated

Fires when video or custom track send settings have changed (see updateSendSettings() for details). This occurs once upon join() and once each time send settings are changed via a call to updateSendSettings().

show-local-video-changed

Fires when a local participant hides or shows their own video element (or when the setShowLocalVideo() method is called).

input-settings-updated

Emitted every time the input settings object changes (see updateInputSettings() for details). Includes all input settings, even those that have not changed.

face-counts-updated

Emitted when the face count has been updated. It can help identify the number of people in view at a given time. This event is only triggered when the face-detection processor is in progress, (see updateInputSettings() for details).

nonfatal-error

"type": "input-settings-error"

Fires if and when an error occurs while applying input settings changes.

"type": "live-streaming-warning"

Emits if there is an error during a live stream, such as when a user attempts to remove all live streams with removeLiveStreamingEndpoints().

"type": "local-audio-level-observer-error"

Fires if an error occurs while the local audio level observer is running.

"type": "meeting-session-data-error"

Fires when there’s been an error updating meeting session data (i.e. applying setMeetingSessionData()).

"type": "screen-share-error"

Emitted if there is an error when a participant begins a screen share.

Details can be found in the details object included in the event payload. This object will always include a category and browserError.

category categorizes errors into two buckets: 1) "permissions", 2) "unknown".

browserError is the browser error message or object, which provides supplementary information about the error, which can be especially helpful in the event of an "unknown" error.

In general, a "screen-share-error" event is emitted with three root causes:

1. The user has not permitted the browser to access screen sharing. ("category": "permissions")
2. The user's OS has been configured to block screen sharing. ("category": "permissions")
3. A getDisplayMedia() exception was thrown due to reasons other than a user or OS blocking a screen share. ("category": "unknown")

For a "permissions" error, an additional field called blockedBy will be included in the details object to specify whether the cause of the error was "browser" (meaning a user blocked access) or "os" (meaning the OS was configured to block access).

For an "unknown" error, the browserError property will include supplementary information about the root cause of the error. "unknown" is a catchall for errors that likely require either a browser or system restart.

"type": "video-processor-error"

Fires if the CPU becomes too high, resulting in the video processor turning off and the camera muting.

"type": "audio-processor-error"

Fires if audio processing (i.e. noise cancellation) fails, resulting in the audio processor turning off and the microphone muting.

custom-button-click

Fires when a local participant clicks a custom tray button. You might listen to this event and use the button_id from the payload to call your custom button behavior.

meeting-session-state-updated

Fires when anything in meetingSessionState() changes, which includes anything set via setMeetingSessionData() and information about the meeting session, like network topology (e.g. 'sfu' or 'peer').

sidebar-view-changed

Fires when there is a change to the sidebar in Daily Prebuilt. Changes to the sidebar are caused by either a user interaction in the application or calling the setSidebarView() method.

local-screen-share-started

Fires when the local screen share has started.

local-screen-share-stopped

Fires when the local screen share has stopped.

local-screen-share-canceled

Fires when the user cancels out of sharing their screen before ever starting it.

local-audio-level

Event containing the local participant latest audio level information.

Fires based on the frequency specified when starting the local audio level observer.

remote-participants-audio-level

Event containing the remote participants latest audio level information.

Fires based on the frequency specified when starting the remote participants audio level observer.