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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

CCM 3.1.3(a) Trace File Errors

CCM 3.1.3(a), three call managers total in the same cluster, two subscribers, one publisher.

A weird situation going on:

We've been having problems with 7940 and 7960 IP phones and VG248's that seem to drop their connection and start the registration process over again seemingly at random. This has been happening for over a month, and we're still trying to pin down the cause - is it the call managers? Is it the new switches we ordered? Is the wiring in the new closets substandard? We don't know, and personally I'm reaching my wit's end.

Here's the scenario:

1. All phones that are re-registering are connected to two brand new wiring closets. One closet has phones that re-register more than others.

2. Both closets have a VG248. However, I have four VG248's installed total, one also in a new closet that has had no problems. We never had any problems until a month ago.

3. I usually receive one error on the VG248 a few minutes before the phones restart themselves: "Registration Failed: Unexpected CM Register Acknowledgment"

4. The re-registering does not occur at the same time every day.

5. Today, the CallManager service gave me a "SDL Router Services Declared Dead" on the subscriber call manager the phones normally register with. The server was restarted, and everything came right back where it should.

6. The status on my VG248's and the inline power switches say they've been up for over a month, so I don't think it's a power loss issue.

7. A few days ago, while the phones tried to re-register, I was getting TFTP errors, seemingly from those IP phones whose registration took too long (several hours).

Here are some excerpts from the trace logs on the subscriber call manager (these were taken when the devices went to register with their correct subscriber call manager):

Cisco CallManagerStationInit: 83b7da4 Alarm alarmSeverity=2 text="Name=SEP0007EB9485C8 Load=3.1(1.7) Last=TCP-timeout" parm1=2050(802) parm2=527673536(1f73a8c0).

NTHSCM-Cluster 02/06/2003 20:22:17.637 192.168.134.12 192.168.115.31 Trace 2,100,95,1.286960 Cisco CallManagerStationInit - InboundStim - StationRegisterMessageId [Normal Device priority]: tcpHandle=0x83b7da4

NTHSCM-Cluster 02/06/2003 20:22:17.684 192.168.134.12 Cisco CallManager--*RISCMAccess::DeviceRegister(...)

NTHSCM-Cluster 02/06/2003 20:22:17.684 192.168.134.12 Cisco CallManagerDevice Register deviceName : SEP0007EB9485C8, IPAdress : 192.168.115.31, DeviceType : 8

NTHSCM-Cluster 02/06/2003 20:22:17.684 192.168.134.12 Cisco CallManager*--RISCMAccess::DeviceRegister(...)

Cisco CallManagerStationInit - New connection accepted. DeviceName=, TCPHandle=0x841b248, Socket=0x1ec0, IPAddr=192.168.149.36, Port=50834, Device Controller=[0,0,0]

NTHSCM-Cluster 02/06/2003 20:22:32.872 192.168.134.12 192.168.12.47 Trace 2,100,95,1.287487 Cisco CallManagerStationInit - KeepAliveMessage received on backup CM link. Droping KeepAliveAck. DeviceName=, TCPHandle=0x5b863f8, Socket=0x122c, IPAddr=192.168.12.47, Port=50449, Device Controller=[0,0,0]

NTHSCM-Cluster 02/06/2003 20:22:32.919 192.168.134.12 192.168.149.36 Trace 2,100,95,1.287488 Cisco CallManagerStationInit - InboundStim - StationRegisterTokenReqID: tcpHandle=0x841b248

NTHSCM-Cluster 02/06/2003 20:22:32.919 192.168.134.12 192.168.149.36 Trace 2,100,95,1.287488 Cisco CallManagerStationInit - Sending StationRegisterTokenAck registerQueueDept: 0 tokenQueueDepth: 1 tcpHandle=0x841b248

NTHSCM-Cluster 02/06/2003 20:22:33.059 192.168.134.12 Cisco CallManager--*RISCMAccess::DeviceRegister(...)

