Basic Configuration

Cisco voice gateways, by default, support a TDM-to-VoIP or VoIP-to-TDM call. Enabling the VoIP-to-VoIP functionality is configured under the voice service voip configuration mode. The syntax for the allow-connections command is allow-connections h323|sip to h323|sip.

Example 18-1 illustrates the basic configuration to enable a VoIP-to-VoIP call. By configuring "allow-connections h323 to h323," Cisco IOS can permit an incoming H.323 VoIP call to be accepted and sent out as an H.323 VoIP call on the second call leg. Also shown is the configuration for allowing SIP-to-SIP or H.323-SIP calls.

Media-handling mode is configured under the voice service voip configuration mode. The command syntax is media flow-through|flow-around. Example 18-2 illustrates the configuration commands for implementing media flow-through.

Example 18-3 illustrates the configuration commands for implementing media flow-around.

You can achieve the routing of the voice and video calls based on the configuration of the incoming and outgoing dial peers. You can apply the relevant protocol, dual tone multifrequency (DTMF) type, codec information, QoS parameters, and other parameters to each VoIP dial peer.

Example 18-4 illustrates a VoIP dial peer configuration. VoIP dial peer 1 is the incoming H.323 dial peer (default protocol, if session protocol command is not configured). The session target command designates the IP address for this VoIP dial peer, which in this example is the IP address of the originating endpoint. The codec G711ulaw command specifies that the codec to be used for this dial peer is G711ulaw. The dtmf h245-alphanumeric command specifies that the dtmf type to use for this dial peer is h-245 alphanumeric. VoIP dial peer 2 is a SIP-based VoIP dial peer. This is explicitly configured in the session protocol sipv2 command. The destination pattern is the called-party number that the originating endpoint dials. The dtmf-relay rtp-nte command specifies the RFC 2833 dtmf type to be used on the outgoing leg.

Also, because the IPIPGW and gatekeeper functionality are supported in the same Cisco IOS image, you can run both these functionalities on the same router. You can run the IPIPGW in conjunction with the Cisco gatekeeper using a concept called via-zones.

Via-Zones

Chapter 16, "Deploying Gatekeepers," introduced the Cisco IOS gatekeeper and the concept of local and remote zones. The Cisco Multiservice IPIPGW feature introduces gatekeeper via-zones. A via-zone is a Cisco term for a zone that contains IPIPGWs. A via-zone-enabled gatekeeper is capable of recognizing via-zones and sending traffic to via-zone gateways.

You must configure IPIPGW to register to a local zone on the gatekeeper. You would use this zone as the via-zone. You could configure the zone local or zone remote command to take the incoming call through the IPIPGW. You can achieve this based on the invia and outvia configuration in the zone command. The invia command specifies the gatekeeper for the calls that are entering the particular zone, and the outvia command specifies the gatekeeper that is leaving that zone. When the invia and outvia commands are configured, the gatekeeper returns the IP address of the IPIPGW in the Admission Confirm (ACF)/Location Confirm (LCF) messages to the originating gateway. The originating gateway then sends an H.323 setup to the IPIPGW, which in turn terminates and reoriginates traffic to its final destination.

Figure 18-3 illustrates a gatekeeper via-zone call flow. A caller from area code 408 calls a party in area code 972, and the following actions occur.

Figure 18-3. Gatekeeper Via-ZoneSample Call Flow

1. ORIG_GW sends an Admission Request (ARQ) with the 972-based number to ORIG_GK.
2. ORIG_GK sees prefix 972 as reachable through VIA_GK and sends a Location Request (LRQ) to VIA_GK.
3. The LRQ for 972 is received by VIA_GK. VIA_GK looks at the H.323 ID in the inbound LRQ to find the remote zone. Then it looks for a via-zone keyword associated with that remote zone. Because the via-zone gatekeeper ID is a local zone, it allocates the call to the IPIPGW in the via-zone and returns an LCF specifying IP-TO-IP_GW.
4. ORIG_GK returns the ACF, specifying the IP address of IP-TO-IP_GW.
5. ORIG_GW sends a SETUP message to IP-TO-IP_GW for the 972 call.
6. IP-TO-IP_GW sends an ARQ to VIA_GK to admit the incoming call (answerCall=true).
7. VIA_GK returns an ACF.
8. IP-TO-IP_GW has a dial peer specifying ras VIA_GK for the 972 prefix (or all prefixes) and sends an ARQ (with answerCall set to FALSE) to VIA_GK for prefix 972.
9. VIA_GK sees prefix 972 as TERM_GK, and there is no outvia zone, so VIA_GK sends an LRQ to TERM_GK.
10. TERM_GK sees prefix 972 as in its own zone and sends an LCF pointing to TERM_GW.
11. VIA_GK returns an ACF specifying IP-TO-IP_GW.
12. IP-TO-IP_GW sends a SETUP message to TERM_GW for the 972 call.
13. TERM_GW sends an ARQ answerCall to TERM_GK.
14. TERM_GK returns an ACF for answerCall.

Example 18-5 shows the configurations for the gatekeepers and IPIPGW to support the call flows shown in the preceding list.