Configuring Call Transfer and Forward
Configuring call transfer and forwarding for H.323 VoIP calls is a fairly complex task in most real-world H.323 VoIP networks. This is especially true if you have a mixture of H.323 VoIP systems from different vendors. Even if you have an all-Cisco H.323 VoIP network, there are still interactions to consider, unless all your VoIP systems are running relatively up-to-date Cisco IOS software. This means having at least Cisco IOS 12.3 software in all your voice-enabled routers. Ideally, you should have Cisco IOS 12.3(4)T or later software (this is the Cisco CME 3.0 base code version). There are also some special considerations if you are using a Cisco CallManager in addition to your Cisco IOS-based Cisco CME systems, which you'll learn more about in Chapter 7, "Connecting Multiple Cisco CMEs with VoIP." The good news is that with the right software and configuration, there are workable solutions for most of your VoIP call transfer and forwarding needs.
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 CME system configuration. A call transfer also depends on the capabilities of the final VoIP system that you are transferring the call to.
In traditional TDM-based PBX telephony, call transfer and forwarding usually operate within the limited scope of a single PBX system and, therefore, are simpler operations. For example, you are often limited to call transfers between extensions on the same PBX only.
In a VoIP-based system, you can potentially transfer or forward calls between any VoIP endpoints, regardless of their physical location. Of course, being able to do this in practice requires making sure that you have support for transfer and forwarding built into all your VoIP endpoints.
With Cisco CME, you have three basic choices for the protocol used to support call transfer and forwarding for H.323 VoIP calls:
- Standards-based H.450—Strongly recommended because it provides for optimal call paths and unlimited sequential transfers and forwards
- Cisco-proprietary H.323 extension—Mostly obsolete, but useful if you are using software older than Cisco IOS 12.2(15)T
- Hairpin call routing—Maximum compatibility but uses more WAN bandwidth and results in higher delay and jitter
The default H.323 call transfer protocol used by Cisco CME is the Cisco-proprietary 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 versions.
The default call forwarding mechanism provides for automatic local forwarding only (that is, within the same Cisco 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 CME system that are nonlocally forwarded to a third Cisco 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 CME router. (PSTN voice ports on a router other than the Cisco CME system appear as H.323 VoIP calls to the Cisco 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 Terminology
To fully comprehend the different call flows when talking about transfers, you should be familiar with the following terms:
- Transferee—The person who is being transferred. Usually this is the person who placed the original call.
- Transferor—The person who invokes the transfer. Usually this is the initial recipient of the incoming call.
- Transfer-to—The person who becomes the final recipient of the call after the transfer has been completed.
- Consultation call—The call between the transferor and transfer-to parties. This is usually the call that introduces the transfer where the transferor and transfer-to parties talk (consult) before the transferee is connected to the transfer-to party.
- Transfer commit at connect—The act of completing the (consultative) transfer after the transferor and transfer-to party have talked to each other. The transferee party does not hear the transfer-to party's phone ring. The transfer-to party's phone shows the transferor as the (initial) calling party.
- Transfer commit at alerting—The act of committing the (consultative) transfer during the time that the transfer-to party's phone is ringing. In this case, a consultation call is placed but is abandoned before the transfer-to party answers the phone. The transfer-to party's phone shows the transferor as the (initial) calling party. The transferee party hears the transfer-to party's phone ringing. Note that in a VoIP system, it's usually not possible to commit a transfer to a busy destination, unless you use the blind transfer approach. You can commit a transfer to a busy destination that has call forward-on-busy, provided that the forward-to destination itself is available (for example, forward on busy to voice mail). However, none of this is necessarily visible to the transferor.
- Blind transfer—This is also called unsupervised transfer and sometimes full blind transfer. It is the act of invoking a call transfer without first checking to see if the transfer-to party is available. In the traditional TDM PBX world, this is often considered to be the same as commit at alerting when the transferor commits the transfer without waiting to hear the transfer-to party's phone ring, usually by hanging up the phone. The transfer-to party's phone shows the transferee as the calling party.
In the VoIP world, there are two key differences between the blind and commit-at-alerting case. The first difference is in the calling party information sent in the H.323 call setup request toward the transfer-to party. In the blind case, this is the transferee, and in the commit at alerting/connect case, it's the transferor. This can affect the billing for the call. The second difference is that a blind transfer doesn't involve doing a call replace operation, which is needed to switch the transfer-to party's call between transferor and transferee. So you might sometimes want to consider the blind form of transfer, because it eliminates the transfer capability dependency on the transfer-to endpoint VoIP system.
Call Transfer Methods for VoIP
This section describes several methods for implementing call transfer across VoIP networks:
- H.450 and SIP
- Hairpin routing
- H.450.12
- Empty Capability Set
H.450 and SIP
The ITU-T standards-based H.450.2 transfer method and the Cisco-proprietary method operate in a similar fashion. 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's 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 replaces operation fails, it's 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-proprietary 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 superceded 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 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 CME system. This means that the transferred call continues to consume resources on the transferor Cisco 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 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 CME system (this is recommended). You must be using at least Cisco CME 3.1 to use H.450.12. With H.450.12 enabled, your Cisco 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 CME system can automatically detect when an H.450.2 transfer is possible. When it isn't possible, the Cisco CME system can fall back to using VoIP hairpin routing. Cisco CME also can automatically detect a call from a (non-H.450-capable) Cisco CallManager.
Empty Capabilities Set
For the sake of completeness, it's worth mentioning a fourth alternative for call transfers: Empty Capabilities Set (ECS). Cisco CME does not support the instigation of transfer using ECS. But because a Cisco CME router also has the full capabilities of the Cisco IOS 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 CME system can be a transferee or transfer-to party in an ECS-based transfer. A Cisco 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 don't allow you to transfer a call that has already been transferred in the general case of VoIP intersystem transfers.
Cisco CME VoIP Call Transfer Options
Your Cisco CME system by default is set up to allow local transfers between IP phones only. It uses the Cisco-proprietary H.323 call transfer extensions to transfer calls that include an H.323 VoIP participant.
To configure your Cisco 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 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 can't be transferred (or forwarded) using H.450, use the allow-connections command. Example 5-36 shows a call transfer configuration using this command.
Example 5-36 Call Transfer Configuration
router#show running-config 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 Example 5-36 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.)
Example 5-37 shows a configuration for more restrictive transfer permissions.
Example 5-37 More Restrictive Call Transfer Configuration
router#show running-config 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.
Call Transfer Billing Considerations
You should consider what your billing requirements are for transferred calls. Most enterprise VoIP networks have no requirement for separate billing for VoIP call legs within an internal VoIP network. Most enterprise networks are concerned only with billing for external PSTN call legs.
The billing for a PSTN call leg usually goes to the party identified as the calling party on the outbound PSTN call setup. For a PSTN call using ISDN BRI/PRI, the calling party number is passed from the Cisco CME extension that originated the call. You can use the Cisco CME dialplan-pattern or Cisco IOS voice dial peer translation rule commands to convert from two-to-five-digit abbreviated extension numbers into a national number format acceptable to your PSTN service provider. If you are using simple analog FXO port connections to connect to the PSTN (simple subscriber line), you have no control over the billing party information, so you can probably skip the rest of this section. Calls on an analog subscriber line are simply billed to the number associated with the subscriber line by the PSTN service provider.
For the ISDN PRI/BRI case, this is an area where the difference between transfer commit at connect/alerting and blind transfers may be significant. It's also an area in which hairpin call routing may provide you with some advantages.
When an H.450.2-style transfer is committed at alerting/connected, the calling party number for the consultation call setup to the transfer-to party (from the transferor) is normally equal to the transferor's phone number. This is usually the bill-to number that's associated with the call. If the consultation call involves a PSTN call leg using PRI/BRI (either a direct PSTN connection on the Cisco CME router or a remote PSTN gateway call reached via an intermediate VoIP leg), it's useful to have the initial calling party number for the outbound PRI/BRI PSTN leg equal to the transferor's phone number. This assumes that you want any transferred call to be billed (or traceable) to the person who invokes the transfer. When the replaces operation is triggered to connect the transferee to the transfer-to party, the calling party information associated with the PSTN leg normally does not change. This means that even after the transferor has dropped out of the call, the call continues to be billed to the transferor, at least as far as the external PSTN call leg is concerned. This is true for PSTN access that's directly on your Cisco CME router and also when the PSTN access is on a remote VoIP-PSTN gateway accessed via a VoIP link. This is because the H.450.2 call transfer replaces operation is confined to the H.323 VoIP network. The replaces operation normally cannot extend into the PSTN connection.
Transfers that use the blind mechanism work differently. In the blind transfer case, the transferor does not originate a consultation call. The initial call received by the transfer-to party in an H.450.2 transfer case by default has the transferee's phone number as the calling party. The transferee is often a phone number belonging to some external party. You are often not permitted to bill calls to this phone number even if you want to. Your PRI/BRI PSTN connection is very likely to reject any outbound calls that attempt to claim an external number as the calling party identifier.
You can work around this issue in a couple of different ways, depending on the reason you chose to select the blind transfer method. For example, you may be using blind transfer to avoid the H.450.2 replaces operation if it is not supported by your PSTN access voice gateway. The workaround methods include the following:
- You can place a translation rule on the dial peer associated with the outgoing PRI/BRI PSTN port that overwrites the transferee calling party number with the general public phone number for your company.
- You can elect to force hairpin VoIP routing with transfer commit-at-alerting/connect as an alternative to blind transfer such that the outgoing PSTN call carries the transferor's phone number.
To use the first alternative, you must have control of the PSTN gateway. This is true if the PSTN access is local to your Cisco CME router. This may not be true if you get remote PSTN access across a WAN connection from a VoIP telephony service provider (TSP). In this case, your VoIP TSP may share the PSTN access ports across multiple end customers.
The second hairpin case is the most robust approach, because it forces a separate call leg to be generated for the outgoing PSTN call segment.
To force hairpin VoIP call routing, you can switch on H.450.12 services on your Cisco CME router and use a separate PSTN gateway router on which H.450.12 is disabled (or not supported). Alternatively, you can explicitly turn off H.450.2 service on your Cisco CME voice dial peers that route calls to the PSTN gateway router. You do this using the no supplementary-service h450.2 command, as shown in Example 5-38.
Example 5-38 Turning Off H.450 on a Dial Peer
router#show running-config dial-peer voice 100 voip destination-pattern 9.T session target ipv4:10.0.1.20 no supplementary-service h450.2
Because Cisco CME includes the standard Cisco IOS voice infrastructure functionality, you can also connect your Cisco CME system to a Remote Authentication Dial-In User Service (RADIUS) server to capture call records for more detailed call tracking information collected. If you don't have a RADIUS server, you can also configure your Cisco CME system to generate SYSLOG messages that include call details. You can use a simple PC as a SYSLOG server to record the call data, using one of several freeware SYSLOG programs available on the Internet.
Call Forward Methods for VoIP
This section describes different mechanisms for handling call forwarding in a VoIP network:
- H.450.3 call forwarding
- H.323 Facility Message
- VoIP hairpin call forwarding
You can configure your Cisco CME to handle VoIP call forwarding in several different ways. Select the method to use depending on how you want forwarding to operate.
H.450.3 Call Forwarding
You can use the ITU-T H.450.3 standard for call forwarding (this is recommended). It has some similarities to H.450.2 (call transfer). When a call is forwarded, an H.450.3 message is sent back to the calling party requesting that the caller reoriginate a follow-on call to the forwarded-to destination. If Cisco CME is configured to use H.450.3, it is used even if the forward-to destination is another local IP phone within the same Cisco CME system as the forwarding phone (or forwarder). Use this method if you want the calling VoIP party to always be able to see the phone number he or she is being forwarded to. Just like the H.450.2 transfer case, use of H.450.3 requires that all the VoIP endpoints in your VoIP network support H.450 services.
H.323 Facility Message
The second choice is to use the quasi-standard H.323 Facility Message mechanism for forwarding. This is the default call forwarding configuration for Cisco CME. This method is used as the default, because it provides backward compatibility with earlier (and current) Cisco IOS releases. It's also quite widely supported by third-party and non-Cisco IOS VoIP systems. When this mechanism is used, an H.323 Facility Message is sent back to the VoIP caller only for the case of forwarding to a nonlocal number. If the forward-to destination is local to the forwarding phone, the call forward operation is handled internally within the Cisco CME system. In this case, the remote calling IP phone cannot update its display to show the forwarded destination.
VoIP Hairpin Call Forwarding
Your third choice is to use VoIP call hairpin routing. This is similar to the call transfer hairpin option. A second independent VoIP call leg is created for the forwarded call leg. This leg is bridged to the original incoming VoIP call leg. As for the transfer hairpin case, the disadvantage of this approach occurs if you have to support sequential or chained forwarding. Sequential hairpin forwarding of VoIP calls results in accumulated bandwidth and jitter/delay issues.
Just like the call transfer discussion, if you have to deal with only local LAN and PSTN connections and do not have to route VoIP H.323 calls across a WAN connection, you can just configure your system for H.450.3 operation to get your system ready to interoperate with other H.450-capable endpoints should you need this in the future.
You can also compromise between the H.450.3 and hairpin configuration by using the H.450.12 service to automatically detect H.450.3-capable VoIP endpoints, and fall back to hairpin routing for calls that don't support H.450.3.
Cisco CME VoIP Call Forwarding Options
Your Cisco CME system by default is configured to support internal local forwarding. It sends only H.323 Facility Messages back to the VoIP caller for nonlocal VoIP forwarding destinations. If you have direct PSTN access on your Cisco CME system, PSTN destinations accessed via local ports are considered local for the purposes of this discussion.
To turn on H.450.3 services for VoIP calls, you use the call-forward pattern command under telephony-service. This command lets you conditionally select H.450.3 service based on matching the calling party's telephone number. This lets you invoke H.450.3 for calls only from VoIP phone numbers that you know support H.450.3. You can configure the matching pattern to use .T to match all possible calling party numbers. This is similar to the match-all configuration used with the transfer-pattern command.
To permit VoIP-to-VoIP hairpin (or tandem) call routing for forwarded calls, set the allow-connections command under voice services voip. If you've already done this to allow hairpin transfers, you don't need to do it again for call forwarding.
As with the H.450.2 transfer case, you can turn on the H.450.12 service to compromise and allow H.450.3 where possible, and fall back to hairpin forwarding otherwise. Note that H.450.12 support was introduced in Cisco CME 3.1.
Example 5-39 shows a basic configuration.
Example 5-39 Turning On H.450 on a Dial Peer
router#show running-config voice service voip supplementary-service h450.12 allow-connections h323 to h323 telephony-service call-forward pattern .T
Call Forward Billing Considerations
Similar billing issues apply to call forwarding as for call transfer. You can choose to have the calling party information for the forwarded call reflect the party being forwarded (in the H.450.3 case). You also can have the information show the calling party number of the phone that requested the forwarding (in the VoIP hairpin case). As for the call transfer case, you can use the dialplan-pattern command and voice dial peer translation rule options to control the format of the calling party on outgoing PSTN PRI/BRI calls. Again, this issue does not apply for PSTN analog subscriber line connections via FXO ports.
Transfer and Forward Proxy Function
The transfer and forward discussion so far in this chapter has related to the configuration of a single Cisco CME system to cope with various possible VoIP network scenarios, including networks that have endpoints with mixed capabilities. If you have a network of Cisco CME systems, you should consider partitioning it to provide a section that contains only H.450-capable endpoints. This allows you to gain the full set of H.450 service benefits within the group of VoIP network devices that support them. You can then link this segment of your VoIP network to the non-H.450 network using a Cisco IOS router configured to act as an H.450 Tandem Gateway.
An H.450 Tandem Gateway can act as a proxy for H.450.2 and H.450.3 services on behalf of VoIP devices that don't support H.450. Calls between the H.450 and non-H.450 devices can be routed to pass through the H.450 Tandem Gateway. H.450 messages originated by Cisco CME systems can be terminated on the H.450 Tandem Gateway, which can invoke hairpin call routing for transfers and call forwarding as needed.
An H.450 Tandem Gateway makes the most sense if your network topology is arranged in a hub-and-spoke fashion. Consider a network design that has a number of Cisco CME systems located at the end of WAN link spokes connected to a central hub network. In this type of network, it often makes sense to locate an H.450 Tandem Gateway at the central hub and to use it as a linkage point to act as a bridge into the non-H.450 segment of the VoIP network. With an H.450 Tandem Gateway, calls that enter the H.450 network segment through the Tandem Gateway can be transferred and forwarded using H.450 services within the H.450 segment of the network. Calls transferred or forwarded to destinations outside the H.450 segment are hairpin routed as needed by the H.450 Tandem Gateway. If the H.450 Tandem Gateway is located at a central hub location, hairpin routing the call at the hub is a better option than hairpin routing the call from a Cisco CME system located at the far end of one of the network spokes over a WAN link. (Figure 5-3 in the next section shows a Tandem Gateway.)
Call Transfer and Forward Interoperability with Cisco CallManager
Cisco CallManager (version 4.0 and earlier) does not support H.450 services. Cisco CME 3.1 can automatically detect H.323 calls that go to or come from Cisco CallManager. It does this using H.323 information elements included in H.323 call setup, progress, alerting, and connect messages. You can optionally turn on H.450.12 services for calls to Cisco CallManager, and use the lack of H.450.12 indications to invoke hairpin VoIP call routing by your Cisco CME systems, but this is not required.
You may have a VoIP network in which turning on H.450.12 produces ambiguous results as far as the detection of H.450.2 and H.450.3 capabilities. One example of this occurs when you have older Cisco CME 3.0 (or even Cisco ITS [Cisco CME's earlier name] 2.1) systems in your network. Although Cisco CME 3.0 systems do support H.450.2 and H.450.3, they don't support H.450.12 capabilities indications. If you turn on H.450.12 on your Cisco CME 3.1 systems and you also have some older Cisco CME 3.0 routers, the CME 3.1 systems assume that the CME 3.0 routers cannot perform H.450.2/3 services, because no H.450.12 indication is forthcoming from the Cisco CME 3.0 systems. So in a network with a mixture of Cisco CME 3.0, Cisco CME 3.1, and Cisco CallManagers, it makes sense to turn off the H.450.12 service and assume that all endpoints can perform H.450.2/3 except for the endpoints that are detected as explicitly being Cisco CallManager systems.
Also, if you have a Cisco CallManager system, it's likely to be located at a central corporate site with Cisco CME systems at branch offices. This arrangement lends itself naturally to a hub-and-spoke network design with the Cisco CallManager at the hub and the Cisco CME systems at the ends of the network spokes. This type of network design is a good candidate for an H.450 Tandem Gateway using the H.450 Tandem Gateway to front-end the Cisco CallManager and act as a proxy for H.450 services between the Cisco CallManager and the network of Cisco CME systems. The H.450 Tandem Gateway can also be configured to act as the PSTN Voice Gateway for the Cisco CallManager system (using either H.323 or MGCP), so you don't need to dedicate a separate router for the H.450 Tandem Gateway. It can also provide centralized PSTN access for the Cisco CME systems. Performance wise, calls that pass through the H.450 Tandem Gateway consume a similar amount of CPU and memory resources as a call terminated by the router as a PSTN gateway call. See Figure 5-3.
)
Figure 5-3 H.450 Tandem Gateway
A Cisco CallManager (version 4.0 or earlier) should be configured to interface with Cisco CME systems or an H.450 Tandem Gateway using H.323 Inter-Cluster Trunk (ICT) mode and a Media Termination Point (MTP). In addition, Cisco CallManager version 3.3(3) should be configured to disable H.323 fast-start.
Call Transfer and Forwarding with Routed Signaling H.323 Gatekeepers
An H.323 gatekeeper that uses routed signaling acts as a call proxy for basic A-to-B calls. All calls that reference the gatekeeper have H.323 signaling that passes through the gatekeeper. The presence of this type of gatekeeper in your network has a significant impact on your network from the H.450 service point of view. Your routed signaling gatekeeper may or may not support H.450 services. It may be able to pass through H.450 messages transparently, or it may block some or all of them. It may even be able to act as an H.450 Tandem Gateway.
A worst-case design approach for dealing with a routed signaling gatekeeper would be to assume that H.450.2/3 services do not work through the gatekeeper. In this case you can configure your Cisco CME systems to force hairpin routing of all VoIP calls that have to transfer or forward back into the VoIP network. You can do this by turning off H.450 services under the voice service voip command, as shown in Example 5-40.
Example 5-40 Turning Off H.450 Services
router#show running-config voice service voip no supplementary-service h450.2 no supplementary-service h450.3 allow-connections h323 to h323 telephony-service call-forward pattern .T transfer-system full-consult transfer-pattern .T
Note that by default, the H.450.12 service is disabled, so there's no need to specifically include commands to turn it off.