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

Mon Oct 31 11:47:35 EDT 2011

No SCCP devices that I know of, other than the conf and transcode.
I'll work on a packet cap or something this afternoon.

Here is my sccp config, with the MGCP ccm-manager stuff thrown in for
good measure:

! MGCP config ccm-manager
ccm-manager redundant-host x.x.x.y
ccm-manager mgcp
no ccm-manager fax protocol cisco
ccm-manager config server 10.x.x.a 10.x.x.z
ccm-manager config
!
sccp local Loopback1
sccp ccm 10.x.x.x identifier 1 version 7.0
sccp ccm 10.x.x.y identifier 2 version 7.0
sccp ccm 10.x.x.z identifier 3 version 7.0
sccp
!
sccp ccm group 999
 description CCM Group for Transcoders and Conferencing
 bind interface Loopback1
 associate ccm 1 priority 1
 associate ccm 2 priority 2
 associate ccm 3 priority 3
 associate profile 888 register OWP_Conf
 associate profile 777 register OWP_Trans
!
dspfarm profile 777 transcode
 codec g711ulaw
 codec g711alaw
 codec g729ar8
 codec g729abr8
 maximum sessions 23
 associate application SCCP
!
dspfarm profile 888 conference
 codec g711ulaw
 codec g711alaw
 codec g729ar8
 codec g729abr8
 codec g729r8
 codec g729br8
 maximum sessions 26
 associate application SCCP

On Mon, Oct 31, 2011 at 10:59 AM, Wes Sisk <wsisk at cisco.com> wrote:
> 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
>
>
>

-- 
Ed Leatherman