WebRTC with PSTN Fallback: Keep Calls Connected

Why WebRTC calls fail

WebRTC is reliable on ordinary home and mobile connections. Failures cluster in a few predictable situations, and knowing them tells you which fallback each one needs.

The fallback ladder

The goal is to try the cheapest, best-quality option first and fall back only as far as you have to. ICE, the connection process built into WebRTC, already tries the first three steps automatically if you give it the right servers. The last step is yours to build.

Get TURN right before adding the phone

A phone fallback is no substitute for a well-configured TURN service; it is what you add after it. Most "WebRTC doesn't work here" reports disappear once TURN over TLS on port 443 is in place.

• Run TURN servers close to your users, in each region you serve.
• Offer TURN over UDP, TCP and TLS, with TLS on port 443 using a valid certificate.
• Give the browser all of them in iceServers, so ICE can try each automatically.
• Use short-lived TURN credentials generated by your server, not static passwords in the page.
• Monitor TURN usage and bandwidth; relayed calls cost you bandwidth on every minute.

Our production TURN server guide covers coturn configuration, TLS on 443 and scaling in detail.

Detecting a failing call

The sooner you notice a problem, the sooner you can offer the phone, ideally before the user gives up. Combine three signals:

Don't switch on a single bad second. Smooth the numbers over several seconds, show a gentle "connection is weak" notice first, and offer the phone if it doesn't recover.

Detection code in the browser

// Watch connection state and quality; offer phone fallback when needed
function watchCall(pc, onTrouble) {
  let badSamples = 0;

  pc.addEventListener("iceconnectionstatechange", () => {
    if (pc.iceConnectionState === "failed") onTrouble("no-connection");
  });

  const timer = setInterval(async () => {
    const stats = await pc.getStats();
    stats.forEach((r) => {
      if (r.type === "remote-inbound-rtp" && r.kind === "audio") {
        const loss = r.fractionLost ?? 0;          // 0..1, reported by the far end
        const rtt = r.roundTripTime ?? 0;          // seconds
        const poor = loss > 0.05 || rtt > 0.4;     // tune for your users
        badSamples = poor ? badSamples + 1 : 0;
        if (badSamples >= 5) onTrouble("poor-quality"); // about 5 seconds of poor audio
      }
    });
  }, 1000);

  return () => clearInterval(timer);
}

// Usage: show the fallback panel with dial-in details or a call-me form
const stop = watchCall(peerConnection, (reason) => {
  showPhoneFallback({ reason });                  // your UI
});

Report each fallback with its reason to your analytics. Over time you will see which networks and regions cause trouble, which often points to a missing TURN region or a customer whose firewall needs a rule.

Try audio-only before the phone

When the connection works but bandwidth is poor, the phone isn't the first answer. Video uses far more bandwidth than voice, so dropping it often rescues the call while keeping the user in the browser.

• Turn off the user's outgoing video, or lower its resolution and frame rate, when packet loss or round-trip time rises.
• Stop receiving other participants' video, or switch to a low-quality layer if your SFU uses simulcast.
• Keep Opus audio with forward error correction (FEC) enabled, which helps it survive packet loss.
• Prioritise audio in your SFU, so voice keeps flowing when the network is congested.
• Tell the user what happened ('switched to audio only to keep your call stable') and let them turn video back on.

Only if audio is still poor, or the connection fails outright, offer the phone.

Phone fallback options

Most products offer both dial-in and call-me, with call-me as the default and dial-in for users who prefer it or whose number can't receive calls.

Joining the phone into the same call

The critical design choice: the phone leg must join the same session, not start a new call. Otherwise the user disappears from the meeting and reappears as a stranger.

Link the phone participant to the user's identity, so the room shows "Priya (phone)" rather than an unknown number, and so you can mute the browser's microphone automatically when the phone connects. Our WebRTC-SIP gateway guide covers the gateway side.

Example: call the user back into a LiveKit room

With LiveKit, your server can dial the user's phone and add them to the existing room as a SIP participant, using an outbound SIP trunk you have configured.

# Python (livekit-api): call the user's phone and join it to the same room
from livekit import api

async def call_me(room_name: str, user_id: str, phone_e164: str):
    lk = api.LiveKitAPI()   # reads LIVEKIT_URL, LIVEKIT_API_KEY, LIVEKIT_API_SECRET
    try:
        await lk.sip.create_sip_participant(api.CreateSIPParticipantRequest(
            sip_trunk_id="ST_outbound_trunk_id",       # your outbound trunk
            sip_call_to=phone_e164,                     # e.g. "+14155550123"
            room_name=room_name,
            participant_identity=f"{user_id}-phone",    # tie it to the user
            participant_name="Phone audio",
        ))
    finally:
        await lk.aclose()

Validate the phone number on your server, limit how often a user can request callbacks, and only allow callbacks to the number on the user's account or one they have verified, to prevent abuse.

Mobile apps: the same idea, easier switch

Native mobile apps have an advantage: the phone itself can make the fallback call. Instead of asking the user to dial and type a PIN, the app can start a regular phone call to your dial-in number with the PIN sent automatically as keypad tones.

// A tel: link with pauses and the PIN as DTMF: dial-in number, wait, then PIN and #
// iOS and Android both understand commas as pauses in tel: links
const dialIn = "tel:+14155550100,,482913%23";   // %23 is "#"
window.location.href = dialIn;                     // in a native app, open it with the platform's URL API

• Offer 'Continue on a regular phone call' when the in-app call degrades.
• Use CallKit on iOS and the Android telecom framework, so the switch looks like a normal phone call.
• Keep the app's video and chat running if the user wants them, muting the app's audio.
• Fall back to call-me when the device can't place calls, for example on a tablet without a SIM.

Designing the user experience

• Show the fallback inside the call screen, not as an error page: 'Your connection is weak. Continue by phone?'
• Default to call-me with the user's saved number, one click to confirm.
• Show dial-in numbers for the user's country, with the PIN pre-filled where the phone supports it.
• When the phone connects, mute the browser microphone and speaker automatically to prevent echo.
• Keep video, screen sharing and chat running in the browser if they still work.
• Let the user switch back to the browser when their connection recovers.
• Tell other participants what happened: 'Priya joined by phone'.

Cost, numbers and security

Because fallback is used on a small share of calls, phone costs are usually modest. Track minutes per call and per region to catch abuse or a misconfigured TURN region early. Our WebRTC developments guide covers related trends.

Testing your fallback

Fallback paths are used rarely, which is exactly why they break unnoticed. Test them on purpose, regularly.

Metrics to track

Review these numbers monthly. A rising share of TURN TCP or phone fallback in one region usually means a missing TURN server nearby, a new corporate customer behind a strict firewall, or a browser update that changed behaviour, all of which are cheaper to fix than to keep paying for in phone minutes.

A real example

CelloIP built a WebRTC-to-SIP gateway for a VoIP provider using Kamailio, RTPengine and FreeSWITCH. Browser users get a web softphone, a click-to-call widget, video calls and calls to ordinary phone numbers, at hundreds of concurrent calls. The same building blocks, a SIP gateway between browsers and the phone network, are what make a PSTN fallback possible: the phone and the browser meet on the same platform.

Frequently asked questions