[cisco-voip] Moving phones from CM 4.1.3 to a CME / 12.4(20)T

[Jeff Garvas]

This part of it is entirely labbed up on my desk so there isn't much
sensitive.  For brevity I've included what I believe is all of the relevant
config.     Just experimenting so there are not dial peers or fxo
connections yet.

I assumed the phones would be told to download whatever is defined in the
load command by model, but it appears that they're remembering their
original call manager configuration and ignoring the CME load command but
pulling the right option 150 address, etc via DHCP.  I dug around in the
7911 status messages and saw each of:

"DNS Timeout CiscoCM1", "TFTP NOT AUTHORIZED: 192.168.1.129", "CTL update
failed", two attempts to resolve a hostname based call manager from the old
configuration, "No DNS Server IP", and a "File Not Found" with no detail on
the filename being sought.

...but none of the tftp or sccp debugging on the router is revealing any
attempts to communicate with the router for any files or images.

Here is the CME router:

boot system flash:c2800nm-advipservicesk9-mz.124-20.T.bin
!
!
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 192.168.1.129
!
ip dhcp pool VOICE
   network 192.168.1.128 255.255.255.192
   option 150 ip 192.168.1.129
   default-router 192.168.1.129
   domain-name foo.com
!
tftp-server flash:P00307020200.bin
tftp-server flash:P00307020200.loads
tftp-server flash:P00307020200.sb2
tftp-server flash:P00307020200.sbn
tftp-server flash:P00403020214.bin
tftp-server apps11.8-3-2-27.sbn
tftp-server cnu11.8-3-2-27.sbn
tftp-server cvm11sccp.8-3-2-27.sbn
tftp-server dsp11.8-3-2-27.sbn
tftp-server jar11sccp.8-3-2-27.sbn
tftp-server SCCP11.8-3-3S.loads
tftp-server term06.default.loads
tftp-server term11.default.loads
!
telephony-service
 load 7911 SCCP11.8-3-3S
 load 7960-7940 P00307020200
 max-ephones 30
 max-dn 30
 ip source-address 192.168.0.1 port 2000
 max-conferences 8 gain -6
 transfer-system full-consult
 create cnf-files version-stamp Jan 01 2002 00:00:00
!
!
ephone-dn  1  dual-line
 number 1000 secondary 2025551111
!
!
ephone-dn  2  dual-line
 number 1112 secondary 2025551112
!
!
ephone  1
 device-security-mode none
 mac-address 001B.0C18.3E0C
 button  1:2 2:1
!
ephone  2
 device-security-mode none
 mac-address 0012.DAAD.3143
 button  1:2 2:1
!
ephone  3
 device-security-mode none
 mac-address 001B.D4A0.5D5E
 button  1:2 2:1
!


On Wed, Sep 3, 2008 at 1:29 PM, Paul <asobihoudai at yahoo.com> wrote:

> Let's see your configuration....[preferrably without any sensitive
> information in it...]
>
> Paul
>
> ----- Original Message ----
> From: Jeff Garvas <jeff at cia.net>
> To: cisco-voip at puck.nether.net
> Sent: Wednesday, September 3, 2008 9:47:14 AM
> Subject: [cisco-voip] Moving phones from CM 4.1.3 to a CME / 12.4(20)T
>
>
> I'm experimenting with CME in a 12.4(20)T install (2811, 3560) and trying
> to move phones from a CUCM 4.1.3 environment to CME.
>
> If I take a 7911 phone that is working in the CUCM environment and move it
> to the labbed up CME install it boots, states that its configuring IP,
> configuring the CM list, and then goes back to configuring IP.   It remains
> looping indefinately, but if I do a factory reset the phone will upgrade and
> register to CME.
>
> CME is configured to 'load 7911 SCCP11.8-3-3S' and there is a matching
> ephone configured as well, but it appears as if nothing is every queried via
> tftp.
>
> If I query the settings in the phone itself while its looping it still
> knows about the CUCM settings despite its new found DHCP / TFTP values.
>
> Is there a way to get the phone to upgrade/downgrade its image without
> doing a physical factory reset?  I'd like to be able to modify phones "in
> place" without needing to physically touch them.
>
> If I take the 'upgraded' phone back to the CUCM cluster it immediately
> upgrades without being factory reset.  Am I missing something in the CME
> configuration that could permit this?
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20080903/e38ab5ed/attachment-0001.html>