NTHSCM-Cluster 02/06/2003 20:22:33.075 192.168.134.12 Cisco CallManagerDevice Register deviceName : SEP0007EBCDCA07, IPAdress : 192.168.149.36, DeviceType : 8

NTHSCM-Cluster 02/06/2003 20:22:33.075 192.168.134.12 Cisco CallManager*--RISCMAccess::DeviceRegister(...)

NTHSCM-Cluster 02/06/2003 20:22:33.356 192.168.134.12 192.168.149.22 Trace 2,100,95,1.287506 Cisco CallManagerStationInit: 841b2ac Alarm alarmSeverity=2 text="Name=SEP0007EB3F53CC Load=3.1(1.7) Last=TCP-timeout" parm1=2054(806) parm2=378906816(1695a8c0).

NTHSCM-Cluster 02/06/2003 20:22:33.356 192.168.134.12 192.168.149.24 Trace 2,100,95,1.287507 Cisco CallManagerStationInit - InboundStim - StationRegisterTokenReqID: tcpHandle=0x841b504

NTHSCM-Cluster 02/06/2003 20:22:33.356 192.168.134.12 192.168.149.24 Trace 2,100,95,1.287507 Cisco CallManagerStationInit - Sending StationRegisterTokenAck registerQueueDept: 0 tokenQueueDepth: 1 tcpHandle=0x841b504

NTHSCM-Cluster 02/06/2003 20:22:33.356 192.168.134.12 192.168.149.22 Trace 2,100,95,1.287508 Cisco CallManagerStationInit - InboundStim - StationRegisterMessageId [Normal Device priority]: tcpHandle=0x841b2ac

Cisco CallManagerStationInit: 85690fc Alarm alarmSeverity=2 text="Name=SEP00062825D38F Load=3.1(1.7) Last=TCP-timeout" parm1=2054(806) parm2=345352384(1495a8c0).

Cisco CallManager***** StationInit - Socket Broken. DeviceName=Unknown, TCPHandle=0x841b75c, Socket=0x1e90, IPAddr=192.168.149.30, Port=0xc33b, Device Controller=[0,0,0]

NTHSCM-Cluster 02/06/2003 20:22:39.434 192.168.134.12 192.168.237.79 Trace 2,100,95,1.287741 Cisco CallManagerStationInit - StationCloseReq received: 0x841b75c

NTHSCM-Cluster 02/06/2003 20:22:39.434 192.168.134.12 Alarm Alarm Cisco CallManagerDeviceTransientConnection - Transient connection attempt. Connecting Port:2000 Device name [Optional].: Device IP address.:192.168.149.30 Device type. [Optional]:255 Reason Code [Optional].:6 App ID:Cisco CallManager Cluster ID:NTHSCM-Cluster Node ID:192.168.134.12

NTHSCM-Cluster 02/06/2003 20:22:39.434 192.168.134.12 192.168.237.79 Trace 2,100,95,1.287741 Cisco CallManagerStationInit - Closing Station connection DeviceName=, TCPHandle=0x841b75c, Socket=0x1e90, IPAddr=192.168.149.30, Port=49979, Device Controller=[0,0,0]

NTHSCM-Cluster 02/06/2003 20:22:39.434 192.168.134.12 Cisco CallManagerDevice Transient deviceName : , IPAddress : 192.168.149.30

Any ideas at this point would be greatly appreciated.

TMH

2 REPLIES
Bronze

Re: CCM 3.1.3(a) Trace File Errors

Take a look at the release notes for CCM 3.1.3a... There is a bug listed under open caveats that sounds like it matches your problem description. The resolution is to "Set runtime priority on StiView.exe to low using task manager. This will prevent the Cisco CallManager from stopping and restarting."

New Member

Re: CCM 3.1.3(a) Trace File Errors

Turns out we had a bad fiber connection somewhere along the line to that closet. Everything's been fixed, and the problem hasn't reoccurred.

TMH

267
Views
0
Helpful
2
Replies