This section discusses how the Refer message request facilitates call transfer.
There are two types of call transfer: blind and attended. The primary difference between the two is that the Replaces header is used in attended call transfers. The Replaces header is interpreted by the final recipient and contains a Call-ID header, indicating that the initial call leg is to be replaced with the incoming INVITE request.
As outlined in the Refer message request, there are three main roles:
Originator--User agent that initiates the transfer or Refer request.
Recipient--User agent that receives the Refer request and is transferred to the final recipient.
Final-Recipient--User agent introduced into a call with the recipient.
A gateway can be a recipient or final recipient, but not an originator.
Blind Call-Transfer Process
A blind, or unattended, transfer is one in which the transferring phone connects the caller to a destination line before ringback begins. This is different from a consultative, or attended, transfer in which one of the transferring parties either connects the caller to a ringing phone (ringback heard) or speaks with the third party before connecting the caller to the third party. Blind transfers are often preferred by automated devices that do not have the capability to make consultation calls.
Blind transfer works as described in the
Types of SIP Call Transfer Using the Refer Message Request. The process is as follows:
- Originator (user agent that initiates the transfer or Refer request) does the following:
- Sets up a call with recipient (user agent that receives the Refer request)
- Issues a Refer request to recipient
- Recipient does the following:
- Sends an INVITE request to final recipient (user agent introduced into a call with the recipient)
- Returns a SIP 202 (Accepted) response to originator
- Notifies originator of the outcome of the Refer transaction--whether final recipient was successfully (SIP 200 OK) contacted or not (SIP 503 Service Unavailable)
If successful, a call is established between recipient and final recipient.
The original signaling relationship between originator and recipient terminates when either of the following occurs:
One of the parties sends a Bye request.
Recipient sends a Bye request after successful transfer (if originator does not first send a Bye request after receiving an acknowledgment for the NOTIFY message).
The figure below shows a successful blind or unattended call transfer in which the originator initiates a Bye request to terminate signaling with the recipient.
Figure 2. Successful Blind or Unattended Transfer--Originator Initiating a Bye Request
The figure below shows a successful blind or unattended call transfer in which the recipient initiates a Bye request to terminate signaling with the originator. A NOTIFY message is always sent by the recipient to the originator after the final outcome of the call is known.
Figure 3. Successful Blind or Unattended Transfer--Recipient Initiating a Bye Request
If a failure occurs with the triggered INVITE to the final recipient, the call between originator and recipient is not disconnected. Rather, with blind transfer the process is as follows:
Originator sends a re-INVITE that takes the call off hold and returns to the original call with recipient.
Final recipient sends an 18x informational response to recipient.
The call fails; the originator cannot recover the call with recipient. Failure can be caused by an error condition or timeout.
The call leg between originator and recipient remains active (see the figure below).
- If the INVITE to final recipient fails (408 Request Timeout), the following occurs:
- Recipient notifies originator of the failure with a NOTIFY message.
- Originator sends a re-INVITE and returns to the original call with the recipient.
Figure 4. Failed Blind Transfer--Originator Returns to Original Call with Recipient
Attended Transfer
In attended transfers, the Replaces header is inserted by the initiator of the Refer message request as an overloaded header in the Refer-To and is copied into the triggered INVITE request sent to the final recipient. The header has no effect on the recipient, but is interpreted by the final recipient as a way to distinguish between blind transfer and attended transfer. The attended transfer process is as follows:
- Originator does the following:
- Sets up a call with recipient.
- Places recipient on hold.
- Establishes a call to final recipient.
- Sends recipient a Refer message request with an overloaded Replaces header in the Refer-To header.
- Recipient does the following:
- Sends a triggered INVITE request to final recipient. (Request includes the Replaces header, identifying the call leg between the originator and the final recipient.)
- Recipient returns a SIP 202 (Accepted) response to originator. (Response acknowledges that the INVITE has been sent.)
Final recipient establishes a direct signaling relationship with recipient. (Replaces header indicates that the initial call leg is to be shut down and replaced by the incoming INVITE request.)
Recipient notifies originator of the outcome of the Refer transaction. (Outcome indicates whether or not the final recipient was successfully contacted.)
Recipient terminates the session with originator by sending a Bye request.
Replaces Header
The Replaces header is required in attended transfers. It indicates to the final recipient that the initial call leg (identified by the Call-ID header and tags) is to be shut down and replaced by the incoming INVITE request. The final recipient sends a Bye request to the originator to terminate its session.
If the information provided by the Replaces header does not match an existing call leg, or if the information provided by the Replaces header matches a call leg but the call leg is not active (a Connect, 200 OK to the INVITE request has not been sent by the final-recipient), the triggered INVITE does not replace the initial call leg and the triggered INVITE request is processed normally.
Any failure resulting from the triggered INVITE request from the recipient to the final recipient does not drop the call between the originator and the final recipient. In these scenarios, all calls that are active (originator to recipient and originator to final recipient) remain active after the failed attended transfer attempt
The figure below shows a call flow for a successful attended transfer.
Figure 5. Successful Attended Transfer
Attended Transfer with Early Completion
Attended transfers allow the originator to have a call established between both the recipient and the final recipient. With attended transfer with early completion, the call between the originator and the final recipient does not have to be active, or in the talking state, before the originator can transfer it to the recipient. The originator establishes a call with the recipient and only needs to be setting up a call with the final recipient. The final recipient may be ringing, but has not answered the call from the originator when it receives a re-INVITE to replace the call with the originator and the recipient.
The process for attended transfer with early completion is as follows (see the figure below):
- Originator does the following:
- Sets up a call with recipient.
- Places the recipient on hold.
- Contacts the final recipient.
- After receiving an indication that the final recipient is ringing, sends recipient a Refer message request with an overloaded Replaces header in the Refer-To header. (The Replaces header is required in attended transfers and distinguishes between blind transfer and attended transfers.)
- Recipient does the following:
- Returns a SIP 202 (Accepted) response to the originator. (to acknowledge that the INVITE has been sent.)
- Upon receipt of the Refer message request, sends a triggered INVITE request to final recipient. (The request includes the Replaces header, which indicates that the initial call leg, as identified by the Call-ID header and tags, is to be shut down and replaced by the incoming INVITE request.)
Final recipient establishes a direct signaling relationship with recipient.
Final recipient tries to match the Call-ID header and the To or From tag in the Replaces header of the incoming INVITE with an active call leg in its call control block. If a matching active call leg is found, final recipient replies with the same status as the found call leg. However, it then terminates the found call leg with a 487 Request Cancelled response.
 Note |
