What Happens Between a Publisher Ping and a Buyer Call?

A publisher ping and a buyer call are related events, but they are not the same event.

The ping asks a routing question:

Is there an eligible buyer for this call opportunity right now, under terms the publisher can evaluate?

The live call creates a delivery event:

Did the expected caller arrive through the approved route in time, connect to the selected buyer, and later satisfy the applicable qualification and financial rules?

A lot has to happen between those two questions.

The system may need to identify the publisher and source, resolve the campaign, evaluate buyer eligibility, contact buyer endpoints, interpret different responses, rank the available routes, protect private destination information, create a short-lived reservation, return publisher-safe instructions, match the arriving call, bridge it to the buyer, record status changes, and preserve enough evidence to explain the result later.

When those steps are treated as one vague action called “routing,” problems become hard to diagnose. A no-bid gets confused with a rejected call. An expired reservation gets confused with buyer capacity. A connected call gets confused with a billable call. A publisher is told only that a call “did not go through,” even though the actual failure occurred at a specific and knowable stage.

This article walks through the full operating journey from publisher ping to buyer call.

The short answer

A typical pre-call RTB journey looks like this:

1. A publisher has a real call opportunity.
2. The publisher sends a ping containing the agreed call context.
3. The exchange authenticates or identifies the publisher and source.
4. The campaign and permitted buyer paths are resolved.
5. Ineligible buyer targets are removed.
6. Eligible fixed routes or buyer RTB endpoints are evaluated.
7. Buyer responses are normalized into comparable options.
8. The available options are ranked under the routing policy.
9. The selected path is tied to a short-lived, single-use reservation.
10. The publisher receives a controlled phone number, SIP address, or other route handle with the applicable terms and expiration.
11. The publisher sends the live call to that handle.
12. The arriving call is matched to the reservation.
13. A valid reservation is consumed and the call is bridged to the protected buyer destination.
14. Connection, completion, qualification, buyer billing, publisher payout, disputes, and adjustments are recorded as separate downstream events.

The important principle is this:

The ping makes a temporary decision. The live call has to fulfill the conditions of that decision before the buyer call actually exists.

A successful ping does not prove that a call was delivered. A delivered call does not prove that it connected. A connected call does not automatically become qualified, billable, payable, or converted.

Start by separating the ping from the call

In a pre-call ping model, the publisher usually has a caller, transfer opportunity, or call-ready consumer and wants to know whether an approved buyer path is available before sending the call.

The publisher sends data first. The voice call follows only if the returned option is acceptable.

That differs from call-time routing, where the exchange already controls the inbound call and makes the routing decision while the caller is inside the call flow.

Both models can use real-time decisioning, but the operating sequence is different.

Pre-call ping

The publisher sends a request before delivering the live call.

The response may include:

• An accepted or rejected result.
• A publisher-facing payout or bid value.
• A required duration or other term.
• A temporary phone number or SIP address.
• An expiration time.
• A request, bid, or reservation identifier.

The publisher then decides whether and where to send the call.

Call-time routing

The consumer has already called a number controlled by the exchange or routing operator.

The system evaluates available targets and bridges the caller without requiring the publisher to make a second delivery step.

The distinction matters because pre-call pinging creates a gap between decision time and delivery time. The reservation and matching process exists to control that gap.

For the broader RTB concepts, see Pay-Per-Call RTB Explained: How Real-Time Call Routing Works.

Step 1: The publisher creates a call opportunity

The process begins before the HTTP request.

A publisher has generated or received a call opportunity through an approved source. Depending on the campaign, that may be:

• A consumer-initiated inbound call.
• A warm transfer.
• An owned-and-operated website call.
• A media-buying campaign.
• A call generated through another approved channel.

The publisher should already know the commercial and operational expectations for that traffic.

That includes questions such as:

• Which campaign is this traffic approved for?
• Which source or subsource produced it?
• Is the consumer currently on the line?
• Is the call consumer-initiated or transferred?
• Which geographic fields are required?
• Is caller identification required for matching or duplicate checks?
• How quickly must the call be sent after an accepted response?
• What qualification rule will be returned or applied?

A ping should not be used to disguise unreviewed traffic as generic availability.

The more accurately the request describes the real call opportunity, the more accurately the routing system can evaluate it.

Step 2: The publisher sends the agreed call context

The ping normally contains only the information needed to make the routing decision.

Common fields may include:

• A publisher or endpoint credential.
• A campaign or tracking identifier established by the integration.
• A publisher request ID.
• Caller ID when required and permitted.
• State, ZIP code, or another geographic signal.
• Source or subsource information.
• Call type.
• Tags relevant to buyer eligibility.
• Whether the publisher can route by SIP, phone number, or both.

