RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc3891.html

Published

2004-09

Updated

unknown

Accessed

2026-09-16

HTTP status

200

License

IETF Trust / BCP 78; permitted with the RFC's own copyright and license notices intact

Source notes citing this source

• A user agent server must reject a request with 400 Bad Request if more than one Replaces header field is present in an INVITE, if a Replaces header field is present in a request other than INVITE, or if a Replaces header field is present alongside another header field with contradictory semantics. in context
• A Replaces header field that matches no dialog, that matches more than one dialog, or that matches a dialog not created with an INVITE is answered with 481 Call/Transaction Does Not Exist, and in the multiple-match case the user agent must act as if no match was found. in context
• Where a Replaces header field matches a dialog that has already terminated the user agent should decline the request with a 603 Declined, and RFC 3891 gives the reason: a 600-class response prevents an irritating race condition in which the user agent rings or alerts for a replacement call that is no longer wanted. in context
• Where a Replaces header field matches an active dialog the user agent must verify that the initiator of the new INVITE is authorised to replace it; RFC 3891 names authentication equivalent to the replaced user as sufficient, and says a user agent should treat a replacement as authorised where the request carries a Referred-By header corresponding to the user being replaced. in context
• On accepting a replacement a user agent shuts down the replaced dialog differently by its state: a confirmed dialog is accepted with a 2xx and ended with a BYE, an early dialog that the user agent itself initiated is accepted with a 2xx and ended with a CANCEL, and an early dialog that the user agent did not initiate is refused with 481 and left unchanged. in context
• The early-only parameter in a Replaces header field restricts the replacement to an early dialog, and where it is present and the header matches a confirmed dialog the user agent rejects the request with a 486 Busy response. in context
• If a user agent cannot accept a replacing INVITE, for example because it cannot establish required quality of service or keying or has incompatible media, it must return an appropriate error response and must leave the matched dialog unchanged. in context
• The Replaces header field identifies an existing dialog by Call-ID, to-tag and from-tag, and a user agent server matches those parameters as if they were tags in an incoming request, comparing the to-tag parameter to its own local tag and the from-tag parameter to the remote tag. in context
• Proxy servers require no new behaviour to support Replaces and simply pass the header field transparently, and RFC 3891 notes that a proxy forking on application logic such as caller screening or time-of-day routing can forward a Replaces INVITE to a completely different set of contacts from the request it was meant to replace, in which case the request fails. in context
• A user agent client 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 that INVITE, and should address replacement requests to the SIP Contact URI of the target rather than to an address of record. in context

Cite this source record

APA

WarmTransfer. (n.d.). RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-3891-replaces

BibTeX

@misc{warmtransfer-rfc-3891-replaces,
  title  = {RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header},
  author = {{WarmTransfer}},
  year   = {2004},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-3891-replaces},
  note   = {IETF / RFC Editor, accessed 2026-09-16}
}