Send RTB calls to a SIP without username and password

Summary

Publishers can now deliver RTB calls to Retreaver by addressing the call to the reservation UUID itself, without needing to configure SIP username/password authentication.

Althoug username and password are not required we do not allow at the moment for any IP address to send requests. Let us know the IP addresses from which the requests will be coming from so that we could whitelist them. Send an email to support@retreaver.com

Why we built this

Username/password authentication is a cornerstone of the SIP protocol — it's the standard, expected way for two systems to trust each other on a SIP call. Retreaver fully supports it, and it remains the recommended path.

However, some third-party platforms publishers simply cannot send SIP credentials. That's a limitation of those platforms, not of SIP — but it may blocked otherwise-good publishers from bringing their calls into Retreaver at all.

This release closes that gap. If a publisher's platform can't authenticate with a username and password, they can still participate in RTB by sending the call to the reservation UUID returned by the bid request. We'd rather help those publishers bring their traffic in than turn it away over a platform constraint they can't control.

Scope: This applies to RTB scenarios only. It is not a general replacement for SIP authentication on standard (non-RTB) call delivery.

How it works

When a publisher requests a bid, the RTB response now includes an inbound_number — a SIP address built from the reservation UUID. The publisher sends the call to that address. No SIP credentials are involved.

Example

Request a bid:

% curl -X POST "https://rtb.retreaver.com/rtbs.json?key=7070c73f-2db9-434b-a3a3-ee63cbacdde2" | jq
{
  "uuid": "e3e89678-a2be-43ab-8530-ade2879e9ca9",
  "status": "reserved",
  "retreaver_payout": 25.0,
  "retreaver_seconds": 90,
  "inbound_number": "sip:e3e89678-a2be-43ab-8530-ade2879e9ca9@sip.rtb.retreaver.com",
  "expires_at": "2026-05-14T06:19:36.766Z"
}

Then send the call to the inbound_number from the response:

sip:e3e89678-a2be-43ab-8530-ade2879e9ca9@sip.rtb.retreaver.com

The reservation UUID in the SIP address is what ties the incoming call back to the bid, so no credentials are needed to establish trust.

Important: calls without a caller number

This flow also makes it possible to send the call without a caller number — if that is genuinely what the publisher wants. Before relying on that, publishers should understand the trade-off.

Suppression lists are checked when the call arrives, not at bid time.

When no caller number is supplied with the bid request, Retreaver has no way to check the caller against any suppression (caller) lists before responding. As a result:

1. Retreaver returns a bid to the publisher.
2. The publisher sends the call to Retreaver.
3. Only when the call actually arrives does Retreaver evaluate the caller lists attached to the campaign and the buyers.
4. If the caller number turns out to be on a suppressed caller list, the call fails at that point.

So a publisher may receive a bid and deliver a call expecting to be paid for it — but if that caller is suppressed, the call won't complete and won't be billable. With a caller number supplied up front, Retreaver can screen the caller against suppression lists before returning a bid, avoiding this situation entirely.

Recommendation: publishers should send a caller number whenever their platform can provide one. Omitting it is supported, but it shifts suppression checks to call-arrival time and introduces the risk of delivering a call that ends up rejected.

Visibility for publishers

Publishers can see when a call failed because the caller was on a suppression list, so they can understand why a delivered call wasn't billable and decide whether sending a caller number up front is worth it for their traffic.