If you've ever transferred a call on a modern VoIP system, picked up a ringing line from a different desk phone, or moved an in-progress conversation from your desk to your mobile without dropping it, you've used RFC 3891. It's a tiny three-line addition to SIP that quietly powers some of the most useful telephony features of the last twenty years.

The problem. SIP (RFC 3261) was designed around a clean model: INVITE creates a dialog, BYE tears it down, and each dialog is identified by a Call-ID plus two tags. But real telephony needs dialog substitution — the ability for one endpoint to say "take this existing call I'm in, and hand it to that other endpoint instead, atomically." Classic three-way call transfers (REFER + new INVITE) work, but they don't cover scenarios like:

• Attended transfer: Alice is on a call with Bob, puts him on hold, calls Carol to consult, then wants Bob and Carol connected directly while she drops out.
• Call pickup: Bob's phone is ringing; Alice wants to grab the call from her own phone.
• Call park retrieval: A call is parked in slot 701; any phone should be able to retrieve it.
• Single-line extension / shared appearance: The same call rings on multiple devices and one of them takes over.

The design. RFC 3891 defines exactly one new header. An INVITE can carry a Replaces header naming an existing dialog by its three identifiers:

Replaces: [email protected];to-tag=7743;from-tag=6472

When a UA receives an INVITE with Replaces, it matches the header to a confirmed dialog it's participating in. If the match succeeds and the policy checks pass, it accepts the new INVITE as if it were a re-INVITE on that dialog, then sends BYE on the old dialog. The result: media flows shift to the new peer atomically, with no ring, no glare, no awkward gap.

Why the design choices matter. A few details look pedantic but are load-bearing:

• Both tags required. Early-dialog matching (only one tag known) was considered and rejected in the general case because it opens race conditions and security holes — though the spec carves out specific rules for replacing early dialogs in the UAC role.
• Authorization is the implementer's problem. The spec is explicit: a UA must not blindly accept a Replaces just because the dialog IDs match. Otherwise anyone who learns a Call-ID and tags (often visible in logs, SIP trunks, or via eavesdropping) could hijack your call. Real deployments lean on the SIP authentication of the inbound INVITE.
• Option tag replaces. Endpoints advertise support in Supported:, and a transferor can require it with Require:. This lets transfer flows degrade gracefully when one party is old.
• Pairs with REFER. The common idiom is REFER with a Refer-To URI that embeds the Replaces parameters as escaped headers — so "transfer Bob to Carol's existing call" becomes a single referral.

Why it still matters. Every PBX, softswitch, and SBC speaking SIP — Asterisk, FreeSWITCH, Cisco CUCM, Avaya, Microsoft Teams' SIP gateway, Zoom Phone, all the carrier-grade kit — implements Replaces. The "blind transfer," "consultative transfer," "directed pickup," and "call park" buttons on hundreds of millions of desk phones are essentially UI veneers over a REFER carrying a Replaces. WebRTC-to-SIP gateways translate browser handoffs through the same mechanism. And as enterprises lift voice into the cloud, Replaces is the primitive that lets a call walk from your desktop softphone to your mobile mid-sentence.

It's a beautiful example of minimal extension design: one header, ten pages of spec, an enormous behavioral payoff.