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

Figure 8-2. Verifying the Registration Status of a T1/E1 Port

Chapter 9 discusses these tools in detail.

Figure 8-3 shows the performance counters on a CallManager server for the performance object MGCP PRI device. To access the Performance Monitor application on a CallManager server, click Start > Programs > Administrative Tools > Performance. Figure 8-3 shows the status of the 23 B channels (channels 1 to 23) and the D channel (channel 24) of the selected MGCP PRI gateway. The status code for channel 23 is 3 (Busyindicates an active call on the channel), whereas the status code for all the other B channels is 2 (Idlenot in use).

As you can see in Figure 8-3, after registering the gateway with the CallManager, you can check the channel status through the performance counters and monitor the change in the status code after placing the calls. Figure 8-3 shows one active call on the PRI on channel 23. The gateway selected channel 23 because, in the CallManager configuration for this gateway, the channel selection order was configured as bottom up.

A status code of 0 (Unknown) indicates that the status of the channel could not be determined; 1 (Out of service) indicates that this channel is not available for use; 4 (Reserved) indicates that this channel has been reserved for use as a D channel or for use as a synchronous channel for E-1.

Implementing a Catalyst T1/E1 Voice Gateway by Using a CMM Module

Chapter 6, the CMM module has four slots. One slot is an internal slot and is not available to plug in any T1/E1 module. The internal slot can only accept an Ad Hoc Conferencing and Transcoding (ACT) adapter. The three other slots can be filled either with three T1/E1 modules each with 6 T1/E1 ports (18 total) or any combination of T1/E1 modules and ACT adapters.

With WS-X6608-T1 (E1) modules, unused T1/E1 ports can be configured as conferencing and transcoding resources. This is not the case with T1/E1 ports on the CMM module. You require the ACT adapter for conferencing and transcoding purposes. Another difference between the WS-X6608-T1 module and CMM is that CMM supports both H.323 and MGCP protocols, besides supporting Survivable Remote Site Telephony (SRST). The following steps cover how to provision the CMM module.

Step 1: Access the CMM

The CMM module has its own Cisco IOS image. To access the CMM module from the Catalyst switch running the Cat OS and Multilayer Switch Feature Card (MSFC) running the IOS code, enter the session mod_num command on the switch console, as shown in Example 8-4. The mod_num is the module number where CMM is installed. From Example 8-1, the CMM modules are available in modules 6 and 7 on the Cat6k-voice switch used in this configuration.

Example 8-4. Accessing CMM from the Switch Console

cat6k-voice> (enable) session 6
Trying VOICE-GATEWAY-6...
Connected to VOICE-GATEWAY-6.
Escape character is '^]'.
User Access Verification
Password:
SJ-CMM1>en
Password:
SJ-CMM1#                         

Note that the host name used for the CMM is SJ-CMM1. You have to input this host name when configuring the CMM in CallManager Administration.

Step 2: Configure the T1/E1 Port

The CMM runs the Cisco IOS image. Therefore, the configuration steps for T1/E1 ports are similar to those for any T1/E1 port on a Cisco IOS router. Example 8-5 shows the configuration for a T1 port. The configuration for the E1 port is similar except that you select the E1 port and configure different line code and framing.

Example 8-5. Configuring the T1/E1 Port

SJ-CMM1# conf
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line. End with CNTL/Z.
! Configure the ISDN Switch type                                              
SJ-CMM1(config)#isdn switch-type primary-ni
! Enable the MGCP process on the CMM                                          
SJ-CMM1(config)#mgcp
! Specify the MGCP Call Agent address, which is, the IP address of the primary
! CallManager. You can specify backup CallManager's by using the command      
! ccm-manager redundant-host command                                          
SJ-CMM1(config)#ccm-manager mgcp
SJ-CMM1(config)#mgcp call-agent 172.21.51.237
! Configure the Gigabit ethernet interface. This is the interface through     
! which the T1/E1 ports communicate with CallManager                          
SJ-CMM1(config)#int gigabitEthernet 1/0
SJ-CMM1(config-if)#ip address 172.21.54.89 255.255.255.128
SJ-CMM1(config-if)#no shutdown
SJ-CMM1(config-if)#ip default-gateway 172.21.54.5
! Configure the T1 port with correct line code and framing                    
SJ-CMM1(config)#controller t1 1/0
SJ-CMM1(config)#no shutdown
SJ-CMM1(config-controller)#linecode b8zs
SJ-CMM1(config-controller)#framing esf
SJ-CMM1(config-controller)#pri-group timeslots 1-24 service mgcp
! After configuring the pri-group command under the T1/E1 controller,         
! router adds the D channel interface.                                        
! The ISDN bind command configures the ISDN-PRI back-haul to the CallManager  
SJ-CMM1(config)#interface serial 1/0:23
SJ-CMM1(config-if)#isdn  bind-l3 ccm-manager
Configure the POTS dial peer and associate the voice port 1/0:23 to this dial peer. The
application command  informs the CMM that the voice port 1/0:23 is controlled by MGCP.
SJ-CMM1(config)#dial-peer voice 1 pots
SJ-CMM1(config-dial-peer)#application mgcp
SJ-CMM1(config-dial-peer)#port 1/0:23

