Pay-per-call platforms sell you a live caller. They route that call to a destination you nominate - a phone number, or a SIP address. Point that destination at your VICIfast box and the call lands in a VICIdial in-group, on an agent screen, with the buyer's data attached.
Integrations on demand. There is no connector to switch on. Our team wires your platform to your server as a scoped piece of work, quoted per setup, because the routing, the data you want carried and the campaign it lands in differ every time.
Platforms in this category
Ringba · Retreaver · Trackdrive · Invoca · CallRail · Marchex
The mechanism below is the same for all of them. What changes is where you configure the destination and what the platform calls it.
How it works
A call platform hands off in one of two ways, and the difference matters more than the vendor does.
To a phone number. The platform dials a DID you own. Simple, works with every platform, and you pay for the leg twice - once to your carrier, once inside the platform's rate.
To a SIP address. The platform connects straight to your box over SIP. Faster to connect, better audio, and - the part that actually matters - it can carry data in the SIP headers alongside the call.
Ringba is the clearest example. A Ringba Target takes either an inbound phone number or a SIP address; their Ring Tree export has a Type field that is literally "number or SIP". Their own material describes SIP routing as connecting "directly to your buyer's contact center software" with "the ability to seamlessly pass data in the SIP header".
On the VICIdial side that becomes:
- The call arrives at Asterisk on your server.
- The dialplan reads the platform's headers with
PJSIP_HEADER(read,<name>)and writes them onto the lead. - VICIdial routes the DID to an in-group, and the agent screen paints with the buyer's fields already populated.
PJSIP_HEADER() is not theoretical here - it is already in use on every VICIfast box for auto-answer signalling. Reading a header instead of adding one is the same function.
Setup, in order
- Decide number or SIP. SIP if you want the data; a DID if you want it working this afternoon.
- Whitelist the platform. Your firewall is default-deny, so the platform's media IPs have to be allowed before the first call.
- Create the in-group and map the DID to it, so the call has somewhere to land.
- Point the platform's destination at the number or the SIP URI.
- Map the headers you want on the lead - buyer token, campaign, caller data.
- Place one test call and watch it hit an agent screen.
Gotchas
A SIP destination means an unsolicited INVITE. Your box will not accept it until the platform's media IPs are whitelisted. This is the single most common reason a first test call goes nowhere, and it looks like the platform is broken when it is not.
A DID with no in-group mapping lands nowhere. The call connects, the caller hears nothing, and the platform records it as delivered. Map the DID first.
Header names are case-sensitive and platform-specific. Get the exact names from the platform before you write the dialplan; guessing produces empty lead fields and no error.
Routing priority is theirs, not yours. In Ringba, Targets sit in a Routing Plan with a priority (lower wins) and a weight for splitting across targets at the same priority. If your floor is not getting the volume you expected, that is where to look before blaming the dialer.