Quick answer: Browser-native click-to-call uses WebRTC — real-time media negotiated in the browser over HTTPS — to start a voice interaction from a website without a phone number, a PSTN hop, an app install, or a browser extension. When that path lives inside a CPaaS like Devotel Orbit's RTC-PaaS pillar, it becomes a first-class inbound surface alongside SIP trunks, DID numbers, and PSTN: the visit's page context resolves the caller's identity and intent before the agent picks up, agents work off a wallboard instead of a handset, and PSTN fallback takes over when the browser path can't. This guide covers why the "chat is solved" frame misses the real gap, what WebRTC adds that phone numbers can't, how to evaluate the operational posture, which controls the tenant owns, a three-way comparison, and a worked e-commerce escalation example.
Why "chat is solved" is wrong
Websites converged on a widget-first contact model in the 2010s, and most of the buyers comparing CPaaS platforms today inherited that convergence. The widget answers what it can answer, and when it can't, the customer is handed a phone number, a form, or a "we'll email you" promise. The underlying assumption — that voice is a separate channel the visitor escalates to elsewhere — is the gap.
Voice conversion on web traffic stays unmeasured because it depends on a channel change. The visitor whose intent is high ("Can someone confirm this SKU ships today?") loses momentum the moment they dial. The agent who does pick up gets a cold start: no page context, no cart, no attribution. Any team measuring abandonment on the "call us" step sees the leak, but the framing stays "voice is for callers, chat is for browsers" because the two surfaces have always been wired separately.
The gap closes when a page element acts as a phone. The visitor clicks, consent prompts are honored in the browser, a WebRTC session opens to the same agent pool the PSTN lands on, and the agent answers with the page, cart, and prior chats already on the desk. That closing is what Devotel Orbit's click-to-call surface builds on — but to evaluate it, a buyer has to understand where WebRTC sits relative to the PSTN leg they already run.
Where WebRTC sits in the CPaaS portfolio
WebRTC is a transport, not a channel. It rides HTTPS with the page, uses the browser's media stack (capture, echo control, Opus), and terminates on a WebRTC-aware edge the same way an inbound SIP trunk terminates on a SIP-aware edge. In Orbit's nine-pillar layout, WebRTC click-to-call is part of RTC-PaaS, the pillar that also carries video rooms, live broadcast, recording, and co-browse. The voice side shares infrastructure with SIP on the termination edge but presents an entirely different call origination story.
The differences matter when you compare it against a DID number:
- Context pre-resolve. A PSTN call arrives with an ANI and a caller name lookup at best. A WebRTC session can attach the page URL, UTM parameters, cart contents, signed-in user id, and transcript of any prior in-page chat before the first audio frame. Agents open the page-analytics snapshot, not a blank CRM draft.
- Identity resolution without an account check. A known user clicking on a "call sales" button connects as that user. Even where the session is anonymous, device- and first-party-cookie-level identification replaces the "can I get the last four of your card" dance.
- No per-call deliverability. No STIR/SHAKEN attestation, no PSD/CNAM risk, no carrier-flagged "scam likely" screen. The visitor's origin is provable from the browser session.
- Route into the same queue. Orbit's voice queue and wallboard treat a WebRTC leg as an inbound call with a
webrtcorigination tag. Supervisors see the same SLA posture, agents answer on the softphone or SIP device they already use.
None of this replaces PSTN — it complements the PSTN leg that handles true cold callers and mobile-fallback. See the comparison below for when each lane should win.
How an operations team evaluates browser calling
Buyer checklists for embedded voice tend to fixate on SDK ergonomics; the questions below are the ones that survive a real deployment:
Latency baseline. Establish the browser path's end-to-end latency budget on your region's connection. WebRTC's peer-to-peer ideal holds in a demo and collapses at scale, so the path of record should be browser → TURN-relay or SFU-alike edge → your agent. In Orbit the tenant sees the media path in the call detail record and can flag legs that fall back to relay when direct UDP wasn't feasible. Treat 150–250 ms one-way as healthy; anything above 400 ms will degrade echo control and agent patience.
Agent presence. The click-to-call widget is only as useful as the queue it rings. Before launch, confirm the widget targets a queue with logged-in agents during the advertised hours, and that the wallboard shows the origination tag (webrtc) distinctly so supervisors can see the lane's health. A click-to-call button that rings an empty queue teaches visitors "this button is decorative" in the first hour.
PSTN fallback policy. Browser voice fails in predictable places: hardened desktop policies, restrictive enterprise proxies, older mobile browsers, and networks that block UDP entirely. When the browser fails, the widget should present a PSTN dial or call-back option rather than silently fail. In Orbit this is a configuration toggle on the widget surface, not a product fork — treat "fallback path exists and is staffed" as a launch blocker.
Recording and storage. If your PSTN calls record, WebRTC calls record under the same retention policy. The path-conditional settings some point solutions carry ("record SIP only, not browser legs") are exactly the kind of asymmetry auditors flag — confirm the widget leg inherits your global recording default.
Tenant-owned controls
Embedded voice is tenant-configured surface, not a vendor opinion. Orbit exposes the WebRTC posture as tenant-owned knobs:
- TURN/STUN posture. TURN relay is required for NAT traversal; the tenant picks whether to allow UDP-direct attempts first (better latency, wider browser coverage) or force relay (predictable path, tighter firewall story). Both postures are correct for different risk models; the control exists so you can pick.
- Consent prompt before mic access. The browser's getUserMedia prompt is the legal/consent boundary in most jurisdictions. The widget must present a first-party prompt explaining the call before the browser-level prompt fires, and the dismissal of that prompt must be honored without re-prompting on the next page load.
- Recording-consent announcement. Where your recording Consent Mode is set to announce, the WebRTC leg plays the spoken disclosure the same way the PSTN bridge paths do. Your configured announcement mode applies, not a "browser-leg exemption."
- Origination tagging. Legs arriving over WebRTC carry an
origination=webrtctag so the wallboard, agent reports, and billing exports distinguish the lane without your analysts rebuilding classification heuristics.
All of these are configuration the tenant owns. None require code change, and none ask you to break the PSTN leg.
WebRTC vs PSTN click-to-call vs call-back
| Dimension | Browser-native WebRTC | PSTN click-to-call | Call-back (request a return call) |
|---|---|---|---|
| Setup for the visitor | None — one click in the page | They dial a number the site renders | They leave a number and wait |
| Audio path | HTTPS/WebRTC through the CPaaS edge | Direct PSTN on a DID | Outbound PSTN call from your pool |
| Page context for the agent | Attached pre-pickup | None (or poor CLID) | None — reversal loses the context |
| Attestation / deliverability | Not applicable | STIR/SHAKEN applies | STIR/SHAKEN applies |
| Mobile coverage | Good (modern Safari/Chrome) | Universal | Universal |
| Agent staffing posture | Queue must be logged-in | Queue must be logged-in | Can queue behind true follow-up |
| Fallback posture | Must offer PSTN fallback | N/A | N/A |
| When it wins | e-commerce escalation, SaaS support, embedded product flows | Desktop B2B where visitors expect a number | Low-staff hours, high abandonment risk |
The rules of thumb: WebRTC for high-intent page visitors and high-context escalations, PSTN click-to-call for the "visitors want to use the phone they have" segment, call-back for the understaffed-hours or long-queue case. Most Orbit tenants run all three lanes simultaneously with routing logic that picks WebRTC when the queue is staffed, PSTN when specific visitor segments demand it, and call-back when the queue is capped.
Worked example: e-commerce pre-purchase chat escalation
The tenant in this example sells made-to-order furniture, staffs a queue from 09:00–21:00 local, and routes PSTN inbound to the same agents. Chat on the checkout page escalates to voice via a click-to-call button that appears only on the checkout, product-detail, and shipping-questions pages. The sequence below is illustrative — it shows the operational points a launch plan has to cover, and any numbers you measure will come from your own telemetry, not from a vendor report.
- Scope the button. The widget renders only on high-intent pages, so the queue does not take a click from every banner ad on the blog. Page-level scoping is the cheapest abandonment control you own.
- Attach pre-pickup context. Checkout context — cart SKUs, page URL, the chat transcript that triggered the escalation — arrives on the agent desk before the first audio frame. That is the handle-time lever: the agent skips the identity and intent-asking ritual.
- Measure the fallback, not just the click. Corporate proxies and locked-down mobile browsers knock a share of attempts onto PSTN dial or call-back. Because the widget presents those options inline, those visitors stay in the funnel; the exact fallback share is the delta your own
originationtagging reports. - Attribute without a survey. Pairing the widget's
origination=webrtctag with the page-analytics snapshot already attached at call-open makes attribution a join you do not have to build.
Frequently asked questions
Which browsers does it support?
Current Chrome, Edge, Firefox, and Safari on desktop, and current mobile Chrome/Safari. The widget detects browser capability and falls back to PSTN click-to-call where WebRTC is unavailable — so browser coverage is the widget's problem, not your visitors'.
What about mobile?
Mobile WebRTC is solid on today's iOS and Android. For the tails (older mobile browsers, locked-down enterprise devices, and UDP-blocking networks) the widget offers a PSTN dial or call-back. Test the fallback path before launch.
Are there regulatory or recording-consent differences by region?
The tenant's recording Consent Mode applies the same on a WebRTC leg as on a PSTN leg, including spoken announcements where configured. Cross-border recording law (one-party vs all-party consent, EU GDPR-RTC considerations) is the tenant's responsibility the same way it is on PSTN. The platform does not gate geography; it enforces whatever recording policy the tenant selected.
Does this replace the PSTN numbers we run today?
No. PSTN remains the primary inbound surface for cold callers and outbound contact; WebRTC click-to-call complements it on the web surface. Most tenants run both; the comparison section above covers the lane-selection rule.
How is this priced?
The WebRTC leg flows over the RTC-PaaS usage surface the same way video rooms, broadcast, and co-browse do. There is no separate click-to-call line item: the audio minutes terminate into the same minute accounting your PSTN inbound already uses, plus the RTC transport the pillar meters.
Product framing — where the concept lands
Devotel Orbit's browser-native click-to-call sits on the RTC-PaaS surface and tunnels into the same voice queues and wallboard your PSTN legs use, with tenant-owned TURN/STUN, consent, and recording-announcement controls. It complements, not replaces, the SIP and DID paths on /voice/sip-trunks — the comparison table above is the lane-picker. When you evaluate the wedge, the fallback question is the one to press first: where WebRTC can't negotiate, the widget should degrade to PSTN or call-back rather than fail silently.