Table Of Contents

SIP Call Transfer

Contents

Restrictions for SIP Call Transfer Support

Information About SIP Call Transfer

REFER Requests

NOTIFY Messages

Replaces Headers

SIP Call Transfer

---

The Session Border Controller (SBC) supports Session Initiation Protocol (SIP) call transfer, a standard Internet telephony service. Call transfer allows a wide variety of decentralized multiparty call operations. These decentralized call operations form the basis for third-party call control, and are important features for voice over IP (VoIP) and SIP. Call transfer is also critical for conference calling, where calls can transition smoothly between multiple point-to-point links and IP level multicasting. The SBC SIP call transfer feature includes basic in-dialog transfer and advanced call transfer for the following network topologies:

•Central SBC

•Transfer intra network

•Transfer out of network

•Transfer to colleague

---

Note For ACE SBC Release 3.0.00, this feature is supported in the unified model only.

---

Feature History for SIP Call Transfer

Release	Modification
ACE SBC Release 3.0.00	This feature was introduced on the Cisco 7600 series router along with support for the SBC unified model.

Contents

This module contains the following sections:

•Restrictions for SIP Call Transfer Support

•Information About SIP Call Transfer

Restrictions for SIP Call Transfer Support

The following is a list of restrictions for SIP call transfer support:

•The Configuration feature is expected to be "always on." Therefore, no configuration is required and it is not possible to disable it.

•REFER subscription state is not maintained over failover. Therefore, after a failover, any subsequent NOTIFYs telling the one referring about the progress of the referral are lost. They are bounced back with a 481 SIP error response. This will not prevent calls from being transferred, but may result in a few error logs if diagnostics are enabled.

Information About SIP Call Transfer

REFER Requests

The REFER method has 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.

The REFER method always begins within the context of an existing call and starts with the originator. The originator sends a REFER request to the recipient (user agent receiving the REFER request) to initiate a triggered INVITE request. The triggered INVITE request uses the SIP URL contained in the Refer-To header as the destination of the INVITE request.

The recipient then contacts the resource in the Refer-To header (final-recipient), and returns a SIP 202 (Accepted) response to the originator. The recipient also must notify the originator of the outcome of the REFER transaction—whether the final-recipient was successfully or unsuccessfully contacted. The notification is accomplished using the Notify Method, SIP's event notification mechanism.

A Notify message with a message body of SIP 200 OK indicates a successful transfer, while a body of SIP 503 Service Unavailable indicates an unsuccessful transfer. If the call was successful, a call between the recipient and the final-recipient results.

SBC accepts and passes through in-dialog REFER requests. Standard SIP headers are manipulated as normal. The call-transfer specific headers are treated in the following way:

•The Refer-To header is passed through unchanged

•The Referred-By header:

–Any received Referred-By header is passed through ignored.

–On the outbound REFER, the following header is written:

Referred-By: <sip:endpoint_dn@sbc_adj_sip_domain_name>

except that,

–If the side of the call on which SBC received the REFER has privacy enabled (configured in CAC), then no Referred-By header is written on the outbound REFER

•The Replaces header is treated in the same way as for the INVITE requests

Out-of-dialog REFER requests are rejected. The Target-Dialog header is not explicitly supported, and therefore is stripped or passed through, subject to header and method white/blacklisting configuration.

NOTIFY Messages

When the outcome of the REFER transaction is known, the recipient of the REFER request must notify the originator of the outcome of the REFER transaction—whether the final-recipient was successfully or unsuccessfully contacted. The notification is accomplished using the NOTIFY method, SIP's event notification mechanism. The notification contains a message body with a SIP response status line and the response class in the status line indicates the success or failure of the REFER transaction.

SBC accepts and passes through in-dialog NOTIFY requests. Standard SIP headers are manipulated as normal.

•If the NOTIFY contains a body of type message/sipfrag, and if the start of this body can be correctly parsed as a SIP response status line, then the outbound NOTIFY is given a message/sipfrag body containing a SIP response status line with the same response code (and nothing else).

•If there is no body of type message/sipfrag on the NOTIFY, or the first line of the NOTIFY body cannot be correctly parsed as a status line, then the onbound NOTIFY is sent without a body. This includes the case where there is a message/sipfrag body included as part of a mime/multipart body.

Replaces Headers

The processing of Replaces headers is the key logic involved in supporting call transfer across SBC. SBC does a lookup on the call IDs and tags in the received Replaces header. If it finds the corresponding call branch (for example, C1), then it looks up the partner call branch (for example, C2). C1 and C2 together make up another call through SBC. The Replaces header sent out on the request which is forwarded on might refer to call branch C1 or C2, depending on the request type and other considerations. Any "early-only" flag on the Replaces header is passed through.