Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

In a VoIP network, getting an optimized system working for call transfer and forwarding requires the active cooperation of all endpoints involved in a call transfer or call forward. This means your ability to perform a call transfer or forward depends on the capabilities of the calling party’s VoIP system as well as your Cisco Unified CME system configuration. A call transfer also depends on the capabilities of the final VoIP system that you are transferring the call to.

Let’s get to familiar with the terms first:

Call Forwarding

Call forwarding allows you to send all your incoming calls to another landline or cell phone number. Call forwarding overrides the ability to answer the phone forwarded from the original line. This service requires a subscription through your phone service provider and may incur an additional monthly fee.

Call forwarding in SIP trunk

When a call comes in on a SIP trunk and gets forwarded (CFNA / CFB / CFA), then the default behavior is for the CME to send the 302 “Moved Temporarily” SIP message to the Service Provider (SP) proxy. The user portion of the Contact Header in the 302 message might need to be translated to reflect a DID that the SP proxy can route to. Or else, the calling user will get a busy tune or other unexpected error, such as being treated as an international call and getting blocked.

One of following method should be used:

1)  The host portion of the Contact Header in the 302 message should be modified to reflect the Address of Record (AOR) :

Router(config-sip-ua)#host-registrar

And:

!--- Voicemail Configuration ---

dial-peer voice 10 voip
 description **CUE Voicemail**
 translation-profile outgoing PSTN_CallForwarding
 destination-pattern 600
 b2bua

!--- Used by CME to send its IP address to SP proxy instead of CUE

 session protocol sipv2
 session target ipv4:172.22.1.155
 dtmf-relay sip-notify

!--- This can also be RFC2833 going to CUE

 codec g711ulaw

!--- CUE only supports G711ulaw as the codec

 no vad

!--- With VAD enabled, messages left on CUE could be blank or poor quality

 host-registrar CLI under sip-ua and the b2bua CLI under the VoIP dial peer going to the CUE.

2 ) Some SIP proxies might not support this. If so, then you need to add this:

Router(config)#voice service voip
Router(conf-voi-serv)#no supplementary-service sip moved-temporarily
Call Transfer

Call transfer allows you to send a call from one phone to another telephone without the need to disconnect the phone call. This feature is usually activated by the push of a button followed by dialing an extensión.

Types of call transfer:

In the Call Center space, the following type of call transfers can be undertaken and take on a slightly different meaning:

Warm transfer: (also known as a live or hot transfer) the call center operator dials a number and talks to the person who has picked up the call before transferring the caller over to them. This could also be a three-way conference before the call center operator drops-off.One common example of a warm transfer is when a receptionist or virtual receptionist takes a call for the business and notifies the party attempting to be reached who the person is and the nature of their call.

Tepid transfer: This involves the call center operator dialing a number and transferring the caller on to the called number without conferencing or speaking to the third party. Tepid transfer usually applies when a transfer is being made to a number where queue management has been implemented in some capacity (multiple lines or hunt groups, IVR, voicemail, callback facility etc)

Cold transfer: This transfer is in reality not a transfer, but a pass-on of information for the caller to call a particular number after they hang up the current call. However, in certain instances a cold transfer may be implemented by calling the desired number on behalf of the caller, the original call handler/operator then drops-off without waiting for the called number to be picked up, whether or not the dialed number had queue management implemented or not.

With Cisco Unified CME, you have three basic choices for the protocol used to support call transfer and forwarding for H.323 VoIP calls:

Standards-based H.450Recommended because it provides for optimal call paths and unlimited sequential transfers and forwards.
Cisco H.323 extension—Mostly obsolete, but useful if you are using software older than Cisco IOS Release 12.2(15)T.
Hairpin call routing—Allows for maximum compatibility, but uses more WAN bandwidth and results in higher delay and jitter.

The default H.323 call transfer protocol used by Cisco Unified CME is the Cisco mechanism. This mechanism supports only blind call transfer (that is, no transfer consultation). It is selected as the default simply for purposes of backward compatibility with earlier Cisco IOS releases.

The default call forwarding mechanism provides for automatic local forwarding only (that is, within the same Cisco Unified CME system). It does not provide forwarding display update notification of the call
forwarding to the calling party’s IP phone. For incoming VoIP calls from another Cisco Unified CME system that are nonlocally forwarded to a third Cisco Unified CME system, the Cisco-proprietary H.323 protocol extensions are used.

Even if you do not require H.323 VoIP call transfers (because you do not need to make calls across an IP connection to another site), you should still select the H.450 configuration method for call transfers. This enables call transfer with consultation for local calls within your system and for PSTN calls that use PSTN voice ports that are physically on your Cisco Unified CME router. (PSTN voice ports on a router other than the Cisco Unified CME system appear as H.323 VoIP calls to the Cisco Unified CME system.) It also prepares your system to use the standards-based H.450 protocol in case you want to add support for H.323 or SIP VoIP transfer and forwarding to another site at some point in the future.

 

 

Call Transfer Methods for VoIP

This section describes several methods for implementing call transfer across VoIP networks:

 

H.450 and SIP