If early transfer is attempted and the call involves quality of service (QoS) or Resource Reservation Protocol (RSVP), the triggered INVITE from the recipient with the Replaces header is not processed and the transfer fails. The session between originator and final recipient remains unchanged.
|
Recipient notifies originator of the outcome of the Refer transaction--that is, whether final recipient was successfully contacted or not.
Recipient or originator terminates the session by sending a Bye request.
Figure 6. Attended Transfer with Early Completion
VSA for Call Transfer
You can use a vendor-specific attribute (VSA) for SIP call transfer.
Referred-By Header
For consistency with existing billing models, Referred-By and Requested-By headers are populated in call history tables as a VSA. Cisco VSAs are used for VoIP call authorization. The new VSA tag
supp-svc-xfer-byhelps to associate the call legs for call-detail-record (CDR) generation. The call legs can be originator-to-recipient or recipient-to-final-recipient.
The VSA tag
supp-svc-xfer-by contains the user@host portion of the SIP URL of the Referred-By header for transfers performed with the Refer message request. For transfers performed with the Bye/Also message request, the tag contains user@host portion of the SIP URL of the Requested-By header. For each call on the gateway, two RADIUS records are generated: start and stop. The
supp-svc-xfer-byVSA is generated only for stop records and is generated only on the recipient gateway--the gateway receiving the Refer or Bye/Also message.
The VSA is generated when a gateway that acts as a recipient receives a Refer or Bye/Also message with the Referred-By or Requested-By headers. There are usually two pairs of start and stop records. There is a start and stop record between the recipient and the originator and also between the recipient to final recipient. In the latter case, the VSA is generated between the recipient to the final recipient only.
Business Group Field
A new business group VSA field has been added that assists service providers with billing. The field allows service providers to add a proprietary header to call records. The VSA tag for business group ID is
cust-biz-grp-id and is generated only for stop records. It is generated when the gateway receives an initial INVITE with a vendor dial-plan header to be used in call records. In cases when the gateway acts as a recipient, the VSA is populated in the stop records between the recipient and originator and the final recipient.
 Note |
For information on VSAs, see the RADIUS VSA Voice Implementation Guide .
|