Browser softphone (WebRTC) vs agent-mobile dialer: which mode fits your team

Two ways an agent can take a call on a cloud dialer: through a browser tab talking WebRTC to the platform's SIP gateway, or through the platform bridging a call to the agent's mobile phone via a trunk. Both are legitimate. Both ship in production on dialque tenants today. And picking the wrong one for your team profile will cost you either audio quality, per-minute margin, or the ability to keep dialing when a fibre link drops in Vidarbha.

This post is the honest trade-off — what each mode actually is, what changes mechanically between them, the cost math that flips once you fold in trunk billing, which team profiles pick which, how the hybrid deployment works, and how to migrate a live floor between modes without dropping calls. Written for contact-centre ops leads in India who have to defend the decision to a CFO who reads the trunk bill line by line.

What each mode actually is

Browser softphone (WebRTC). The agent opens the dialque web app in Chrome or Edge, keeps the Dialer tab foregrounded, and answers calls on a USB headset. The audio path is browser → WebRTC (Opus codec) → dialque's SIP gateway → carrier trunk → customer. One media leg on the platform side (the customer leg); the agent's audio never touches a trunk minute because it never leaves WebRTC.

Agent-phone via trunk ("mobile mode"). The tenant is switched to Phone mode in System Settings. When a call is placed, the platform first dials the agent's mobile number — read from the Phone Number field on their agent profile — over the same class of SIP trunk it uses for customers, waits for the agent to answer, then dials the customer number and bridges the two legs. The agent's browser tab keeps running: dispositions, campaign controls, status, notes and screen-pop all live there. Only the audio moves to the phone.

Both modes work for manual dial, click-to-call, inbound queue delivery, and IVR transfers. Predictive and progressive autodial stay on the browser softphone regardless of tenant setting — the reason is on the timing side and we get to it below. Agents in a Phone-mode tenant who have not filled in a Phone Number silently stay on the browser softphone, which is the correct fallback, not a bug.

The mechanical differences that matter

| Dimension | Browser softphone (WebRTC) | Agent phone via trunk | |---|---|---| | Media legs | 1 (platform → customer) | 2 (platform → agent, platform → customer, bridged) | | Codec | Opus 48 kHz on the agent side | G.711 on both legs, typically | | Setup latency | ~200-400 ms | ~2-4 s (agent-leg ring + pickup) | | DTMF reliability | RFC 2833 / SIP INFO, near-perfect | Depends on trunk DTMF passthrough | | Warm transfer / conference | Full, agent-controlled | Limited — the mobile leg cannot be splintered mid-call | | Recording quality | Best (Opus source) | Trunk-quality on both legs | | Hardware per seat | USB headset + wired internet | Just the agent's phone | | Survives browser going offline | Call drops | Call survives, only app controls freeze | | One-way audio failure mode | WebRTC ICE / NAT / codec | SIM-operator quality and trunk signalling |

Two of those rows drive most of the operational decisions.

Setup latency is the reason predictive and progressive dialing do not run in Phone mode. Predictive relies on the dialer having a live agent ready inside a two-second window when a customer answers — a 2-4 second agent-leg ring on top of the pacing math would push abandon rate straight through the TRAI TCCCPR 2018 cap of 3%. Progressive is more forgiving on abandon, but the pacing still assumes near-zero agent-side setup. The platform enforces this: even in a Phone-mode tenant, predictive campaigns keep dialing the browser softphone. Intentional, and the right default.

The one-way-audio row is where mobile mode quietly wins in tier-2 and tier-3 India. WebRTC needs a stable path with enough upstream to sustain the Opus stream — around 40 kbps encoded, bursty and jitter-sensitive. A shared 30 Mbps BSNL fibre pipe feeding a 40-seat office in Nashik with a monsoon flap on it is exactly the failure profile that produces "the customer sounds like a robot" tickets. A 4G Jio or Airtel connection to the agent's phone is often more consistent under the same conditions because the mobile network is engineered for voice first and everything else second.

The cost math

