Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Call-Flow Scenarios

So far, this chapter has discussed call signaling, media protocols, call-processing servers, and other IPT endpoints used in Cisco IPT. To understand how all of these components work together, this section discusses the following call-flow scenarios:

IP phone to IP phone call

Intracluster call

Intercluster call

Intercluster call with gatekeeper

Off-net calls

Using MGCP gateway

Using H.323 gateway with gatekeeper

IP Phone-to-IP Phone Call

In the first scenario, IP phone 1 and destination IP phone 2 are registered with the same CallManager, CCM1. Figure 1-20 shows the high-level sequence of steps that occur when source IP phone 1 calls destination IP phone 2.

Figure 1-21 shows the sequence of SCCP messages that are exchanged between the phones and the CallManager to establish and tear down the call.

The SCCP messages in Figure 1-21 are grouped together to correlate with the high-level sequence of steps shown in Figure 1-20.

The description of the sequence of steps is given here:

As the preceding steps demonstrate, all the instructions come from the CallManager. The phone has little intelligence. In this scenario, after establishing an RTP stream between the two phones, the communication can continue even if the CallManager server goes down, because the CallManager is not involved in passing the media streams between the phones. However, if the CallManager server to which the phones are registered fails during a conversation, users will not be able to invoke some of the supplementary servicessuch as hold, park, and mute during the conversationthat require the participation of CallManager in signaling. The phones will be reregistered to the backup CallManager after hang-up of the active call.

Intracluster Call

In the second scenario, IP phones 1 and 2 are registered with CallManager CCM1, and Phone 3 is registered with CallManager CCM2. Both CCM1 and CCM2 are part of the same CallManager cluster. Figure 1-22 shows the intracluster call scenario when source IP Phone 2 calls destination IP phone 3. In this call scenario, CallManager and IP phone communication is done using SCCP, and CallManager-to-CallManager communication is based on Intra-Cluster Communication Signaling (ICCS). As the name implies, ICCS is a signaling protocol used between the CallManager servers in a cluster. The same sequence of events takes place between the IP phone and CallManager as described in the preceding section, "IP Phone-to-IP Phone Call." As you can see, the other members of the cluster automatically know about the devices that are registered in the cluster because the database is the same across all the servers.

Intercluster Call

In the third scenario, shown in Figure 1-23, IP Phones 1 and 2 are registered with CallManager CCM1 in CallManager Cluster 1 and destination IP Phone 3 is registered with CallManager CCM2 in CallManager Cluster 2. CCM 1, and CCM 2 are part of different CallManager clusters and an ICT connects the two clusters. The ICT protocol is similar to the H.323 Version 2 protocol with some extensions. CallManager sends ICT protocol signaling directly to the other CallManager in another cluster without the involvement of a gateway and uses a TCP/IP connection path available between the two clusters.

When a phone call is made from Phone 2 to Phone 3, the CallManager node CCM1 establishes a TCP/IP connection to a CallManager node CCM2 in the destination cluster. CCM1 in the originating cluster sends the Setup message, and CCM2 responds with the Call Proceeding, Alerting, and Connect messages, which are similar to the H.323 messages that are exchanged between two H.323 endpoints as the call progresses and is answered.

Intercluster Call with the Gatekeeper

The fourth scenario is similar to the third scenario except for the addition of the gatekeeper for CAC purposes. Gatekeeper-controlled ICTs are required when the clusters are separated by a WAN link and you need to control the number of calls that can go through the WAN link. In a large deployment involving multiple CallManager clusters, the gatekeeper can also perform the call routing via the locally configured dial plan.

Figure 1-24 shows the call flow for this scenario. The IP phones communicate with the CallManager using SCCP. The CallManager communicates with the gatekeeper using the H.323 RAS protocol. CCM A and CCM B are part of CallManager Cluster 1, and CCM C and CCM D are part of CallManager Cluster 2. These two clusters are connected via the ICT through the gatekeeper. Phone 1 is registered with CCMB, and Phone 2 is registered with CCMC.

