Registration Rejected: DBCo... - New 7942 Phones

Answered Question
Nov 17th, 2008

Hello,

We recently received some new 7942 phones and had some issues getting them to work. We discovered we needed to upgrade our Callmanager version, and add the latest device pack. We have done both of these and are currently running as follows:

Cisco Callmanager version: 4.1(3)

Device Pack: ciscocm.4-1-DevPack-78

The device defaults are set to use SCCP42.8-3-5S for the 7942 phones. When first connected, the phones appear to upgrade via tftp with no problem, then reboot. Then the error: Registration Rejected: ErrorDBCo... appears.

The Status Messages screen repeatedly scrolls the following:

<timestamp> SEP<MAC>.cnf.xml

<timestamp> No CTL Installed

<timestamp> File Not Found: CTLFile.tlv

In reading through some troubleshooting docs here, it was mentioned to check the .cnf.xml files on the server - however I have searched both our call managers (both house tftp for redundancy) and neither seems to have any of these files.

The TFTP paths on both are quite full of what I am sure are old and outdated configs - but these systems were installed long before I arrived here so I am loathe to clean them up.

Any help in getting these phones up and running would be appreciated.

I would also like some recommendations on proper configuration of our phone cluster. We are small - with only about 300 phones. 2 Call Managers, one publisher, one subscriber. Both run TFTP. DHCP is handled by our domain controllers. Should we have one central location for TFTP?

I have this problem too.
0 votes
Correct Answer by Rob Huffman about 8 years 2 months ago

Hi David,

I would schedule a time to give this a try. There is a need to reboot when adding support for a "new" device type;

Procedure

NOTE: Apply this patch to all of your Cisco CallManager servers, beginning with the publisher server and TFTP server.

**When applying this Device Package to enable new device support, a cluster-wide reboot is required for those devices to register successfully. A clusterwide reboot IS NOT required when running to update existing firmware/support.

If installing on a Cisco Unified CallManager version earlier than 4.1(3)sr2, the following message will be displayed: “Install on all nodes is required. All nodes will be rebooted as part of the installation.”

If installing on Cisco Unified CallManager 4.1(3)sr2 (recommended), the following message will be displayed: "Install on Publisher and TFTP server is required. Installation on all nodes is highly recommended." A clusterwide install/reboot is required.

From these older Device Pack Notes (this would be for your DevPak as well :)

http://ftp-sj.cisco.com/cisco/crypto/3DES/voice/callmgr/4.1/ciscocm.4-1-DevPack-43_readme.htm

Hope this helps!

Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2.9 (8 ratings)
Loading.
Rob Huffman Mon, 11/17/2008 - 13:34

Hi David,

Did you upgrade CCM to at least Service Release sr5b? This is the minimum version that supports the 7942's.

Here is some related info;

7942G Call Control Compatibility

Supported in Cisco Unified Communications Manager Versions 4.1(3)sr5b, 4.2(3)sr2b, 4.3(1), 5.1.1(b), 5.1(2), 6.0(1) and greater

Supported in Cisco Unified Communications Express and SRST Version 4.1

Cisco Unified IP Phone 7942G

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps379/ps8535/product_data_sheet0900aecd8069bb68.html

Hope this helps!

Rob

Jaime Valencia Mon, 11/17/2008 - 15:37

are they trying to auto-register or did you configured them previously??

are these 7942G or 7942G-GE??? they're not the same to the system and need to be configured using the right option, otherwise that error can happen

HTH

java

if this helps, please rate

dbwebster Mon, 11/17/2008 - 16:34

They are manually configured. I have also tried auto registration and this does not work either.

The phone is picking up all the correct settings - both call managers, the proper DHCP server and VLAN, and TFTP servers, however it simply won't register.

I don't believe there is a 7942G-GE, perhaps you are thinking the 7941G-GE.

These are 7942G phones, and that is the option being selected.

Rob Huffman Tue, 11/18/2008 - 06:45

Hi David,

Just for troubleshooting purposes can you please try setting up these 7942's in a Device Pool that only references the Publisher (not subscriber) in it's Callmanager Group. It almost sounds like there might be a Replication problem.

Let us know,

Rob

dbwebster Tue, 11/18/2008 - 07:27

Rob,

Alright, done. I set up a test pool with only the Publisher in the CM Group, same error.

Once again the phone recieves all proper settings for Call Manager, Vlan, IP, TFTP, etc. but will not register.

allan.thomas Tue, 11/18/2008 - 08:19

Curious as to why the phone would look for the CTL file?

The Certificate Trust List is a list of CallManager and TFTP servers with which the IP Phone is able to connect to. It would appear that the IP Phone is attempting to tftp the CTL file which doesn't exist.

Have you activated in CTL in your cluster? If this is not the case is the phone configured for non-secure? In the phone device, there is an option Device Security Mode, what is this set to?

