Audio and video calls overview
Understand VoIP calling signaling, room information, and event boundaries in the OpenIM Flutter SDK.
The OpenIM Flutter SDK's SignalingManager provides signaling APIs for initiating, accepting, rejecting, cancelling, hanging up, querying rooms, and synchronizing call states. It coordinates participant entry into rooms and manages call session lifecycles; it does not capture camera video, play remote audio/video tracks, or render call UI components.
Pass the roomID, token, and liveURL returned by the SDK to your chosen WebRTC/live media engine (such as LiveKit). Your application manages device hardware permissions, audio/video track capture, network fallback policies, and UI views. The OpenIM Flutter SDK provides call signaling orchestration rather than standalone media streaming pipelines.
Calling lifecycle workflow
- Call Start a single call or Start a group call.
- The invitee receives an invitation notification in Handle call events, extracts
SignalingInfo, and decides whether to accept or reject. - The callee calls Accept a call. Both parties connect to the media server using the returned room credentials.
- Update local state as participants, media streams, and custom signals arrive via listeners during the call.
- The initiator can cancel an unanswered invitation; any connected participant can hang up an active call.
Core data structures
| Structure | Description |
|---|---|
InvitationInfo | Inviter, invitee list, group ID, room ID, media type, timeout, and session type. Fields are nullable in Dart; validate them when handling callbacks. |
SignalingInfo | Operator userID, the full invitation payload, and optional offlinePushInfo. |
SignalingCertificate | Room credentials returned by OpenIMServer, including roomID, token, liveURL, and busy user lists. |
RoomCallingInfo | Group call status including room details, invitations, active participants, and access credentials. |
customData is not a property of the Flutter InvitationInfo model. For lightweight negotiation during a call, send custom signaling messages within the room. Custom signaling is intended for temporary in-call coordination, not persistent data storage or file transfer.
State synchronization and event boundaries
State-modifying operations (initiating, accepting, rejecting, cancelling, and hanging up) require handling both the Future and listener callbacks. Future completion signifies that the signaling request reached the server; listener events reflect asynchronous state transitions received across participants and other devices.
Listen to invitation lifecycles, participant joins/leaves, hang-ups, and stream changes in Handle call events. For in-room messaging, see Send a custom signal. Room and token queries return snapshot data at invocation time via Futures and are documented under the call information guides.
Manage call listeners centrally in Handle call events. Use roomID as the primary merge key, qualified by participant userID. When rendering room membership, query fresh room status snapshots to reconcile UI state.
Related guides
Was this page helpful?