# Telephony Integration Without SIP Trunking > How telephony partners that cannot provide a SIP trunk can connect their phone system to a RevRag AI voice agent — options, flowcharts, and trade-offs. URL: /integrations/telephony-without-sip Markdown: /integrations/telephony-without-sip.md **Audience:** Telephony partners, BPOs, and contact-centre operators who want to connect their phone system to a RevRag AI voice agent but **cannot provide a standard SIP trunk** (no SIP trunk URL + DID + credentials to hand over). **Status:** Reusable reference, shared by direct link only. Applicable to any telephony partner without SIP connectivity. *** ## 1. Purpose [#1-purpose] RevRag's normal integration is a **SIP trunk**: the partner shares a trunk URL, a DID/phone number, and a username/password, and RevRag's voice pipeline connects to it. Some partners run **GSM-based phone systems** (SIM banks, mobile dialers, handset-based telecalling) and **cannot expose a SIP trunk**. This document lists every viable way to connect such a system to a RevRag voice agent, with flowcharts, action items for each side, and honest pros/cons — so a partner can pick the option that matches what their system *can* do. *** ## 2. The one constraint that shapes everything [#2-the-one-constraint-that-shapes-everything] > **A cloud voice agent needs a real-time IP (VoIP) audio path. A GSM/PSTN call is not IP. So *somewhere*, the call's audio must be converted GSM/PSTN → IP.** There are only three places that conversion can happen: | Where GSM→IP happens | What it requires | SIP on partner side? | | ------------------------------------------------------------------------ | --------------------------------------------------------------------- | -------------------- | | **At the partner's premises** | A GSM gateway / SBC (hardware) | Yes — produces SIP | | **Inside the public phone network**, on a number **RevRag** already owns | Nothing new from the partner — just a normal phone call to our number | **No** | | **At the partner's IP-PBX/dialer** that already speaks SIP | Their existing SIP capability | Yes | The middle row is the key to a no-SIP integration: **route the live call over the normal phone network to a RevRag-operated number**, and let RevRag's existing carrier do the GSM→IP conversion. The partner never touches SIP. **Impossible combination (state this up front):** *"Calls must originate/stay on our own SIMs"* **+** *"single, clean audio hop"* **+** *"no SIP and no new hardware"* cannot all be true at once. If single-hop audio on the partner's own SIMs is mandatory, a gateway/SIP path (Section 7) is unavoidable. *** ## 3. Quick chooser [#3-quick-chooser] ``` ┌─────────────────────────────────────────────┐ │ Does your phone system speak SIP at all, │ │ or can you add a GSM gateway / SBC? │ └─────────────────────────────────────────────┘ │ YES │ NO ▼ ▼ Use the standard SIP ┌──────────────────────────┐ integration (Section 7 │ Which direction of calls? │ / separate SIP guide). └──────────────────────────┘ │ INBOUND │ OUTBOUND ▼ ▼ Solution A Solution B (preferred) (call forward) or Solution C ``` | If you need… | Use | | --------------------------------------------------------- | ------------------------------------------------------------ | | Customers call **your** number, bot answers | **Solution A** — Call forwarding to a RevRag DID | | Bot calls customers, **dialed from your SIMs / your CLI** | **Solution B** — Outbound dial + bridge to bot (recommended) | | Bot calls customers, you only manage the **contact list** | **Solution C** — RevRag dials, you integrate via API | | Best possible audio quality, willing to add hardware | **Solution D** — GSM gateway / SBC (true SIP) | | Move the number permanently to RevRag | **Solution E** — Number porting / handover | *** ## 4. Solution A — Inbound via call forwarding *(no SIP, no new hardware)* [#4-solution-a--inbound-via-call-forwarding-no-sip-no-new-hardware] **Use when:** customers dial a number the partner publishes, and the bot should answer. **Idea:** The partner sets **call forwarding** (operator/SIM feature) on their published number to a **RevRag-operated DID**. The bot answers on RevRag's existing inbound trunk. GSM→IP happens at RevRag's carrier, invisible to the partner. ### Flowchart [#flowchart] ``` Customer mobile │ dials partner's published number ▼ Partner number / SIM │ GSM/operator CALL FORWARD (always / on-busy / on-no-answer) ▼ RevRag DID ──(RevRag's existing carrier SIP trunk)──▶ Voice Agent │ bot answers & talks ``` ### Action items [#action-items] | RevRag | Partner | | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | Allocate a RevRag DID, bind it to the right agent/workspace (existing inbound trunk + dispatch rule). | Set **call forwarding** on the customer-facing number(s) to the RevRag DID. | | Decide caller-ID handling (see cons); optionally use a **dedicated DID per campaign** to encode context. | Choose forwarding type (always / busy / no-answer). | | (Optional) Configure **bot → human handback** (bot places an outbound call to the partner's queue). | Confirm with their operator whether the **original caller's number is preserved** on forward. | ### Pros [#pros] * Zero SIP and zero new hardware for the partner — pure operator feature. * Fastest to pilot; reuses RevRag's existing inbound telephony (no new vendor). * Single GSM/PSTN hop → audio quality close to RevRag's normal inbound calls. ### Cons [#cons] * **Caller ID is operator-dependent** — the bot may see the partner's number instead of the customer's. Mitigate with per-campaign DIDs or out-of-band context. * The forwarded leg is **billed to the partner** (operator charge for redirected minutes). * Inbound only. The partner's system steps out of the live audio path. *** ## 5. Solution B — Outbound via dial + bridge *(no SIP, no new hardware)* — **recommended for outbound** [#5-solution-b--outbound-via-dial--bridge-no-sip-no-new-hardware--recommended-for-outbound] **Use when:** the bot must call customers but the calls should be **dialed from the partner's own SIMs / CLI** (the partner keeps their dialing workflow, identity, and compliance). **Idea:** The partner dials the customer outbound as usual; on answer, the partner places a **second call to a RevRag DID** (a normal phone call → reaches the bot), then **bridges/conferences** the two legs. This is the standard dialer "agent-bridge" pattern, with the bot in the agent's seat. ### Flowchart [#flowchart-1] ``` Leg A: Partner ──GSM outbound──▶ Customer (customer answers) Leg B: Partner ──phone call──▶ RevRag DID ──carrier SIP──▶ Voice Agent (answers, waits) │ ▼ Bridge / 3-way conference ( Leg A + Leg B ) │ ▼ Customer ⇄ Voice Agent talk ``` ### Recommended sequence [#recommended-sequence] 1. Partner dials the **customer** → customer answers. 2. Partner dials the **RevRag DID** → bot answers and **waits silently**. 3. Partner **bridges** the two legs. 4. Bot speaks its opener on a **trigger** (first customer audio / DTMF marker / short delay) — **not** on call-answer, so the greeting isn't clipped. ### Action items [#action-items-1] | RevRag | Partner | | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Provide a dedicated inbound DID → correct agent/workspace. | Dial the **customer** via existing SIMs. | | Gate the bot's **opener on a bridge trigger**, not on answer. | On answer, dial the **RevRag DID** as a second leg. | | Decide context-passing: dedicated DID per campaign, **DTMF** digits, or an **API** call at bridge time. | **Bridge/conference** the two legs (PBX conference or handset 3-way merge). | | Size inbound DID **concurrency** for the campaign. | **Propagate hangup both ways** (either side drops → tear down both legs). | | Return transcript / recording / disposition via webhook/API. | Ensure the bridge has **echo cancellation** enabled. | ### Pros [#pros-1] * No SIP, no new hardware; the partner keeps **their SIMs, their CLI, their dialing workflow**. * Bot is reached as an ordinary phone call — identical to inbound on RevRag's side. * Works with any system that can place two calls and conference them (even a handset's 3-way merge). ### Cons (sharper for a *bot* than for a human agent) [#cons-sharper-for-a-bot-than-for-a-human-agent] * **Two GSM/PSTN hops + double transcoding** (customer↔bridge↔RevRag) → measurably worse audio into speech-to-text. This is the biggest risk — **pilot and listen first**. * **Added latency** from the extra leg + bridge → affects turn-taking and interruption handling. * **Echo**: relies entirely on the partner's bridge doing echo cancellation; without it the bot may hear itself. * **Customer identity**: the bot leg's caller ID is the partner's number, not the customer's → use a dedicated DID, DTMF context digits, or an API hand-off. * **2 legs per conversation** (customer + RevRag DID), both billed to the partner; DTMF keypad capture across two bridged GSM legs can be flaky. *** ## 6. Solution C — Outbound via RevRag dialer + API integration *(no SIP, no new hardware)* [#6-solution-c--outbound-via-revrag-dialer--api-integration-no-sip-no-new-hardware] **Use when:** the partner is fine with **RevRag placing the calls** and only wants to manage the contact list and receive results. **Idea:** The bot dials customers through **RevRag's own existing outbound telephony** (the campaign engine). The partner integrates only at the **data/API layer**. ### Flowchart [#flowchart-2] ``` Partner system │ API: contact list / trigger ▼ RevRag campaign engine ──RevRag's existing outbound trunk──▶ Customer mobile ⇄ Voice Agent │ │ webhook/API: recording, transcript, disposition, post-call variables ▼ Partner system (CRM / workflow) ``` ### Action items [#action-items-2] | RevRag | Partner | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Expose/reuse the campaign / outbound-call **API** + a **results webhook**. | Push **contact lists / triggers** via the API; consume results. | | Place calls via RevRag's outbound trunk; present an agreed **CLI** (subject to regulation). | Provide the **CLI** they want presented and confirm authorization to use it. | ### Pros [#pros-2] * No telephony work for the partner at all — just an API integration. * **Single, clean audio hop** → best outbound audio quality of the no-hardware options. ### Cons [#cons-1] * Calls are **not dialed from the partner's SIMs** — their phone system is out of the call path entirely. * Presenting the partner's number as CLI from RevRag's trunk is **regulated** (e.g., TRAI in India) and depends on RevRag's carrier supporting it. *** ## 7. Solution D — GSM gateway / SBC at partner premises *(reintroduces SIP — best quality)* [#7-solution-d--gsm-gateway--sbc-at-partner-premises-reintroduces-sip--best-quality] **Use when:** the partner can add hardware and wants the **best audio quality** and/or must keep calls on **their own SIMs in a single bot-controlled leg**. **Idea:** A **GSM gateway / SIM bank** (e.g., Dinstar, Yeastar TG/TA, Portech, Synway) or an SBC converts GSM↔SIP on the partner's side. That device *is* a SIP endpoint, so the integration becomes the standard SIP flow — RevRag provides the trunk and the gateway connects to it (inbound and/or outbound). ### Flowchart [#flowchart-3] ``` INBOUND: Customer ─GSM─▶ Gateway (SIM) ─GSM→SIP─▶ RevRag SIP ─▶ Voice Agent OUTBOUND: RevRag SIP ─SIP─▶ Gateway ─SIP→GSM─▶ SIM dials ─▶ Customer ``` ### Pros [#pros-3] * **Single audio hop, best quality and latency** — ideal for speech-to-text. * Keeps the partner's **own SIMs / CLI** in a fully bot-controlled call (both directions). * Standard, well-understood SIP integration. ### Cons [#cons-2] * Requires **new hardware** the partner owns/maintains (and SIM channel capacity = concurrency ceiling). * Some setup effort (firewall, allowlisting, codec/DTMF config). > If this path is viable, follow RevRag's **standard SIP integration guide** instead of this document. *** ## 8. Solution E — Number porting / handover *(structural)* [#8-solution-e--number-porting--handover-structural] **Use when:** the partner is willing to move the customer-facing number to RevRag permanently. **Idea:** Port the number to RevRag's telephony so customer calls land directly on the bot. Heaviest option; regulatory and operationally involved. Usually only worth it for a long-term, single-purpose number. * **Pros:** cleanest long-term inbound path; single hop; no per-call partner action. * **Cons:** porting is slow and regulated; the partner loses direct control of the number. *** ## 9. Solution comparison at a glance [#9-solution-comparison-at-a-glance] | | A: Forward | B: Dial+Bridge | C: RevRag dials | D: Gateway/SIP | E: Porting | | ----------------------- | ---------- | -------------- | --------------- | ----------------------- | ---------- | | Direction | Inbound | Outbound | Outbound | Both | Inbound | | SIP on partner side | No | No | No | **Yes** | No | | New hardware | No | No | No | **Yes** | No | | New vendor | No | No | No | No | No | | Partner's SIMs/CLI used | n/a | **Yes** | No | **Yes** | No | | Audio hops | 1 | **2** | 1 | **1** | 1 | | Expected audio quality | Good | **Fair** | Good | **Best** | Good | | Setup effort | Low | Low–Med | Low | Med | High | | Per-customer variables | Via key\* | Via key\* | **Native** | Native (out) / key (in) | Via key\* | \* *Key = a per-call identifier RevRag can use to attach the right customer's variables: API pre-registration, a DTMF reference code, or reliable caller-ID lookup. See Section 10.* *** ## 10. Custom variables (agent personalization data) — where supported [#10-custom-variables-agent-personalization-data--where-supported] RevRag agents are driven by **custom variables**: values injected into the agent's prompt/context to personalize a call (e.g., customer name, loan amount, due date, account status, campaign offer). These come in two kinds, and the integration option decides which kind is possible: * **Agent-level / static variables** — the same for every call of that agent (company name, product details, script constants). **Supported in every solution**, because they don't depend on knowing who is on the call. * **Per-call / per-customer dynamic variables** — different for each contact (name, amount, reference no.). **Supported only when RevRag can tie the call to a specific customer record at call time.** ### The rule [#the-rule] > Per-customer variables work only when RevRag either **(a) places the call itself** with the variables attached, or **(b) receives a reliable key at call time** to look them up. When RevRag *initiates* a call (its own outbound), it already holds the contact and its variables — full personalization, no extra step. When the call *arrives at a RevRag number* (any inbound/bridged leg), RevRag does not inherently know which customer it is, so a key must be supplied. ### Ways to supply per-customer variables to an *inbound / bridged* bot leg [#ways-to-supply-per-customer-variables-to-an-inbound--bridged-bot-leg] | Mechanism | How it works | Granularity | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | **RevRag-initiated outbound** | Variables passed in the call/campaign API payload when RevRag dials | Per customer (native, best) | | **API pre-registration** | Partner calls a RevRag API just before the call/bridge — "expect a call for reference X with these variables" — and RevRag binds them to the incoming leg | Per customer (recommended for Solution B) | | **DTMF reference code** | Partner sends a customer/reference ID as DTMF on connect; RevRag resolves a pre-uploaded variable map | Per customer (DTMF-reliability caveat) | | **Caller-ID (CLI) lookup** | RevRag matches the customer's phone number to a pre-loaded map | Per customer — needs **reliable** caller ID (SIP/gateway: yes; operator call-forward: often masked) | | **Dedicated DID per segment** | The DID itself encodes context | Campaign/segment level only — **not** per customer | ### Support by solution [#support-by-solution] | Solution | Agent-level variables | Per-customer variables | | -------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **A — Call forwarding (inbound)** | ✅ Yes | ⚠️ Only via API pre-registration / DTMF / dedicated DID. CLI lookup is unreliable (forwarding usually masks the caller's number). | | **B — Dial + bridge (outbound)** | ✅ Yes | ⚠️ Yes **if** the partner passes a key — **API pre-registration** (recommended) or **DTMF** at bridge time. Without a key, agent-level only. | | **C — RevRag dialer + API (outbound)** | ✅ Yes | ✅ **Native** — variables are sent per contact in the API payload. | | **D — Gateway / SBC (SIP)** | ✅ Yes | Outbound: ✅ native. Inbound: ✅ via **reliable CLI lookup** (SIP carries caller ID), API, or DTMF. | | **E — Number porting (inbound)** | ✅ Yes | ⚠️ Via CLI lookup (reliable on a ported number), API, or DTMF. | **Takeaway:** If full per-customer personalization is essential, the strongest options are **C** (RevRag dials with variables) and **D-outbound**. For the no-SIP outbound bridge (**Solution B**), plan an **API pre-registration step** so the bot receives the customer's variables before speaking — otherwise the bot runs on agent-level data only. *** ## 11. Cross-cutting technical requirements [#11-cross-cutting-technical-requirements] Applies to whichever solution is chosen (and especially to D's SIP path): * **Codec:** G.711 µ-law (PCMU), 8 kHz, is the safe baseline. * **DTMF:** RFC 2833 (telephone-event) on SIP legs; inband tones across bridged GSM legs (Solution B) — test detection. * **Caller ID (CLI):** agree how the customer's number reaches the bot (passthrough, dedicated DID, DTMF, or API). * **Number format:** standardise on **E.164** (`+91XXXXXXXXXX`) end-to-end. * **Session timers (RFC 4028):** on any SIP/gateway path, **disable session timers or set `refresher=uas`** — IMS/carrier session-timer refresh has silently cut calls at \~10 minutes. * **Security (Solution D):** SIP digest auth + IP allowlisting; SIP-TLS + SRTP if supported; optional IPsec site-to-site VPN. * **Concurrency:** capped by the partner's SIM/channel count (B, D) and by RevRag DID concurrency (A, B, C). * **Audio-quality pilot:** for any **multi-hop** path (Solution B), run a short audio + latency + echo pilot before committing — speech-to-text accuracy is the deciding factor. *** ## 12. Information to exchange before a pilot [#12-information-to-exchange-before-a-pilot] | Item | Provided by | | ------------------------------------------------------------------------------------------------------------------------- | ---------------- | | RevRag DID(s) + target agent/workspace mapping | RevRag | | Custom-variable / context passing method (API pre-registration / DTMF / CLI / dedicated DID) + the per-call variable list | RevRag + Partner | | Campaign/outbound API + results webhook spec (Solution C) | RevRag | | Call direction(s) and chosen solution(s) | Partner | | Forwarding capability + caller-ID behaviour (Solution A) | Partner | | Dialer/PBX conference capability + echo cancellation (Solution B) | Partner | | Who owns the customer-facing numbers | Partner | | Gateway make/model + SIM channels (Solution D) | Partner | | Expected concurrency / call volume | Partner | *** ## 13. Glossary [#13-glossary] * **SIP** — Session Initiation Protocol; the signalling standard for VoIP calls. * **SIP trunk** — a SIP connection that carries calls between two phone systems. * **DID** — Direct Inward Dialing number; a phone number that routes to a specific destination. * **GSM gateway / SIM bank** — hardware with SIM slots that converts GSM (mobile) calls to/from SIP. * **SBC** — Session Border Controller; secures and normalises SIP traffic. * **Bridge / conference** — joining two call legs so both parties hear each other. * **CLI** — Calling Line Identification; the caller's phone number shown to the called party. * **DTMF** — the tones produced by phone keypad presses. * **PSTN** — the public switched telephone network.