What is the Device Security Mode parameter under Enterprise Parameters? Default is Non Secure, this is what the default is on the device.

If CTL is installed, then you are possibly hitting a known issue which was first discovered in 8.4.1 which causes phones not to register when CTL is configured across the cluster in mixed mode.

The workaround was to change CTL authentication to non secure. This was apparently resolved in 8.4.1(SR2)

Can you advise what all the security settings are on one of the 7942 Phones. Press the settings softkey and select option 4 Security Configuration.

Hope this helps

Allan.

Pls rate helpful posts.

dbwebster Tue, 11/18/2008 - 08:38

Allan,

Device Security in Enterprise Parameters is set to Non Secure (all default).

On the phone, Security Configuration:

1 Web Access Enabled: Yes

2 Security Mode: Non Secure

3 MIC: Installed

4 LSC: Not Installed

5 CTL File: Not Installed

6 Trust List - under this option there is a locked option for Trust List that is checked?

7 CAPF Server

8 802.1X Authentication (disabled)

9 802.1X Authentication Status (disabled)

Thanks.

dbwebster Tue, 11/18/2008 - 11:11

Quick update, tried another 7942 out of the box, same thing. Any other ideas out there??

allan.thomas Tue, 11/18/2008 - 12:03

Hi David, can you go back into the Phone Security Configuration options, and then unlock the Phone (**#) and then press 6 to expand the Trust List, is there anything listed?

Regards

Allan

dbwebster Tue, 11/18/2008 - 12:32

Allan,

Unlocked the list but nothing appears when pressing 6, I assume this means nothing is there.

allan.thomas Tue, 11/18/2008 - 13:05

Hi David, you are correct.

Have you tried statically configuring IP on the phone instead of DHCP?

Manually set the IP Address, Mask, Default Gateway and primary TFTP address on the phone.

Then try substituting the TFTP IP address with secondary TFTP server and reset the phone.

Incidentally, did you installed the device-pack on both TFTP servers?

Regards

Allan.

dbwebster Wed, 11/19/2008 - 07:03

Allan,

I have not tried this, but I can. I don't suspect it's related since the phones TFTP upgrade when first plugged in, and are receiving the correct IP addressing for the voice VLAN, mask, gateway, and tftp servers set in option 150 on the DHCP servers. So, essentially they are talking to the network fine, but not playing well with CallManager.

Speculative - but that's why I'm asking the questions here, not answering them. :)

Anyway, I'll try a static configuration and let you know.

Edit: Yes, the device pack was installed to both of our TFTP servers (which reside on both CallManagers - publisher and subscriber).

I may also try having the phone register with only the subscriber and see what happens.

Thanks!

Rob Huffman Wed, 11/19/2008 - 07:26

Hi David,

Did you bounce all the boxes after the Device Pack was installed?

Rob

dbwebster Wed, 11/19/2008 - 07:42

Rob,

We did not restart either of the CallManager servers as the DevPack didn't indicate one was needed.

If you mean the phones, we reset a couple of them to test the update, and had planned a mass reset of all phones overnight, but decided against it when we discovered the new 7942's weren't registering.

Of the ones we tested, our existing 7940 and 7960's seemed to update and come back up fine.

Thanks.

Correct Answer
Rob Huffman Wed, 11/19/2008 - 09:01

Hi David,

I would schedule a time to give this a try. There is a need to reboot when adding support for a "new" device type;

Procedure

NOTE: Apply this patch to all of your Cisco CallManager servers, beginning with the publisher server and TFTP server.

**When applying this Device Package to enable new device support, a cluster-wide reboot is required for those devices to register successfully. A clusterwide reboot IS NOT required when running to update existing firmware/support.

If installing on a Cisco Unified CallManager version earlier than 4.1(3)sr2, the following message will be displayed: “Install on all nodes is required. All nodes will be rebooted as part of the installation.”

If installing on Cisco Unified CallManager 4.1(3)sr2 (recommended), the following message will be displayed: "Install on Publisher and TFTP server is required. Installation on all nodes is highly recommended." A clusterwide install/reboot is required.

From these older Device Pack Notes (this would be for your DevPak as well :)

http://ftp-sj.cisco.com/cisco/crypto/3DES/voice/callmgr/4.1/ciscocm.4-1-DevPack-43_readme.htm

Hope this helps!

Rob

dbwebster Wed, 11/19/2008 - 09:08

Rob,

I love/hate it when things come down to fundamentals. Lesson learned.

The 7942's are up and running after a reboot.

Thanks everyone for your help and suggestions. Ratings all around.

Rob Huffman Wed, 11/19/2008 - 09:19

Hey David,

You are most welcome! These things are always tricky to say the least. You would think that if the new device is offered under the "Device Defaults" you would be good to go. I think that this had us all fooled :)

Cheers!

Rob

Actions

This Discussion