Call Transfer and Call Forwarding in an H.323 Network Using H.450 Services

The ITU-T H.450 services are a set of standard supplementary services defined for H.323 VoIP networks. H.450 provides services above and beyond basic A to B telephone calls. Cisco CME 3.0 offers only the services related to call transfer (H.450.2) and call forwarding (H.450.3). Cisco CME 3.1 also introduced support for the H.450.12 capabilities discovery protocol to ease interworking issues with non-Cisco CME H.323 systems.

Here's a full list of the H.450.x services, including the date when they became formal ratified ITU-T standards:

• H.450.1 (2/1998)A generic functional protocol that supports supplementary services in H.323 (supported by Cisco CME)
• H.450.2 (2/1998)A call transfer supplementary service for H.323
• H.450.3 (2/1998)A call diversion supplementary service for H.323 (supported by

  Cisco CME)

• H.450.4 (5/1999)A call hold supplementary service for H.323
• H.450.5 (5/1999)A call park and call pickup supplementary service for H.323
• H.450.6 (5/1999)A call waiting supplementary service for H.323
• H.450.7 (5/1999)An MWI supplementary service for H.323
• H.450.8 (2/2000)A name identification service
• H.450.9 (11/2000)A call completion supplementary service for H.323 (includes callback for a busy subscriber)
• H.450.10 (3/2001)A call offering supplementary service for H.323 (includes camp-on busy subscriber)
• H.450.11 (3/2001)A call intrusion supplementary service for H.323
• H.450.12 (7/2001)A common information additional network feature for H.323 (for H.450.x capabilities discovery, supported by Cisco CME 3.1 and later)

An important thing to note about the dates these standards became available is that many H.323 networks were brought into service before these standards were issued. This means that support of these standards within H.323 networks varies widely, which causes some challenges in deploying these services within multivendor H.323 networks. Even within the overall Cisco voice product line, support of these services is not yet widespread.

H.450.2 and H.450.3 services are present and enabled by default in Cisco IOS 12.3(4)T and later (for voice-enabled images). This allows an IOS voice gateway (without CME configuration) to be used as a VoIP-to-PSTN gateway and to automatically support the forwarded party, transferee, and transfer-to roles when using the standard default voice session application.

The earlier Cisco IOS 12.2(15)T and later software releases can also support H.450.2 and H.450.3 provided that they are configured to use a special Toolkit Command Language (TCL) script (called app_h450_transfer.tcl and available on Cisco.com) in place of the default voice session application.

H.450.12 services are available in Cisco IOS 12.3(7)T. They need to be explicitly enabled using the supplementary-service command.

The next sections describe H.450.2 call transfer, H.450.3 call forward, and H.450.12 supplementary services in more detail, including proxying of these services. It also introduces digital signal processor (DSP) farm services that are needed to support some modes of call transfer and call forwarding.

H.450.2 Call Transfer

For call transfer with consultation, the basic operation of the telephone user interface is expected to look like this:

1.	The inbound call to the phone is answered. The parties talk.
2.	The phone user (transferor) presses the transfer key, gets dial tone, and enters the transfer-to destination. The calling party (transferee) is placed on hold and may hear the music on hold audio feed.
3.	The transferor hears the transfer-to phone start to ring.
4.	The phone at the transfer-to destination is answered, and a consultation call takes place between the transfer-to and the transferor.
5.	The transferor presses the transfer key a second time (or simply hangs up) to execute the transfer.
6.	The original caller (the transferee) is connected to the transfer-to party.

The H.450.2 protocol is designed to allow this operation to take place where the transferee, transferor, and transfer-to parties are all associated with different H.323 endpoints, regardless of physical location. This means (for example) that a transferee party originating a call in Paris can place a call to a transferor in Los Angeles and get transferred to a transfer-to destination in London. In a VoIP network that fully supports H.450.2, the resulting post-transfer call between Paris and London is a direct call and does not have to be relayed via the transferor (in Los Angeles). This is an especially important consideration when you consider the network design implications from a voice quality, delay, and scalability point of view. It's an even more important consideration for cases in which a call might need to be transferred multiple times before it reaches its final destination.

