The Session Initiation Protocol (SIP) "Replaces" Header
Extracted elements (30)
A new INVITE with an explicit Replaces header was chosen over implicit dialog association based on Call-ID or other fields because: an INVITE already has correct new-call semantics; the explicit header makes intent obvious; a unique Call-ID can be assigned to the replacement; and there are no adverse effects if the header is unsupported.
The "early-only" flag prevents a race condition in call pickup scenarios: without it, if a confirmed dialog is matched when only an early dialog replacement was intended, the UA would disconnect an active call. The flag causes the UAS to return 486 Busy if it matches a confirmed dialog, forcing the UAC to reattempt or fail gracefully.
For compatibility with RFC 2543-compliant UAs that may use a tag value of zero, a tag of zero in a Replaces header matches both a tag of zero and a null tag in the matched dialog.
Proxy servers require no new behavior to support the Replaces extension and simply pass the header transparently. However, a proxy that forks based on application-layer logic (caller screening, time-of-day routing) may forward an INVITE with Replaces to a set of Contacts unrelated to the intended target, causing the request to fail.
A Replaces header field MUST contain exactly one to-tag and exactly one from-tag, as they are required for unique dialog matching.
A UAC MUST NOT send an INVITE with a Replaces header field that attempts to replace an early dialog which was not originated by the target of the INVITE with a Replaces header field.
If both a Replaces header field and another header field with contradictory semantics are present in a request, the request MUST be rejected with a 400 Bad Request response.
If more than one Replaces header field is present in an INVITE, or if a Replaces header field is present in a request other than INVITE, the UAS MUST reject the request with a 400 Bad Request response.
If no match is found for the Replaces header, the UAS rejects the INVITE with a 481 Call/Transaction Does Not Exist response. Likewise, if the Replaces header field matches a dialog not created with an INVITE, the UAS MUST reject the request with a 481 response.
If the Replaces header field matches a dialog which has already terminated, the UA SHOULD decline the request with a 603 Declined response, to prevent a race-condition where the UA alerts for an unwanted replacement call.
If the Replaces header field matches an active dialog, the UA MUST verify that the initiator of the new INVITE is authorized to replace the matched dialog, checking equivalence via Digest authentication or S/MIME credentials.
If the Replaces header field matches an early dialog that was not initiated by this UA, it returns a 481 response to the new INVITE and leaves the matched dialog unchanged.
If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found.
If the Replaces header matches a confirmed dialog and the "early-only" flag is present, the UA rejects the request with a 486 Busy response. Otherwise, it accepts the new INVITE with a 200-class response and shuts down the replaced dialog with a BYE.
If the Replaces header matches an early dialog initiated by the UA, it accepts the new INVITE with a 200-class response and shuts down the replaced dialog by sending a CANCEL.
If the UA cannot accept the new INVITE (e.g., cannot establish required QoS or keying, or has incompatible media), the UA MUST return an appropriate error response and MUST leave the matched dialog unchanged.
Implementations SHOULD NOT rely on former-participant credential reuse as the sole authorization mechanism for replacement, as this method is considered more dangerous than authorization-by-delegation approaches.
Implementations SHOULD only address replacement requests (i.e., set the Request-URI) to the SIP Contact URI of the target, to avoid unexpected behavior in the face of proxy forking.
Implementations which support the Replaces header SHOULD also implement the Referred-By mechanism (RFC 3892), which allows a UAS to verify that a replacement request was sent on behalf of the other participant in the matched dialog.
Invitations with the Replaces header MUST only be accepted if the peer requesting replacement has been properly authenticated using a standard SIP mechanism (Digest or S/MIME), and authorized to request a replacement of the target dialog.
UAs which support the Replaces header MUST include the "replaces" option tag in a Supported header field.
Use of message integrity protection for dialog information (Call-ID, to-tag, from-tag) used in Replaces headers is STRONGLY RECOMMENDED; use of end-to-end security mechanisms to encrypt this information is also RECOMMENDED.
The Replaces header is a SIP request header defined only for INVITE requests. It contains call-id, to-tag, and from-tag identifying an existing dialog to be shut down and logically replaced by the incoming INVITE. Only a single Replaces header field value may be present in a SIP request.
The "replaces" option tag is defined for use in Require and Supported headers. UAs that support the Replaces header MUST include the "replaces" option tag in a Supported header field. UAs wanting explicit failure notification MAY include it in a Require header.
RFC 3891 registers the "Replaces" SIP header field in the SIP header registry with no short form; normative description is section 6.1 of this document.
RFC 3891 registers the "replaces" SIP option-tag for use in Require and Supported headers, indicating support for the Replaces header field.
Four authorization scenarios are defined as warranting replacement: (1) replacement by a party equivalent to the replaced party; (2) replacement on behalf of the replaced party, possibly transitively via REFER/Referred-By; (3) replacement by a former participant; (4) replacement by a specifically authorized party. Former-participant authorization (#3) is the weakest and SHOULD NOT be relied upon alone.
The Replaces extension significantly changes SIP security posture: an eavesdropper who learns Call-ID, To, and From headers of a dialog can now use the Replaces header to disconnect or replace participants, unlike in baseline SIP where Digest or end-to-end integrity would protect against this. Proper authentication and authorization of replacement requests is therefore critical.
UAS dialog replacement state: (1) match confirmed dialog + early-only flag → reject 486; (2) match confirmed dialog, no early-only → accept 200, send BYE on old dialog; (3) match early dialog initiated by this UA → accept 200, send CANCEL on old dialog; (4) match early dialog not initiated by this UA → reject 481; (5) no match or terminated match → reject 481 or 603.
Replaces header ABNF: `Replaces = "Replaces" HCOLON callid *(SEMI replaces-param)` where `replaces-param = to-tag / from-tag / early-flag / generic-param`, `to-tag = "to-tag" EQUAL token`, `from-tag = "from-tag" EQUAL token`, `early-flag = "early-only"`. The header MUST contain exactly one to-tag and one from-tag.