# Call transfer semantics REFER and Replaces

Canonical: https://warmtransfer.net/knowledge/call-transfer-semantics

Last verified: 2026-09-16

A SIP transfer involves 3 core actors: the Transferor who initiates the transfer, the Transferee who is transferred, and the Transfer Target introduced into the call[^54]. To describe end-to-end call control scenarios, RFC 5589 additionally names 4 scenario roles: the Originator, the Facilitator, the Screener, and the Recipient[^21].

## How REFER and Event Subscriptions Work

The REFER method requests that the recipient refer to a resource provided in the request[^30]. A REFER request must contain exactly 1 Refer-To header field value, and any request with 0 or more than 1 Refer-To header field must be rejected with a 400 Bad Request[^28]. The Contact header field is used strictly for the Route and Record-Route mechanism and is not available to designate the target of the reference[^20]. A user agent accepting a well-formed REFER should seek interactive or policy-based user approval, may decline immediately with a rejection if denied, and should not accept REFER requests to non-SIP URIs if unable to access them[^25].

RFC 7647 deprecates the 202 response code for REFER[^11]. An element accepting a REFER request must not respond with 202, must treat an incoming 202 as identical to 200, and must return 200 wherever RFC 3515 previously specified 202[^11]. Accepting a REFER with any 2xx response obligates the recipient to create an implicit subscription and notify the referring party of the refer status[^11]. REFER is the only mechanism permitted to create a subscription to the refer event package; a SUBSCRIBE request sent for event refer without an existing subscription must be rejected with a 403[^30].

Every NOTIFY reporting refer status must include an Event header field set to refer and a message/sipfrag body beginning with a SIP Response Status-Line[^33]. Because the refer event package does not support state deltas, each body is a complete status statement[^33]. RFC 3515 outlines a minimal set of 4 status-line bodies:[^31]

* `SIP/2.0 100 Trying` while the subscription is pending[^31].
* `SIP/2.0 200 OK` when the reference succeeds[^31].
* `SIP/2.0 503 Service Unavailable` when the reference fails[^31].
* `SIP/2.0 603 Declined` when the REFER was accepted prior to approval and approval was subsequently denied[^31].

Creating the subscription results in an immediate NOTIFY, and the sender of the REFER must be prepared to receive a NOTIFY before the REFER transaction itself completes[^29]. Neither the REFER request nor its response carries a subscription duration; the lifetime follows the progress of the referenced request and is set by the notifier in the initial NOTIFY Subscription-State expires parameter, which can be set to terminate the subscription immediately if the notifier declines to hold state[^34]. Unsubscribing or rejecting a NOTIFY terminates the subscription but does not indicate that the referenced request should be cancelled, and the agent executing the transfer should not send a CANCEL because the subscription ended early[^59].

Where the remote party in an existing dialog has provided a Globally Routable User Agent URI as its contact, RFC 7647 prohibits dialog reuse: the user agent must construct the REFER as an out-of-dialog message without a tag in the To header field, unless the peer is an older RFC 3515 implementation lacking such a URI[^32]. When identifying an existing dialog for transfer under RFC 5589, RFC 7647 requires the use of the Target-Dialog extension from RFC 4538, and user agents accepting REFER must be capable of processing Target-Dialog[^51].

## Transfer Signaling and Execution

RFC 5589 requires that a transfer transaction does not remove the Transferor and Transferee from their session, preserving behaviors like ringback on transfer failure[^57]. A successful REFER transaction does not terminate the original session between Transferor and Transferee; ending it requires a subsequent BYE[^27]. The media negotiated between the Transferee and Transfer Target is renegotiated from scratch: the Transferee's INVITE carries the same session description it would have sent independently, and the REFER leaves the original media streams unchanged[^23]. Furthermore, RFC 5589 requires that the Transferor learns whether the transfer succeeded, that the Transferee can replace an existing dialog, and that the Transferor informs the other parties of transfer progress[^58].

User agents fully supporting RFC 5589 support REFER, Replaces, Target-Dialog, and RFC 3261[^18]. Participants in basic transfers should advertise REFER and NOTIFY in Allow header fields on INVITE, 200 OK, and OPTIONS, and advertise Target-Dialog in Supported[^18].