Multiple transfer is one area in which VoIP-based networks have considerable superiority over traditional legacy-based TDM networksif they are implemented to take full advantage of the H.450.2 service.

There are other ways of invoking a call transfer that don't follow the usual user interface steps. One particular example is a three-party conference call where A calls B, B calls C, and then B joins the AB and BC calls together as a conference. If the B party conference initiator wants to drop out of the conference and leave the A and C parties connected to each other, this can be implemented as a call transfer where B invokes a transfer of A to C.

The following detailed protocol transactions allow the transfer to take place (see Figure 7-4):

1.	The original incoming call is just an ordinary "A calls B" H.323 call between two parties. Of course, the original call doesn't even have to be an incoming call. For example, it could be an outgoing call placed by an assistant on behalf of an executive who is transferred to the executive as soon as the call is successfully connected.
1.	The transferring party presses the transfer key. This puts the original call on hold. A second line or call instance is acquired on the transferor's phone, and dial tone is obtained. The transferor dials the phone number of the transfer-to destination using the second line or call instance. This consultation call is also a simple "B calls C" H.323 call between two parties. To the external H.323 network, the AB and BC calls are seen as unrelated at this point. At this stage in the process, there is no guarantee that a transfer will actually take place. The BC call can return a busy indication, and the B (transferor) party can elect to try a different transfer-to destination, D. The BC call may connect, and a consultation call may take place in which C declines to talk to A. The BC call can terminate at that point, and the transferor B party may then resume the AB call. Alternatively, B can place another consultation call BD.
2.	The transferor B decides to commit the transfer either by pressing the transfer button a second time or by hanging up. At this point, a complex sequence of actions takes place in an attempt to transfer the call. First, the transferor B puts the BC call into a hold state and then sends an H.450.2 message to the transfer-to destination C. This informs C that a transfer will take place and requests that C issue a unique consultation ID to B. This consultation ID is used to identify the call that is being transferred.
3.	When B receives the consultation ID from C, it sends an H.450.2 transfer request to A containing the consultation ID. This message includes the phone number for C.
4.	When the A party (the transferee) receives the transfer request, it places a direct H.323 call to C using the phone number provided by B. This call includes the consultation ID that was generated by C and passed via B (the transferor). The transfer-to destination receives the AC call from A. At this point the BC consultation call is still active. The transfer-to C destination uses the consultation ID from the AC call to match the BC call. Because the BC and AC calls have the same consultation ID, the transfer-to C party can tell that the AC call is intended to replace the BC call.
5.	As soon as the transfer-to C has matched up the AC and BC calls using the consultation ID, C disconnects the BC call. When the transferee A gets a successful call response from C so that the AC call enters the connected state, the transferee A disconnects the AB call. The transferor B party gets a disconnect indication for both the AB and BC calls and drops out of the transferred call.

Figure 7-4. H.450.2 Call Transfer Protocol

A couple of minor variations on this flow are worth mentioning. The transferor phone user at B can choose to commit the transfer before the BC consultation call is answered, while the BC call is still in the alerting (ringing) state. The B to C consultation ID request can take place regardless of whether the BC consultation call is in the connected or alerting (ringing) state.

The transferor phone B can be configured to invoke a transfer to C without first placing a consultation call. In this case, the B to A call transfer request carries a zero consultation ID. This type of transfer has the disadvantage that B has no guarantee that the AC transferred call will succeed. It has the advantage that it does not require the transfer-to C destination to support the H.450.2 protocol and the associated BC-to-AC call replacement operation. This type of blind transfer is useful when the transfer-to destination is some type of automatic voice system, such as a voice mail device or a call queuing service.

So, as you can see, you can invoke three types of transfers using the H.450.2 call transfer protocol:

• Transfer with consultation with the transfer committed when the BC call is in the connected state. Cisco CME calls this type full consult with transfer at connected.
• Transfer with consultation with the transfer committed when the BC call is in the alerting (ringing) state. CME calls this type full consult with transfer at alerting.
• A blind transfer that does not involve a consultation call. Cisco CME calls this type a full-blind transfer.

Cisco CME lets you mix and match the full-consult and full-blind transfer types at several levels:

• Configure a global default using the transfer-system command (under telephony-service) and select either transfer-system full-consult or transfer-system full-blind.
• Override the global transfer system selection for each IP phone line (ephone-dn) using the transfer-mode command. You can select either transfer-mode consult or transfer-mode blind. For example, you might choose to have a receptionist phone that deals with a high volume of calls always perform blind transfers.
• Use the transfer-pattern command to force selection of the blind transfer mode for specific transfer-to destination numbers. The transfer-pattern command is also used to set up transfer permissions for nonlocal transfer-to destinations. This is useful if you need to prohibit trunk-to-trunk transfers and prevent toll fraud.

Now that you understand the process for H.450.2 call transfer, the next section discusses H.450.3 call forwarding.

H.450.3 Call Forwarding

For call forwarding, similar considerations as with call transfer apply:

1.	An inbound call is placed to an IP phone.
2.	The IP phone is busy, does not answer, or is configured for unconditional call forwarding (call forward all).
3.	The IP phone forwards the call to an alternate destination.
4.	The original calling phone may optionally receive a display update to show that the call has been forwarded. This can be an important issue if billing or cost differences depend on the location of the final destination.
5.	The IP phone at the alternate destination answers the call or may forward it to another destination. The IP phone that receives the forwarded call receives information that lets it know that the call was forwarded. This may include information about the original called number.

The H.450.3 protocol is designed to allow this operation to take place where the original calling party, forwarding phone, and forward-to party are all associated with different H.323 endpoints, regardless of physical location.

This means, for example, that a calling party originating a call in Paris can place a call to an IP phone in Los Angeles and get forwarded to a destination in London. In a VoIP network that fully supports H.450.3, the resulting forwarded call between Paris and London is a direct call and does not have to be relayed via the forwarder (in Los Angeles).

The H.450.3 forwarding protocol details are quite a bit simpler than the H.450.2 transfer case. When call forwarding takes place on an A to B call, the forwarding party B simply sends an H.450.3 message back to the calling A party to request that A call C (the forward-to destination). Generally, there is no requirement that the C party be aware of the H.450.3 protocol message exchange between A and B. If the A party accepts the call forwarding request, the A party disconnects the original AB call, as shown in Figure 7-5.

Figure 7-5. H.450.3 Call Forwarding Protocol

You activate the H.450.3 service using the call-forward pattern command. This is designed to let you selectively invoke the end-to-end H.450.3 style of call forwarding based on matching the calling party phone number. To invoke H.450.3 for all possible calling party numbers, you configure call-forward pattern .T, where the .T pattern parameter provides a wildcard match of any length.

If you do not configure the H.450.3 service, by default you are restricted to forwarding incoming VoIP calls only within the scope of the local Cisco CME system. The local scope includes forwarding to other local IP phones or to voice ports physically connected to the router (including PSTN access).

Caution

If you permit call forwarding of incoming PSTN calls into outgoing PSTN calls where your PSTN interface uses simple analog Foreign Exchange Office (FXO) ports, you may have a problem with disconnect supervision. In many cases, your PSTN provider will not have enabled call disconnect signaling on the PSTN subscriber lines connected to your FXO ports. For the case of a PSTN FXO-to-FXO hairpin call path, this can result in hung voice ports, because there is no signaling of disconnect when the remote PSTN parties hang up. If you encounter this problem, you need to contact your PSTN service provider and have it enable disconnect supervision on your PSTN phone lines. Note that for most PSTN hairpin call paths, the caller ID of the original caller is replaced by the caller ID of the outgoing PSTN interface.

 

