SIP Call Transfer

Cisco Unified Border Element (SP Edition) 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 Cisco Unified Border Element (SP Edition) 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 Cisco IOS XE Release 2.4, this feature is supported in the unified model only.

Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).

For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:

http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html.

For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.

Feature History for SIP Call Transfer

 

Release
Modification

Cisco IOS XE Release 2.4

This feature was introduced on the Cisco IOS XR along with support for the unified model.

Contents

This module contains the following sections:

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.

Cisco Unified Border Element (SP Edition) 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 Cisco Unified Border Element (SP Edition) 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.

Cisco Unified Border Element (SP Edition) 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 Cisco Unified Border Element (SP Edition). Cisco Unified Border Element (SP Edition) 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 Cisco Unified Border Element (SP Edition). 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.