Summary

  • A SIP Replaces header identifies one existing INVITE dialog with Call-ID, to-tag and from-tag. The receiving user agent must still authenticate and authorize the initiator, then decide whether it can accept the new INVITE.
  • Replacement is ordered for safety: admit the new dialog first; only then send BYE for a confirmed old dialog or CANCEL for an eligible early one. If media, keying, QoS or another admission condition fails, the old dialog must remain unchanged.
  • REFER acceptance, Referred-By provenance, dialog knowledge, a replacement 2xx and an old-leg termination are different evidence. Collapsing them gives an automation or platform more authority than the protocol does.

The transfer that succeeded only on the dashboard

Imagine three systems involved in an attended transfer. An agent is speaking to a customer. The agent first calls a specialist, then asks the customer's phone to connect to that specialist. The agent's platform sends REFER and receives a successful response. Its dashboard immediately marks the transfer complete and closes the agent's work item.

The customer's user agent follows the reference and sends a new INVITE to the specialist. That INVITE carries Replaces, identifying the consultation dialog between the agent and specialist. The specialist's endpoint recognizes the dialog but rejects the replacement because the new caller is not authorized under local policy. The customer remains on hold. The agent has not yet sent BYE. A NOTIFY later reports the failed referenced action.

No message in that sequence has to be malformed. The REFER can be accepted. The Replaces triple can match. The target can still deny authority. The original conversation can still exist. The dashboard is wrong because it promoted the earliest positive response into the final state of a multi-step operation.

RFC 3891 does not make that category error. It defines a narrow primitive for logically replacing one SIP dialog with a new one. Its processing order keeps four questions apart:

  1. Which dialog is being named?
  2. Is the initiator entitled to replace it?
  3. Can the new INVITE be accepted?
  4. Once accepted, how should the old dialog be shut down?

The protocol's restraint is the useful lesson. A common identifier can coordinate a decision without becoming the authority that makes the decision.

Why the replacement arrives as a new INVITE

Replaces is not an instruction to edit an existing dialog in place. It appears in a new INVITE, and the proposed replacement dialog carries a new Call-ID of its own.

The choice is deliberate. An INVITE already has the semantics of admitting a new session. An explicit Replaces field makes the additional intent visible. A new Call-ID avoids implicit associations that different user agents might infer differently. An endpoint that does not understand the extension can fail without accidentally mutating the old call.

The sender can place Require: replaces in the INVITE when it needs explicit failure from a peer that lacks support. A user agent that supports the extension advertises the replaces option tag in Supported. The current IANA SIP registry records both the header and option tag.

Capability is only the outer gate. Supported: replaces says that software understands the grammar and processing model. It does not promise that every request will be authorized, that every media offer will work or that a transfer policy will permit the handoff.

RFC 3891 also keeps Replaces independent from REFER. They are frequently combined for transfer, but a user agent can learn dialog information through another protected mechanism and send an INVITE with Replaces directly. Conversely, a REFER can point to a resource without asking to replace any dialog. Treating the two as synonyms erases the decision surface between them.

The triple identifies one dialog, from one perspective

A Replaces value carries three matching elements: Call-ID, to-tag and from-tag. The receiving UAS compares to-tag with its local tag and from-tag with its remote tag.

That direction is easy to mishandle. A trace displays To and From according to the message in which they appeared. The new INVITE reaches an endpoint whose local and remote perspective may reverse the order an operator expects. Copying labels instead of reconstructing perspective can produce 481 or point an implementation toward the wrong state.

The RFC 3891 errata record makes the hazard unusually visible. One verified editorial erratum corrects reversed tags in the early-dialog example. Another tag correction is held for a future document update. They do not change the normative procedure, but they are a warning against using an example as a substitute for local/remote reasoning.

Exactly one dialog is the scope. RFC 3891 states that Replaces does not match multiple dialogs, an entire call, an entire transaction or a chain of proxy forks. If an original INVITE created several early dialogs, selecting one branch does not select its siblings. If a proxy later redirects the replacement INVITE to an unrelated Contact set, matching fails rather than following the original fork tree.

This is where application schemas routinely overstate the primitive. A contact-centre “interaction ID” may cover the agent leg, customer leg, consultation leg, conference interval, recording segments and charging records. The Replaces triple names one SIP dialog inside that business object. Promoting its result to the aggregate requires an explicit reconciliation rule.

Matching is not a soft hint

The UAS first validates the request. More than one Replaces value, or Replaces in a method other than INVITE, produces 400. So does a request carrying contradictory call-control semantics.

