A call can work perfectly in the office and fail on a mid-range Android phone with a weak connection. I build the call flow, the media layer and the fallback behaviour together, including permissions, reconnects, billing events and the notifications that bring people back into the call.
Flutter · WebRTC · 100ms · LiveKit · Android & iOS · Remote worldwide
Permissions, camera and microphone checks, network quality, ring state, joining, reconnecting, ending and billing all belong to the same flow. If those states live in different screens, users get stuck in a room that looks connected but has no audio.
I design the call state machine first, then wire it to the media provider and the backend. That makes it possible to show a useful message when the camera is unavailable, the network drops or the other person never joins.
100ms and LiveKit can remove a lot of WebRTC infrastructure work. The trade-off is cost, vendor lock-in and the limits of the provider's SDK. A custom WebRTC stack gives more control but needs TURN servers, monitoring and a team that can operate it. I help choose based on call volume, recording needs, moderation and budget.
Either way, the app still needs device testing. Audio routing, Bluetooth, speakerphone, camera switching and background behaviour vary across Android manufacturers. Those differences are where call products usually break.
Per-minute billing, wallets, host payouts, refunds and failed-call handling need a source of truth on the server. The client should never be the only place that decides how long a call lasted. I build idempotent call events and reconcile them with the provider's webhooks.
Safety features — block, report, call recording consent, moderation and a clear policy for abusive behaviour — are part of the product, not an afterthought. I can build the flows and the admin tools around them.
Explore examples of mobile, Smart TV and integrated product work.
It depends on the product. 100ms and LiveKit are good managed options; Agora is another. A custom WebRTC build makes sense when you need control that a provider cannot give you. I will recommend one after looking at call volume, recording, moderation and budget.
Audio routing, camera behaviour, permissions and background restrictions vary by manufacturer and OS version. The fix is a device matrix and explicit fallback states, not assuming one emulator represents every phone.
Yes. The server records call events, calculates duration and charges a wallet or subscription. Provider webhooks are reconciled so a dropped client does not become a free call.
Recording is possible with some providers and custom stacks, but it brings consent, storage, privacy and app-store policy questions. We would decide the rules before implementation.
Yes. Push notifications, deep links and the in-app ring state are part of the flow. The exact behaviour depends on Android and iOS background restrictions.
Yes. Chat, presence and call invitations can share the same account and conversation model. I would still build and test the call lifecycle separately.
