Call Transfer

Cisco CallManager and Cisco CME implement significantly different approaches to handling call transfer. These differences are related to the basic architectural differences that exist between a highly centralized (CallManager) and fully distributed (Cisco CME) VoIP network architecture.

In Cisco CME, the preferred mechanism for handling call transfer is H.450.2. This allows calls to be transferred in a highly optimized fashion not only between phones on the same Cisco CME system, but also between different Cisco CME systems. This is a significant attribute when you consider that Cisco CME-based VoIP networks can include hundreds or thousands of individual CME nodes. Each CME node is a distinct and separate H.323 device with autonomous call processing.

In Cisco CallManager, the call transfer mechanism is designed to allow calls to be transferred between hundreds or thousands of IP phones controlled by the same Cisco CallManager (or CallManager cluster). Furthermore, in a Cisco CallManager environment, there is a significant need to separate the H.323 control path from the H.323 media path. Because a single Cisco CallManager server can be required to control approximately 2500 IP phones, it's impossible for the server to play an active intermediary role in the media path for all phone calls. Consider that there's a media packet in each direction every 20 milliseconds (ms) for each call, and then multiply this by 2500 phones. To allow a Cisco CallManager to support this number of phones, the media path for phone-to-phone calls must be directly between the phones whenever possible.

Note that each Cisco CallManager (or CallManager cluster) represents a single H.323 device from the external VoIP network perspective regardless of how many IP phones it supports.

One other issue to examine when comparing Cisco CallManager to Cisco operation CME is that for enterprise telephone systems, the ratio between internal and external call counts is related to the overall size of the phone system. As the number of extensions attached to a phone system increases, so does the relative proportion of internal calls compared to external calls. For example, in a system with only ten phones, almost 100% of phone calls are external calls between a phone and the outside world. In a system with 1000 phones, the external calls may make up only about 10% of the total call volume.

You can view this call transfer difference between Cisco CallManager and Cisco CME as being equivalent to the difference between an internal intra-private branch exchange (PBX) call transfer and an inter-PBX transfer. Viewed from the legacy PBX perspective, you can see that these are fundamentally different problems.

H.323 Call Transfer Using an Empty Capabilities Set

The problem with call transfer becomes more complex when you consider the interaction of Cisco CallManager IP phones with an external H.323 network. When an H.323 call exists between an external H.323 device and a Cisco CallManager IP phone, the preferred arrangement is to have a direct media path between the endpoints that does not pass through the Cisco CallManager server. In some cases, a direct media path is not possible (as described in the section "Call Transfer and the Media Termination Point"). In this case, it is necessary to introduce a Media Termination Point (MTP) into the media path. The MTP acts as a media relay or middleman and relays the Real-Time Transport Protocol (RTP) voice packets between the two terminating endpoints. The call signaling path does pass through the Cisco CallManager server. The H.323 signaling is terminated on the Cisco CallManager server and then is converted into SCCP to talk to the IP phone. The Cisco CallManager is required to participate in this signaling path to provide the needed conversion between H.323 and SCCP.

When there is a call transfer for an H.323 call from one Cisco CallManager IP phone (phone A) to another (phone B), the H.323 signaling path does not change. It remains terminated on the Cisco CallManager server. The Cisco CallManager server establishes a new SCCP signaling path to phone B. Of course, the media path also has to change. Changing the media path on the IP phones is easy. The Cisco CallManager simply sends the appropriate SCCP messages to phone B, telling it to participate in the media connection to the external H.323 endpoint.

To change the media connection on the H.323 side, the Cisco CallManager uses a mechanism known as Empty Capabilities Set (ECS). This mechanism informs the external H.323 device that it should stop sending its media packets to phone A's IP address and should instead send the media packets to phone B's IP address. This mechanism allows the media stream to be redirected to the transfer-to destination phone while preserving the original H.323 control path connection. Figure 8-2 shows the media path before and after the transfer.

Figure 8-2. Cisco CallManager ECS Transfer

With this arrangement, there is no limit on the number of times the call can be transferred, as long as the call termination point remains within the set of phones controlled by CallManager. This is the behavior you would expect, considering how a legacy time-division multiplexing (TDM)-based PBX works. There's usually no limit on the number of internal chained transfers. Cisco CME (and Cisco IOS-based H.323 PSTN gateways in general) supports receipt of ECS signaling from Cisco CallManager but does not initiate ECS signaling for call transfer.

H.323-to-H.323 Call Transfer

Now consider what happens when the transfer-to destination is not an internal IP phone. In the case of an H.323 endpoint that calls an internal IP phone and then is transferred to a second external H.323 endpoint, the same ECS mechanism can be used. The transferred call has its H.323 signaling path relayed through the Cisco CallManager, but the media path is direct between the two external H.323 endpoints.

This process works fine except in the case where one of the H.323 endpoints wants to further transfer the call (or perform some other media-related operation, such as call hold with music on hold [MOH]). In general, chained H.323 ECS operations do not work well. This is because the attempt to chain-transfer the call results in a very indirect H.323 control path. None of the entities in the H.323 control path is directly connected to both of the call media final termination points. This means that the media path negotiations have to pass through two middlemen instead of one.

For example, for the first transfer, A calls B and is transferred to C. The transferor node B is in direct contact with both the A and C points and can help them negotiate a mutually acceptable media path. The H.323 control path is A-to-B-to-C, but the media path is A-to-C.

