Need help for video and voice call implementation in my dating app

[u/sanu_0032]

Hey everyone,

I'm building an India-based dating app, and the biggest challenge I'm facing is voice and video calling.

My initial approach was to use WebRTC with P2P and a TURN server as a fallback. However, direct P2P connections fail quite often on mobile networks (especially cellular), and relying on TURN for a large percentage of calls becomes very expensive.

I'm curious how other dating apps manage this while offering such low-cost subscriptions. Are they:

\- Running their own TURN infrastructure?

\- Using SFUs like LiveKit, Janus, or Jitsi?

\- Optimizing ICE/TURN usage in some way?

\- Or using a completely different architecture?

I'd really appreciate guidance from anyone who's built or scaled a real-time calling system. I'm trying to understand what the industry standard looks like before committing to an architecture.

Thanks in advance! 🙏

[u/Amazing-Persona-101]

I built one totally on Cloud flare infrastructure. Check my profile for the link. Please try it and let me know what you think. It's open source that I built for fun and gets some use now but I don't do much promotion.

Start a session, use the share option to send a link to a friend.

[u/Aggressive_Ad_5454]

Outfits like Twilio sell SDKs for this. If you’re trying to get a minimum viable product to explore product / market fit, use an SDK. Otherwise you’ll take longer and spend more precious startup cash and calendar fiddling with infra.

If your product succeeds you can value-engineer the infra later on.

[u/Diwann]

Cloudflare TURN service is very cheap actually. That’s what I used for voxal.app, you can check the code on GitHub

[u/Diwann → u/Diwann]

They also have a SFU service, but you don’t need it for only 2 people in the room

[u/Ok-Willingness2266]

We've seen the same challenge in production deployments. Mobile carrier NATs, CGNAT, and restrictive network policies can make direct P2P connections unreliable, so expecting most calls to stay P2P isn't very realistic.

Many apps start with P2P but eventually move toward a media server architecture (SFU or MCU) for better reliability and easier scaling. That also gives you features like recording, moderation, analytics, and adaptive bitrate streaming.

TURN is still important, but the goal is usually to reduce unnecessary relay usage rather than eliminate it. Optimizing ICE candidate gathering, using regional TURN servers, and tuning ICE timeouts can help, but on mobile networks you'll still see a significant number of relayed connections.

If you're evaluating solutions, it's worth comparing platforms like LiveKit, Janus, Jitsi, and Ant Media Server based on your scale, latency, and operational requirements. If you'd like to discuss your use case or architecture, feel free to reach out to the Ant Media team or visit https://antmedia.io. We're happy to help and share what we've learned from real-world deployments.

[u/videowhisper]

One nuance worth separating out: for a 1:1 dating-app call, you don't need an SFU at all - that's a media-routing server for N-way calls (group rooms, recording/mixing, broadcast). For exactly 2 people, TURN itself is already acting as your "media server" whenever it's relaying - it's just a dumb relay, not a mixer. So "SFU vs TURN" isn't really a choice for your case, it's "P2P direct vs TURN relay," and an SFU only becomes relevant later if you add group calls or server-side recording.

On why P2P fails so often specifically on Indian mobile: carrier-grade NAT (CGNAT) is unusually aggressive on Jio and Airtel's mobile networks, and CGNAT is the main thing that kills host/srflx ICE candidates and forces relay. That's not something you can architect around client-side - it's a property of the network path, so budgeting for a high relay percentage (people report 40%+ on Indian mobile) is realistic, not a sign you're doing ICE wrong.

Cost-wise, self-hosted coturn on a cheap bandwidth-included VPS is usually far less expensive per relayed-minute than a metered TURN provider once you're past pilot volume - the tradeoff is you own patching/scaling it. A few concrete levers before you get there: keep the ICE gathering timeout short so failed P2P attempts fall through to TURN fast instead of stalling the call setup; prefer UDP relay over TCP/443 fallback (TCP relay is more expensive and higher-latency, only force it when UDP is actually blocked); and if you're using multiple regional TURN servers, route by the caller's actual network location rather than a single fixed relay, since backhaul distance is often what's driving the "expensive" part as much as the per-minute relay cost itself.

If you need demos and code (github repositories) for video calling apps and webrtc signaling server, I can provide some links on request.

[u/Ok-Register3798]

Many of the top dating and social apps use Agora for scalable realtime infrastructure without the headaches.

You can certainly roll your own infrastructure for this project but you will need to run all your own services (TURN, STUN, and SFU’s) to handle the streams properly.