The exact payload should follow the agreed integration contract. Sending extra consumer data “just in case” is not a substitute for a clear contract.

There are two competing risks.

Too little information

The exchange may not be able to evaluate:

• Geography.
• Duplicate policies.
• Source approval.
• Buyer-specific filters.
• Caller matching.
• Campaign fit.

The result may be a no-bid, a less accurate offer, or a route that fails when the call arrives.

Too much information

The request may expose unnecessary personal information, create security risk, or make downstream handling harder to control.

A serious integration defines the minimum required fields, how they are protected, which systems may receive them, and how they are retained.

Retreaver’s current RTB documentation illustrates the tradeoff: it supports availability requests without a caller number in some configurations, but explains that geographic matching, caller-list checks, and buyer-specific matching may become less precise. The right answer is not always “send every field” or “send no fields.” It is to agree on what the routing decision genuinely requires. See Retreaver’s Real-Time-Bidding API guide.

Step 3: The exchange identifies who is asking

Before evaluating buyers, the exchange needs to know which publisher relationship and approved source the request belongs to.

This identification may come from:

• An API key.
• A secret endpoint token.
• A tracking key tied to a publisher-campaign assignment.
• An authenticated account.
• A controlled integration record.

The request body should not be allowed to freely declare any publisher, campaign, or source it wants.

A safer pattern is to derive the trusted identity from the credential or endpoint configuration and then compare the submitted fields with what that identity is allowed to use.

That protects against several problems:

• A publisher accidentally sending traffic to the wrong campaign.
• One source impersonating another source.
• Cross-account data exposure.
• Unapproved traffic reaching an otherwise valid buyer path.
• Attribution records that cannot be trusted later.

Publisher identity is not merely an authentication concern. It determines which sources, campaigns, buyers, formulas, and reporting records can apply.

Step 4: The campaign and call context are resolved

Once the publisher is identified, the system resolves the operating context for the request.

That may include:

• The campaign.
• The publisher assignment.
• The source and subsource.
• The vertical.
• The call type.
• The geographic market.
• The approved buyer relationships.
• The routing policy.
• The commercial rule set.

This is where a tracking identifier becomes more than a string.

It should connect the ping to a known relationship and a controlled set of routing possibilities.

If the identifier is unknown, inactive, revoked, assigned to another organization, or not permitted for the credential, the system should fail closed. It should not guess which campaign the publisher probably meant.

Step 5: Ineligible buyer targets are removed

A buyer can exist in the system and still be ineligible for this call.

Before contacting or selecting buyers, the routing process may need to check:

• Whether the buyer and target are active.
• Whether the target is assigned to the campaign.
• Whether the current time is inside the target schedule.
• Whether the buyer is under daily, weekly, monthly, or other caps.
• Whether the target has available concurrency.
• Whether sufficient budget or credit is available.
• Whether the caller geography is accepted.
• Whether the publisher source is enabled for that target.
• Whether required tags match.
• Whether the call type is accepted.
• Whether duplicate or suppression rules block the opportunity.
• Whether the destination is healthy enough to receive calls.

This is one of the most important parts of the journey.

The system should not ask every buyer about every call and hope the buyer rejects what it does not want. Good routing removes obviously invalid paths before the auction or selection stage.

That protects the buyer from unwanted traffic and protects the publisher from wasting a live caller on a route that should never have been considered.

Our guide to how caps, schedules, and concurrency shape call flow explains several of these controls in more detail.

Step 6: Eligible buyer paths are evaluated

The remaining options may include fixed-price targets, live buyer RTB endpoints, or a controlled combination of both.

For a live buyer endpoint, the exchange sends the agreed fields and waits for a response within a strict time budget.

A buyer may respond in several ways:

• Accept with a price and terms.
• Decline normally.
• Return a malformed or incomplete response.
• Time out.
• Return a server error.
• Be skipped because the remaining decision budget is too small.

These outcomes should not be collapsed into one generic “buyer rejected” status.

A normal no-bid means the buyer evaluated the opportunity and chose not to accept it under current conditions.

A timeout means the exchange did not receive a usable answer in time.

A malformed response means the integration contract was not satisfied.

A server error means the endpoint failed to complete the request.

Those differences matter for troubleshooting, buyer performance review, and decisions about whether an endpoint should continue receiving traffic.

Step 7: Buyer responses are normalized

Different buyers and platforms may express the same concepts differently.

One may return JSON. Another may return query-string fields. Another may use headers. Field names, currencies, duration formats, destination types, and rejection reasons can vary.