A problem arises when C wants to transfer the call to D. This would create an A-to-B-to-C-to-D H.323 control path. In this case, neither of the B or C middlemen is in direct contact with both of the A and D final endpoints. This can make successful media negotiation between A and D quite difficult to achieve in practice.

Call Transfer and the Media Termination Point

One way to solve the problem of end-to-end negotiation of the media path is to use an MTP that can provide transcoding services. One example of this type of MTP is the digital signal processor (DSP) farms that are supported on Cisco IOS voice-enabled routers. DSP farms are controlled by a Cisco CallManager (or Cisco CME) using the SCCP protocol. The term transcode means the ability to convert the media stream from one codec type to another. You may sometimes see this term abbreviated as xcode.

If you introduce a transcoding MTP into the media path, there is no need to perform end-to-end media path renegotiation for the chained call transfer case. The use of an MTP simplifies the problem of connecting or transferring a call through multiple H.323 endpoints, because it removes the need to perform a multiparty negotiation and capabilities adaptation between all the H.323 entities involved. Figure 8-3 shows the media path before and after the transfer.

Figure 8-3. Cisco CallManager Transfer with MTP

In general, the MTP approach simplifies the set of H.323 signaling operations required and increases the overall compatibility and the ability to interoperate. This is true even in cases where everyone uses the same codec type and actual transcoding of codecs is unnecessary.

The drawback to this approach is the impact on overall scalability, because an MTP channel is needed for every H.323 (external) call. A mitigating factor in this situation (as mentioned earlier, in the section "Call Transfer") is that as the number of IP phones in the Cisco CallManager cluster increases, the fraction of H.323 calls to internal calls decreases. In general, the expense of adding MTPs is worthwhile because of the reduction in H.323 interoperability issues.

Another issue with the chained transfer cases is that each leg in the transfer chain contributes additional delay to both the signaling and media path. If a call is chain-transferred too many times, the resulting delay and voice quality are likely to become unacceptable. In general, end-to-end one-way delays of more than 150 to 200 ms are unacceptable to phone users.

The chained-transfer issues apply only to intersite transfers that are chained across multiple separate H.323 nodes. Transfers within the internal scope of a single H.323 node do not suffer from this problem, because (with an MTP) the transfer is invisible to the other H.323 endpoints involved.

Connecting Cisco CallManager with Cisco CME

This section examines how what you've learned so far in this chapter relates to connecting a Cisco CallManager to a network of Cisco CME systems.

You learned in Chapter 7 that Cisco CME prefers to perform call transfers using H.450.2 but can perform VoIP-to-VoIP hairpin or tandem routing when needed. You also learned that a Cisco CME can automatically detect calls to or from a Cisco CallManager and can use this information to disable its normal H.450.2 behavior. The final piece of this puzzle is to understand that an H.323 call to a Cisco CME IP phone always passes through an MTP-like mechanism within Cisco CME. This arrangement allows the Cisco CME to optionally perform its internal transfers without using H.450.2 and without affecting the H.323 connection to Cisco CallManager.

In Cisco CME, the MTP is the Cisco CME router itself. However, you still need a separate MTP device on the Cisco CallManager side in case the Cisco CallManager phone itself invokes additional call transfer operations on the same call. Figure 8-4 shows Cisco CME connecting to a Cisco CallManager using MTP.

Figure 8-4. Cisco CallManager and Cisco CME Connected Using MTPs

The issue of MTP scalability largely doesn't apply to Cisco CME for two reasons. First, the RTP media stream voice packets have to pass through the Cisco CME router anyway. Even if Cisco CME did not deliberately invoke MTP treatment for the media stream packets, the packets would still need to be routed by the Cisco CME's IP routing function. In many cases, the router might also have to perform other operations on the media stream packets, such as firewall and Network Address Translation (NAT). As a result, no additional real-world penalty is incurred by the MTP treatment; it's more or less free.

Second, the number of IP phones that Cisco CME supports is relatively low compared to a Cisco CallManager. The number of phones supported by a Cisco CME router is scaled according to the overall performance of the specific Cisco IOS router model used. Many different router models are available with IP phone support, which ranges from 24 phones to about 240 phones. This topic is covered in Chapter 1, "Introducing Cisco IPC Express."

The only condition under which the Cisco CME's MTP treatment incurs an additional cost is when you actually need codec transcoding. Even in this case, the additional cost usually is not large, because you almost certainly already have DSP resources included in your Cisco CME router to support its PSTN ports. In many cases, you can meet the MTP transcoding requirement simply by adding DSP chips to your existing voice-port hardware. This is in contrast to the need to explicitly add an entire voice module solely for DSP farm transcoding purposes.

However, in many cases transcoding for call transfer is unneeded, because a Cisco CME has only a single WAN link carrying H.323 calls, and all the H.323 calls tend to use the same codec (either G.711 or G.729). Your Cisco CME may still need DSP farm transcoding services to support three-party conferencing for G.729 calls (see Chapter 7).

Intersite Call Transfer with Multiple CME Systems

The final call transfer scenario you should understand is what happens with a call placed from a Cisco CallManager to a Cisco CME system that is then transferred to a second Cisco CME system (see Figure 8-5). In this case, the first Cisco CME detects that the call is from a Cisco CallManager. As a result, it invokes VoIP-to-VoIP tandem or hairpin routing to provide the call path (see Chapter 7 for details).

Figure 8-5. Intersite Call Transfer for a Cisco CallManager with Multiple Cisco CME Systems

Call Forwarding