This is where the CFO gets involved. On dialque's platform-provided trunks the rule is simple: phone-mode calls count at 2× minutes because you are paying for the agent leg and the customer leg. BYOC — bring-your-own-carrier trunks contracted directly with Tata, Airtel Business, Reliance or VilPower — changes the shape. The customer leg rides your trunk at your rate. The agent leg is billable on either your trunk or the platform's, depending on how you routed it in the SIP profile.

Take a typical Indian outbound SDR seat: 4 hours of talk time per day, 22 working days per month, ≈ 5,280 talk minutes/month per agent. Trunk minutes at ₹0.50/min on a passthrough Tata / VilPower / Airtel Business contract:

| Mode | Trunk minutes billed | Trunk cost per agent per month | |---|---|---| | Browser softphone (WebRTC) | 5,280 (customer leg only) | ₹2,640 | | Phone mode, platform-provided trunk | 10,560 (agent + customer) | ₹5,280 | | Phone mode, BYOC customer + platform agent leg | 5,280 BYOC + 5,280 platform | ₹2,640 + platform agent-leg rate |

For a 30-agent outbound team, phone mode on a platform-provided trunk adds ≈ ₹79,200/month in raw trunk cost versus WebRTC. That is real money and it is why the default recommendation for high-volume office-based teams is WebRTC. The trade flips a little when you fold in the hardware side: a USB headset that survives call-centre wear runs ₹1,500-2,500 per seat and gets replaced every 12-18 months. Thirty seats on headsets is ₹45,000-75,000 in year-one hardware alone, plus someone in ops running the replacement cycle.

The dialque platform pricing itself is per-agent per-month — Starter ₹1,500, Growth ₹2,000, Enterprise ₹2,500 — and does not change between modes. What changes is the trunk bill underneath and the hardware bill next to it. See the full breakdown on the [pricing page](/pricing).

Which team profiles pick which

WebRTC wins for:

• Office-based inside-sales floors with wired internet, USB headsets, and full-desk agent setups
• Any team running predictive or progressive autodial — the platform enforces this, no override
• BFSI voicebots and collections desks where recording quality and DTMF reliability into IVR menus are load-bearing
• Teams that use warm-transfer and conference regularly — three-way collections calls with a supervisor, sales handoffs to a solution engineer
• High-volume outbound where the 2× trunk math is material at your minute count

Phone mode wins for:

• Field agents — home-lending DSAs, insurance surveyors, medical reps on doctor visits — who cannot sit at a headset
• Teams in tier-2 / tier-3 cities where office internet is a coin flip and mobile networks are more reliable than the BSNL fibre in the wall
• Small teams (5-15 seats) who want zero hardware procurement and are comfortable spending a bit more on trunk minutes
• Agents on legacy 2 GB-RAM Windows 10 machines where the Chrome + WebRTC stack chokes and the CPU sits at 95% during a call
• Recovery lines where the customer conversation is inherently mobile-centred and the agent is often walking the customer through a UPI payment on their own phone

Neither list is theoretical. Both configurations are running on dialque today and both are correct for the team that picked them.

Hybrid: some agents on WebRTC, some on phone

The tenant setting is global, but the escape hatch is per-agent. Because agents with a blank Phone Number silently keep using the browser softphone, you can run a hybrid deployment inside one tenant by leaving the tenant in Phone mode and not filling in Phone Numbers for the office-based seats. Field team gets bridged to their mobiles. Inside team keeps WebRTC.

The pattern we see most often on Indian lending books: a central telecalling floor in Gurugram or [Bengaluru](/dialer/bengaluru) — 60-80 seats, predictive dialing, headsets — on WebRTC, and a network of field DSAs across tier-2 cities in Phone mode. One tenant, one dashboard, one set of dispositions, two audio paths. Reporting stays unified because the campaign, disposition, recording URL and transcript all sit on the platform regardless of where the agent audio landed. Same DLT template registration for the payment-link SMS. Same NDNC scrub before the dial. Same RBI FPC window enforcement on the calling hours.

Migrating a team between modes

Configuration change, not a re-platform. The steps that matter:

1. In System Settings, flip the tenant default from Browser to Phone (or the reverse). This affects new call sessions only — currently-live calls are not disturbed.
2. If moving to Phone mode, populate the Phone Number field for every agent who should be bridged to their mobile. Any agent whose field stays blank keeps the browser softphone as a per-agent exception.
3. Move any campaign that is predictive-paced back to progressive or preview if you want its agents on the phone. Predictive campaigns override the tenant default and stay on WebRTC regardless — the safety governor for the TCCCPR abandon cap sits at the campaign level.
4. Warn the agent floor 24 hours ahead. The first Phone-mode call feels different — the browser tab rings, the agent's phone rings, they answer the phone, then the customer connects. Training moment, not a support ticket.
5. Run a one-week reconciliation on the trunk bill. Confirm the 2× minute math on platform-provided trunks lines up with what you expected. If it does not, the audit path is the trunk-side CDR — usually there are more transfer-to-IVR minutes in the call profile than the steady-state talk-minute estimate assumed.

FAQ

Which mode gives better audio quality?

WebRTC, in a clean-network office environment. Opus at 48 kHz beats the G.711 that both legs of a phone-mode call ride on, and recording clarity for QA and dispute audit is meaningfully higher. The reverse holds when the office network is the constraint — a lossy WebRTC path sounds worse than a clean VoLTE phone leg, and the phone leg wins on perceived quality even though the codec ceiling is lower. The audio-quality argument is really a network-quality argument in disguise.

Does phone mode consume the agent's mobile data?

No. The agent's phone rings via a normal PSTN call over their SIM's voice channel, not data. Voice-over-LTE (VoLTE) on Jio, Airtel or Vi is what carries the audio on modern handsets, but from the agent's billing perspective it is a regular incoming call. On any standard postpaid plan, or a Jio / Airtel prepaid pack with unlimited incoming, there is no per-minute personal cost to the agent — which is what you want, because you do not want your recovery agents worrying about their own airtime while on a customer call.

Can we run predictive dialing in phone mode?

No, and the platform will refuse to. Predictive paces outbound dials against the pool of agents statistically ready to talk inside the next 1-2 seconds. The 2-4 second agent-leg ring in phone mode wrecks that math, drives the abandon rate above the TRAI TCCCPR 2018 3% cap, and puts your DLT registration and NDNC posture at risk. Progressive and preview modes are the safe choices for phone-mode seats — pacing is one-at-a-time, so the agent-leg ring is absorbed inside the natural pause between calls rather than colliding with the abandon governor.

Can one team have some agents on WebRTC and some on phone?

Yes. Set the tenant to Phone mode and leave the Phone Number field blank for any agent you want on the browser softphone. Those agents fall through to WebRTC silently. This is how most hybrid deployments — inside-sales floor plus field-DSA network — are configured on dialque today, all inside one tenant with one dashboard.

What happens if the agent's browser tab loses internet during a phone-mode call?

The audio call continues — it is on the trunk, not on WebRTC. The agent will lose the ability to change status, capture a disposition, or hang up from the app until the browser reconnects, but the customer conversation is unaffected. This is a genuine reliability advantage of phone mode in flaky-network environments and it is one of the reasons the mode survived to launch alongside WebRTC rather than as a fallback under it.

How do we migrate a live team from WebRTC to phone mode without dropping calls?

Flip the tenant setting during a low-volume window. Agents currently on live calls stay on WebRTC for the duration of the call — the setting change only affects new sessions. Populate Phone Numbers for the field seats ahead of the flip and leave the office seats blank. Confirm predictive campaigns are re-paced to progressive or preview if their agents are moving to phone. Full migration is usually done inside one shift and no live customer call is ever hung up by the change itself.

---

If you are still deciding which mode fits your ops profile, or you want to see the hybrid pattern configured against your own agent split, [book a walkthrough of both modes on real Indian trunks](/contact?source=demo&topic=browser-softphone-vs-mobile-phone-dialer) and we will spin up a test tenant with your call profile.