H.450.12 Supplementary Services Capabilities

As you've seen, the H.450.2 and H.450.3 protocols can give you a significant degree of flexibility in distributing and moving H.323 calls in your VoIP network irrespective of geographic location considerations. At the same time, this can present a challenge when you attempt to deploy these services into an existing H.323-based network where support of H.450.x is not widespread.

To help you operate H.450.2 and H.450.3 services in a mixed-capability network, the CME 3.1 release introduced support of H.450.12. The formal name for this service is Common Information Additional Network Feature for H.323. Basically, this means that H.450.12 provides an H.450.x service capabilities exchange between H.323 endpoints.

The H.450.12 protocol allows Cisco CME to detect the H.450.x service capabilities that are available on a call-by-call basis. This allows the Cisco CME system to safely invoke H.450.2 transfer and H.450.3 forwarding without risk of dropping calls, because one or more of the remote endpoints involved in the call does not support H.450.

If Cisco CME detects that H.450.2 or H.450.3 is not supported for the call, you can configure CME to support the transfer or forwarding by locally bridging together the call legs to form VoIP-to-VoIP hairpin or tandem call paths. The term hairpin is used because the call path doubles back on itself in a U shape that resembles a hairpin. You may sometimes see this type of call path called tromboning, because a trombone has a similar U shape.

In the case of a call transfer, this means that the AB original call and the B C consultation calls are retained and then simply bridged together to create a hairpin or tandem call A to B to C. In the case of a call forward, the call path for A calls B and B forwards to C also becomes A to B to C.

The Cisco CME 3.1 code has the restriction that to successfully hairpin or tandem VoIP calls, the call legs for the A B and B C segments must have compatible properties. This primarily means that the A B and A C call legs must both use the same voice compression codec (either G.729 or G.711). This restriction does not apply in the special case that either A and B or B and C are phones or voice ports connected to the same Cisco CME system.