In a basic transfer, the Transferor supplies the Transfer Target's contact to the Transferee, exposing that contact for potential future calls[^15]. The dialog between Transferor and Transferee stays connected on hold throughout the REFER process, making the call recoverable if the Transfer Target cannot be reached[^16]. A blind or unattended transfer is a basic transfer in which the Transferor's agent issues a BYE immediately upon completion of the REFER transaction without participating in recovery[^17].

In an attended transfer, the Transferor places the Transferee on hold, calls the Transfer Target to consult, places the Target on hold, and sends a REFER containing an escaped Replaces header field inside the Refer-To header[^14]. The Transferor should use the Transfer Target's Contact URI in Refer-To unless it is known or suspected not to route outside the dialog, in which case the address of record is used; the Transferee may retry with the Contact URI if the initial INVITE yields a timeout, 403, or 404[^35]. WarmTransfer's reading of the sources is that because an attended transfer's Refer-To carries an escaped Replaces containing question marks and semicolons, RFC 8217 requires that Refer-To to use the name-addr form with angle brackets rather than a bare URI[^13]. The triggered INVITE should include a Require header field specifying replaces so that a target lacking Replaces support does not answer without a dialog match[^48]. If the Transfer Target does not support Replaces and rejects the INVITE with a 420 Bad Extension, the Transferor falls back directly to a basic transfer[^12].

In a semi-attended transfer, the Transferor hangs up before establishing the consultation call, and the client continues the transfer as an attended flow[^50]. Media must be played to the Transfer Target upon answer, or the Target may hang up and cause the transfer to fail[^50]. If a Transferor abandons consultation by sending a CANCEL and converts to a blind transfer, a race condition can occur if the Target answers on a gateway just after receiving the CANCEL; the subsequent triggered INVITE will hit a busy tone or voicemail because the handset is off-hook[^19]. Using the semi-attended flow avoids this gateway glare condition[^19].

Transfer scenarios can also reverse roles to protect the Transfer Target's contact identity, causing the Target to initiate the transfer of the Transferee[^52]. In this case, the Transferee receives a new incoming call from the Target, which may ring on a separate call appearance or be rejected with Busy Here if the Transferee cannot associate it with the existing session[^52]. Alternatively, RFC 5589 models transfer as an ad hoc conference where the Transferor acts as a focus, allowing simulated ringback or announcements while the parties subscribe to the conference package[^55].

Removing a PSTN gateway hairpin after a transfer requires both legs of the target call to reside on that same gateway; because neither consultative nor blind transfer provides a proxy with dialog correlation across calls, a proxy cannot coerce both legs to the same gateway[^22].

## The Replaces Header

The Replaces header field identifies an existing dialog by Call-ID, to-tag and from-tag[^45]. A user agent server evaluates these values against its own dialog table, matching the to-tag parameter to its local tag and the from-tag parameter to the remote tag[^45].

A receiving user agent server must reject an incoming request with 400 Bad Request if it contains more than 1 Replaces header field, if Replaces appears on a method other than INVITE, or if Replaces appears alongside contradictory header fields[^37]. The server must return 481 Call/Transaction Does Not Exist if Replaces matches no dialog, matches multiple dialogs (acting as if no match was found), or matches a dialog not established by an INVITE[^38]. If Replaces matches an already terminated dialog, the server should return 603 Declined to prevent unwanted ringing[^39]. If the Replaces header contains the early-only parameter and matches a confirmed dialog, the server rejects it with a 486 Busy response[^43]. If the server cannot accept the replacement due to incompatible media, lack of keying, or failed quality of service, it returns an error response and leaves the matched dialog intact[^44].

When accepting an authorised replacement, the user agent terminates the replaced dialog based on its state:[^42]

* A confirmed dialog is accepted with a 2xx response and terminated with a BYE[^42].
* An early dialog initiated by the user agent itself is accepted with a 2xx response and terminated with a CANCEL[^42].
* An early dialog not initiated by the user agent is rejected with a 481 and left unchanged[^42].

A user agent client must not send an INVITE with a Replaces header field targeting an early dialog not originated by that INVITE's target, and should direct replacement INVITEs to the target's Contact URI rather than its address of record[^47]. Proxies forward Replaces transparently without modified behavior, but application-level proxy forking (such as time-of-day routing or screening) can misroute a replacement INVITE to a different contact set, causing the replacement to fail[^46].

