Telephony Integration Without SIP Trunking

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

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

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:

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

                    ┌─────────────────────────────────────────────┐
                    │ 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

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

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

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

• 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

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

   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

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

Pros

• 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)

• 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)

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

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

Pros

• 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

• 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)

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

INBOUND:   Customer ─GSM─▶ Gateway (SIM) ─GSM→SIP─▶ RevRag SIP ─▶ Voice Agent
OUTBOUND:  RevRag SIP ─SIP─▶ Gateway ─SIP→GSM─▶ SIM dials ─▶ Customer

Pros

• 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

• 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)

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

* 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

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

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

Support by solution

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

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

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.