[cisco-voip] How to get a Phone's .cnf.xml file from CUCM

Tue Oct 11 12:20:52 EDT 2011

The HTTP interface cited below is great.  Keep in mind the config file is in XML.  The browser might try to render that and give errors. You can still save the file and view it in your favorite XML or text editor.  This does not work if you are using encrypted config files.  It does work if you are only using signed config files.

A few other ideas in this area:

Depending on your CM version and phone loads the phones may report back to CM when config file parsing fails.  This would allow you to centrally report on phones with the problem:

Phones unregister for a plethora of reasons.  Historically we only got two bits of information when a phone unregistered:
1. CUCM reason code - the reason CUCM perceived the phone to unregister
2. Last= reason code - the reason the phone perceived that it unregistered

CUCM reason code came from event logs (syslogs) and Last=came from grep'ing SDI traces or doing device report/device search in RTMT and including last unregister reason.

That approach misses correlation such as:
* phones unregistering due to a specific protocol message not being passed and parsed properly
* phones unregistering due to issues on an access switch

We tried to address this with the enhanced alarm message added with the energywise feature in CM8.0.

Sample use case:
SIP Phones unregister when SIP inspection is enabled on ASA:

Packet capture shows the enhanced alarm message when phone re-registers:
Content-Length: 1471
Content-Type: application/x-cisco-alarm+xml
Content-Disposition: session;handling=required
<?xml version="1.0" encoding="UTF-8"?>
<x-cisco-alarm>
<Alarm Name="LastOutOfServiceInformation">
<ParameterList>
<String name="DeviceName">SEP108CCFE101EC</String>
<String name="DeviceIPv4Address">10.10.0.186/29</String>
<String name="IPv4DefaultGateway">10.10.0.185</String>
<String name="DeviceIPv6Address"></String>
<String name="IPv6DefaultGateway"></String>
<String name="ModelNumber">CP-7945G</String>
<String name="NeighborIPv4Address">10.10.10.1</String>
<String name="NeighborIPv6Address"></String>
<String name="NeighborDeviceID">cr-soho-fwadmins.uspto.gov</String>
<String name="NeighborPortID">FastEthernet0</String>
<Enum name="DHCPv4Status">1</Enum>
<Enum name="DHCPv6Status">0</Enum>
<Enum name="TFTPCfgStatus">1</Enum>
<Enum name="DNSStatusUnifiedCM1">4</Enum>
<Enum name="DNSStatusUnifiedCM2">4</Enum>
<Enum name="DNSStatusUnifiedCM3">4</Enum>
<String name="VoiceVLAN">103</String>
<String name="UnifiedCMIPAddress">10.10.112.37</String>
<String name="LocalPort">50763</String>
<String name="TimeStamp">128931588171913122087697191312211295244131221130647213122113302701312211341062131221140232413122114150451312211440334131221145204913122117105551289315872962</String>
<Enum name="ReasonForOutOfService">10</Enum>
<String name="LastProtocolEventSent">Sent:NOTIFY sip:29903 at 10.10.112.37 SIP/2.0  Cseq:3 NOTIFY CallId:91e7d448-36d1d5c0 at 10.10.0.186</String>
<String name="LastProtocolEventReceived"></String>
</ParameterList>
</Alarm>
</x-cisco-alarm>

In the SIP stack the last unacknowledged event sent from the phone is NOTIFY.  This leads directly to:
CSCtq15731    7900 Series NOTIFY message body missing trailing CRLF 
ASA dropped this malformed packet and causing phones to unregister.  The enhanced alarm message gives significant information about the device at the time of unregistration.

For your scenario the phones should report that config file parsing failed. I believe that will manifest as <Enum name="TFTPCfgStatus">0</Enum>
These alarms are routed to the alternate syslog that is available via RTMT.

