Florian, That's good information but I don't believe it applies here. This would be after the phone has its config file and is in the process of registering via SCCP. I think the Station Capabilities Response is what is getting lost here. I had the same issue trying to register my 7861s on my lab cluster. I had to lower the MTU in CUCM in order for the TCP MSS to get updated to a lower value.
Brian On Tue, Jun 3, 2014 at 2:02 PM, Florian Kroessbacher < [email protected]> wrote: > Hy > > 8.3.3 does everything through udp tftp > 9.3. does the new method over http 6970 (so the size is greater than the > udp 576 Bytes) > > look here > > http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cuipph/7900_series/firmware/9_3_1/release_notes/P790_BK_RF1DAED3_00_rn-9_3_1-7900-series/P790_BK_RF1DAED3_00_rn-9_3_1-7900-series_chapter_00.html#P790_RF_H0DA5A91_00 > > Florian Kroessbacher > > gmail: [email protected] > > > 2014-06-03 19:38 GMT+02:00 Brian Meade <[email protected]>: > >> You can do the capture on the CUCM side via CLI but that doesn't help you >> prove you lost a packet since you'll also need from the phone side via Span >> To PC: >> >> utils network capture eth0 size all count 100000 file 7970testreg >> Press Ctr+c to end the capture after the reject. >> >> You can get the capture from RTMT via Trace&Log Central->Collect >> Files->Packet Capture Logs (on 2nd page). >> You can also use SFTP: >> file get activelog platform/cli/7970testreg.cap >> >> >> On Tue, Jun 3, 2014 at 1:29 PM, Mike King <[email protected]> wrote: >> >>> Hmm.. >>> >>> Before I bust out my span sessions, is there a way to packet capture >>> from the CUCM / Phone? >>> >>> >>> On Tue, Jun 3, 2014 at 1:22 PM, Brian Meade <[email protected]> wrote: >>> >>>> Sounds like an MTU issue to me based on those logs. Get captures from >>>> the phone side and CUCM. >>>> >>>> >>>> On Tue, Jun 3, 2014 at 1:04 PM, Mike King <[email protected]> wrote: >>>> >>>>> Now I'm more confused. >>>>> Did I pull the right Traces? >>>>> >>>>> <ServiceName name="Cisco CallManager"> >>>>> <ServiceName name="Cisco Tftp"> >>>>> >>>>> This is from the Callmanager trace: (attached is the whole log, >>>>> device MAC is 0019AAAA3EB6) >>>>> >>>>> 00268821.002 |12:51:14.196 |AppInfo |EndPointTransientConnection - An >>>>> endpoint attempted to register but did not complete registration >>>>> Connecting >>>>> Port:2000 Device name:SEP0019AAAA3EB6 Device IP address:10.103.5.133 >>>>> Device >>>>> type:119 Reason Code:27 Protocol:SCCP Device MAC address:0019AAAA3EB6 >>>>> IPAddressAttributes:3 LastSignalReceived:StationResponseTimerType >>>>> StationState:wait_capabilities App ID:Cisco CallManager Cluster >>>>> ID:StandAloneCluster Node ID:BE6K-CUCM >>>>> 00268821.003 |12:51:14.197 |AlarmErr |AlarmClass: CallManager, >>>>> AlarmName: EndPointTransientConnection, AlarmSeverity: Error, >>>>> AlarmMessage: >>>>> , AlarmDescription: An endpoint attempted to register but did not complete >>>>> registration, AlarmParameters: ConnectingPort:2000, >>>>> DeviceName:SEP0019AAAA3EB6, IPAddress:10.103.5.133, DeviceType:119, >>>>> Reason:27, Protocol:SCCP, MACAddress:0019AAAA3EB6, IPAddrAttributes:3, >>>>> LastSignalReceived:StationResponseTimerType, >>>>> StationState:wait_capabilities, AppID:Cisco CallManager, >>>>> ClusterID:StandAloneCluster, NodeID:BE6K-CUCM, >>>>> 00268821.004 |12:51:14.197 |AppInfo |StationD: (0001646) >>>>> RegisterReject text=''. >>>>> 00268822.000 |12:51:14.198 |AppInfo >>>>> |-->RISCMAccess::DeviceTransientConnection(...) >>>>> 00268823.000 |12:51:14.198 |AppInfo |Device Transient deviceName : >>>>> SEP0019AAAA3EB6, IPAddress : 10.103.5.133, IPv6Address : not shown, >>>>> IPv4Attribute :3, IPv6Attribute :0, Protocol : 1 >>>>> 00268824.000 |12:51:14.198 |AppInfo |DebugMsg deviceName : >>>>> SEP0019AAAA3EB6, DeviceType : 119, risClass: 1 >>>>> 00268825.000 |12:51:14.198 |AppInfo >>>>> |<--RISCMAccess::DeviceTransientConnection(...) >>>>> >>>>> >>>>> On Tue, Jun 3, 2014 at 11:57 AM, Ryan Ratliff (rratliff) < >>>>> [email protected]> wrote: >>>>> >>>>>> > Any Idea's why the phones are being rejected? >>>>>> >>>>>> Not from that log that I can tell. Look at the CCM traces. Obvious >>>>>> reasons are wrong device model in the database, not in the database at >>>>>> all >>>>>> and auto-registration is disabled, phone configured with a secure profile >>>>>> requiring an LSC and none is present. >>>>>> >>>>>> -Ryan >>>>>> >>>>>> On Jun 3, 2014, at 11:08 AM, Mike King <[email protected]> wrote: >>>>>> >>>>>> We just purchased a BE6K to setup a lab. >>>>>> >>>>>> I've run through the setup, and have that all sorted, or so I think. >>>>>> (So the environment may or may not be the issue) >>>>>> >>>>>> We have a couple of very phones we were going to recycle. >>>>>> >>>>>> Right now we have two, a 7970, and a 7971. >>>>>> >>>>>> The started life phone firmware at 6.0(2). Utilizing factory >>>>>> defaulting off my laptop, I got them to 8.3.3. (I couldn't get them to >>>>>> associated with 6.0(2)) >>>>>> >>>>>> Running 8.3.3, they were able to register, and function. >>>>>> >>>>>> I pushed the firmware up to 9.3(1SR3.1S) >>>>>> >>>>>> Now none of the phones are registering. I've read the release notes, >>>>>> and I should be able to goto 9.3.1 from 8.3.3 directly on these phones, >>>>>> with no further intermediate releases. >>>>>> >>>>>> Attached is one of the phone logs. Both phone's are showing the same >>>>>> behavior. >>>>>> >>>>>> The phone is just sitting there with the wrong date and time in the >>>>>> corner, and every once and awhile will print out "Registration Rejected: >>>>>> " >>>>>> >>>>>> Any Idea's why the phones are being rejected? >>>>>> <log199.log>_______________________________________________ >>>>>> cisco-voip mailing list >>>>>> [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> cisco-voip mailing list >>>>> [email protected] >>>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> cisco-voip mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