Chapter 6 section "Survivable Remote Site Telephony" to see a sample configuration of a local dial plan on routers. When the router is in SRST mode, the gateway falls back to H.323 mode and uses the local dial plan to perform the call routing.

Step 3: Configure the Gateway on CallManager

To configure a gateway on the CallManager Administration page, choose Device > Gateway. Click the Add New Gateway option on the Gateway page. On the Add a New Gateway page, choose Communication Media Module as the gateway type and click Next. In the Domain Name field, enter the host name of the CMM module and select the interface cards inserted into the modules, as shown in Figure 8-4. Click Insert to insert the gateway into the CallManager.

After you insert the CMM module, you need to specify the subunits that are inserted in the CMM module. In Figure 8-5, the T1 card WS-X6600-T1 is selected.

After you insert the subunits and update the configuration, click the T1 port that you want to configure. The configuration of the T1 port is similar to that of the T1 port configuration on the 6608, as shown in Figure 8-5. You need to provide values for the fields such as Device Pool, Interface parameters for the T1/E1, calling search space, and so forth.

Step 4: Verify the Connectivity Status

After completing the configuration, you need to verify whether the physical connection to the PSTN is up. You can use the show isdn status command, as shown in Example 8-6. The Layer 2 status should report MULTIPLE_FRAME_ESTABLISHED.

Example 8-6. Verifying the T1/E1 Port Connectivity Status on the CMM

SJ-CMM1#show isdn status
Global ISDN Switchtype = primary-ni
ISDN Serial1/0:23 interface
dsl 0, interface ISDN Switchtype = primary-ni
L2 Protocol = Q.921  L3 Protocol(s) = CCM-MANAGER
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED 
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask:  0x807FFFFF
Number of L2 Discards = 0, L2 Session ID = 3
Total Allocated ISDN CCBs = 0
SJ-CMM1#

If you do not see the successful connectivity status, verify that line code, framing, and clocking are configured correctly. You can use the show controllers t1 1/0 command to verify these configurations, as shown in Example 8-7.

Example 8-7. Verifying the Controller Configuration

SJ-CMM1#show controllers t1 1/0                                            
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
  Framing is ESF, Line Code is B8ZS, Clock Source is Line.                 
