Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

ATA186 with CM 3.2 Problem

I have three ATA-186 set to be put into production. I used the special image required for Media Gateway Control Protocol (MGCP) or Signaling Connection Control Part (SCCP) so the Call Manager servers could register the phones. My first 2 phones were setup correctly no problem, the CM even recognized the phones as Default ATA's. My 3rd ATA was going well. The image upgrade completed and I started to look for the phone on my CM box. For some weird reason the CM picked up the phone as a 7960 instead of an ATA box. I read the URLS below and it said 3.1 and 3.0 (Call Manager) will register the phone as a 7960 while 3.2 will register the phone as Default ATA 186.

URLS READ:

http://www.cisco.com/warp/public/788/voip/ata_basicconfig.html

http://www.cisco.com/warp/public/788/voip/ata_sccp.html

How can I change it to where it is registered as a Default ATA 186? I have tried deleting the box from the CM. I have redid the image upgrade and it still registers as a 7960. The ATA works, but I would prefer it to work like the first 2 did and register correctly as a Default ATA 186. Any thoughts?

Thanks for your help.

-G

2 REPLIES

Re: ATA186 with CM 3.2 Problem

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center (http://www.cisco.com/tac) or speak with a TAC engineer. You can open a TAC case online at http://www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

Community Member

Re: ATA186 with CM 3.2 Problem

Glenn,

I had a nightmare with the ATA's here is what we found out.

ATA Booting Process

When the Analog Telephone Adaptor first boots, it attempts to TFTP its configuration file from a TFTP server. If both the UseTFTP and TFTPURL parameters in the device configuration of the ATA are set to 0, then the ATA uses the Option 150 value from its DHCP server in order to determine the configuration file to download.

When looking for the file to download, the ATA will request (in this order) the following files: ATA.cnf.xml, SEP.cnf.xml, and XMLDefault.cnf.xml; and will load the first file that it successfully receives from the TFTP server. The reason the ATA looks for all of these files is that SCCP integration with Call Manager was originally done by having the ATA appear and register as a 7960 phone.

From the traces we took last night (and what makes sense), the configuration file type that the ATA downloads determines how the ATA registers with Call Manager. If it downloads an ATA configuration file, then the adaptor registers as an ATA; if it downloads an SEP file, then the adapter registers as a 7960 phone. It is also important to remember that this process is repeated for EACH enabled port on the ATA. In other words, the ATA registers each port as a distinct device in Call Manager.

Once the ATA has downloaded a configuration file and registered with Call Manager, it periodically (for the interval specified in CfgInterval) checks for new configuration files, using the same file list and same order as the boot process above. The same applies if the ATA gets timeouts when trying to download its configuration file. It simply will continue looking for the three configuration files listed above at increasingly longer intervals until it downloads one successfully.

Call Manager Auto Registration

Each Call Manager in the cluster can be configured to support auto registration or not. Enabling auto registration on the Call Manager allows the administrator to specify a range of automatically assigned directory numbers (DN), and thus avoid explicitly entering the devices into Call Manager. With auto registration disabled, administrators must explicitly add the phones into the Call Manager administration page, which in turn creates a configuration file for the device named .cnf.xml, where is ATA, SEP, CTI, etc. Enabling auto registration on a Call Manager essentially enables the automatic creation of these configuration files.

This may be best illustrated with an example: Say you have a hardware 7960 phone, with a MAC address of 00089925813b. When the phone boots up and after getting a DHCP address, it will contact its TFTP server and request the file SEP00089925813b. If the file exists, then the phone has been explicitly added into Call Manager (or auto registered before), and Call Manager immediately serves the file. If the file does not exist and auto registration is DISABLED, then Call Manager returns a “File Not Found” error in a TFTP response message to the device. If auto registration is ENABLED, then Call Manager immediately creates and serves the configuration file to the device.

Causes for Inappropriate Registration

From the traces last night, there appear to be two distinct (but related) vectors that cause the ATA to register incorrectly with Call Manager. First, if the ATA has not been added to Call Manager and auto registration is ENABLED, Call Manager will return a “File Not Found” TFTP error when the ATA requests its ATA configuration file, but create and return successfully the SEP configuration file (see above for background on the ATA’s booting and registration process). Essentially, the Call Manager will not create an ATA configuration file, even with auto registration ENABLED. The only way to create this file appears to be explicitly adding the ATA to Call Manager.

Second, if the Call Manager is unavailable to the ATA for any reason (Call Manager is down, network issues, etc.); and the timing is such that a Call Manager with auto registration ENABLED becomes reachable when the ATA is requesting an SEP configuration file, then Call Manager will create the SEP configuration file and serve it to the ATA. As with the first case above, this causes the ATA to register with Call Manager as a 7960 phone.

Recommendations

We believe that the main thing that will address this problem, at least in the short term, is to DISABLE auto registration on all Call Manager clusters. This will prevent the Call Manager from dynamically creating the SEP configuration files that cause the ATA to register as a phone. During our testing last night, the ATA never registered as a phone with Call Manager when auto registration was DISABLED.

A related fix is to set the Skinny ID (SID) to 0 for any unused ATA port in the device’s configuration page. Setting the SID to 0 for any ATA port explicitly disables that port, preventing the ATA from attempting to register the port at all. By default, (again, see above) the ATA will attempt to register each of its analog ports as a distinct device in Call Manager. In cases where only one ATA port has been added to Call Manager, and the ATA is attempting to register its other (unused port), one of two things will happen: The port will register as a 7960 phone if auto registration is DISABLED; or Call Manager will record excessive “transient connection attempt” errors in its event log if auto registration is DISABLED. Explicitly disabling unused ports by setting the SID to 0 will prevent both of these from happening.

Send me you e-mail address and I will send you a doc I wrote up. there is also some work to be done on the Voice gateway.

Stephen

126
Views
0
Helpful
2
Replies
CreatePlease to create content