RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer

Publisher

IETF / RFC Editor

URL

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

Published

2009-06

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

• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context
• 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. in context

Cite this source record

APA

WarmTransfer. (n.d.). RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-5589-call-control-transfer

BibTeX

@misc{warmtransfer-rfc-5589-call-control-transfer,
  title  = {RFC 5589 — Session Initiation Protocol (SIP) Call Control - Transfer},
  author = {{WarmTransfer}},
  year   = {2009},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-5589-call-control-transfer},
  note   = {IETF / RFC Editor, accessed 2026-09-16}
}