The ITU-T standards-based H.450.2 transfer method and the Cisco method operate in a similar way. In both cases, when a call transfer occurs, a control message is sent back to the transferee party to request that the transferee initiates a follow-on call from the transferee to the final transfer-to destination. In the H.450.2 case, the follow-on call originated by the transferee can act to replace the transfer consultation call that is in progress between the transferor and the transfer-to destination party. The consultation call between transferor and transfer-to and the original transferee-transferor call are not torn down until the “replaces” operation is completed successfully. The term replaces is used here in the context of “Call 2 replaces call 1.” If for any reason the replacement operation fails, it is usually possible for the transferor to reconnect the call to the transferee. The H.450.2 mechanism works in a manner similar to the REFER method used for SIP VoIP calls. The Cisco transfer mechanism does not support the call replacement mechanism and, therefore, allows you to perform only blind call transfers. This proprietary method is similar to the older BYE/ALSO method that was used to perform blind transfers for SIP VoIP calls. The BYE/ALSO method has been mostly superseded by the SIP REFER method.

Both of these H.323 call transfer methods result in an optimal direct call path between the transferee and the transfer-to party after the call transfer is committed.

Hairpin Routing

 

The third alternative is to hairpin route the VoIP call transfer. In this case, the original transferee-to-transferor VoIP call leg is kept, and a second transferor to transfer-to VoIP call leg is created for the consultation call phase of the transfer. When the transfer is committed, the original and consultation call legs are simply bridged together at the Cisco Unified CME router. This method has the advantage that it has no end-to-end dependency on the capabilities of the transferee or transfer-to VoIP endpoint.

It also has disadvantages. One significant disadvantage is that the final transferred call is relayed through the transferor’s Cisco Unified CME system. This means that the transferred call continues to consume resources on the transferor Cisco Unified CME system even after the transfer is committed. It also means that the media path for voice packets for the transferred call may hairpin route through the transferor’s Cisco Unified CME system, so both the original call and the transferred call continue to consume WAN bandwidth. If the amount of WAN bandwidth is limited, this may prevent new VoIP calls from being established until the transferred call is terminated. The other significant disadvantage of hairpin routing calls is the cumulative bandwidth, delay, and jitter problems that occur if a call is transferred multiple times (chained or sequential transfers).

H.450.12

You can compromise between the H.450.2 and hairpin routing call methods by turning on the H.450.12 protocol on your Cisco Unified CME system (this is recommended). You must be using at least Cisco Unified CME 3.1 to use H.450.12. With H.450.12 enabled, your Cisco Unified CME system can use the H.450.12 protocol to automatically discover the H.450.x capabilities of VoIP endpoints within your VoIP network. When H.450.12 is enabled, the Cisco Unified CME system can automatically detect when an H.450.2 transfer is possible. When it isn’t possible, the Cisco Unified CME system can fall back to using VoIP hairpin routing. Cisco Unified CME also can automatically detect a call from a (non-H.450-capable) Cisco Unified CallManager.

Empty Capabilities Set

For the sake of completeness, it is worth mentioning a fourth alternative for call transfers: Empty Capabilities Set (ECS). Cisco Unified CME does not support the instigation of transfer using ECS. But because a Cisco Unified CME router also has the full capabilities of the Cisco IOS Release H.323 voice infrastructure software, it can process receipt of an ECS request coming from a far-end VoIP device. In other words, a Cisco Unified CME system can be a transferee or transfer-to party in an ECS-based transfer. A Cisco Unified CME system does not originate a transfer request using ECS. The problem with ECS-based transfers is that in many ways they represent a combination of the worst aspects of the end-to-end dependencies of H.450.2 together with the cumulative problems of hairpin for multiple transfers. Many ECS-based transfer implementations do not allow you to transfer a call that has already been transferred in the general case of VoIP intersystem transfers.

Cisco Unified CME VoIP Call Transfer Options

Your Cisco Unified CME system by default is set up to allow local transfers between IP phones only. It uses the Cisco H.323 call transfer extensions to transfer calls that include an H.323 VoIP participant.

  • To configure your Cisco Unified CME system to use H.450.2 transfers (this is recommended), set transfer-system full-consult under the telephony-service command mode. You also have to use this configuration for SIP VoIP transfers.
  • To configure your Cisco Unified CME system to permit transfers to nonlocal destinations (VoIP or PSTN), set the transfer-pattern command under telephony-service. The transfer-pattern command also allows you to specify that specific transfer-to destinations should receive only blind transfers. You also have to use this configuration for SIP VoIP transfers. The transfer-pattern command allows you to restrict trunk-to-trunk transfers to prevent incoming PSTN calls from being transferred back out to the PSTN (employee toll fraud). Trunk-to-trunk transfers are disabled by default, because the default is to allow only local extension-to-extension transfers.
  • To allow the H.450.12 service to automatically detect the H.450.2 capabilities of endpoints in your H.323 VoIP network, use the supplementary-services command in voice service voip command mode.
  • To enable hairpin routing of VoIP calls that cannot be transferred (or forwarded) using H.450, use the allow-connections command. The following example shows a call transfer configuration using this command.
voice service voip
 supplementary-service h450.12
 allow-connections h323 to h323
telephony-service
 transfer-system full-consult
 transfer-pattern .T
  • The configuration shown in the preceding example turns on the H.450.2 (transfer-system full-consult) and H.450.12 services.
  • allows VoIP-to-VoIP hairpin call routing (allow-connections) for calls that don’t support H.450, and permits transfers to all possible destinations (transfer-pattern).
  • The transfer permission is set to .T to provide full wildcard matching for any number of digits. (The T stands for terminating the transfer destination digit entry with a timeout.)

The following example shows a configuration for more restrictive transfer permissions.

telephony-service
 transfer-system full-consult
 transfer-pattern 1...
 transfer-pattern 2... blind

This example permits transfers using full consultation to nonlocal extensions in the range 1000 to 1999. It also permits blind transfers to nonlocal extensions in the range 2000 to 2999.