The exchange needs to convert those responses into a stable internal model.

A normalized accepted option might include:

• Buyer and target identity.
• Buyer price.
• Buyer qualification requirement.
• Destination type.
• Protected destination reference.
• Expiration.
• Response status.
• Buyer request or bid identifier.
• Relevant decision metadata.

Normalization makes comparison possible and prevents downstream routing from depending on every buyer’s custom response shape.

It also creates a clean boundary: raw buyer responses can be retained for controlled diagnostics where appropriate, while the routing system operates on validated, typed fields.

Step 8: Available routes are ranked

The highest gross bid does not automatically have to be the correct route.

A serious routing policy may consider:

• Buyer price.
• Publisher payout terms.
• Required duration.
• Buyer capacity.
• Destination health.
• Source eligibility.
• Recent route reliability.
• Quality or dispute signals.
• Campaign priorities.
• Whether the route satisfies required confirmation or reservation rules.

The ranking policy should be defined, controlled, and explainable.

That does not mean every internal score or commercial detail should be disclosed to every party. Buyers should not receive another buyer’s private bid. Publishers should not receive protected buyer destination data or confidential exchange economics.

It means the operator should be able to reconstruct why the selected path was considered valid and why it ranked ahead of the alternatives.

For a deeper explanation of the decision itself, read What Is a Call Routing Decision?.

Step 9: The selected route becomes a reservation

The selected buyer path is still not a delivered call.

The publisher needs time to receive the response, parse it, choose it, and send the live call. During that gap, the system needs a controlled record connecting the ping decision to the call that may follow.

That record is the route reservation.

A useful reservation can bind together:

• The original request or call opportunity.
• The publisher and source.
• The campaign.
• The selected buyer target.
• The protected destination.
• The publisher-facing terms.
• The buyer-facing terms.
• The expected caller identifier when used.
• The creation and expiration times.
• The route handle returned to the publisher.
• Whether the reservation has already been consumed.
• The rule or policy versions used for the decision.

The reservation should normally be short-lived and single-use.

That prevents an accepted ping from becoming an unlimited authorization to send later calls under stale terms.

See Why Reservation Windows Matter in Pay-Per-Call for a full discussion of expiration, caller matching, retries, and late calls.

Step 10: The publisher receives a safe response

The publisher needs enough information to decide whether to send the call and how to deliver it.

The response may include:

• Accepted or rejected status.
• Publisher payout or bid amount.
• Required call duration or other terms.
• A phone number or SIP address controlled by the exchange.
• Expiration information.
• A publisher-safe request or bid ID.
• A rejection reason when appropriate.

The response should not include information the publisher does not need, such as:

• The buyer’s private destination.
• Another publisher’s identity.
• Another buyer’s bid.
• Confidential margin data.
• Internal credentials.
• Unnecessary consumer information.

Official Ringba publisher documentation follows the same general handoff pattern: an accepted response returns a temporary phone number or SIP address, expiration information, bid terms, and a bid identifier. It also states that the arriving caller ID must match the submitted caller ID when required and that the call must be transferred before the response expires. See Ringba’s publisher RTB implementation guide.

The visible number or SIP address is therefore not the entire routing decision. It is a controlled handle that lets the publisher fulfill the decision without receiving the protected buyer destination directly.

Step 11: The publisher decides whether to send the call

An accepted response does not force the publisher to deliver the call.

The publisher may be comparing several approved demand options. The caller may hang up. The transfer agent may lose the call. The returned terms may not meet the publisher’s requirements. Another route may be selected.

That is why an RTB operation may create more accepted reservations than delivered calls.

The publisher should make the decision quickly and preserve the response identifier used for the selected route.

If the publisher does not use the route, it should expire cleanly. Depending on the platform and agreement, an explicit confirmation or cancellation may also help capacity management.

A successful ping should not be counted as a routed, connected, qualified, billable, or payable call.

It is an accepted opportunity that may or may not become a call.

Step 12: The live call arrives at the controlled handle

When the publisher selects the response, it transfers or routes the live call to the returned phone number or SIP address.

The call now enters the delivery stage.

The telephony provider sends the inbound call to the application responsible for deciding what to do with it. In a Twilio-based flow, for example, an inbound call can trigger an HTTP request to the application, and the application responds with TwiML instructions such as <Dial> to connect another party. See Twilio’s official TwiML <Dial> documentation.

The exchange should not blindly forward every call that reaches the handle.

It should first determine whether the call matches a valid reservation.

Step 13: The reservation is matched and consumed

The matching process may check:

• Does a pending reservation exist for this handle?
• Has it expired?
• Has it already been used?
• Does the arriving caller match the expected caller when matching is required?
• Does the provider call identifier show that this is a retry for a call already matched?
• Is the reservation in a state that permits routing?

A valid reservation is then consumed atomically so a second unrelated call cannot reuse it.

An invalid call should fail at this stage rather than being sent to whatever destination happens to be associated with the handle.

Common reservation-stage failures include:

• The call arrived after expiration.
• The caller did not match.
• The reservation was already used.
• The handle was invalid or not associated with a current reservation.
• The publisher sent the call to the wrong route.
• A replay attempted to reuse a prior response.

These failures are different from a buyer not answering. The buyer call has not been attempted yet.

Step 14: The call is bridged to the buyer

After a valid reservation is consumed, the exchange resolves the protected destination and creates the buyer leg of the call.

A bridge is more controlled than exposing the buyer’s number and telling the publisher to dial it directly.

The exchange can remain in the call path and record events such as:

• Route attempted.
• Buyer leg ringing.
• Buyer leg answered.
• Call connected.
• Buyer leg failed.
• Call completed.
• Duration reported.
• Recording metadata received when recording is authorized and enabled.

Keeping the exchange in the path also helps protect destination information and preserve a consistent call identity across the publisher leg, buyer leg, and later financial records.

The goal is not merely to hide a phone number. It is to keep routing, status, qualification, and reconciliation tied to the same explainable call record.

Step 15: Connection and completion are recorded separately

A buyer call can fail after a valid route is created.

The destination may be busy. The agent may not answer. A carrier may reject the call. The buyer leg may ring and time out. The consumer may hang up before connection.

That is why the operation should distinguish:

• Reservation matched.
• Route attempted.
• Buyer leg initiated.
• Buyer leg answered.
• Call connected.
• Call completed.

A route attempt is not a connection.

A connection is not completion.

A completed call still needs the correct duration or outcome evidence before financial qualification can be decided.

The status sequence gives operators a much better diagnostic trail than a single final label.

Step 16: Qualification and settlement happen after routing

Once the call completes, the operation can evaluate the applicable commercial rules.

For a duration-based call, that may involve comparing the completed duration with separate buyer billing and publisher payout thresholds.

For a CPA call, the call may remain pending until the buyer reports the agreed conversion event.

Other rules may address:

• Duplicate treatment.
• Invalid or blocked callers.
• Geographic mismatch.
• Call-type requirements.
• Conversion reversals.
• Disputes and credits.
• Reporting deadlines.

This is where terminology matters.

A call can be:

• Offered.
• Reserved.
• Routed.
• Connected.
• Completed.
• Qualified.
• Billable to the buyer.
• Payable to the publisher.
• Converted.
• Disputed.
• Adjusted.
• Invoiced.
• Paid.

Those statuses should not be collapsed into “good call” or “bad call.”

Our guide to routed, qualified, and billable call differences explains the financial distinctions.

A failure map for the full journey

The easiest way to improve RTB operations is to identify the stage where failure occurred.

That table shows why “the buyer rejected the call” is often an inaccurate explanation.

The buyer may never have seen the ping. The buyer may have accepted the ping but never received the live call. The live call may have reached the exchange but failed reservation matching. The buyer leg may have been attempted but not answered. The call may have connected and later failed the commercial rule.

Each situation needs a different fix.

What publishers should monitor

Publishers do not need every internal routing detail, but they need enough data to understand their side of the journey.

A useful publisher view or export should help answer:

• Which request ID was sent?
• When was the ping sent?
• Was it accepted or rejected?
• What publisher-facing terms were returned?
• Which route handle was selected?
• When did it expire?
• Was the live call sent?
• Did it arrive before expiration?
• Did caller matching pass?
• Did the call connect?
• What duration or outcome was recorded?
• Did the call become payable?
• Was it later disputed or adjusted?

Publishers should also monitor ratios between stages:

• Pings to accepted responses.
• Accepted responses to attempted deliveries.
• Attempted deliveries to matched reservations.
• Matched reservations to connected calls.
• Connected calls to payable outcomes.

A drop between accepted responses and delivered calls may reflect publisher decisioning or caller abandonment.

A drop between delivery and reservation matching may reflect late transfers, wrong handles, or caller-ID problems.

A drop between matched reservations and connections may reflect destination health or buyer capacity.

A drop between connections and payable outcomes may reflect qualification, duplicate, or conversion performance.

Those are different optimization problems.

What buyers should monitor

Buyers should not evaluate RTB only by total call volume.

Useful buyer questions include:

• How often is the target eligible?
• How often does the endpoint respond in time?
• What percentage of responses are normal declines versus technical failures?
• How often do accepted pings become delivered calls?
• How often do routed calls connect?
• Which sources produce the strongest connected and qualified outcomes?
• Are caps and concurrency aligned with real agent capacity?
• Are destination failures concentrated by hour, target, or route?
• Are qualification rules clear enough to reconcile later?
• Are disputes concentrated in one stage of the journey?

A buyer may appear to receive low volume because its endpoint times out, its schedule is wrong, its source permissions are narrow, or its destination fails to answer. Those causes require operational fixes, not simply more publisher traffic.

What the operator should be able to reconstruct

A dependable exchange should be able to answer the following without relying on memory:

1. Who sent the ping?
2. Which source and campaign did it represent?
3. What call context was provided?
4. Which buyer targets were eligible or ineligible?
5. Which buyer endpoints were contacted?
6. How did each endpoint respond?
7. Which options remained valid?
8. Why was the selected route chosen?
9. What publisher-facing terms were returned?
10. What reservation and expiration applied?
11. Did the expected call arrive?
12. Did reservation matching pass?
13. Which protected destination was used internally?
14. Did the buyer leg answer?
15. When did the call connect and complete?
16. What qualification rule applied?
17. Did buyer billing and publisher payout each become earned?
18. Were there later disputes, credits, reversals, or adjustments?

Not every answer belongs in every partner portal.

Scoped transparency matters. A buyer should see the evidence needed to understand its calls and charges. A publisher should see the evidence needed to understand routing and payout. The operator needs the fuller audit trail without exposing one partner’s confidential information to another.

A practical integration checklist

Before enabling a publisher ping flow, buyers, publishers, and operators should agree on the following.

Request contract

• Approved endpoint and authentication method.
• Required and optional fields.
• Trusted publisher and campaign identity.
• Source and subsource rules.
• Geography format.
• Caller-ID expectations.
• Request ID and retry behavior.
• Data protection and retention boundaries.

Response contract

• Accepted and rejected response shapes.
• Publisher-facing amount and terms.
• Phone, SIP, or both.
• Expiration fields.
• Stable bid or reservation ID.
• Rejection reasons.
• Timeout behavior.

Delivery contract

• How quickly the call must be sent.
• Whether caller matching is required.
• Whether confirmation is required.
• Which route handle must be used.
• What happens to expired or reused routes.
• How retries are recognized safely.

Buyer contract

• Eligibility filters.
• Schedules and timezone.
• Caps and concurrency.
• Bid or fixed-price logic.
• Qualification terms.
• Destination-health expectations.
• Normal decline versus technical-failure handling.

Financial contract

• Buyer price.
• Publisher payout.
• Billable and payable rules.
• Duplicate policy.
• CPA outcome reporting when applicable.
• Dispute and adjustment process.
• Invoice and payout timing.

Reporting contract

• IDs shared across systems.
• Status definitions.
• Timezone and timestamp standards.
• Call-level exports.
• Error and rejection visibility.
• Reconciliation process.
• Privacy boundaries.

When these contracts are vague, the integration may still move calls, but the operation will struggle to explain them.

The Dependable Calls approach

Dependable Calls is being built around a ping-first, controlled-routing model in which publisher traffic is tied to reviewed source relationships, eligible buyer paths are evaluated, publisher-safe route handles are returned, and the protected buyer destination remains inside the routing layer.

The current implementation supports the main journey described in this article: publisher request handling, buyer evaluation, controlled bid transformation, short-lived route reservations, hidden-destination routing, call bridging, status tracking, and downstream financial records.

That does not mean every scenario should be treated as fully mature or universally available.

Integration behavior still depends on the publisher platform, buyer endpoints, telephony configuration, campaign rules, and live operating conditions. The model remains subject to live campaign validation, monitoring, and continued hardening.

That caution is important because code existence is not the same as dependable live operations.

The goal is a call flow that can be explained from the first ping through the final financial record.

The main takeaway

The time between a publisher ping and a buyer call is not empty technical space.

It is where the operation decides:

• Who is asking.
• Which source the call represents.
• Which buyers are eligible.
• Which buyers are willing to receive it.
• Which route should be selected.
• Which terms apply.
• How the buyer destination stays protected.
• How long the decision remains valid.
• Whether the arriving call matches the decision.
• Whether the call actually connects.
• What evidence will support later qualification and settlement.

A dependable RTB system does not merely return a number.

It creates a controlled chain of decisions and records that lets publishers deliver calls, lets buyers receive calls they are prepared to handle, and lets the operator explain what happened when the result is questioned.

Need a more controlled path from publisher ping to buyer call? Start a conversation with Dependable Calls.