Qwen-Omni-Realtime WebRTC access
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.
This document provides the WebRTC integration procedure for this model, along with a complete browser-side example.
This document is aimed at Qwen-Omni-Realtime. Existing integration documentation covers: qwen3.8-omni-flash-realtime, qwen3.5-omni-plus-realtime, qwen3.5-omni-flash-realtime. The example model is
The browser submits an Offer SDP to the business AppServer. The AppServer forwards the following request using the API Key and returns the Answer SDP unchanged to the browser; long-term API Keys do not reach the frontend.
The following is a complete browser-side example. First, implement the
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.
Complete regional, address, and authentication details can be found in Authentication and SDP Exchange. The business AppServer’s interface is implemented by the business itself and is not part of Model Studio’s SDK API.
On the web side, create a
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
The following example demonstrates two-way voice with optional video upload. The three switches in
Create a DataChannel before creating an Offer so that the SDP includes data channel negotiation. Refer to Data Channel Send and Receive Events for how the client and server handle channel creation.
DataChannels carry model initialization, text, and control events, and return model results, status, and errors. Media tracks carry audio and video.
The complete example creates a client event channel and registers the server-side channel callback before creating an Offer.
Complete the connection in the following order:
Listen 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, when configuring a model using
The following example demonstrates the
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
Check that the channel is
Use the same binding function for client-created and server-created channels. It handles transport and JSON parsing;
Also follow these rules:
Scope of Application
This document is aimed at Qwen-Omni-Realtime. Existing integration documentation covers: qwen3.8-omni-flash-realtime, qwen3.5-omni-plus-realtime, qwen3.5-omni-flash-realtime. The example model is qwen3.8-omni-flash-realtime.
- Use the API Key and Workspace ID corresponding to your selected region and workspace.
- Beijing domain:
{WorkspaceId}.cn-beijing.maas.aliyuncs.com; Singapore domain:{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com. - Long-term API Keys are stored on the server side and should not be included in browser or mobile applications. For instructions on generating temporary API Keys and their permissions, see Generate Temporary API Key.
Authentication and SDP Exchange
The browser submits an Offer SDP to the business AppServer. The AppServer forwards the following request using the API Key and returns the Answer SDP unchanged to the browser; long-term API Keys do not reach the frontend.
- Method:
POST - Beijing address:
https://{WorkspaceId}.cn-beijing.maas.aliyuncs.com/api/v1/webrtc/realtime?model=qwen3.8-omni-flash-realtime - Singapore address:
https://{WorkspaceId}.ap-southeast-1.maas.aliyuncs.com/api/v1/webrtc/realtime?model=qwen3.8-omni-flash-realtime - Request headers:
Authorization: Bearer <API_KEY>,Content-Type: application/sdp - Request body: Offer SDP string.
- Successful response: HTTP 200, with the Answer SDP in the body; failure returns 4xx.
/api/realtime/sdp refers to a custom interface built by the business AppServer, which must implement the aforementioned forwarding process—it is not a URL provided by Model Studio.
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 indicates that the transmission channel has been established, but it does not mean that the model has finished initializing. When using
qwen3.8-omni-flash-realtimeon this page, start the required upstream media only after sendingsession.updateand receivingsession.updated.
Complete Example
The following is a complete browser-side example. First, implement the /api/realtime/sdp interface of the business AppServer as described in Authentication and SDP Exchange; then open this HTML page from the same origin as the business AppServer, ensuring that the protocol, host, and port match. For example, both the page and /api/realtime/sdp are served by http://localhost:3000. The server is responsible for storing the API Key and forwarding the SDP; do not include long-term API Keys in the page. Click “Start” to establish the connection; click “End” to release resources when the interaction concludes. This example establishes one connection at a time; reload the page to initiate another session.
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
On the web side, create a RTCPeerConnection; on other platforms, perform the corresponding library initialization. Before establishing the connection, register the following handlers:
- Connection state changes: Determine whether the connection succeeded, failed, or was disconnected.
- DataChannel establishment, opening, messages, and closure: carries model events.
- Remote media track: receives and plays audio, or handles other media supported by the target application.
txt, so you must handle the datachannel callback.
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 |
|---|---|
| Push audio | Negotiate audio sending capabilities and prepare the microphone or an external audio track; attach the track after the model is ready. |
| Pull audio | Negotiate audio receiving capabilities and bind audio playback in the remote track callback |
| Push video | When the target model supports visual input, negotiate video sending capabilities and prepare the camera or an external video track |
m=audio media section. Do not remove it merely because the application does not need audio playback.
Media Direction for This Model
| Model or application | Send audio | Receive audio | Send video | Receive video |
|---|---|---|---|---|
| Qwen-Omni-Realtime | enable when voice input is required | enable when voice response is needed | enable when visual input is required | cannot enable |
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.
Audio sending, audio receiving, and video sending should be configured separately as needed; do not combine microphone activation, audio playback, and model initialization into a single operation.
Media configuration example
The following example demonstrates two-way voice with optional video upload. The three switches in media control audio sending, audio receiving, and video sending, respectively. addTransceiver pre-negotiates the direction; captured tracks are first stored locally until the model is ready, then mounted to the sender.
See full example for the code.
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 event channels
Create a DataChannel before creating an Offer so that the SDP includes data channel negotiation. Refer to Data Channel Send and Receive Events for how the client and server handle channel creation.
DataChannels carry model initialization, text, and control events, and return model results, status, and errors. Media tracks carry audio and video.
The complete example creates a client event channel and registers the server-side channel callback before creating an Offer.
4. Establish Connection
Complete the connection in the following order:
- Call
createOfferandsetLocalDescription. - Collect candidate information according to the ICE methods supported by the server; in this example, the local SDP is sent after ICE collection is complete.
- Send the local SDP to the business AppServer, which uses the API Key to request the Model Studio SDP exchange interface.
- Check the HTTP status, and upon success, call
setRemoteDescriptionusing the returned Answer SDP. - Wait for the connection status to become successful, and confirm that the DataChannel used for sending model events has been opened.
setRemoteDescription only indicates that the corresponding negotiation step has been completed; it cannot be directly taken as proof that the media connection has succeeded. Model events also cannot be sent when the DataChannel is not in the open state.
Connection Code and Status Callbacks
Listen to connectionstatechange to determine the connection status, and listen to icegatheringstatechange to wait for the complete local SDP. Model initialization also requires the open of the DataChannel and the model’s ready event; it should not rely solely on the completion of SDP exchange for judgment.
The full example completes SDP exchange via startSession() and handles the connection result through the connection status callback.
The business AppServer should forward the Offer according to the address and request headers specified in Section 1; the sample API is expected to return plain SDP text. Do not pass content containing HTTP response headers, logs, or JSON wrappers directly to 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, when configuring a model using session.update, construct the event according to its protocol and wait for configuration confirmation before sending input. Parameters such as voice, output modalities, VAD, and sampling rate should all be derived from the current model’s documentation.
session.created indicates session creation; it should not be uniformly regarded as configuration having taken effect. For models that require confirmation of session configuration, wait for session.updated.
Model event definitions can be found in Client Events and Server Events. Media transmission and available modes should be handled according to the instructions on this page.
When Qwen-Omni-Realtime is accessed over WebRTC, only VAD mode is supported; Manual mode is not supported. Audio is transmitted via the audio track, without sending input_audio_buffer.append; video is transmitted via the video track, without sending input_image_buffer.append.
Model Event Examples
Audio and video are transmitted via media tracks, without using WebSocket’s media send events.
session.created → session.update → session.updated process for qwen3.8-omni-flash-realtime. Configuration fields should follow this model’s event reference. After receiving session.updated confirming that configuration is complete, mount the upstream media track.
See full example for the code.
For the example model qwen3.8-omni-flash-realtime, when audio output is enabled, you can use response.audio.done to check the model’s audio generation status; this event does not indicate that the client has finished playing the audio.
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.
startSendingMedia() attaches the upstream track, and ontrack processes the received media.
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.
In the complete example, endSession() is responsible for releasing the connection and media resources.
Call 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 the Data channel
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.
The names, fields, parameters, and timing of sent events follow the target model’s Client Event Definitions; the parsing method, state changes, results, and error handling after receiving messages adhere to the model’s Server Event Definitions. Initialization events are sent as needed according to the model’s requirements, while subsequent text and control events are sent based on business needs.
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.
In the complete example, sendModelEvent() and bindDataChannel() send and receive events.
In the complete example, the start button calls startSession() and the end button calls endSession(). These are functions defined in this example, not built-in WebRTC APIs.
Qwen-Omni-Realtime Event Definitions
| Model or application | Client events (send) | Server events (receive) |
|---|---|---|
| Qwen-Omni-Realtime | Client Events | Server Events |
-
Use the
typefield of events to identify model events, and handle associated identifiers according to this model’s event reference. - Operations such as initialization confirmation, input submission, response cancellation, and task completion—required by the model—are all handled within the Data channel according to the corresponding protocol; these constitute the model’s interaction semantics and are distinct from disconnecting the transport connection.
- Audio and video data are transmitted via media tracks. When referencing the model event documentation, media encapsulation and available interaction modes still follow the access methods outlined here and do not directly adopt WebSocket’s media transmission approach.