Audio and video calling overview

Every capability in this section is Commercial and requires OpenIMServer commercial signaling services. unix-openim-sdk provides the signaling APIs required to invite, accept, reject, cancel, hang up, query rooms, and synchronize call state. It coordinates participants, room information, and the signaling lifecycle; it does not capture camera frames, render remote media, or provide call UI.

The application passes the returned roomID, token, and liveURL to its realtime media engine and remains responsible for device permissions, media tracks, weak-network behavior, and UI state. Signaling is not a complete WebRTC media SDK. For complete call and meeting UI, integrate openim-av-runtime; it reuses the login owned by this plugin and never initializes a second OpenIM Core.

Call flow

1. Log in to IM and register signaling listeners. Call signalingInvite() for a one-to-one call or signalingInviteInGroup() for a group call.
2. The invitee receives a raw JSON payload from onReceiveNewInvitation, validates it, maps it to OpenIMSignalingInvitationInfo, and presents incoming-call UI.
3. The invitee requests media permission before calling signalingAccept(), or calls signalingReject() to decline.
4. Both sides use the returned room ID, token, and live URL to join the media engine.
5. Participant, stream, and custom-signal events update the local call state while the room is active.
6. The inviter can cancel an unanswered invitation, and any participant can hang up an established call.

Core data

customData and custom signaling are suitable only for non-secret negotiation data. Never put long-lived credentials, administrator secrets, or private authorization state in them.

State and event ownership

For invite, accept, reject, cancel, and hangup operations, handle the Promise result separately from signaling events. Promise success means OpenIMServer accepted or completed that request; events describe incremental state observed by the inviter, invitee, other devices, or room participants. They are not the same completion signal.

Signaling events carry raw JSON strings and must be validated before they enter application state. The complete invitation and room event lifecycle belongs to Handle call events. Custom signal events belong to Send a custom signal. Room, token, and startup-invitation queries only return a snapshot from their Promise.

Use roomID as the primary call key and combine it with user IDs for participant state. Re-login creates a new event scope; query a room only when a current snapshot is needed.

Find a task

Keep one active call or meeting per login/runtime. Never persist or log tokens, live URLs, or raw signaling payloads.