SIP Protocols & StandardsKnowledge baseIETF Standards · RFC 3515 / RFC 3891

SIP REFER Method (RFC 3515) Deep Dive: Executing Blind and Attended Call Transfers

by Provider Adminlast verified 2026-08-04

Overview

This guide provides a comprehensive deep dive into the SIP REFER request method defined in RFC 3515, which enables session transfer mechanisms in VoIP networks. You will learn the mechanics of both Blind and Attended call transfers, the roles of key headers like Refer-To and Replaces, and how implicit subscriptions track transfer completion via NOTIFY messages.

Illustration for SIP REFER Method (RFC 3515) Deep Dive: Executing Blind and Attended Call Transfers

Key takeaways

Understand the RFC 3515 REFER request lifecycle and implicit NOTIFY subscriptions.
Differentiate between Blind Call Transfer and Attended Call Transfer mechanics.
Master the syntax of the Refer-To header, including embedded parameters and the Replaces header (RFC 3891).
Analyze SIP signaling flows and sipfrag payloads during transfer execution.
Identify security considerations and SBC handling strategies for call transfers.

Prerequisites

Solid understanding of core SIP dialogs, transactions, and INVITE request flows.
Familiarity with RFC 3261 fundamentals and basic SIP headers.
Basic knowledge of call signaling capture analysis tools like Wireshark.

Guide

section #1
Overview of the SIP REFER Method and Implicit Subscriptions The SIP REFER request, standardized in RFC 3515, is used by a SIP user agent (the Transferor) to request that another user agent (the Transferee) contact a third party (the Transfer Target). Unlike standard mid-dialog requests, issuing a REFER implicitly creates an event subscription governed by RFC 6665. The Transferee MUST send SIP NOTIFY requests back to the Transferor to communicate the status of the new dialog attempt. The body of these NOTIFY requests uses the 'message/sipfrag' content type, containing the status line (e.g., 'SIP/2.0 100 Trying' or 'SIP/2.0 200 OK') of the newly initiated call session.
sip
```
REFER sip:transferee@192.168.1.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK776asdhds
From: <sip:transferor@192.168.1.20>;tag=11111
To: <sip:transferee@192.168.1.10>;tag=22222
Call-ID: 38482712@192.168.1.20
CSeq: 101 REFER
Refer-To: <sip:target@192.168.1.30>
Referred-By: <sip:transferor@192.168.1.20>
Contact: <sip:transferor@192.168.1.20:5060>
Content-Length: 0
```
section #2
Anatomy of the Refer-To Header and URI Parameters The core component of the REFER method is the mandatory Refer-To header, which specifies the destination URI the Transferee should contact. The URI can be a standard SIP/SIPS URI, a tel URI, or include embedded headers using URI header escaping (syntax '?HeaderName=HeaderValue'). For example, when performing an Attended Transfer, the Refer-To URI embeds a 'Replaces' header containing the Call-ID, To-tag, and From-tag of the consultation dialog. Additionally, optional parameters like 'method=INVITE' can explicitly define the SIP method to execute, though INVITE is the default.
sip
```
Refer-To: <sip:target@192.168.1.30?Replaces=493021%40192.168.1.30%3Bto-tag%3D33333%3Bfrom-tag%3D44444>
```

section #3

Blind Call Transfer Protocol Flow In an Unattended or Blind Transfer, the Transferor instructs the Transferee to connect to the Transfer Target immediately, without prior consultation. The Transferor sends a REFER request containing the target's URI. Upon receiving a 202 Accepted response from the Transferee, the implicit subscription triggers an initial NOTIFY (100 Trying). The Transferee sends a new INVITE to the Transfer Target. As the Target responds with provisional (180 Ringing) and final (200 OK) responses, the Transferee forwards these state changes to the Transferor using NOTIFY requests with 'message/sipfrag' bodies. Once the target answers, the Transferor sends a BYE to terminate its original leg with the Transferee.

text

Transferor                Transferee               Target
    |                          |                         |
    |--- REFER (Refer-To: C) ->|                         |
    |<-- 202 Accepted ---------|                         |
    |<-- NOTIFY (100 Trying) --|                         |
    |--- 200 OK --------------->|                         |
    |                          |--- INVITE ------------->|
    |                          |<-- 180 Ringing ---------|
    |<-- NOTIFY (180 Ringing) -|                         |
    |--- 200 OK --------------->|                         |
    |                          |<-- 200 OK --------------|
    |<-- NOTIFY (200 OK) ------|                         |
    |--- 200 OK --------------->|                         |
    |--- BYE ----------------->|                         |
    |<-- 200 OK ---------------|                         |

section #4
Attended Call Transfer and RFC 3891 Replaces Header An Attended (or Consultative) Transfer occurs when the Transferor first establishes a second leg with the Transfer Target to announce the caller before completing the transfer. To bridge the Transferee and Target seamlessly, RFC 3891 introduces the 'Replaces' header. When the Transferor issues the REFER to the Transferee, the Refer-To header contains Target's URI appended with an escaped Replaces parameter that references the consultation dialog identifiers (Call-ID, To-tag, From-tag). When the Transferee sends an INVITE to the Target containing this Replaces header, the Target matches it with the existing consultation leg, answers the new INVITE, and automatically terminates the consultation dialog with the Transferor.
sip
```
INVITE sip:target@192.168.1.30 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK887asdhds
From: <sip:transferee@192.168.1.10>;tag=22222
To: <sip:target@192.168.1.30>
Call-ID: 99887766@192.168.1.10
CSeq: 1 INVITE
Replaces: 493021@192.168.1.30;to-tag=33333;from-tag=44444
Content-Type: application/sdp
Content-Length: 180

[SDP Offer]
```
section #5
Managing Event Subscriptions and Sipfrag Payloads The implicit subscription established by a REFER request persists until a final response (2xx-6xx) is received for the triggered request, or until a subscription timeout occurs (typically 30-180 seconds). Notifications are carried in NOTIFY requests with 'Event: refer' and 'Content-Type: message/sipfrag;version=2.0'. The body of a sipfrag contains only a SIP status line (e.g., 'SIP/2.0 200 OK') or partial header fields. Upon receipt of a sipfrag containing a final success status code (200 OK), the Transferor terminates the implicit subscription and proceeds to tear down its active session with the Transferee via BYE.
sip
```
NOTIFY sip:transferor@192.168.1.20:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK998asdhds
From: <sip:transferee@192.168.1.10>;tag=22222
To: <sip:transferor@192.168.1.20>;tag=11111
Call-ID: 38482712@192.168.1.20
CSeq: 501 NOTIFY
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Content-Length: 17

SIP/2.0 200 OK
```
section #6
Security Considerations and Best Practices for REFER Handling Because REFER requests instruct an endpoint to place outgoing calls, improper handling can lead to unauthorized call routing, toll fraud, or denial-of-service conditions. User agents and Session Border Controllers (SBCs) must validate REFER requests within active, authenticated dialogs. RFC 3892 defines the 'Referred-By' header, which uses cryptographic signatures or network identity assertions to guarantee the identity of the referring party. In SBC implementations, engineers often choose between handling REFER end-to-end (passthrough) or consuming/localizing the REFER on the SBC to hide internal topology and strictly manage call legs.

SIP REFER Method (RFC 3515) Deep Dive: Executing Blind and Attended Call Transfers

Overview

Key takeaways

Prerequisites

Guide

Further reading