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:
– 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.
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.
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.