Share this page : facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Configure CUBE

Protocol Interworking Command

 

To enable protocol interworking, use the allow-connections from-type to to-type command in voice service configuration mode. The from-type and to-type options specify the signaling protocols, as detailed in Table 9-2.

Table 9-2 allow-connections Syntax Description

Parameter Description
from-type Originating endpoint type. The following choices are valid: h323—H.323
sip—SIP
To Indicates that the argument that follows is the connection target.
to-type Terminating endpoint type. The following choices are valid:
h323—H.323
sip—SIP

 

When interworking H.323 and SIP, the configuration is unidirectional; thus, if bidirectional interworking is required, you need to configure the mirroring statement as well. For example, if bidirectional H.323 to SIP interworking is required, you need to configure allow connections h323 to sip as well as allow connections sip to h323.

 Protocol Interworking Topology Example
Protocol Interworking Topology Example

 

Protocol Interworking Configuration

R1(config)#voice service voip

R1(config-voice-service)# allow-connections h323 to h323

R1(config-voice-service)#  allow-connections h323 to sip

R1(config-voice-service)#  allow-connections sip to h323

R1(config-voice-service)#  allow-connections sip to sip

 

Configuring H.323-to-H.323 Interworking

H.323-to-H.323 gateway configuration provides a network-to-network demarcation point between independent VoIP and video networks for billing, security, call-admission control, QoS, and signaling interworking. It performs most of the functions of a PSTN-to-IP gateway but joins two H.323 VoIP call legs.

As shown in the figure, to configure H.323-to-H.323 interworking between a Cisco Unified Communications Manager cluster and a Cisco Unified Communications Manager Express gateway, follow these steps:

Step 1: Enabling H.323-to-H.323 Interworking

By default, a Cisco IOS gateway will not allow connections between two VoIP dial peers. To change this behavior and allow H.323-to-H.323 connections, use the allow-connections h323 to h323 command in voice service configuration mode:

R1(config)#voice service voip

R1(config-voice-service)# allow-connections h323 to h323

Step 2: Configuring H.323 Dial Peers

After H323-to-H323 calls have been allowed, configure the appropriate dial peers to route between the Cisco Unified Communications Manager cluster and the Cisco Unified Communications Manager Express router. No special configuration on the dial peers is required. Example bellow illustrates this dial-peer configuration.

H.323 Dial Peers

R1(config)#dial-peer voice 2001
R1(config-dial-peer)#description To Cisco UCM
R1(config-dial-peer)#destination-pattern 2...
R1(config-dial-peer)#session-target ipv4:192.168.1.1
R1(config-dial-peer)#exit
R1(config)# dial-peer voice 3000
R1(config-dial-peer)#description To Cisco UCME
R1(config-dial-peer)#destination-pattern 3...
R1(config-dial-peer)#session-target ipv4:192.168.2.254

 

Configuring H.323-to-SIP Interworking

Figure 9-16 shows a sample scenario used to configure H.323-to-SIP interworking with a Cisco UBE router. The Cisco Unified Communications Manager cluster in San Jose routes calls to the SIP carrier via a Cisco UBE router. The connection between the Cisco Unified Communications Manager and the Cisco UBE router is H.323 and the connection between the Cisco UBE router and the SIP carrier is SIP.

H.323-to-SIP Interworking Scenario

You can follow these steps to configure H.323-to-SIP interworking:

Step 1. Enable H.323-to-SIP interworking.

Step 2. Configure H.323 and SIP dial peers to route international calls between the Cisco Unified Communications Manager cluster and the SIP carrier.

Step 1: Enabling H.323-to-SIP Interworking

As with an H.323-to-H.323 connection, by default a Cisco IOS gateway will not allow connections between an H.323 and a SIP VoIP dial peer. To change this behavior and allow H.323-to-SIP connections, use the allow-connections h323 to sip command in voice service configuration mode. Then issue the allow-connections sip to h323 command to enable SIP to H.323 calls:

R1(config)#voice service voip
R1(config-voice-service)#allow-connections h323 to sip
R1(config-voice-service)#allow-connections sip to h323

Step 2: Configuring Dial Peers

For a SIP (rtp-nte)-to-H.323 (h245-alphanumeric) call via a Cisco UBE router, if any RTP named telephony event (NTE) packets are sent before the H.323 endpoint answers the call, the DTMF signal is not heard on a terminating gateway (TGW).

Note debug output reveals that the H245 out-of-band messages are sent to the TGW. However, the digits are not heard on the phone.

To avoid sending both in-band and out-of-band tones to the outgoing leg when sending Cisco UBE calls in-band (rtp-nte) to out-of-band (h245-alphanumeric), configure the dtmf-relay rtp-nte digit-drop command on the incoming SIP dial peer.  On the H.323 side, configure either dtmf-relay h245-alphanumeric or dtmf-relay h245-signal. This can also be used for H.323-to-SIP calls.

