Welcome to the new Daily Docs. Please let us know what you think.

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

Emitted when a camera error occurs. Reasons, detailed in the errorMsg value on the event include:

  • "devices Error": camera and/or mic are not detected. check the values of audioOk and videoOk for which one(s) are not available.
  • "camera/mic error": other
  • "not allowed": the user/browser/os has blocked access to the camera and/or mic

When a device is in use by another application, error.type will have one of the following values:

  • cam-in-use
  • mic-in-use
  • cam-mic-in-use

joining-meeting

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

The joined-meeting event object returns a list of all participants on the call, including all available information about those other participants: whether their audio is on, whether they're the local user, the size of their cameras, and then some.

You might want to respond to this event to update a participant list once a new caller has joined, or to change the view a participant sees once they've joined a call, for example.

left-meeting

Compatibility:
Prebuilt
Custom

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).

meeting-session-updated

Compatibility:
Prebuilt
Custom

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.

fullscreen

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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:

error

Compatibility:
Prebuilt
Custom

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

Compatibility:
Prebuilt
Custom

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

receive-settings-updated

Compatibility:
Prebuilt
Custom

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().