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

[Ed Leatherman]

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