Data in current interval (15 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
SJ-CMM1#

Step 5: Verify the Registration Status

To verify the T1/E1 port registration status on the CMM, use the show ccm-manager command, as shown in Example 8-8. The output should show Registered if the port is successfully registered to the CallManager.

Example 8-8. Verifying the Registration Status of the T1/E1 Port on the CMM

SJ-CMM1#show ccm-manager                                                       
MGCP Domain Name: SJ-CMM1
Priority        Status                   Host
============================================================
Primary         Registered               172.21.51.237                         
First Backup    None
Second Backup   None
Current active CallManager:    172.21.51.237                                   
Backhaul/Redundant link port:   2428
Failover Interval:              30 seconds 
Keepalive Interval:             15 seconds
Last keepalive sent:            23:24:31 UTC Mar 22 1993 (elapsed time: 00:00:09
)
Last MGCP traffic time:         23:24:31 UTC Mar 22 1993 (elapsed time: 00:00:09
)
Last failover time:             None
Last switchback time:           None
Switchback mode:                Graceful
MGCP Fallback mode:             Not Selected
Last MGCP Fallback start time:  None
Last MGCP Fallback end time:    None
PRI Backhaul Link info:
Link Protocol:      TCP
Remote Port Number: 2428
Remote IP Address:  172.21.51.237
Current Link State: OPEN
Statistics:
Packets recvd:   463
Recv failures:   76
Packets xmitted: 390
Xmit failures:   0
PRI Ports being backhauled:
Slot 1, port 0
Configuration Error History:
FAX mode: cisco                                                                
SJ-CMM1#

Troubleshooting Gateway Connectivity and Registration Issues

This section provides troubleshooting tips if you are having trouble completing the gateway registration, confronting issues with port status, or experiencing unsuccessful inbound/outbound calls for Catalyst-based voice gateways.

To determine whether the problem is related to a registration issue, do the following:

Check the basic network connectivity by pinging the TFTP server and the CallManager from the gateway module.

Check whether the port that is configured for the voice gateway is enabled.

Check whether the correct IP address, subnet mask, gateway, and VLAN are configured for the port.

If you are not using DHCP, ensure that the DHCP helper address is configured on the routed interface that is directly connected to the subnet where the gateway port resides.

Check whether the correct TFTP server is configured.

If you are using the DNS name for the TFTP server, ensure that the switch can resolve the TFTP server name to the IP address.

If all of the previous points are correct, check that the MAC address entered in the CallManager matches the MAC address of the port.

To determine whether the problem is related to a connectivity issue, check whether the port status is Connected; refer to Example 8-3. If it is not, check that the interface parameters such as the isdn switch-type, line code, and framing configured on the gateway are set according to the values required by your local telco; refer to Example 8-5.

To determine whether the problem is related to unsuccessful calls (made to and from a Cisco IP Phone through the gateway), verify the following:

If you cannot make outbound calls from a Cisco IP Phone, check the dial plan configurations and Cisco IP Phone's CSS configuration.

If you are not able to receive incoming calls from the gateway, check the values in the Inbound Calls section of the Gateway configuration page in the CallManager, such as the Calling Search Space and Significant Digits fields.

If you still have problems, look into the TFTP traces or CallManager traces to resolve the issue.

The preceding paragraphs discussed the implementation procedures and troubleshooting procedures for commonly used gateways. If your network uses other gateways, refer to the Cisco.com product-specific documentation for configuration and troubleshooting assistance.

Implementing IP Phones

You can deploy IPT components such as IP Phones and gateways either manually or by using automated tools such as BAT. Use of the automated tools makes the IPT implementation more robust and smooth. These tools can assist you in speeding up the IPT implementation process in most cases, but using them is not mandatory for the IPT implementation process. The following sections describe the implementation of IP Phones using BAT and the physical installation of IP Phones.

Implementation of IP Phones Using BAT

To enable you to configure or update your CallManager database faster and with less manual entry for larger systems, CallManager ships BAT. By using BAT, you can perform bulk add, update, and delete operations of phones, users, and gateways. The export feature in BAT comes in handy when you are consolidating multiple CallManager clusters into a single CallManager cluster. By using the export feature, you can export the configuration information of phones and users from a CallManager cluster into a CSV file and import the contents of the CSV file into the new CallManager cluster.

BAT is available on the CallManager Install Plugins page. You can install BAT only on a CallManager publisher server. After you install BAT, you can access it by entering the following URL:

http://CCM_PUBLISHER_IP_ADDRESS/bat

A complete installation and configuration guide for BAT is available at the following URL:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_user_guide_book09186a0080212686l

The next two sections discuss the procedures and tools that you can use to provision Cisco IP Phones in the CallManager.

Barcode Scanners

When you are using BAT to add the MAC address of the IP Phones for a large-scale IPT deployment, you need to type each MAC address, one by one, into the Bat.xlt (BAT Microsoft Excel Template) file, which is a tedious process.

Use of bar-code scanners greatly reduces the chance of human error in entering the MAC addresses while configuring the IP Phones in CallManager and helps you to accelerate largescale IP Phone deployments.

The back of the IP Phone has a barcoded MAC address. Barcode vendors offer a wide variety of models. The scanner you choose needs to scan the MAC address and put it in the database efficiently. Here is a brief list of barcode scanner manufacturers:

Socket Communications http://www.socketcom.com/

Symbol Technologies http://www.symbol.com

Wasp Technologies http://www.waspbarcode.com

While choosing among different scanner models, the following are features to look for:

It can read and insert the barcode value into any type of application that is running on the workstation OS that you are using.

It can write the decoded value into any standard application without the need to install special software on the workstation.

It is easy to hook up with your workstation, such as via a keyboard interface or USB interface.

After you connect the scanner to your workstation, open the Bat.xlt file (you can copy this file from C:\CiscoWebs\BAT\ExcelTemplate directory on the CallManager publisher server to your location workstation) and scan the barcode of the MAC address on the back of the IP Phone. Repeat this process for all the IP Phones. The scanner records the value of the cell to which the pointer is pointing. The pointer moves automatically to the next row or to the next cell after scanning each input. After scanning the MAC address of the IP Phone, you can input the rest of the phone configuration information, such as the extension number, number of lines on the phone, number of speed dials, and so forth, into the BAT Excel template.

When you are ready with all the information for the IP Phones that need to be deployed, export the data in the BAT Excel template file into a CSV file. You can then import this CSV file via the BAT application to configure the IP Phones in the CallManager.

Tool for Auto-Registered Phones Support

An alternate approach to the barcode scanners is to use TAPS in conjunction with BAT to update auto-registered phones and replace phones that have a predefined device configuration. TAPS is available on the CallManager Install Plugins page. You can use TAPS to avoid manual entry of the MAC addresses of the IP Phones in the database.

TAPS requires the Customer Response Solution (CRS) server to execute a script that plays prompts and receives the digits from the user to configure the IP Phones. If you have not purchased CRS server software, you can download the optional, free-of-charge software called Cisco CallManager Extended Services, which is available on Cisco.com on the CallManager software downloads page, to provision the IP Phones using TAPS. The Cisco CallManager Extended Services includes the CRA engine that can use applications such as TAPS and Cisco Auto Attendant (AA) can use. The CRA engine that is included with Extended Services comes with a limited number of ports and does not offer you the CRA editor utility to create or modify the application scripts.

The TAPS installation process copies the TAPS script (TAPS.aef) to the C:\Program Files\Wfavvid directory on to the CRA or Extended Services server.

If you have a co-resident CallManager and CRS/Extended Services application installation, you need to install the TAPS only once on the CallManager publisher server. If you have CRS installed on a separate server, you need to install TAPS both on the CallManager publisher server and on the CRS server.

Refer to the BAT user guide on Cisco.com for instructions on installing and using TAPS:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_user_guide_book09186a0080212686l

Physical Phone Installation

Install Cisco IP Phones in your network by connecting the Ethernet wire coming from the Ethernet jack in the wall to the back of the IP Phones. IP Phones obtain the DHCP address and TFTP server information and attempt the registration with CallManager.

A complete IP Phone implementation guide is available on Cisco.com:

http://www.cisco.com/en/US/partner/products/hw/phones/ps379/products_administration_guide_chapter09186a0080080680l

To troubleshoot issues with Cisco IP Phone registration during implementation and operation, refer to the following document on Cisco.com:

http://www.cisco.com/en/US/partner/products/hw/phones/ps379/products_administration_guide_chapter09186a0080080689l

Implementing the Dial Plan

Dial Plan Architecture" section in Chapter 6 discussed the steps involved in designing the dial plan. The implementation of the dial plan consists of configuring the following dial plan components in the CallManager:

Partitions

Calling search spaces

Route groups

Route lists

Route patterns

Translational patterns

Configure your dial plan based on the final design. The next section introduces the Dialed Number Analyzer tool and explains how this tool can help you verify whether the dial plan configured in the CallManager is working according to the design.

Dialed Number Analyzer

If you have a large dial plan and complex call-routing requirements, you end up with a huge number of dial plan components. The DNA tool helps you to troubleshoot issues when you have such complex dial plans.

From the CallManager perspective, you can make different types of calls, such as IP Phone-to-IP Phone calls, gateway-to-IP Phone calls, IP Phone-to-gateway calls, gateway-to-gateway calls, and calls to feature-specific patterns. The DNA tool recognizes all of these types of calls to display end-to-end details pertaining to the call. In CallManager, the calling and called party transformations affect the calling and called number. The tool considers all of these transformations configured under various dial plan elements and shows the final transformed number.

The DNA tool compares the dialed digits with the list of route patterns specified in the CSS for the device selected (IP Phone, gateway, trunk) and shows you the call flow path. If the call flow path shown by the DNA tool does not match what you thought it would, you can go back, change your dial plan, and rerun the DNA tool.

As discussed in the next section, you do not have to look at CallManager traces to know whether the call flow is correct. After verifying from the DNA tool that the call flow is as per your design, you can make a real call to check whether the call goes through. If you still have problems, the problem could be configurations on the terminating device or the devices outside the CallManager's control. For example, if you have an H.323 gateway, the DNA tool can show you the call reaching the H.323 gateway. The configurations on the H.323 gateway are not known to CallManager; therfore, they are not known to the DNA tool.

The DNA tool is available for installation on the Cisco CallManager Install Plugins page. You can also download the tool from Cisco.com:

http://www.cisco.com/cgi-bin/tablebuild.pl/callmgr-40

Analyzing the DNA Tool Output

Recall from the discussion in the "Calling Search Space Design" section in Chapter 6 that you can configure the CSS for an IP phone device at the device level, at the line level, or at both places. If you configure CSS at both places, CallManager places the partitions that appear in the line-level CSS on the top of the list and selects the best match.

Assume that you wanted the IP Phone 2001, with the following configuration, to make only local, long-distance, toll-free, and emergency calls, but no international calls:

The IP phone, 2001, is in partition pt_internal.

The device-level CSS is css_SJ.

The line-level CSS is css_line_LD.

The partitions that CSS references are the same as the ones described in Tables 6-41 to 6-43.

To test the configuration, in DNA, select Analysis > Phones and select the IP Phone whose line is 2001. Enter an international number as the dialed digits 90119187724436598. Figure 8-6 shows the output of the DNA tool.

var ldapserver = "10.1.1.1";
var ldapport = "389";
var ldapuserid = "IPT User";
var ldappassword = "cisco123";
var ldapsearchbase = "CN=Users, dc=xyz, dc=com"
s.server = ldapserver;
s.port = ldapport;
s.AuthName = ldapuserid;
s.AuthPasswd = ldappassword;
s.searchbase = ldapsearchbase;