## Security and Identification

Without a Referred-By header field, a Transfer Target lacks definitive identity details about who initiated the transfer[^36]. The header can be populated in the REFER and copied into the triggered INVITE, or supplied as a cryptographic token signed by the Transferor and carried in a message body across the Transferee[^36]. A user agent should treat a dialog replacement as authorised if the INVITE contains a Referred-By header corresponding to the user being replaced, or if the initiator has authentication equivalent to that user[^41].

REFER requests require standard SIP authentication and authorisation to prevent call hijacking[^56]. Replacing INVITEs must also be authenticated and authorised, and the user must authorise any additional media streams introduced by the replacement dialog[^56].

## Applicability

Applies to: IETF Session Initiation Protocol. Sources checked 2026-09-16. RFC 3515 is updated by 2 documents: RFC 8217 Clarifications for When to Use the name-addr Production in SIP Messages and RFC 7647 Clarifications for the Use of REFER with RFC 6665[^49]. RFC 3891 and RFC 5589 carry neither an Updated by nor an Obsoleted by entry in their RFC Editor metadata[^40]. RFC 7647 and RFC 8217 likewise carry neither an Updated by nor an Obsoleted by entry[^53].

## What remains uncertain

Which of the RFC 5589 flows Unified CM and Webex Calling actually emit is not covered by the sources below. How phone transfer is defined and executed in other platforms is not covered by the sources below. What the Target-Dialog header field does and when it is required, beyond its general requirement for transfer signaling and support advertisement, is not covered by the sources below.

## See also

