Introducing the Cisco Unified Border Element Gateway (Establishing a Connection with an Internet Telephony Service Provider) Part 3

Cisco UBE Gateway Call Flows

Cisco UBE call flow depends on network topology and features implemented. The following call-flow scenarios listed will be used to illustrate the concepts about Cisco UBE that have been discussed thus far:

■ Cisco Unified Communications Manager—Cisco UBE—Cisco Unified Communications Manager Express

■ Cisco Unified Communications Manager—Cisco UBE with RSVP—Cisco Unified Communications Manager

■ Cisco Unified Communications Manager—Cisco UBE—SIP Carrier

■ Cisco Unified Communications Manager—Gatekeeper—Cisco UBE—SIP Carrier

■ Cisco Unified Communications Manager—Via-Zone Gatekeeper—Cisco UBE— Cisco Unified Communications Manager

Figure 9-9 shows a call flow between a Cisco Unified Communications Manager server and a Cisco Unified Communications Manager Express router using Cisco UBE.

Cisco Unified Communications Manager Express uses H.450 for optimized call transfers and call forwards without requiring hairpinning. Because Cisco Unified Communications Manager does not support H.450, a transfer involving H.323 VoIP connections might lead to suboptimal traffic flows.

Cisco UBE Call Flows: Cisco UCM to Cisco UCME


Figure 9-9 Cisco UBE Call Flows: Cisco UCM to Cisco UCME

Cisco UBE can be used to solve H.450 Cisco Unified Communications Manager and Cisco Unified Communications Manager Express interoperability issues. In this example, a call between Phone1-1 and Phone2-1 is transferred to Phone3-1. Because Cisco UBE supports H.450, the resulting traffic flow will be directly between the Cisco UBE router and Cisco Unified Communications Manager 2. Without Cisco UBE, the call transfer would be done using hairpinning on Cisco Unified Communications Manager 1.

RSVP-based intercluster CAC can be implemented using Cisco UBE. Figure 9-10 shows two Cisco Unified Communications Manager clusters interconnected by two Cisco UBE routers. Each Cisco Unified Communications Manager cluster has an H.323 call leg to the local Cisco UBE local. The two Cisco UBE routers perform RSVP-based CAC, and because RSVP-based CAC requires media flow-through, a call between the two clusters will flow through the two Cisco UBE routers. Note that phones still use the Skinny Client Control Protocol (SCCP) for signaling toward a Cisco Unified Communications Manager server.

Figure 9-11 shows a simple Cisco UBE deployment where Cisco UBE is used to translate a H.323 call leg with a Cisco Unified Communications Manager cluster to a SIP call leg point to a SIP carrier. Because this is a connection to an external VoIP network, media flow-through is required to hide internal IP addresses and overcome IP interworking issues, such as duplicate private IP addresses.

 Cisco UBE Call Flows: Cisco UCM to Cisco UCM

Figure 9-10 Cisco UBE Call Flows: Cisco UCM to Cisco UCM

Cisco UBE Call Flows: SIP Carrier Interworking

Figure 9-11 Cisco UBE Call Flows: SIP Carrier Interworking

Figure 9-12 shows an H.323 gatekeeper deployment that includes a Cisco UBE integrated with a gatekeeper and a SIP carrier. Calls from the Cisco Unified Communications Manager cluster are routed via H.225 RAS from the San Jose gatekeeper to the ITSP gatekeeper, which then routes the call to the Cisco UBE router. Cisco UBE then performs standard protocol interworking, allowing connections from the Cisco Unified Communications Manager H.323 network to the SIP carrier network.

 Cisco UBE Call Flows: Gatekeeper and SIP Carrier Interworking

Figure 9-12 Cisco UBE Call Flows: Gatekeeper and SIP Carrier Interworking

Figure 9-13 shows the concept of via-zone enabled gatekeepers using Cisco UBE.

Cisco UBE Call Flows: Cisco UBE and Via-Zone Gatekeeper

Figure 9-13 Cisco UBE Call Flows: Cisco UBE and Via-Zone Gatekeeper

Three gatekeepers are deployed:

■ San Jose gatekeeper: This gatekeeper has a single zone called 408.

■ Boston gatekeeper: This gatekeeper has a single zone called 857.

■ Via-zone gatekeeper: This gatekeeper has a single zone called via-zone (VIA).

The San Jose (SJC) Cisco Unified Communications Manager cluster is registered at the San Jose gatekeeper; the Boston (BOS) Cisco Unified Communications Manager cluster is registered at the Boston gatekeeper; and the Cisco UBE router is registered at the via-zone gatekeeper.

The San Jose gatekeeper will route all calls made to the remote 857 zone to the via-zone gatekeeper, and the Boston gatekeeper will route all calls made to the remote 408 zone to the via-zone gatekeeper.

The via-zone gatekeepers will route the calls to the remote 408 and 857 zones, but not directly to the gatekeepers in San Jose and Boston. Instead, the routing will be done using the local VIA zone.

The following steps, numbered in Figure 9-13, describe an example call flow from the San Jose Cisco Unified Communications Manager cluster in zone 408 on the San Jose gatekeeper to the Boston Cisco Unified Communications Manager cluster located in zone 857 on the Boston gatekeeper:

1. A call is placed from the San Jose Cisco Unified Communications Manager to someone in area code 857.

2. The San Jose Cisco Unified Communications Manager sends an ARQ to the San Jose gatekeeper.

3. The San Jose gatekeeper resolves the 857 that belongs to the via-zone gatekeeper and sends a Location Request (LRQ).

4. The VIA gatekeeper receives an LRQ for 857 and resolves the 857 prefix to the Cisco UBE. The VIA gatekeeper sends a LCF to the San Jose gatekeeper.

5. The San Jose gatekeeper returns an ACF that specifies the Cisco UBE to the San Jose Cisco Unified Communications Manager.

6. The San Jose Cisco Unified Communications Manager sends a SETUP message to the Cisco UBE for the 857 number.

7. The Cisco UBE sends an ARQ to the VIA gatekeeper with the answerCall=true parameter set to admit the incoming call.

8. The VIA gatekeeper responds with an ACF to admit the call. From the perspective of the VIA gatekeeper, the first call leg is established.

9. The Cisco UBE gateway has a dial peer that specifies that RAS messages should be sent to the VIA gatekeeper for all prefixes. The Cisco UBE gateway initiates the process of resending the call by sending the ARQ message with answerCall=false to the VIA gatekeeper for 857.

10. The VIA gatekeeper knows that prefix 857 belongs to the Boston gatekeeper, and because the source zone is the via-zone, the VIA gatekeeper sends an LRQ to the Boston gatekeeper.

11. The Boston gatekeeper sees prefix 857 as a local zone and sends an LCF pointing to the Boston Cisco Unified Communications Manager.

12. The VIA gatekeeper returns an ACF to the Cisco UBE that specifies the Boston Cisco Unified Communications Manager.

13. The Cisco UBE gateway sends a SETUP message to the Boston Cisco Unified Communications Manager for the 857 call.

14. The Boston Cisco Unified Communications Manager sends an ARQ to the Boston gatekeeper to request admission for the call.

15. The Boston gatekeeper sends an ACF with the answerCall=true parameter.

Next post:

Previous post: