This guide gives an overview of the API methods you can use to create meeting with audio and video with a roster of attendees and basic controls. Several additional API methods that may be helpful are also described and marked optional.
The MeetingSession and its AudioVideoFacade are the starting points for creating meetings. To create a meeting session, you will first need a Logger, DeviceController, and MeetingSessionConfiguration. The subsequent sections assume that you have created these four things.
const logger = new ConsoleLogger('MeetingLogs', LogLevel.INFO);
Create a DefaultDeviceController and pass in the Logger you created. This object allows you to enumerate and select audio and video devices and control some of their features, even before the meeting session has been created.
const deviceController = new DefaultDeviceController(logger);
Create a MeetingSessionConfiguration object with the responses to chime:CreateMeeting and chime:CreateAttendee. Your server application should make these API calls and securely pass the meeting and attendee responses to the browser client application.
const configuration = new MeetingSessionConfiguration(meetingResponse, attendeeResponse);
Using the above objects, create a DefaultMeetingSession.
const meetingSession = new DefaultMeetingSession(configuration, logger, deviceController);
Before starting the meeting session, you should configure audio and video devices. By default, no devices are selected.
When obtaining devices to configure, the browser may initially decline to provide device labels due to privacy restrictions. However, without device labels the application user will not be able to select devices by name. When no labels are present, the device-label trigger is run. The default implementation of the device-label trigger requests permission to the mic and camera. If the user grants permission, the device labels will become available.
You can override the behavior of the device-label trigger by calling meetingSession.audioVideo.setDeviceLabelTrigger(trigger).
You can receive events about changes to available devices by implementing a DeviceChangeObserver and registering the observer with the device controller.
To add a DeviceChangeObserver, call deviceController.addDeviceChangeObserver(observer).
To remove a DeviceChangeObserver, call deviceController.removeDeviceChangeObserver(observer).
You can implement the following callbacks:
To send audio to the remote attendees, list the available audio input devices and choose an input to use.
To retrieve a list of available audio input devices, call meetingSession.audioVideo.listAudioInputDevices().
To use the chosen audio input device, call meetingSession.audioVideo.chooseAudioInputDevice(device).
You can create a WebAudio AnalyserNode from the current audio input to generate a display such as a mic indicator. This is useful for allowing attendees to preview their microphone volume level prior to joining the meeting.
To create the AnalyserNode, call meetingSession.audioVideo.createAnalyserNodeForAudioInput().
On browsers that support setSinkId, you can optionally list the available audio output devices and choose one to use.
To retrieve a list of available audio output devices, call meetingSession.audioVideo.listAudioOutputDevices().
To use the chosen audio output device, call meetingSession.audioVideo.chooseAudioOutputDevice(deviceId).
To hear audio from the remote attendees, bind the audio output device to an HTMLAudioElement in the DOM. The element does not need to be visible; you can hide it with CSS style
To bind the chosen audio output device to a HTMLAudioElement, call meetingSession.audioVideo.bindAudioElement(element).
To unbind the chosen audio output device, call meetingSession.audioVideo.unbindAudioElement().
To send video to remote attendees, list the available video input devices, optionally select video quality settings, and choose a device to use.
To get a list of available video input devices, call meetingSession.audioVideo.listVideoInputDevices().
You can configure the quality of the video that is sent to the remote attendees by calling meetingSession.audioVideo.chooseVideoInputQuality(width, height, frameRate, maxBandwidthKbps). The changes take effect the next time a video input device is chosen. The default quality is 960x540 @ 15 fps with a maximum uplink bandwidth of 1400 kbps. The maximum supported quality settings are 1280x720 @ 30 fps with a maximum uplink bandwidth of 2400 Kbps. Actual quality achieved may vary throughout the call depending on what the device, system, and network can provide.
To use the chosen video input device, call meetingSession.audioVideo.chooseVideoInputDevice(device).
Before the session is started, you can start a preview of the video in an HTMLVideoElement in the DOM.
To start video preview, call meetingSession.audioVideo.startVideoPreviewForVideoInput(element).
To stop video preview, call meetingSession.audioVideo.stopVideoPreviewForVideoInput(element).
You can receive audio and video events by implementing the AudioVideoObserver interface and registering the observer with the meeting session.
To add an AudioVideoObserver, call meetingSession.audioVideo.addObserver(observer).
To remove an AudioVideoObserver, call meetingSession.audioVideo.removeObserver(observer).
You should implement the following key observer callbacks:
You may optionally listen to the following callbacks to monitor aspects of connection health:
After completing configuration of audio and video (see previous sections) call
meetingSession.audioVideo.[start()](https://aws.github.io/amazon-chime-sdk-js/interfaces/audiovideofacade.html#start). This method will initialize all underlying components, set up connections, and immediately start sending and receiving audio.
To stop the meeting session, call
stop() method does not clean up observers. You can start and stop a session multiple times using the same observers. In other words observers are not tied to the lifecycle of the session.
You can specify a
signalingOnly option when calling
start to cause only the initial signaling connection to be established, then complete meeting join with a second call to
start after choosing audio and video sources. This can improve meeting join latency. You can use this approach if you know that the user wants to join a meeting prior to wanting to share media or having selected input devices — for example, you can initialize the signaling connection early if you have a 'lobby' experience after choosing to join but before entering the interactive portion of the meeting.
Use the following methods to learn when attendees join and leave and when their volume level, mute state, or signal strength changes.
When implementing a real-time callback, you must ensure that it never throws an exception. To preserve privacy, uncaught exceptions inside a real-time callback are treated as fatal: the session is disconnected immediately. The cautions around real-time callbacks do not apply to the observers. For example, uncaught exceptions are not fatal to observers (though they should be avoided).
Real-time volume indicator callbacks are called at a rate of 5 updates per second. Ensure that your application is able to smoothly render these updates to avoid causing unnecessary CPU load that could degrade the meeting experience.
If you are using Angular, ensure that all calls to the SDK are run outside of the Angular zone. Otherwise, the real-time messages received via the signaling channel and their real-time callbacks may cause the DOM to thrash with updates and degrade performance.
To learn when attendees join or leave, subscribe to the attendee ID presence changes. The callback provides both the attendee ID and external user ID from chime:CreateAttendee so that you may map between the two IDs.
To subscribe to attendee presence changes, call meetingSession.audioVideo.realtimeSubscribeToAttendeeIdPresence(callback).
To unsubscribe to attendee presence changes, call meetingSession.audioVideo.realtimeUnsubscribeToAttendeeIdPresence(callback).
To show speaker volume, mute state, and signal strength for each attendee, subscribe to volume indicators for each attendee ID. You should subscribe and unsubscribe to attendee volume indicators as part of the attendee ID presence callback.
Volume is on a scale of 0 to 1 (no volume to max volume). Signal strength is on a scale of 0 to 1 (full packet loss to no packet loss). You can use the signal strength of remote attendees to show an indication of whether an attendee is experiencing packet loss and thus may be unable to communicate at the moment.
To subscribe to an attendee’s volume indicator, call meetingSession.audioVideo.realtimeSubscribeToVolumeIndicator(attendeeId, callback).
To unsubscribe from an attendee’s volume indicator, call meetingSession.audioVideo.realtimeUnsubscribeFromVolumeIndicator(attendeeId).
To subscribe to the local attendee’s signal strength changes, call meetingSession.audioVideo.realtimeSubscribeToLocalSignalStrengthChange(callback).
To unsubscribe from the local attendee’s signal strength changes, call meetingSession.audioVideo.realtimeUnsubscribeToLocalSignalStrengthChange(callback).
If you are interested in detecting the active speaker (e.g. to display the active speaker’s video as a large, central tile), subscribe to the active-speaker detector with an active speaker policy such as the DefaultActiveSpeakerPolicy. You can receive updates when the list of active speakers changes. The list is ordered most active to least active. Active speaker policies use volume indicator changes to determine the prominence of each speaker over time.
DefaultActiveSpeakerPolicy algorithm works as follows: as you speak, your active speaker score rises and simultaneously decreases the score of others. There are some adjustable weightings in the constructor to control how reactive it is. In general, the defaults do a reasonable job of identifying the active speaker, preventing short noises or interjections from switching the active speaker, but also allowing take over to be relatively quick.
To subscribe to active speaker updates, call meetingSession.audioVideo.subscribeToActiveSpeakerDetector(policy, callback).
To unsubscribe from active speaker updates, call meetingSession.audioVideo.unsubscribeFromActiveSpeakerDetector(callback).
Use the below real-time API methods to mute and unmute microphone audio. Mute is effective immediately and applied locally; no audio from the microphone will be transmitted to the server when muted.
When implementing a real-time callback, you must ensure that it never throws an exception. To preserve privacy, uncaught exceptions inside a real-time callback are treated as fatal: the session is disconnected immediately.
To ensure that attendee privacy is respected, pay close attention that the UI controls for mute are implemented properly with as direct a path possible to the mute and unmute methods. Use the real-time API to determine the current state of mute rather than keeping track of mute state yourself.
To mute the local attendee’s audio, call meetingSession.audioVideo.realtimeMuteLocalAudio().
To unmute the local attendee’s audio, call meetingSession.audioVideo.realtimeUnmuteLocalAudio().
To determine if the local attendee’s audio is muted, call meetingSession.audioVideo.realtimeIsLocalAudioMuted().
To subscribe to changes in the local attendee’s audio mute state, call meetingSession.audioVideo.realtimeSubscribeToMuteAndUnmuteLocalAudio(callback).
To unsubscribe from changes in the local attendee’s audio mute state, call meetingSession.audioVideo.realtimeUnsubscribeToMuteAndUnmuteLocalAudio(callback).
Depending on the type of meeting application you are building, you may want to temporarily prevent the local attendee from unmuting (e.g. to avoid disruption if someone is presenting). If so, use the methods below rather than keeping track of your own can-unmute state.
To set whether or not the local attendee can unmute, call meetingSession.audioVideo.realtimeSetCanUnmuteLocalAudio(canUnmute).
To determine whether or not the local attendee can unmute, call meetingSession.audioVideo.realtimeCanUnmuteLocalAudio().
To subscribe to changes in whether or not the local attendee can unmute, call meetingSession.audioVideo.realtimeSubscribeToSetCanUnmuteLocalAudio(callback).
To unsubscribe from changes in whether or not the local attendee can unmute, call meetingSession.audioVideo.realtimeUnsubscribeToSetCanUnmuteLocalAudio(callback).
A video tile is a binding of four key things: a tile ID, an attendee ID, that attendee’s video stream, and an HTMLVideoElement in the DOM. If all those things are present, the video tile is said to be active, and the video element displays video.
Local video is automatically displayed horizontally-mirrored by convention.
After choosing the video input and starting the meeting session, you can share the local attendee’s video with remote attendees.
To start sharing video with others, call meetingSession.audioVideo.startLocalVideoTile().
To stop sharing video with others, call meetingSession.audioVideo.stopLocalVideoTile().
You are responsible for maintaining HTMLVideoElement objects in the DOM and arranging their layout within the web page. To display a video, you must handle the videoTileDidUpdate and videoTileWasRemoved callbacks in an AudioVideoObserver. In the implementation of videoTileDidUpdate, bind the tile ID from the provided VideoTileState with the HTMLVideoElement in your DOM by calling meetingSession.audioVideo.bindVideoElement(tileId, videoElement).
To unbind a tile, call meetingSession.audioVideo.unbindVideoElement(tileId).
tileId is a unique identifier representing a video stream. When you stop and start, it generates a new
tileId. You can have tileIds exceeding 16; they merely identify a particular stream uniquely. When you start video it consumes a video publishing slot, when you stop video it releases that video publishing slot. Pausing does not affect video publishing slots; it allows a remote to choose to not receive a video stream (and thus not consume bandwidth and CPU for that stream).
Video tiles may be paused individually. The server will not send paused video streams to the attendee requesting the pause. Pausing video does not affect remote attendees.
To pause video, call meetingSession.audioVideo.pauseVideoTile(tileId).
To resume a paused video, call meetingSession.audioVideo.unpauseVideoTile(tileId).
To get all video tiles, call meetingSession.audioVideo.getAllVideoTiles().
To get all remote attendees’ video tiles, call meetingSession.audioVideo.getAllRemoteVideoTiles().
To get the local attendee’s video tile, call meetingSession.audioVideo.getLocalVideoTile().
To get a video tile, call meetingSession.audioVideo.getVideoTile(tileId).
You can share any MediaStream, such as from a screen capture or media file, as the content share for an attendee. When a content share is started, another attendee with the attendee ID
<attendee-id>#content joins the meeting. The content audio and video appears like a regular attendee. You can subscribe to its volume indicator to show it in the roster and bind its video tile to a video element the same as you would for a regular attendee.
Each attendee can share one content share in addition to their main mic and camera. Each meeting may have two simultaneous content shares. Content share does not count towards the max video tile limit. There may be up to two content shares irrespective of how many attendees are sharing their camera.
To start the content share, call meetingSession.audioVideo.startContentShare(stream).
To start sharing screen as a content share, call meetingSession.audioVideo.startContentShareFromScreenCapture(sourceId).
To stop the content share, call meetingSession.audioVideo.stopContentShare().
To pause content share, call meetingSession.audioVideo.pauseContentShare().
To resume content share, call meetingSession.audioVideo.unpauseContentShare().
You can receive events about the content share by implementing a ContentShareObserver and adding the observer to the meeting session.
To add a ContentShareObserver, call meetingSession.audioVideo.addContentShareObserver(observer).
To remove a ContentShareObserver, call meetingSession.audioVideo.removeContentShareObserver(observer).
You can implement the following callbacks:
Attendees can broadcast small (2KB max) data messages to other attendees. Data messages can be used to signal attendees of changes to meeting state or develop custom collaborative features. Each message is sent on a particular topic, which allows you to tag messages according to their function to make it easier to handle messages of different types.
To send a message on a given topic, call meetingSession.audioVideo.realtimeSendDataMessage(). When sending a message if you specify a lifetime, then the media server stores the messages for the lifetime. Up to 1024 messages may be stored for a maximum of 5 minutes. Any attendee joining late or reconnecting will automatically receive the messages in this buffer once they connect. You can use this feature to help paper over gaps in connectivity or give attendees some context into messages that were recently received.
To receive messages on a given topic, set up a handler using the meetingSession.audioVideo.realtimeSubscribeToReceiveDataMessage(). In the handler, you receive a DataMessage containing the payload of the message and other metadata about the message.
To unsubscribe the receive message handler, call meetingSession.audioVideo.realtimeUnsubscribeFromReceiveDataMessage().
If you send too many messages at once, your messages may be returned to you with the throttled flag set. The current throttling soft limit for Data Messages is Rate: 100, Burst: 200. If you continue to exceed the throttle limit (hard limit: Rate: 500, Burst: 10000), then the server may hang up the connection.
Note: Take care when using data messages for functionality involving asymmetric permissions (e.g. a moderator attendee sending a message to regular attendees). Any attendee may, in theory, send any message on any topic. You should always confirm that the message's senderAttendeeId belongs to an attendee that is allowed to send that type of message, and your handler should tolerate messages that are not serialized in the format you are expecting.
Generated using TypeDoc