In Figure 1-24, the following sequence of events takes place:

IP phone 1 dials the number of IP Phone 2.

CCM B sends an Admission Request (ARQ) message to the gatekeeper.

From the dial plan configured in the gatekeeper, the gatekeeper finds that CCM C is registered with prefix 2 and returns the Admission Confirmation (ACF) message to CCM B with an IP address of CCM C.

CCM B sends an H.225 call setup message to CCM C with the phone number of Phone 2.

CCM C sends an ARQ message to the gatekeeper asking permission to place the call across the ICT.

The gatekeeper responds with an ACF message to CCMC. Before returning the ACF, the gatekeeper performs checks to ensure that it has enough resources to place the call across the ICT. If no resources such as bandwidth are available, the gatekeeper sends an Admission Reject (ARJ) message.

CCM C initiates the call setup with phone 2 via SCCP.

When phone 2 answers the call by going off-hook, CCM C sends an H.225 Connect message to CCM B and the audio path is made directly between IP phones in different clusters using RTP.

Off-Net Calls

Any call that is routed outside the CallManager cluster is treated as an off-net call. This section discusses two off-net call-flow scenarios with the following types of gateways:

MGCP gateway

H.323 gateway

Using MGCP Gateway

Before analyzing the off-net call flow with MGCP, it is important to understand how the CallManager achieves call survivability with MGCP-based gateways. CallManager uses the MGCP PRI backhaul mechanism to receive the signaling information from the ISDN PRI gateway to provide the call-control functionality and preserve the D channel (and thus call survivability) during the CallManager failover and switchover event. Figure 1-25 shows this mechanism.

As shown in Figure 1-25, the MGCP PRI gateway terminates the D channel link layer (Q.921) signaling. The Q.931 termination remains in the CallManager. The CallManager backhaul function transports the Q.931 messages over the IP network to and from the gateway.

With this backhaul functionality, during the CallManager switchover, because the Q.921 layer is terminated on the gateway, the D channel stays active during the CallManager failure; hence, the active calls are not dropped on that interface.

A UDP logical (UDP port 2427) connection exchanges MGCP messages, and a TCP connection (TCP port 2428) backhauls the Q.931 messages. The values of both default ports are configurable on the CallManager. The source port from the gateway is randomly chosen.

In Figure 1-25, if the physical interface to the PSTN central office switch on the MGCP gateway is other than PRI, such as T1 CAS, FXS, or FXO, the gateway translates these signaling types into MGCP messages and sends them to CallManager for call control.

You should take into account the call-survivability feature with MGCP gateways when choosing the signaling protocol for the voice gateways.

Now look at a call-flow example from an IP phone to a PSTN phone via an MGCP voice gateway. Figure 1-26 shows the CallManager cluster with a registered IP phone 1 and a MGCP gateway with a PRI interface to the PSTN CO switch. The IP phone user makes an off-net call to a PSTN phone (Phone Z). The CallManager routes the call via the MGCP gateway.

CallManager communicates with IP phones via SCCP and with the gateway via MGCP. Figure 1-27 shows the signaling messages exchanged between the IP phone, CallManager, and the MGCP gateway to route this call.

For purposes of clarity, in Figure 1-27, the initial messages from the phone, beginning with the off-hook event until the end of dialing, are not included. These steps are the same as the ones shown in Figure 1-21 that are labeled as Step 1.

The following steps describe the events of messages that take place when IP Phone 1 makes an off-net call through the MGCP gateway:

Using H.323 Gateway

Figure 1-28 shows the CallManager cluster with a registered IP phone 1 and an H.323 gateway. A gatekeeper is also registered with the cluster, and the off-net calls contact the gatekeeper before placing the call. The IP phone user makes an off-net call to a PSTN phone (Phone Z). The CallManager routes the call via the H.323 gateway.

The following steps describe the events of messages that take place when IP phone 1 makes an off-net call via the gatekeeper through the H.323 gateway. Figure 1-29 shows the exact call-signaling sequence.