Dial-Peer Configuration

R1(config)#dial-peer voice 2000 voip

R1(config-dial-peer)#description To CUCM

R1(config-dial-peer)#destination-pattern 2...

R1(config-dial-peer)#session target ipv4:192.168.1.1

R1(config-dial-peer)#dtmf-relay h245-alphanumeric

R1(config-dial-peer)#exit

R1(config)#dial-peer voice 9011 voip

R1(config-dial-peer)#description To International SIP carrier

R1(config-dial-peer)#session protocol sipv2

R1(config-dial-peer)#destination-pattern 9011T

R1(config-dial-peer)#session target ipv4:192.168.10.254

R1(config-dial-peer)#dtmf-relay rtp-nte digit-drop h245-alphanumeric

 

Media Flow and Transparent Codec Commands

To configure media flow-through or media flow-around, use the following media command:

Router(config-dial-peer)#media [flow-around | flow-through]

Note that this command can be issued in dial-peer configuration mode or globally under the voice service configuration mode. The default is media flow-through.

To configure transparent codec pass-through, use the following codec transparent command:

Router(config-dial-peer)# codec transparent

 

Note that this command can be issued in dial-peer configuration mode or via a codec class.

Configuring Transparent Codec Pass-Through and Media Flow-Around

Figure 9-17 shows a sample scenario used to configure H.323-to-H.323 interworking, including transparent codec pass-through and media flow-around, using a Cisco UBE router. The Cisco Unified Communications Manager cluster in San Jose is connected with the Cisco Unified Communications Manager Express router in Chicago using a Cisco UBE router. Codec negotiation is performed directly between the Cisco Unified Communications Manager cluster and the Cisco Unified Communications Manager Express router, and RTP streams flow directly between the endpoints.

 

 

 

Figure 9-17 Transparent Codec Pass-Through and Media Flow-Around Example Topology

Codec transparency enables a Cisco UBE router to pass codec capabilities between end-points. If you configure transparency, a Cisco UBE router uses the codec that was specified by the endpoints for setting up a call. To enable endpoint-to-endpoint codec negotiation without a Cisco UBE router, use the codec transparent command.

With the default configuration, a Cisco UBE router receives media packets from the inbound call leg, terminates them, and then reoriginates the media stream on an outbound call leg. Media flow-around enables media packets to be passed directly between the endpoints, without the intervention of a Cisco UBE router. The Cisco UBE router continues to handle routing and billing functions. Media flow-around for SIP-to-SIP calls is not supported. Use the media flow-around command to enable media flow-around. Example 9-6 illustrates the use of both the codec transparent and the media flow-around commands.

Example 9-6 Transparent Codec Pass-Through and Media Flow-Around Configuration

R1(config)#dial-peer voice 2000 voip

R1(config-dial-peer)#description to CUCM

R1(config-dial-peer)#destination-pattern 2...

R1(config-dial-peer)#session target ipv4:192.168.1.1

R1(config-dial-peer)#dtmf-relay h245-alphanumeric

R1(config-dial-peer)#codec transparent

R1(config-dial-peer)#media flow-around

R1(config-dial-peer)#exit

R1(config)#dial-peer voice 9011 voip

R1(config-dial-peer)#description To CUCME

R1(config-dial-peer)#destination-pattern 3...

R1(config-dial-peer)#session target ipv4:192.168.2.254

R1(config-dial-peer)#codec transparent

R1(config-dial-peer)#media flow-around

 

Figure 9-18 shows a sample scenario used to configure a Cisco UBE router and a via-zone gatekeeper. A gatekeeper is configured with two standard local zones: San Jose (SJC) and Chicago (CHI). The Cisco Unified Communications Manager Express Router1 is registered in the SJC zone, and the Cisco Unified Communications Manager Express Router3 is registered in CHI zone. Calls between Chicago and San Jose should be routed by the gatekeeper. Instead of routing calls directly between the two zones, the gatekeeper should route the calls through the VIA, which includes a Cisco UBE router.

Configuring Cisco UBEs and Via-Zone Gatekeepers

Figure 9-18 shows a sample scenario used to configure a Cisco UBE router and a via-zone gatekeeper. A gatekeeper is configured with two standard local zones: San Jose (SJC) and Chicago (CHI). The Cisco Unified Communications Manager Express Router1 is registered in the SJC zone, and the Cisco Unified Communications Manager Express Router3 is registered in CHI zone. Calls between Chicago and San Jose should be routed by the gatekeeper. Instead of routing calls directly between the two zones, the gatekeeper should route the calls through the VIA, which includes a Cisco UBE router.