Cisco CME 3.2 allows you to overcome this single-codec restriction, because it supports SCCP-based digital signal processor (DSP) farms that can be used to provide transcoding of voice packets between the bridged call legs. The DSP farm transcoding service supports conversion of G.711 voice packets to G.729 as needed (as you'll learn in the next section).

With the VoIP-to-VoIP tandem call routing approach, you lose the final call path optimization that you would get if H.450.x were fully supported. Costs associated with this nonoptimal call routing include extra bandwidth used and additional end-to-end delay in the voice path.

DSP Resources for Transcoding

DSP resources is a group of one or more DSPs that are not directly associated with any physical interfaces (such as PSTN voice ports). Instead, the DSPs are available as a pool of signal processing resources that can be used to provide additional processing services for telephony calls. The primary applications that require DSP resource services are transcoding for VoIP hairpin calls and transcoding for G.729 three-party conferencing. Support for DSP resources for transcoding is available in Cisco CME 3.2 and later releases.

The term transcoding describes the operation of converting a telephone call that is encoded (compressed) using one type of voice coder-decoder (codec) into another. Specifically, transcoding is used to convert voice packets between the G.711 (64 Kbps) and G.729 (8 Kbps) compression formats.

Note

Cisco CME supports the use of DSP resources for only transcoding services. It does not support DSP resources for conferencing services, even though it does use DSP resources to support three-party conferencing for G.729 VoIP calls. The Cisco CME three-party conferencing service uses software-based audio mixing of G.711 audio streams. When Cisco CME needs to conference three-party G.729 calls, it uses the DSP transcoding service to convert the G.729 audio into G.711 and then applies the G.711 software-based audio mixing to the transcoded G.711 audio. DSP resources require separate physical DSPs for the transcoding-versus-conferencing service. It is generally more cost-effective to support G.729 three-party conferencing via a transcode-plus-software-mixer approach rather than dedicating whole DSPs to support just the conferencing service.

Although the DSPs in a resource pool are not directly associated with physical voice ports, they are hardware devices. If you need DSP resource services, you have to consider how and where you can attach these to your Cisco CME system.

The DSP resource systems that Cisco CME supports are the same as those used by Cisco CallManager. So this is one more place where Cisco provides investment protection in case you ever need to redeploy hardware originally purchased for Cisco CME into Cisco CallManager environments (or vice versa).

You can attach DSPs to Cisco CME systems in a number of ways. The simplest way is to insert DSP modules into the DSP sockets on the motherboards of some of the newer routers, such as the Cisco 2800 and 3800 series Integrated Services Routers (ISRs).

For Cisco routers that do not have motherboard DSP sockets, you can usually overprovision extra DSPs into voice network modules (NM) such as the NM-HDV and NM-HDV2 that are used to provide PSTN interfaces. The extra DSPs in these modules that aren't needed to support the PSTN interface connections can be configured as DSP resource pools.

The DSP resources do not even have to be in the same physical router as Cisco CME. The DSP resources are operated and controlled using the SCCP protocol over TCP/IP. This means that you can use a spare NM slot in a second router (that supports DSP resources) and have it controlled by a Cisco CME in a separate router. In practice, the Cisco CME and DSP resource routers do need to be connected locally over Ethernet or some other high-bandwidth interface.

Because the DSP resources are operated using the SCCP protocol, this means that, just as with the SCCP IP phones, the SCCP DSP resources can be used in support of either H.323 or SIP networks.

The configuration steps for DSP resources are too detailed to include in this book. However, they are covered in detail in the Cisco CME 3.2 System Administrator guide. Look for the command dspfarm for configuring the actual DSP resources and the command sdspfarm for configuring the Cisco CME to manage the DSP resources.

Configuring H.450.x Services

This section provides a quick look at the Cisco IOS commands that you use to configure H.450 services. To enable basic H.450.2 and H.450.3 call transfer and call forwarding, you use the transfer-system and call-forward pattern commands, as shown in Example 7-12.

Example 7-12. Calls Forward Pattern

Router#show running-config
telephony-service
 ip source-address 10.1.1.1 port 2000
 max-ephones 24
 max-dns 48
 transfer-system full-consult
 call-forward pattern .T
 create cnf-files

To turn on the H.450.12 service (in Cisco CME 3.1 and above), use the following:

voice service voip
 supplementary-service h450.12

To permit VoIP-to-VoIP hairpin or tandem call routing to work with remote H.323 endpoints that do not support H.450.x service, use this:

voice-service-voip
 allow-connections h323 to h323

Older Cisco CME 3.0 and earlier code does not support the H.450.12 service. This means that if you enable H.450.12 on a Cisco CME 3.1 system and place a call from a Cisco CME 3.0 system, the Cisco CME 3.1 system will incorrectly infer that H.450.x services are not supported by the Cisco CME 3.0 system.

To work around this upgrade issue, you can operate the H.450.12 service in advertise-only mode. In this mode, your CME system transmits H.450.12 capability indications for the benefit of remote H.323 systems that are H.450.12-aware, but it does not require receipt of H.450.12 indications from a remote H.323 endpoint. You can then manually disable the H.450.2 and H.450.3 service for each non-H.450-capable VoIP link using per-dial peer configuration, as shown in Example 7-13.

Example 7-13. Disable H.450.2 and H.450.3

Router#show running-config
voice service voip
 supplementary-service h450.12 advertise-only
 allow-connections h323 to h323
dial-peer voice voip 5000
 destination-pattern 50..
 session target ipv4 10.1.20.1
 no supplementary-service h450.2
 no supplementary-service h450.3

With this configuration, no attempt is made to invoke H.450.2 transfer and H.450.3 forwarding for calls using the VoIP dial peer. Instead, VoIP-to-VoIP hairpin or tandem call routing is used.

Cisco CME Local Supplementary Services

Cisco CME is designed to make use of H.450.2 call transfer and H.450.3 call forwarding for all calls that involve one or more VoIP call legs. For example, for an incoming H.323 VoIP call that is internally forwarded from one local IP phone to a second IP phone, Cisco CME sends an H.450.3 response back to the original calling party. This causes the caller to cancel the original H.323 call to the Cisco CME's first phone and creates a new H.323 call back to the Cisco CME using the second phone's number.

At first, this might seem like doing things the hard way. However, the point of doing this is to make sure that the original caller can see that his call has been forwarded. Returning the call to the originator and making him issue a new call allows the calling party system to have full visibility of what is going on and allows the display on the calling phone to be updated accordingly. This is an important feature if you are trying to create a seamless multisite Cisco CME network as part of an internal enterprise-wide phone system.

You can use the supplementary-service commands to disable this VoIP end-to-end behavior and invoke hairpin and tandem call handling. For the special case in which the forwarding phone and forward-to phone are part of the same Cisco CME system, the hairpin and tandem call routing mechanism can be used without incurring any real-world penalty. For incoming VoIP calls that are locally forwarded within a single Cisco CME system, the final call and media path are the same, regardless of which mechanism you use to handle call forwarding. Although this example describes only local call forwarding, the same principle applies to call transfer.

Also, it's important to stress that the complexities associated with the H.450.x end-to-end services apply only to calls that involve at least one VoIP call leg. For simple standalone Cisco CME usage, in which all external calls directly use the router's PSTN interfaces, CME operation is more simplified. However, to use call transfer with consultation, you still need to configure transfer-system full-consult.

H.450.x and Cisco CallManager

Cisco CallManager (as of release 4.0) does not support H.450.x services, including H.450.12. However, Cisco CME 3.1 (and above) automatically detects a call that involves a Cisco CallManager using special H.323 nonstandard information elements (IEs). Even without an H.450.12 indication, Cisco CME's automatic Cisco CallManager detection can be used to invoke VoIP-to-VoIP hairpin or tandem call routing when needed for call transfer and forwarding. You need to enable the allow-connections h323 to h323 command to make this work.

Some special configuration of the H.323 interface on Cisco CallManager may also be required, depending on the specific Cisco CallManager software version used. For example, you may be required to configure a Media Termination Point (MTP), disable H.323 Fast, Start, and use Cisco CallManager's H.323 Inter-Cluster Trunk (ICT) mode.

H.450.x Proxy Services

You've seen how you can use Cisco CME to create VoIP-to-VoIP call paths for call forwarding and transfer initiated by IP phones attached to Cisco CME. What may not be obvious is that this same mechanism can be applied to calls that simply need to pass physically through a router. This is true regardless of whether the router is configured as a Cisco CME with IP phones attached. Calls that pass through a router as a result of deliberate H.323 call processing (within the router) are not the same as calls that pass through the router at the basic IP packet routing and IP connectivity level. The distinction being made here is the difference between routing H.323 calls and routing IP packets.

When a call passes through a router and the router is used in onward routing of the called number, this is called tandem call routing. In the special case that the tandem call routing results in the call entering and exiting the router on the same VoIP interface, the result is a VoIP-to-VoIP hairpin call.

A Cisco CME system that is deployed at a remote branch office typically has only a single WAN and VoIP interface. This means that all VoIP-to-VoIP call paths created by the CME inevitably are of the hairpin form. Hairpin VoIP-to-VoIP paths are inherently undesirable, because the doubled-back voice path is an inefficient use of scarce WAN bandwidth.

The more general VoIP-to-VoIP tandem case may offer some real advantages. One example is when you choose to use VoIP tandem call routing to provide a proxy for H.450 services.

Consider a VoIP network that connects to a central Cisco CallManager system at a company's headquarters site. Assume that the central site has a single voice mail system. Attached to the central system are a number of remote branches with Cisco CME systems connected over WAN links in a hub-and-spoke arrangement, with the Cisco CallManager site acting as the hub. Because the Cisco CallManager does not support H.450 services, a call from the Cisco CallManager site to a remote Cisco CME system that is forwarded-on-busy to a voice mail system at the central site is VoIP-to-VoIP hairpin routed. This means that the call and media path for the voice mail call extends all the way from the central Cisco CallManager to the remote Cisco CME site and then hairpins back to the central voice mail. This consumes two calls worth of bandwidth on the WAN link and could potentially block other calls from reaching the remote-site Cisco CME.

You can configure a router to act as an H.450 Tandem Gateway, and use it to proxy H.450 service for the Cisco CallManager, and avoid extending the hairpin call path all the way to the remote-branch Cisco CME system.

Calls from the Cisco CallManager to the remote Cisco CME systems are configured to pass through an H.450 Tandem Gateway that is co-located with the Cisco CallManager at the central site. The H.450 Tandem Gateway adds an H.450.12 capabilities indication to the call before it is sent to the remote Cisco CME system. This allows the remote Cisco CME system to invoke H.450.2 transfer or H.450.3 call forwarding on the call. The H.450 Tandem Gateway intercepts any H.450.x service messages sent by the Cisco CME system. If the call path required by the H.450 service invocation requires a VoIP-to-VoIP hairpin, the hairpin is created at the central site, where bandwidth is more plentiful. You still get a VoIP-to-VoIP hairpin path, but the hairpin is located in the central site network instead of the call path going all the way to the remote Cisco CME system at the far end of the WAN link, as shown in Figure 7-6. In this figure, the H.450 Tandem Gateway provides proxy services for H.450 messages coming from the CME systems. Call transfers/forwards are rolled back to the Tandem Gateway instead of hairpinning the call at the remote-branch site.

Figure 7-6. H.450 Tandem Gateway

Consider the case of a call from the Cisco CallManager that goes through the H.450 Tandem Gateway to Cisco CME 1 and is then H.450.3 forwarded to Cisco CME 2. For this case, the H.450.3 forwarding request causes the original call to be rolled back to the H.450 Tandem Gateway and then reoriginated to the second Cisco CME 2. The final call path for the forwarded call is actually optimum for this case. It's the same call path as a direct dialed call from the Cisco CallManager to Cisco CME 2. The physical IP packet path for the call is the same as you would get for a pure H.450.3 case.

Furthermore, the router you deploy to act as the H.450 Tandem Gateway can also be equipped with physical voice ports. It then can do double duty and act as a PSTN gateway to provide central PSTN access for the Cisco CallManager and also, optionally, for the remote Cisco CME systems.

To configure a router to act as an H.450 Tandem Gateway, you simply create VoIP dial peers to direct incoming VoIP calls to outgoing VoIP links, as shown in Example 7-14.

Example 7-14. VoIP Dial Peers

Router#show running-config
voice service voip
 supplementary-service h450.12
 allow-connections h323 to h323

The same caveats that apply to Cisco CME hairpin routing also apply in the H.450 Tandem Gateway case. The inbound and outbound VoIP call legs need to use the same codec unless you use a DSP farm to provide transcoding.

In the case that you use an H.450 Tandem Gateway to also provide PSTN access, you may need to configure separate dial peers to allow the main site Cisco CallManager-to-PSTN calls to operate using G.711 at the same time Cisco CallManager-to-Cisco CME via tandem calls use G.729.

Cisco CME 3 x and Pre H 450 x Transfer and Forwarding

As a little history on the software releases that predate H.450.x support, the original Cisco CME code introduced in Cisco IOS 12.2(8)T did not support H.450. At that time, the Cisco CME product was still called IOS Telephony Services (ITS). This code used a Cisco-proprietary H.323 call transfer and forwarding mechanism. It supported only blind transfers and could not perform VoIP-to-VoIP call forwarding. It's included here only because this is the behavior you get with the default configuration, which provides backward compatibility with the older software. This is the transfer and forwarding mechanism you get if you do not configure the transfer-system and call-forward pattern commands.

Integrating Cisco CME in a SIP Network