SIP—SIP Stack Portability
Available Languages
Table Of Contents
Information About SIP—SIP Stack Portability
Feature Information for SIP—SIP Stack Portability
SIP—SIP Stack Portability
Implements capabilities to the SIP gateway Cisco IOS stack involving user-agent handling of messages, handling of unsolicited messages, support for outbound delayed media, and SIP headers and content in requests and responses.
Prerequisites
Cisco Unified Border Element
•
Cisco IOS Release 12.4(2)T or a later release must be installed and running on your Cisco Unified Border Element.
Cisco Unified Border Element (Enterprise)
•
Information About SIP—SIP Stack Portability
The SIP Stack Portability feature implements the following capabilities to the Cisco IOS SIP gateway stack:
•
•
•
•
It sends an INVITE message request without Session Description Protocol (SDP) and provides SDP information in either the PRACK or ACK message request for both initial call establishment and mid-call re-INVITE message requests.
•
The stack applies certain rules and restrictions for a subset of headers and for some content types (such as SDP) to protect the integrity of the stack's functionality and to maintain backward compatibility. When receiving SIP message requests, it reads the SIP header and any attached body without any restrictions.
To make the best use of SIP call-transfer features, you should understand the following concepts:
SIP Call-Transfer Basics
This section contains the following information:
•
•
Basic Terminology of SIP Call Transfer
Call transfer allows a wide variety of decentralized multiparty call operations. These decentralized call operations form the basis for third-party call control, and thus are important features for 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.
Refer Message Request
The SIP Refer message request provides call-transfer capabilities to supplement the SIP BYE and ALSO message requests already implemented on Cisco IOS SIP gateways. The Refer message request has three main roles:
•
•
•
Note
The Refer message request 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 contacted or not. The notification is accomplished using the SIP NOTIFY message request, SIP's event notification mechanism. A NOTIFY message with a message body of SIP 200 OK indicates a successful transfer, and a message 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.
Figure 1 represents the call flow of a successful Refer transaction initiated within the context of an existing call.
Figure 1 Successful Refer transaction
Refer-To Header
The recipient receives from the originator a Refer request that always contains a single Refer-To header. The Refer-To header includes a SIP URL that indicates the party to be invited and must be in SIP URL format.
Note
The Refer-To header may contain three additional overloaded headers to form the triggered INVITE request. If any of these three headers are present, they are included in the triggered INVITE request. The three headers are:
•
•
•
All other headers present in the Refer-To are ignored, and are not sent in the triggered INVITE.
Note
Referred-By Header
The Referred-By header is required in a Refer request. It identifies the originator and may also contain a signature (included for security purposes). SIP gateways echo the contents of the Referred-By header in the triggered INVITE request, but on receiving an INVITE request with this header, gateways do not act on it.
Note
NOTIFY Message Request
Once 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 contacted or not. The notification is accomplished using the NOTIFY message request, 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.
The NOTIFY message must do the following:
•
•
•
Two Cisco IOS commands pertain to the NOTIFY message request:
•
•
Note
Types of SIP Call Transfer Using the Refer Message Request
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:
•
•
•
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 "Refer Message Request" section. The process is as follows:
1.
a.
b.
2.
a.
b.
c.
3.
4.
•
•
Figure 2 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
Figure 3 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:
1.
2.
3.
4.
5.
a.
b.
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:
1.
a.
b.
c.
d.
2.
a.
b.
3.
4.
5.
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
Figure 5 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 Figure 6):
1.
a.
b.
c.
d.
2.
a.
b.
3.
4.
Note
5.
6.
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-by helps 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-by VSA 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
Feature Information for SIP—SIP Stack Portability
Feature History Table for the ASR
Feature History Table for the ISR
Command Reference
•
Feedback