Learn the WebRTC workflow: prepare authentication, configure media directions, exchange SDP and model events, and release resources.
WebRTC carries audio and video on media tracks and model events and text over DataChannels. Web applications can use native browser APIs; other platforms can use standard WebRTC libraries. Model Studio does not provide a dedicated WebRTC SDK.
AppServer configures SDP exchange for the target model, region, and workspace. The following parameters apply to standard Realtime connections. For application-specific parameters, follow the corresponding best practice.
For regions, endpoints, and authentication, see Token authentication. Implement the AppServer interface in your application; it is not a Model Studio SDK API.
Create an
Register message listeners before initializing the model so that server-initiated session events are not missed. Do not listen only to the client-created channel: the server sends events on a channel named
Directions are relative to the client. WebRTC transceivers negotiate sending and receiving:
Voice conversations typically require bidirectional audio; visual input additionally requires upstream video. The Offer SDP must include an
This table describes the media directions needed by the application; it does not guarantee that every combination can be negotiated independently. Configuration depends on the target model and server negotiation capabilities.
Negotiate the required directions before creating the Offer. For models that require initialization confirmation, reserve sending capabilities without attaching captured tracks. After the model is ready, use
This example uses bidirectional audio with optional upstream video. The four
Set video resolution and frame rate according to the target model. If local preview and upstream frame rates need to differ, see the Canvas implementation in the best practice.
Create a DataChannel before the Offer so that the SDP includes data channel negotiation. For client-created and server-created channels, see the WebRTC best practices below.
DataChannels carry model initialization, text, and control events, and return model results, status, and errors. Media tracks carry audio and video.
Listen for
AppServer must forward the Offer using the endpoint and headers in section 1. The example interface returns plain SDP text. Do not pass HTTP headers, logs, or a JSON wrapper to
When the connection and event channel are available, initialize the target model according to its protocol. Store server initialization events and combine them with channel state to advance the flow; do not assume a fixed callback arrival order.
For example, models configured with
This example demonstrates Omni's
After the model is ready, attach the audio and video tracks needed for upstream transmission. Handle model output in the remote track callback and continue parsing DataChannel events.
When the connection is no longer needed, stop local capture tracks owned by your application, close DataChannels and the
Call
Check that the channel is
Use the same binding function for client-created and server-created channels. It handles transport and JSON parsing;
Place all fragments in the same script. After all declarations and callbacks are registered, call
The multimodal interaction suite defines both directions in one interaction protocol. Select event definitions for the actual model version; models do not share one fixed event schema.
Also follow these rules:
Prerequisites
- Complete the preparations in Connection overview.
- Check Realtime API overview to confirm WebRTC support for your target model. Supported categories include real-time multimodal interaction, voice conversations, speech translation, and the multimodal interaction suite. For speech synthesis or recognition, use AOQ or WebSocket as supported by the model.
- Prepare an API key for the region and workspace on your application server (AppServer), which proxies the SDP exchange. For authentication fields, see Token authentication.
Use a secure browser context and request microphone or camera permission as needed. Handle browser autoplay restrictions when receiving audio.
Workflow