Otherwise, there are a few known issues about bad formatting of config files.  I pulled these from the "Telephone Endpoints" RSS in the TAC Hot Issues RSS Feeds:
http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml
http://www.cisco.com/warp/public/146/news_cisco/data/syndication/ext/tachi/ExternalCUEP.xml
89xx/99xx Phone Cannot Parse Configuration File, Open CSCts73247
6941 phone hangs when service url configured for EM, Fixed CSCtr00081
6945 with firmware 9.2.1 fails to register running SCCP, Fixed CSCtr77596

Regards,
Wes

On Oct 11, 2011, at 9:07 AM, Bruno Takahashi wrote:

Actually the problem happens to just a few phones every now and then, and restarting a service for this particular customer is too complicated =)
The "fix" I use is to make any change on the device configuration.
I was able to get the .cnf files using windows cmd " tftp "host" get SEPxxxx.cnf.xml", but will try the web way Nicholas mentioned and I looked for since it sounds easier.
Now I'll compare both files to see if anything looks like a root cause for this.

On Tue, Oct 11, 2011 at 1:37 AM, Dennis Heim <Dennis.Heim at cdw.com> wrote:
Have you tried cycling the Cisco TFTP service? That should force callmanager to regenerate the tftp cache.

Dennis Heim
Network Voice Engineer
CDW  Advanced Technology Services
10610 9th Place
Bellevue, WA 98004

317.569.4255 Single Number Reach
317.569.4201 Fax 
dennis.heim at cdw.com
cdw.com/content/solutions/unified-communications/

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nicholas Samios
Sent: Monday, October 10, 2011 8:05 PM
To: Anthony Holloway; Bruno Takahashi

Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] How to get a Phone's .cnf.xml file from CUCM

Use HTTP - thanks Wes J

http://myccmserver:6970/SEPmacaddress.cnf.xml

https://puck.nether.net/pipermail/cisco-voip/2011-February/019958.html

https://supportforums.cisco.com/message/3153749#3153749

--
Nicholas Samios

Systems Engineer

<image001.gif>
Level 2, 293 Camerbwell Road, Camberwell VIC 3124
ph: (08) 9213 1316 mob: 0411 618 835 fax: (08) 9221 4539

email: nsamios at staff.iinet.net.au

<image002.jpg><image003.jpg><image004.jpg><image005.jpg>

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Tuesday, October 11, 2011 1:28 PM
To: Bruno Takahashi
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] How to get a Phone's .cnf.xml file from CUCM

On Windows you can just pop open a command prompt window and type:

C:\>tftp <cucm_tftp_server> get SEP<MACADDRESS>.cnf.xml

Example:

C:\>tftp 10.1.1.1 get SEP0000DEADBEEF.cnf.xml

Source:

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/tftp.mspx?mfr=true

NOTE: Win7 users may need to turn on TFTP command line client from within Add/Remove programs first.

On *nix systems: 'man tftp' should tell you what you need to know.

You may also want to SPAN the switch port the phone is on, and look at the traffic.  Perhaps the .cnk.xml file is not even making it to the phone, or perhaps there are missing packets.  TFTP is UDP after all, and therefore has no re-transmits.

-Anthony

On Mon, Oct 10, 2011 at 6:29 PM, Bruno Takahashi <brunots at gmail.com> wrote:

Hello all,

We ran into a problem where it seems the .cnf.xml file of the phones is corrupted so the phone does not registers.

If you change any detail on the device configuration (i.e. add a "-" on description) the phone registers back.

I assume it works because a new file is generated and the phone gets this new, non-corrupted file from TFTP and is able to register.

What I wanted to do is to get the .cnf.xml file from a phone that is not working, then "fix" it and get the new file again to compare and see if something can be found to indicate why this happened.

Does anyone knows how can I get the .cnf file or knows any additional details on this issue?

Thanks!

-- 
Bruno

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-- 
Bruno Takahashi da Silva
Engenheiro de Telecomunicações
CCVP®, CCNA®, CCNA® Voice

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20111011/f77b3b78/attachment.html>