RFC 3911 supplies the clearest contrast. Its Join header uses the same kind of dialog triple, but asks the receiving user agent to add a new dialog to the conversation space. Replaces asks the UA to shut the identified dialog down and substitute the incoming one. An INVITE cannot coherently demand both, so Join and Replaces together are rejected.

The identifier did not determine the action. The header name did. This gives a compact model:

  • the triple identifies an object;
  • the header expresses a proposed operation;
  • authentication says who made the request;
  • authorization says whether that actor may perform that operation;
  • admission says whether it can work now;
  • execution and observation say what actually happened.

If the Replaces value matches more than one dialog, the UA acts as if it matched none. No match, or a match to a dialog not created with INVITE, yields 481. A match to a dialog that already terminated should yield 603, preventing a late replacement request from ringing as an unrelated new call.

None of those codes alone proves why the state diverged. A 481 can mean stale identifiers, reversed tags, wrong endpoint instance, failed state replication, retargeting or an ordinary termination race. An incident record should preserve the state observed at the endpoint, not translate every mismatch into an attack or every match into permission.

The mandatory authorization step

Once an active dialog matches, RFC 3891 requires the user agent to verify that the initiator of the new INVITE is authorized to replace it. The word “authorized” appears after matching for a reason.

The RFC describes several possible bases. An initiator authenticated as equivalent to the user being replaced may be allowed, for example where two endpoints legitimately share credentials for one identity. A request triggered by REFER can carry Referred-By evidence that it was sent on behalf of the other participant. The UAS can apply other local policy, including policy different from that used for the old dialog.

These are scoped inputs, not a universal mandate. Shared credentials can model a useful executive-assistant or call-centre relationship; the same design can make a broad service credential dangerously powerful. Authentication establishes control of a credential. It does not establish that a human currently intended this transfer or that the actor has authority across every tenant, recording regime or commercial account.

RFC 3892 is equally careful about Referred-By. It distinguishes the referrer, the referee that follows the instruction and the refer target. The referee copies the referral information into the triggered request and is therefore able to observe or alter it. A bare Referred-By URI can guide policy, but if it affects admission or what a user is shown, the target should require a valid protected token. Without one, the information is suspect.

Even a verified referral token has a boundary. It can protect statements about who referred whom, to which URI and when. It does not prove a manager's employment power, a patient's consent, a trader's mandate, a call-recording exception or a customer's entitlement. The endpoint or application policy remains responsible for those decisions.

Knowing a dialog can be evidence without becoming ownership

RFC 4538 defines Target-Dialog for requests whose authorization can depend on awareness of an existing dialog. Under its stated assumptions — cryptographically random identifiers, a SIPS-established dialog and a defined trust relation to entities on the original path — knowledge of the triple can support an authorization decision.

That is not a contradiction. It is an example of evidence with conditions. On a non-SIPS path, an eavesdropper may have learned the identifiers, so authorization becomes optional. A recipient can also understand Target-Dialog and still choose not to authorize the request under its policy.

Dialog awareness is therefore neither worthless nor sovereign. It can demonstrate access to a protected coordination fact. What it cannot do is decide its own scope. The requested method, protected path, identity, trust relation and local rule define what the evidence is good for.

This is Heng Lu's distinction between participation and authority in protocol form. Possessing the coordinates of a decision can justify being heard by the decision point. It does not automatically transfer the right to bind the endpoint that bears the loss.

Authorization is still not acceptance

After authorization succeeds, the UAS attempts to accept the new INVITE, reassign the user interface and other resources from the matched dialog, and shut the old dialog down.

The attempt can fail. RFC 3891 names required QoS, keying and incompatible media as examples. The new INVITE is a real session-admission request, not an administrative rename. If the UA cannot accept it, it must return an appropriate error and leave the matched dialog unchanged.

This ordering is a failure-containment rule. Consider the alternatives:

  • terminate on match, and stale or malicious identifiers can destroy a live conversation;
  • terminate on authentication, and an authorized but incompatible replacement can still create an outage;
  • terminate on policy approval before offer processing, and a valid intention can erase the only working media leg;
  • terminate only after new-dialog acceptance, and failure leaves the known working dialog in place.

The standard chooses the last path.

An operator therefore needs separate telemetry for match result, authentication, authorization, offer/admission and old-leg termination. A generic “Replaces accepted” event cannot explain which boundary was crossed.

2xx first, BYE or CANCEL second

For a confirmed matched dialog, the UAS accepts the new INVITE with a 2xx response and then sends BYE on the old dialog. For an early dialog that the UAS itself initiated, it accepts the new INVITE and sends CANCEL on the old INVITE transaction.

The distinction is not cosmetic. BYE ends an established dialog. CANCEL stops a pending invitation. Logs that label both “old call cleared” lose the state transition needed to diagnose races.

The early-only parameter narrows intent. If it is present but the target dialog has already become confirmed, the UAS returns 486. A call-pickup request meant only for a ringing leg must not silently displace an answered conversation because confirmation won a race.

An early dialog not initiated by the receiving UA cannot be replaced through this path. The UAS returns 481 and leaves it unchanged. The one-dialog primitive cannot recreate the forking logic of an invitation that originated elsewhere.

A replacement 2xx is substantial evidence: the target accepted the new dialog and committed to the protocol's follow-on behavior. It is still not the whole observable result. The BYE can be lost. A B2BUA can retain an unmapped downstream leg. Media may fail after offer/answer. A fork sibling may remain. The interface can attach the wrong recording or customer context. Charging may continue on both legs.

The correct conclusion is not that 2xx means nothing. It means one precise thing and starts a sequence that must be observed.

REFER has its own approval and result

RFC 3515 defines REFER as a request that its recipient contact the resource in Refer-To. A UA accepting a well-formed REFER should seek user approval, either through an interactive prompt or configured policy. Only after approval does it contact the resource using the normal method for that URI.

For attended transfer, Refer-To commonly carries a SIP URI with an escaped Replaces value. The transferee follows it by constructing a new INVITE. The transfer target then performs the RFC 3891 sequence: match, authorize, admit and replace.

REFER acceptance and referenced-action success are reported separately. NOTIFY carries the progress and final status of the action. RFC 7647 updates accepted REFER responses to use 200 instead of 202 and generally separates new REFER dialog use from the existing session through GRUU and Target-Dialog. It does not turn that 200 into proof of transfer completion.

RFC 5589, the SIP transfer BCP, makes the operational consequence explicit. A successful REFER transaction does not terminate the original session; termination requires a subsequent BYE. Its failed-transfer flows resume the transferee from hold when the target is busy, does not answer or rejects the replacement. Preserving the old session until the new path succeeds is not an edge-case courtesy. It is the architecture of recovery.

Five records may therefore exist for one user-visible transfer:

  1. approval of the REFER;
  2. acceptance of the REFER transaction;
  3. result of the triggered INVITE with Replaces;
  4. termination of the prior dialog;
  5. media and application continuity after the handoff.

Any platform reporting one of these as all five has created authority by compression.

A transfer evidence chain that can survive dispute

The reconstruction begins by keeping two identities: the Call-ID of the new INVITE and the Call-ID/tag triple named by Replaces. Record the receiver's local and remote perspective, the dialog state at match time, Contact, route and fork branch.

Then record the decision surface: authenticated initiator, Referred-By value and token validation, policy version, tenant or user rule, approval source and reason. “Authorized=true” without the rule and actor is not durable evidence.

Admission needs its own facts: response code, SDP fingerprint, codecs and directions, keying result, QoS or resource refusal, target instance and ACK. If the new dialog succeeds, correlate the old-dialog BYE or CANCEL, response, retransmissions and the last signaling and media observed on that leg.

REFER belongs in the same timeline but not the same state field. Preserve its Call-ID, CSeq, Target-Dialog, Refer-To fingerprint, approval, response and each NOTIFY. A NOTIFY success should reconcile with the replacement INVITE and old-leg evidence rather than overwrite them.

Media and business state remain independent: RTP and RTCP continuity, recording, user prompt, queue or case ownership, charging-leg closure and entitlement. Privacy can justify restricted storage or keyed fingerprints; it does not justify deleting the chain that explains a binding decision.

Useful tests include reversed tags; ambiguous matches; stale and terminated dialogs; early-only losing the confirmation race; unsupported Require: replaces; authorization denial after a correct match; invalid Referred-By token; compatible and incompatible media; keying and QoS failure; target busy and no answer; replacement 2xx followed by lost BYE; fork siblings; retargeting; failover that loses dialog state; and B2BUA mappings that cannot connect upstream and downstream legs.

The purpose is not a prettier success metric. It is a record that can answer, separately: what was requested, which object was named, who was allowed to act, what the endpoint admitted, what it terminated and what the user actually received.

Sources