- Prepare the API key and target model parameters on AppServer.
- Create the client connection object and register callbacks.
- Configure media directions and DataChannels without attaching upstream media tracks.
- Exchange SDP through AppServer and wait for the connection and event channel to become ready.
- Configure the model according to its protocol. Attach the required upstream media tracks after confirmation.
- Stop capture, close the connection, and release resources when interaction is complete.
- WebRTC media tracks carry audio and video. Your application obtains local media tracks, attaches remote players, and exchanges DataChannel messages according to the target model's event definitions.
- WebRTC authentication takes place during SDP exchange; no AOQ token is required. Proxy authentication and SDP through AppServer to keep the long-term API key out of frontend code.
-
A successful connection means that the transport is established, but media must wait until the target model is successfully initialized. For example, Realtime models must wait for
session.updated. The client can enable the required upstream media only after model initialization succeeds.
1. Prepare authentication and connection parameters
AppServer configures SDP exchange for the target model, region, and workspace. The following parameters apply to standard Realtime connections. For application-specific parameters, follow the corresponding best practice.
| Setting | Value |
|---|---|
| Method | POST |
| URL | https://{endpoint}/api/v1/webrtc/realtime?model={model_name} |
Content-Type | application/sdp |
Authorization | Bearer <API_KEY> |
| Request body | Offer SDP |
| Successful response | Answer SDP |
2. Initialize the connection object and register callbacks
Create an RTCPeerConnection in the browser, or initialize the corresponding library on another platform. Before connecting, register handlers for:
- Connection state changes, including success, failure, and disconnection.
- DataChannel creation, opening, messages, and closure.
- Remote media tracks for receiving and playing audio or video.
txt, so handle the datachannel callback as well.
3. Configure media directions and DataChannels
Select media directions
Directions are relative to the client. WebRTC transceivers negotiate sending and receiving: sendrecv is bidirectional, sendonly sends only, and recvonly receives only. Available capabilities also depend on the server's SDP answer and model support.
| Direction | Configuration |
|---|---|
| Send audio | Negotiate audio transmission and prepare a microphone or external audio track; attach it after model readiness |
| Receive audio | Negotiate audio reception and attach playback in the remote track callback |
| Send video | Negotiate video transmission only if the model supports visual input; prepare a camera or external video track |
| Receive video | Negotiate reception and implement rendering only if the model or application explicitly supports video output |
m=audio media section. Do not remove it merely because the application does not need audio playback.
Choose directions for your model
| Model or application | Send audio | Receive audio | Send video | Receive video |
|---|---|---|---|---|
| Qwen-Omni-Realtime | For speech input | For spoken responses | For visual input | Not supported |
| Qwen-Audio-Realtime | For voice conversations | For spoken responses | Not supported | Not supported |
| Qwen-LiveTranslate-Realtime | For speech input | For spoken translations | Depends on the version and scenario | Not supported |
| multimodal-dialog | Based on application input | Based on application output | Based on application capabilities | Only if explicitly supported by the application |
Prepare media without sending it
Negotiate the required directions before creating the Offer. For models that require initialization confirmation, reserve sending capabilities without attaching captured tracks. After the model is ready, use replaceTrack on the corresponding sender to start transmission. Register media reception handlers in advance.
Configure audio sending, audio reception, video sending, and video reception independently. Opening the microphone, playing audio, and initializing the model are separate operations.
Media configuration example
This example uses bidirectional audio with optional upstream video. The four media switches express application requirements. Enable video reception only if the target application explicitly supports it. addTransceiver negotiates directions in advance; captured tracks remain local until they are attached to senders after model readiness.
Create event channels
Create a DataChannel before the Offer so that the SDP includes data channel negotiation. For client-created and server-created channels, see the WebRTC best practices below.
DataChannels carry model initialization, text, and control events, and return model results, status, and errors. Media tracks carry audio and video.
4. Establish the connection
- Call
createOfferandsetLocalDescription. - Collect candidates using an ICE mode supported by the server. This example waits for ICE gathering to complete before sending the local SDP.
- Send the local SDP to AppServer, which calls the Model Studio SDP exchange endpoint with the API key.
- Check the HTTP status. On success, pass the returned Answer SDP to
setRemoteDescription. - Wait for the connection to succeed and confirm that the DataChannel used to send model events is open.
setRemoteDescription only completes that negotiation step; it does not establish that the media connection is ready. Model events cannot be sent until the DataChannel is open.
Connection code and state callbacks
Listen for connectionstatechange to determine connection status and icegatheringstatechange to wait for complete local SDP. Model initialization also depends on the DataChannel being open and on model events; SDP exchange alone is insufficient.
setRemoteDescription.
5. Exchange model events and media
Initialize the model
When the connection and event channel are available, initialize the target model according to its protocol. Store server initialization events and combine them with channel state to advance the flow; do not assume a fixed callback arrival order.
For example, models configured with session.update require an event that follows their protocol and confirmation before input is sent. Obtain voice, output modalities, VAD, and sample-rate parameters from the current model documentation. The multimodal interaction suite uses its own event protocol.
session.created means that the session was created, not necessarily that configuration has taken effect. For models that require session configuration confirmation, wait for session.updated. Other models or applications have their own readiness conditions.
The model navigation in WebSocket connection overview links to event definitions. Reuse only those definitions; WebRTC media transport and restrictions still follow this page.
Model event example: Omni
This example demonstrates Omni's session.created → session.update → session.updated flow. For other models, replace the initialization event and response handling according to their event definitions linked below. Attach upstream media tracks only after session.updated confirms configuration.
Start media transmission and reception
After the model is ready, attach the audio and video tracks needed for upstream transmission. Handle model output in the remote track callback and continue parsing DataChannel events.
-
Audio travels over RTP media tracks; no
input_audio_buffer.appendevent is required. -
Images travel over video tracks. WebRTC does not support
input_image_buffer.append. - DataChannels carry text, status, control, and error events.
6. End interaction and release resources
When the connection is no longer needed, stop local capture tracks owned by your application, close DataChannels and the RTCPeerConnection, release players, and clear application state.
Clear model readiness after a failed or unexpected disconnection. Initialize the model again on a new connection instead of reusing the previous connection's session state.
endSession() when the user ends the call or leaves the page. If your application adds the Canvas or recording features from the best practice, also cancel animation loops and stop Canvas media tracks and the MediaRecorder.
Send and receive events over DataChannels
Check that the channel is open before calling send with a serialized event. Parse incoming messages in its message callback, including events on server-created channels.
Follow the target model's client event definitions for outgoing event names, fields, parameters, and timing. Follow its server event definitions for response parsing, state changes, results, and errors. Send initialization events as required by the model and subsequent text and control events as required by your application.
DataChannel example
Use the same binding function for client-created and server-created channels. It handles transport and JSON parsing; handleModelEvent in section 5 handles model semantics. Use sendModelEvent for model initialization, text, or control events only when permitted by the model's protocol.
startSession() from the start button handler and endSession() from the end button handler. These are example functions, not built-in WebRTC APIs.
Model event definitions
| Model or application | Client events (send) | Server events (receive) |
|---|---|---|
| Qwen-Omni-Realtime | Client events | Server events |
| Qwen-Audio-Realtime | Client events | Server events |
| Qwen-LiveTranslate-Realtime | Client events | Server events |
| multimodal-dialog | Input Message in the interaction protocol | Output Message in the interaction protocol |
-
Identify event types and correlation identifiers according to the model. Realtime events typically use
type; the multimodal interaction suite usesheader.actionfor client events,header.eventfor server events, andtask_idfor correlation. - Handle initialization confirmation, input submission, response cancellation, and task completion over DataChannels as required by the protocol. These operations are distinct from closing the transport connection.
- Media uses media tracks. When referring to model event documentation, follow this WebRTC page for media transport and available interaction modes; do not copy WebSocket media-upload mechanisms.
Best practices
- Real-time Omni calls over WebRTC: application UI, recording, and Canvas frame-rate reduction. Initialize and attach media in the order described on this page.
- Real-time calls with the multimodal interaction suite over WebRTC: application access and its event flow.