Note The Cisco UBE function and the gatekeeper function are performed by the same router.

Configure the Gatekeeper

You can complete these steps to configure a gatekeeper:

Step 1. Create a loopback interface to use for the gatekeeper.

Step 2. Create local, remote, and VIA zones.

Two local zones, SJC and CHI, are configured, but instead of configuring a standard local zone, the invia and outvia options are used to route calls to and from the zones using the VIA zone.

In addition to the SJC and CHI local zones, another local via-zone is configured. This zone will contain the Cisco UBE router.

Figure 9-18 Cisco UBEs and Via-Zone Gatekeepers Configuration Topology

Step 3. Specify zone and technology prefixes.

Standard zone prefix routing is set up, and the default technology 1# is configured. Example 9-7 illustrates a sample via-gatekeeper configuration.

Example 9-7 Via-Zone Gatekeeper Configuration

GK(config)#interface Loopback0

GK(config-if)ip address 192.168.66.14 255.255.255.0

GK(config-if)#exit

GK(config)#gatekeeper

GK(config-gk)# zone local SJC cisco.com 192.168.66.14 invia VIA outvia VIA

GK(config-gk)# zone local CHI cisco.com invia VIA outvia VIA

GK(config-gk)# zone local VIA cisco.com

GK(config-gk)# zone prefix SJC 1*

GK(config-gk)# zone prefix CHI 3*

GK(config-gk)# gw-type-prefix 1#* default-technology

GK(config-gk)# no shutdown

 

Configure the Cisco UBE

After the gatekeeper configuration is done, the Cisco UBE configuration is performed on the same router.

You can complete these steps to configure the Cisco UBE feature:

Step 1. Enable H.323 interworking.

Step 2. Create a loopback interface to use as the source interface for Cisco UBE to register with the gatekeeper.

The Loopback1 interface is used as the H.323 gateway interface. The Cisco UBE router will register in zone VIA with the H.323 ID CUBE and the technology prefix 1#.

Step 3. Create two dial peers—one pointing to San Jose and the other to Chicago.

Step 4. Enable the gateway process.

Example 9-8 illustrates a sample Cisco UBE configuration.

Example 9-8 Cisco UBE Configuration

GK(config)#voice service voip

GK(config-voice-service)#allow-conections h323 to h323

GK(config-voice-service)#exit

GK(config)# interface loopback1

GK(config-if)#ip address 192.168.66.15 255.255.255.0

GK(config-if)#h323-gateway voip interface

GK(config-if)#h323-gateway voip id VIA ipaddr 192.168.66.14 1719

GK(config-if)#h323-gateway voip h323-id IPIPGW

GK(config-if)#h323-gateway voip tech-prefix 1#

GK(config-if)exit

GK(config)#dial-peer voice 10 voip

GK(config-dial-peer)# destination-pattern 1...

GK(config-dial-peer)#session target ras

GK(config-dial-peer)#exit

GK(config)#dial-peer voice 30 voip

GK(config-dial-peer)# destination-pattern 3...

GK(config-dial-peer)# session target ras

GK(config-dial-peer)#exit

GK(config)#gateway

 

 

Verifying Cisco UBEs and Via-Zone Gatekeepers

When you use the show gatekeeper endpoints command on the gatekeeper, a Cisco UBE router will be displayed as an H323-GW type. In the output shown in Example 9-9, the Cisco UBE router is registered using the Loopback1 IP address 192.168.66.15.

Verifying Cisco UBEs and Via-Zone Gatekeepers with the show gatekeeper endpoints Command:

 

When a call is active, the show gatekeeper calls command will display two call legs. The first call leg, as illustrated in Figure 9-19 and Example 9-10, is between the originating gateway (Router1 in this case) and the Cisco UBE router.

Figure 9-19 Verifying Cisco UBEs and Via-Zone Gatekeepers Topology—Call Leg 1

Example 9-10 Verifying Cisco UBEs and Via-Zone Gatekeepers with the show gatekeeper calls Command—Call Leg 1

Example 9-10 Verifying Cisco UBEs and Via-Zone Gatekeepers with the show gatekeeper calls Command—Call Leg 1 continued

The second call leg, as illustrated in Figure 9-20 and Example 9-11, is between the Cisco UBE router and the terminating gateway (Router3 in this case).

Figure 9-20 Verifying Cisco UBEs and Via-Zone Gatekeepers Topology—Call Leg 2

Example 9-11 Verifying Cisco UBEs and Via-Zone Gatekeepers with the show gatekeeper calls Command—Call Leg 2

Reference

http://what-when-how.com/cisco-voice-over-ip-cvoice/configuring-cisco-unified-border-elements-establishing-a-connection-with-an-internet-telephony-service-provider-part-1/