* See also [SIP transactions dialogs and call setup](https://warmtransfer.net/knowledge/sip-transactions-dialogs).
* See also [SIP response codes and failure interpretation](https://warmtransfer.net/knowledge/sip-response-codes).
* See also [Hold resume and conference signaling](https://warmtransfer.net/knowledge/hold-resume-conference).

## Sources

[^1]: Amazon Connect exposes no single warm transfer primitive; a warm transfer is composed from a quick connect that runs a transfer flow plus the agent's subsequent choice of Join, Hold all or End call on the Contact Control Panel (inferred). Source: [Quick connect scenarios for transferring contacts](https://docs.aws.amazon.com/connect/latest/adminguide/how-quick-connects-work.html), Sections User quick connects and Queue quick connects, read together with Set up contact transfers Overview of steps. Checked 2026-09-07.
[^2]: A blind transfer and a consultation transfer are distinguished in the record set by the consultation record's duration: it is 0 for a blind transfer and non-zero for a consultation transfer, while every other marker on the three records is identical (field report). Source: [Call Detail Records Administration Guide for Cisco Unified Communications Manager Release 12.5(1), complete book, Internet Archive capture of 2025-03-23](https://web.archive.org/web/20250323135843id_/https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/12_5_1/cdrdef/cucm_b_cdr-admin-guide-1251.pdf), Call Detail Records chapter, Transferred Calls, the four worked example tables on pages 124 to 126. Checked 2026-09-15.
[^3]: Consult transfer and blind transfer require no separate configuration on Unified CM: the same Transfer control produces both and the difference is only whether the transferring party presses it the second time before or after the target answers. Source: [Feature Configuration Guide for Cisco Unified Communications Manager Release 11.0(1), complete book, Internet Archive capture](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_0_1/featureConfig/cucm_b_feature-configuration-guide-1101.pdf), Feature Configuration Guide 11.0(1), Call Transfer Overview, page 495. Checked 2026-09-15.
[^4]: The recipient of an offer for a held stream should not automatically answer with the corresponding stream held, and RFC 3264 gives the reason: certain third party call control scenarios do not work when an answerer responds to held SDP with held SDP. Source: [RFC 3264 — An Offer/Answer Model with the Session Description Protocol (SDP)](https://www.rfc-editor.org/rfc/rfc3264.html), RFC 3264 section 8.4 Putting a Unicast Media Stream on Hold. Checked 2026-09-15.
[^5]: Cisco states that for mid-call features including call transfer, call park, call pickup, call forwarding and caller identity, the caller identity disposition is based on the verstat value processed on the initial call leg, and that when an incoming call to a Webex Calling user is forwarded and the calling number changes the disposition is still decided by the verstat in the incoming call request. Source: [Secure Calling and Spam mitigation](https://help.webex.com/en-us/article/8j6te9/Secure-Calling-and-Spam-mitigation), Verification of the on-net calls, mid-call features paragraph. Checked 2026-09-16.
[^6]: The console names 5 transfer actions: blind transfer attended transfer fast transfer one-click transfer and transfer to voicemail. Source: [Get started with the Attendant Console](https://help.webex.com/en-us/article/4xgekbb/Get-started-with-the-Attendant-Console), Get started with the Attendant Console, transfer actions. Checked 2026-09-15.
[^7]: The Customer Assist reports define consultative transfer count as transfers to another party after consult and blind transfer count as transfers to another party without consult, making the presence of a consultation the whole of the distinction (disputed). Source: [Webex Calling Customer Assist](https://help.webex.com/en-us/article/72sb3r/Webex-Calling-Customer-Assist), Customer Assist reports, transfer count measures. Checked 2026-09-15.
[^8]: A digital conversation is transferred to a team queue or to a skill queue, and the transfer node offers those two targets and no option to name an agent (field report). Source: [Transfer conversation - WxEngage standalone](https://help.webexconnect.io/docs/transfer-conversation), Transfer conversation node, Route to a Team queue and Route to a Skill queue. Checked 2026-09-15.
[^9]: Blind transfer carries 3 incompatible definitions across the agent details report, the customer session record report and the queue reports (disputed). Source: [Cisco Webex Contact Center Analyzer User Guide](https://help.webex.com/en-us/article/tajemk/Cisco-Webex-Contact-Center-Analyzer-User-Guide), Agent details, customer session record and queue report parameter tables. Checked 2026-09-05.
[^10]: In Survivability mode on MPP devices and the Webex App, attended call transfer and blind call transfer are both supported while conferencing and three-way calling are not, and on VG4xx analog terminal adapters transfer is supported only when the incoming call is received on the adapter. Source: [Site survivability for Webex Calling](https://help.webex.com/en-us/article/d68vi1/Site-Survivability-for-Webex-Calling), Supported features and components, Table 1 rows Attended Call Transfer, Blind Call Transfer and Three-way Calling; and Limitations and restrictions, Conferencing. Checked 2026-09-16.
[^11]: RFC 7647 deprecates the 202 response code for REFER: an element accepting a REFER request must not reply with 202, must treat any 202 it receives as identical to a 200, and must send 200 wherever RFC 3515 requires 202. Accepting a REFER with any 2xx still obliges the recipient to create a subscription and notify the status of the refer. Source: [RFC 7647 — Clarifications for the Use of REFER with RFC 6665](https://www.rfc-editor.org/rfc/rfc7647.html), RFC 7647 section 5 The 202 Response Code Is Deprecated. Checked 2026-09-16.
[^12]: Where a Transfer Target does not support Replaces it rejects the attended transfer's INVITE with a 420 Bad Extension response, and RFC 5589's flow has the Transferor switch immediately from attended transfer to basic transfer. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.7 Attended Transfer Fallback to Basic Transfer and Figure 14. Checked 2026-09-16.
[^13]: An attended transfer's Refer-To carries an escaped Replaces, which contains both a question mark separating the header from the URI and semicolons separating the dialog tags, so under RFC 8217 that Refer-To must be written in the name-addr form with angle brackets rather than as a bare address (inferred). Source: [RFC 8217 — Clarifications for When to Use the name-addr Production in SIP Messages](https://www.rfc-editor.org/rfc/rfc8217.html), RFC 8217 section 4, read against the attended transfer Refer-To of RFC 5589 section 7.3. Checked 2026-09-16.
[^14]: In an attended transfer the Transferor places the Transferee on hold, establishes a call with the Transfer Target to alert them to the impending transfer, places the Target on hold, and then transfers using an escaped Replaces header field inside the Refer-To header. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.3 Attended Transfer, opening paragraph. Checked 2026-09-16.
[^15]: In a basic transfer the Transferor gives the Transfer Target's contact to the Transferee, and RFC 5589 notes that the contact has been exposed and can be used to make new calls in future. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 6 Basic Transfer, opening paragraph. Checked 2026-09-16.
[^16]: In a basic transfer the signalling relationship between the Transferor and the Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached, and RFC 5589's flows keep that dialog connected on hold throughout the REFER process. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 6, opening paragraph and the note preceding Figure 1. Checked 2026-09-16.
[^17]: RFC 5589 describes blind or unattended transfer as the case where the Transferor's agent does not wish to take part in the rest of the REFER process and has no intention of assisting with recovery, and so emits a BYE to the Transferee as soon as the REFER transaction completes. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 6, note preceding Figure 1. Checked 2026-09-16.
[^18]: A user agent that fully supports RFC 5589 transfer supports REFER and Replaces in addition to RFC 3261 and supports the Target-Dialog header field, and participants in a basic transfer should advertise REFER and NOTIFY in Allow header fields on INVITE, 200 OK and OPTIONS and advertise Target-Dialog in Supported. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 1 Overview and section 6 paragraph 3. Checked 2026-09-16.
[^19]: RFC 5589 describes a race in which the Transferor abandons a consultation and turns it into a blind transfer: the Transfer Target on a gateway answers just after receiving the CANCEL, so when the triggered INVITE arrives the Transferee reaches a busy response or the target's voicemail because the handset is off hook, and the recommended behaviour is the semi-attended flow of section 7.6. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 11.2 Consultative Turned Blind Gateway Glare. Checked 2026-09-16.
[^20]: The Refer-To header field carries the URL being referenced and appears only in a REFER request, and RFC 3515 states that the Contact header field is part of the Route and Record-Route mechanism and is not available to indicate the target of the reference. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.1 The Refer-To Header Field. Checked 2026-09-16.
[^21]: RFC 5589 names 4 further roles used to describe transfer scenarios rather than the transfer itself: the Originator places the first INVITE, a Facilitator connects the Originator to the Recipient on the Originator's behalf, a Screener receives a call intended for the Recipient and transfers it on if appropriate, and the Recipient is the party the Originator is ultimately connected to. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 2 Actors and Roles, second list. Checked 2026-09-16.
[^22]: Removing a PSTN gateway from the path after a transfer is only possible when both legs of the target call are on the same gateway, and RFC 5589 states that in the consultative case nothing relates the consultation to the original call and in the blind case nothing relates the target dialog to the original dialog, so a proxy has no information with which to coerce them onto one gateway. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 11.1 Coerce Gateway Hairpins to the Same Gateway. Checked 2026-09-16.
[^23]: The media negotiated between the Transferee and the Transfer Target is not affected by the media negotiated between the Transferor and the Transferee: the INVITE the Transferee issues carries the same session description it would have carried had the Transferee initiated that call on its own, and the REFER does not alter the media streams between the Transferor and the Transferee. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 5, second paragraph. Checked 2026-09-16.
[^24]: If no final response has been generated, the user agent receiving a REFER must return a 202 Accepted before the REFER transaction expires, and if the REFER is accepted with any 2xx the recipient must create a subscription and send notifications of the status of the refer. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.2, final 2 paragraphs. Checked 2026-09-16.
[^25]: A user agent accepting a well-formed REFER should request approval from the user to proceed, which may be satisfied interactively or from configured policy, and may decline the request if that approval is immediately denied; RFC 3515 also says a user agent not capable of accessing non-SIP URIs should not accept REFER requests to them. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.2. Checked 2026-09-16.
[^26]: A REFER request implicitly establishes a subscription to the refer event, creates a dialog and so must contain a single Contact header field value, may be placed outside the scope of a dialog created with an INVITE, and when sent inside an existing dialog must follow that dialog's Route and Record-Route logic. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2 The REFER Method. Checked 2026-09-16.
[^27]: A successful REFER transaction does not terminate the session between the Transferor and the Transferee; if those parties wish to end their session they must do so with a subsequent BYE. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 5 Using REFER to Achieve Call Transfer, first paragraph. Checked 2026-09-16.
[^28]: A REFER request must contain exactly one Refer-To header field value, and an agent responding to a REFER must return 400 Bad Request if the request contained zero or more than one. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 sections 2.4.1 and 2.4.2. Checked 2026-09-16.
[^29]: Creating a subscription always results in an immediate NOTIFY, and the agent that issued the REFER must be prepared to receive a NOTIFY before the REFER transaction completes. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.4. Checked 2026-09-16.
[^30]: REFER is the only mechanism that can create a subscription to the refer event, and a SUBSCRIBE request for event refer received for a subscription that does not already exist must be rejected with a 403. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.4. Checked 2026-09-16.
[^31]: RFC 3515 gives a minimal but complete set of 4 NOTIFY bodies: SIP/2.0 100 Trying while the subscription is pending, SIP/2.0 200 OK if the reference succeeded, SIP/2.0 503 Service Unavailable if it failed, and SIP/2.0 603 Declined where the REFER was accepted before approval could be obtained and approval was then denied. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.5. Checked 2026-09-16.
[^32]: RFC 7647 prohibits dialog reuse for REFER: where the peer in an existing dialog has provided a Globally Routable User Agent URI as its contact, a user agent constructing a REFER that could create an implicit subscription must build it as an out-of-dialog message, so the REFER carries no tag in its To header field. The exception is a peer that is an older RFC 3515 implementation, identified by the absence of such a URI in the remote target. Source: [RFC 7647 — Clarifications for the Use of REFER with RFC 6665](https://www.rfc-editor.org/rfc/rfc7647.html), RFC 7647 sections 3 and 4. Checked 2026-09-16.
[^33]: Every NOTIFY reporting a refer must carry an Event header field with the value refer and a message/sipfrag body that begins with a SIP Response Status-Line whose response class indicates the status of the referred action, and the refer event package does not support state deltas so each body is a complete statement of status. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 sections 2.4.4 and 2.4.5. Checked 2026-09-16.
[^34]: A REFER transaction carries no subscription duration in either the request or the response; the lifetime of the subscribed state follows the progress of the referenced request, and the duration is chosen by the agent accepting the REFER and communicated in the initial NOTIFY's Subscription-State expires parameter, which an agent unwilling to hold state may use to terminate the subscription immediately. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.4, final paragraph. Checked 2026-09-16.
[^35]: For an attended transfer the Transferor should use the Transfer Target's Contact URI as the Refer-To URI unless that URI is suspected or known not to route outside the dialog, in which case the Target's address of record should be used, and the Transferee may retry with the Contact URI if the triggered INVITE fails on a timeout or a 403 or 404. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.3, paragraphs 2 and 4. Checked 2026-09-16.
[^36]: Without Referred-By a Transfer Target has no definitive information about which party initiated the transfer or in some cases that a transfer is taking place at all; the simplest and least secure use is a Referred-By header field in the REFER that is copied into the triggered INVITE, and the more secure form is a security token generated and signed by the Transferor and carried in a message body through the Transferee to the Target. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 8 Transfer with Referred-By. Checked 2026-09-16.
[^37]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, paragraphs 3 and 4. Checked 2026-09-16.
[^38]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, paragraphs 5 and 6. Checked 2026-09-16.
[^39]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, paragraph 7. Checked 2026-09-16.
[^40]: The RFC Editor's document information pages for RFC 3891 and RFC 5589 carry neither an Updated by field nor an Obsoleted by field, where the page for RFC 3515 carries an Updated by field naming 2 documents. Source: [RFC 3891: The Session Initiation Protocol (SIP) "Replaces" Header — RFC Editor document information](https://www.rfc-editor.org/info/rfc3891), RFC Editor information pages for RFC 3891 and RFC 5589, compared with the page for RFC 3515. Checked 2026-09-16.
[^41]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, active dialog paragraphs. Checked 2026-09-16.
[^42]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, the 3 dialog-state paragraphs following the authorisation rules. Checked 2026-09-16.
[^43]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 sections 3 and 4, early-only. Checked 2026-09-16.
[^44]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, paragraph following the authorisation rules. Checked 2026-09-16.
[^45]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 3, first 2 paragraphs. Checked 2026-09-16.
[^46]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 5 Proxy behavior. Checked 2026-09-16.
[^47]: 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. Source: [RFC 3891 — The Session Initiation Protocol (SIP) "Replaces" Header](https://www.rfc-editor.org/rfc/rfc3891.html), RFC 3891 section 4 User Agent Client Behavior. Checked 2026-09-16.
[^48]: RFC 5589 says the Require replaces header field should be used in the triggered INVITE of an attended transfer, to prevent a user agent that does not support Replaces from ignoring it and answering the INVITE without a dialog match. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.3, paragraph 3. Checked 2026-09-16.
[^49]: The RFC Editor's document information page for RFC 3515 lists it as updated by 2 documents: RFC 8217 Clarifications for When to Use the name-addr Production in SIP Messages and RFC 7647 Clarifications for the Use of REFER with RFC 6665. Source: [RFC 3515: The Session Initiation Protocol (SIP) Refer Method — RFC Editor document information](https://www.rfc-editor.org/info/rfc3515), RFC Editor information page for RFC 3515, Updated by field. Checked 2026-09-16.
[^50]: In a semi-attended transfer the Transferor ends its attempt to reach the Transfer Target before that session is established and proceeds with the transfer anyway, the Transferor's user agent continuing as an attended transfer after the Transferor hangs up; RFC 5589 states that media must be played to the Transfer Target on answer or the Target may hang up and the transfer operation will fail. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.6 Semi-Attended Transfer. Checked 2026-09-16.
[^51]: RFC 7647 requires that a user agent wishing to identify an existing dialog, such as for call transfer as defined in RFC 5589, uses the Target-Dialog extension of RFC 4538, and that user agents accepting REFER are able to process that extension in requests they receive. Source: [RFC 7647 — Clarifications for the Use of REFER with RFC 6665](https://www.rfc-editor.org/rfc/rfc7647.html), RFC 7647 section 4 Dialog Reuse Is Prohibited, final paragraphs. Checked 2026-09-16.
[^52]: A transfer that protects the Transfer Target's identity reverses the roles so that the original Target transfers the Transferee, which means the Transferee experiences a new inbound call from the Target; RFC 5589 warns that unless the Transferee can reliably associate that call with the one it already has it may have to alert on another appearance or return a Busy Here that prevents the transfer. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 7.2 Protecting Transfer Target. Checked 2026-09-16.
[^53]: The RFC Editor's document information pages for RFC 7647 and RFC 8217 carry neither an Updated by field nor an Obsoleted by field, so the 2 documents that update RFC 3515 are not themselves updated or obsoleted. Source: [RFC 7647: Clarifications for the Use of REFER with RFC 6665 — RFC Editor document information](https://www.rfc-editor.org/info/rfc7647), RFC Editor information pages for RFC 7647 and RFC 8217. Checked 2026-09-16.
[^54]: A SIP transfer has 3 actors: the Transferor initiates the transfer, the Transferee is the party being transferred, and the Transfer Target is the new party being introduced into a call with the Transferee. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 2 Actors and Roles. Checked 2026-09-16.
[^55]: RFC 5589 models a transfer that keeps both other parties informed as an ad hoc conference in which the Transferor acts as a focus and the Transferee and Transfer Target subscribe to its conference package, and states that this is how requirement 6 is met and that a focus can also introduce media such as simulated ringback or on-hold announcements. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 9 Transfer as an Ad Hoc Conference. Checked 2026-09-16.
[^56]: RFC 5589 states that any REFER request must be appropriately authenticated and authorised using standard SIP mechanisms or calls may be hijacked, that an INVITE carrying Replaces should only be accepted when authenticated and authorised and the requestor authorised to replace the dialog, and that where the replacing dialog adds media streams the user must authorise the addition. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 12 Security Considerations. Checked 2026-09-16.
[^57]: RFC 5589 requires that the Transferor and the Transferee are not removed from a session as part of a transfer transaction, and states that without this requirement some current behaviours such as ringback on transfer failure would be lost. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 4 Requirements, requirement 2 and the paragraph following it. Checked 2026-09-16.
[^58]: RFC 5589 requires that the Transferor must know whether or not the transfer was successful, that the Transferee must be able to replace an existing dialog with a new one, and that the Transferor should give the Transfer Target and the Transferee information about the nature and progress of the transfer. Source: [RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer](https://www.rfc-editor.org/rfc/rfc5589.html), RFC 5589 section 4 Requirements, requirements 3 4 and 6. Checked 2026-09-16.
[^59]: Terminating a refer subscription, either by unsubscribing or by rejecting a NOTIFY, is not an indication that the referenced request should be withdrawn, and RFC 3515 states that an agent acting on a REFER should not issue a CANCEL to the referenced request because the referring agent ended its subscription before that request completed. Source: [RFC 3515 — The Session Initiation Protocol (SIP) Refer Method](https://www.rfc-editor.org/rfc/rfc3515.html), RFC 3515 section 2.4.4. Checked 2026-09-16.