[cisco-voip] What debug should I be looking at..

Wes Sisk wsisk at cisco.com
Mon Oct 31 10:59:37 EDT 2011


Ed,

7.0 should be close enough to 7.1.  

Based on this from your original output:
Protocol.:SCCP

It is an SCCP device from IOS that is triggering the transient connection attempt.  Any chance we can see the config?  Are there any SCCP controlled endpoints on this?

Another possibility is an SCCP device configured in IOS that is not configured in CUCM.  This was a rather systemic issue for a while due to:
CSCsw43113    BAT insert of SCCP VG224 does not add virtual endpoint
(Thanks Ryan!)


The CUCM SDI traces will show if this device actually attempts to register. If you'd prefer to avoid traces then grab a packet capture of traffic between CUCM and that IP:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080b36101.shtml

Wireshark decodes "enough" of the SCCP messages to find a register message and the included device name.  If not, submit a TAC case and TAC can use an updated SCCP decoder to find out what's going on.

/wes



On Oct 31, 2011, at 10:37 AM, Ed Leatherman wrote:

Wes,

Thanks for that, I will research that setting in later IOS versions..
right now my profiles are set for 7.0 on a CM 7.1.5 cluster, perhaps a
later IOS will have 7.1 specifically.

The resources appear to be fully registered at least from ccmadmin and
checking them in ios with 'show sccp':

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.x.x.x, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 777
Reported Max Streams: 46, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum
Packetization Period: 30

Conferencing Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.x.x.x, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 888
Reported Max Streams: 208, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum
Packetization Period: 30


On Mon, Oct 31, 2011 at 10:30 AM, Wes Sisk <wsisk at cisco.com> wrote:
> I think 'debug sccp events'
> 
> On CM transient connection means the TCP session aborted before registration completed. This is why CM does not have the devicename.
> 
> IIRC this was frequently caused by IOS mtp/conf/transcode sessions using a sccp profile that specifies an incorrect CUCM version.  The SCCP version is derrived from the configured CUCM version.
> http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a008084fe1f.shtml#table1
> 
> /wes
> 
> 
> On Oct 31, 2011, at 9:59 AM, Ed Leatherman wrote:
> 
> I have a 3845 setup with some MGCP controlled PRIs, and sccp
> controlled Conference and transcoding services. I'm getting
> DeviceTransientConnection messages from CallManager about this device:
> 
> %CCM_CALLMANAGER-CALLMANAGER-3-DeviceTransientConnection: Transient
> connection attempt. Connecting Port:27400 Device name [Optional].:
> Device IP address [Optional].:10.x.x.x Device type. [Optional]:255
> Reason Code [Optional].:6 Protocol.:SCCP IPAddressAttributes
> [Optional].:0 App ID:Cisco CallManager Cluster ID:OWP-PUB-Cluster Node
> ID:OWP-SUB-B
> 
> I'm getting transients approx every 8 minutes from different
> subscriber, 2 at a time so i'm assuming both transcode and conference
> are changing CM nodes. Doesn't appear to be affecting service to
> anyone but I want to track it down anyway. I do not appear to be
> getting any DeviceUnregistered entries related to these devices.
> 
> gigabit interfaces on the gateway and the upstream routers up to call
> manager look clean, no errors or drops.
> 
> Are there any IOS debugs that would help me figure out what is going
> on here? Currently on 15.0(1)M2, don't see any bugs related to sccp or
> call manager.
> 
> 
> --
> Ed Leatherman
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
> 
> 



-- 
Ed Leatherman





More information about the cisco-voip mailing list