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
