Architecture

Call Forwarding (PSTN bridge)

Call forwarding is a routing mode where an inbound call to a DID is bridged out to a different phone number over the PSTN, instead of (or in addition to) being delivered over SIP. It's the simplest way to point a virtual number at any reachable real-world phone, with full control over what caller-ID the receiving phone sees.

How it differs from SIP routing

SIP routing delivers inbound calls into your VoIP system as a SIP INVITE — your PBX, AI agent, or softphone answers. Call forwarding instead has the carrier originate a new outbound leg over the PSTN to a target number, then bridges the two legs in the carrier network.

SIP routing: 1 leg, IP-only, no per-minute cost on the inbound side, full SIP control.
Call forwarding: 2 legs, second leg is PSTN-billed at outbound rates to the target country, but you don't need any SIP infrastructure on the receiving end.

Use forwarding when the destination is a normal phone (mobile, landline, third-party PBX you don't control). Use SIP routing when you do control the receiver.

Caller-ID handling — the four options

The most-asked question about forwarding is: what does the forward target see as the caller? DIDHub gives you four modes:

Mode	What the receiving phone shows	When to use
Retain original (default)	The real inbound caller’s number	You want context — "the call is from a customer, not from DIDHub". Most common pattern.
Use the DID	Your DIDHub number that received the call	You don’t want personal target numbers exposed to the caller’s history; or callbacks should hit the DID, not the target.
Use a custom DID	Any other verified DIDHub number you own	Brand presence: forward to your real CC, but the caller-ID is a different brand-friendly number.
Anonymous	"Restricted" / "Private number"	Privacy-sensitive scenarios. Sets `Privacy: id` per RFC 3323.

Diversion / History-Info — the receiver knows it was forwarded

When DIDHub forwards a call, it adds a SIP Diversion (RFC 5806) and History-Info (RFC 7044) header chain to the outbound leg. Modern PBXs and Teams use these to display "call forwarded from +44 20 7946 0214" on the recipient's screen, even when the caller-ID is set to retain the original. This preserves the audit trail without surprising the recipient.

Cost model

Forwarding is two billable legs:

Inbound leg — to your DID, included in your DID's monthly fee (no per-minute charge for inbound).
Outbound leg — DIDHub originating to the forward target. Billed at the standard outbound rate for the target country, with Origin-Based Rating applied: forwarding from a UK DID to a UK mobile is the cheap EEA rate; forwarding from a UK DID to a US mobile is the cross-border rate.

The OBR implication: pick the DID country to match where you forward to, and the cross-border surcharge disappears.

Common patterns

Follow-me / on-call: a single DID rings whoever's on call this week. Update the target from the dashboard or API.
Branch / after-hours overflow: office DID forwards to a backup mobile or after-hours answering service.
Local brand presence: a +44 20 London DID forwards to your real call center in Manila, but London callers pay the local rate and see a UK number.
Number-portability bridge: after porting a number into DIDHub, forward it to the legacy carrier briefly while you migrate the SIP integration.
Personal mobile shield: publish a DIDHub DID on your business card; forward to your real mobile so you can revoke the public number whenever you want.

Failover and ring strategy

You can chain failover targets. If the primary forward target doesn't answer in N seconds (default 25s), DIDHub bridges to the secondary. Sequential ring (try primary, then secondary) and simultaneous ring (ring both at once, first to answer wins) are both supported via the API. q.850 reason codes are passed through so your downstream voicemail system knows whether the call was missed, busy, or rejected.