12-30-2014 01:45 PM - edited 03-19-2019 08:59 AM
Using Cisco Call Manager 8.5
We have a homegrown AXL solution that provisions phones via addPhone, and is doing so successfully. However, seemingly without a consistent pattern, some of the phones subsequently fail a getPhone request. The publisher replies with a 500 Internal Server Error, empty faultstring and axlcode -1. But after going into CUCM admin, drilling down to the device, and simply clicking "Save" suddenly it starts working. No changes were made, just the Save button was clicked. I have tried sending all manner of AXL reset requests to the device via doDeviceReset to no avail - those requests themselves are successful and the phone does reset, but the getPhone requests are still "stuck" until the Save button is manually clicked. I have also sent updatePhone requests, which are also successful in applying whatever updates were sent and if applicable causes a restart, but still the getPhone returns a 500.
What function is the Save button within CUCM admin performing that phone resets are not and why is this happening?
Solved! Go to Solution.
01-05-2015 08:22 AM
Hi
It looks a bit like this to me:
https://tools.cisco.com/bugsearch/bug/CSCuj77735
I would check your AXL logs on the server (in tomcat/logs/axl/log4j) to see what errors are logged when you try to write or read the phone.
Also as a little test, here's what I'd do.
1) Create phone with your AXL stuff
2) get the config file for the phone from CUCM via TFTP and rename it to 'bad.xml'
3) Hit 'save' on the phone to 'fix' it
4) get the config file again, then diff it to the 'bad.xml' one you got earlier.
If you can see a difference in the product specific section, it might be a case of tweaking your AXL to set a few more parameters to 'fix' whatever isn't good in the product specific section.
Aaron
12-31-2014 01:17 AM
Hi
So the AXL call works, in as much as it creates the phone, but the phone does not work? That's odd...
Can you post up your server-side AXL log for review? Have you looked at it?
Aaron
12-31-2014 08:02 AM
Thanks Aaron
Actually the phone itself does work, it's just the getPhone AXL requests for it that are not. The logs aren't incredibly helpful but here are the request and server response. Note that the same app & request works fine after performing the Save in CUCM admin so it can't be an issue with the structure of the request.
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:axl="http://www.cisco.com/AXL/API/8.5">
<soap:Body>
<axl:getPhone xmlns="" xmlns:axl="http://www.cisco.com/AXL/API/8.5">
<name xsi:type="xsd:string">SEP123456789012</name>
</axl:getPhone>
</soap:Body>
</soap:Envelope>
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring></faultstring>
<detail>
<axlError>
<axlcode>-1</axlcode>
<axlmessage></axlmessage>
<request>getPhone</request>
</axlError>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
01-05-2015 08:22 AM
Hi
It looks a bit like this to me:
https://tools.cisco.com/bugsearch/bug/CSCuj77735
I would check your AXL logs on the server (in tomcat/logs/axl/log4j) to see what errors are logged when you try to write or read the phone.
Also as a little test, here's what I'd do.
1) Create phone with your AXL stuff
2) get the config file for the phone from CUCM via TFTP and rename it to 'bad.xml'
3) Hit 'save' on the phone to 'fix' it
4) get the config file again, then diff it to the 'bad.xml' one you got earlier.
If you can see a difference in the product specific section, it might be a case of tweaking your AXL to set a few more parameters to 'fix' whatever isn't good in the product specific section.
Aaron
01-06-2015 11:13 AM
Spot on, Aaron. I haven't tested a solution yet, will post when I have, but here's what I found. I verified the XML is 100% identical save for the vendorConfig section. Differences of note: there is a blank line after the parent element in the bad XML and each element is on its own line, whereas the good XML the entire vendorConfig is on one line (though may not look like it in this textbox). This doesn't render the XML malformed but you never know. Also each child element in the bad XML has a "xsi:type='xsd:XVendorConfig'" attribute. Perhaps most importantly the following 6 child elements are missing from the bad XML:
<recordingToneDuration></recordingToneDuration>
<logServer></logServer>
<lldpAssetId></lldpAssetId>
<ipv6LogServer></ipv6LogServer>
<sideToneLevel>0</sideToneLevel>
<headsetRecording>0</headsetRecording>
Here is the bad XML:
<vendorConfig>
<recordingToneRemoteVolume xsi:type="xsd:XVendorConfig">50</recordingToneRemoteVolume>
<minimumRingVolume xsi:type="xsd:XVendorConfig">0</minimumRingVolume>
<pcPort xsi:type="xsd:XVendorConfig">0</pcPort>
<webProtocol xsi:type="xsd:XVendorConfig">0</webProtocol>
<ehookEnable xsi:type="xsd:XVendorConfig">1</ehookEnable>
<headsetWidebandEnable xsi:type="xsd:XVendorConfig">0</headsetWidebandEnable>
<peerFirmwareSharing xsi:type="xsd:XVendorConfig">0</peerFirmwareSharing>
<forwardingDelay xsi:type="xsd:XVendorConfig">1</forwardingDelay>
<recordingToneLocalVolume xsi:type="xsd:XVendorConfig">100</recordingToneLocalVolume>
<disableSpeakerAndHeadset xsi:type="xsd:XVendorConfig">false</disableSpeakerAndHeadset>
<autoCallSelect xsi:type="xsd:XVendorConfig">1</autoCallSelect>
<useEnblocDialing xsi:type="xsd:XVendorConfig">1</useEnblocDialing>
<displayOnWhenIncomingCall xsi:type="xsd:XVendorConfig">0</displayOnWhenIncomingCall>
<disableSpeaker xsi:type="xsd:XVendorConfig">false</disableSpeaker>
<recordingTone xsi:type="xsd:XVendorConfig">0</recordingTone>
<settingsAccess xsi:type="xsd:XVendorConfig">1</settingsAccess>
<handsetHeadsetMonitor xsi:type="xsd:XVendorConfig">1</handsetHeadsetMonitor>
<g722CodecSupport xsi:type="xsd:XVendorConfig">0</g722CodecSupport>
<moreKeyReversionTimer xsi:type="xsd:XVendorConfig">5</moreKeyReversionTimer>
<garp xsi:type="xsd:XVendorConfig">1</garp>
<powerPriority xsi:type="xsd:XVendorConfig">0</powerPriority>
<voiceVlanAccess xsi:type="xsd:XVendorConfig">1</voiceVlanAccess>
<detectCMConnectionFailure xsi:type="xsd:XVendorConfig">0</detectCMConnectionFailure>
<headsetWidebandUIControl xsi:type="xsd:XVendorConfig">0</headsetWidebandUIControl>
<webAccess xsi:type="xsd:XVendorConfig">0</webAccess>
<autoSelectLineEnable xsi:type="xsd:XVendorConfig">0</autoSelectLineEnable>
<loggingDisplay xsi:type="xsd:XVendorConfig">1</loggingDisplay>
<spanToPCPort xsi:type="xsd:XVendorConfig">1</spanToPCPort>
</vendorConfig>
And the post-save good XML:
<vendorConfig>
<disableSpeaker>false</disableSpeaker><disableSpeakerAndHeadset>false</disableSpeakerAndHeadset><forwardingDelay>1</forwardingDelay><pcPort>0</pcPort><settingsAccess>1</settingsAccess><garp>1</garp><voiceVlanAccess>1</voiceVlanAccess><autoSelectLineEnable>0</autoSelectLineEnable><webAccess>0</webAccess><spanToPCPort>1</spanToPCPort><loggingDisplay>1</loggingDisplay><recordingTone>0</recordingTone><recordingToneLocalVolume>100</recordingToneLocalVolume><recordingToneRemoteVolume>50</recordingToneRemoteVolume><recordingToneDuration></recordingToneDuration><displayOnWhenIncomingCall>0</displayOnWhenIncomingCall><moreKeyReversionTimer>5</moreKeyReversionTimer><autoCallSelect>1</autoCallSelect><logServer></logServer><g722CodecSupport>0</g722CodecSupport><headsetWidebandUIControl>0</headsetWidebandUIControl><headsetWidebandEnable>0</headsetWidebandEnable><peerFirmwareSharing>0</peerFirmwareSharing><lldpAssetId></lldpAssetId><powerPriority>0</powerPriority><ehookEnable>1</ehookEnable><ipv6LogServer></ipv6LogServer><detectCMConnectionFailure>0</detectCMConnectionFailure><minimumRingVolume>0</minimumRingVolume><sideToneLevel>0</sideToneLevel><webProtocol>0</webProtocol><handsetHeadsetMonitor>1</handsetHeadsetMonitor><headsetRecording>0</headsetRecording><useEnblocDialing>1</useEnblocDialing></vendorConfig>
01-06-2015 12:06 PM
Aaand fixed! I found that the offending tools were building SOAP objects for each individual vendorConfig element, e.g. (with Perl):
SOAP::Data->name('vendorConfig' => \SOAP::Data->value(
SOAP::Data->name('elementOne')->value('valueOne')->type('xsd:XVendorConfig'),
SOAP::Data->name('elementTwo')->value('valueTwo')->type('xsd:XVendorConfig'),
...
))
Changing this code to just send the raw XML string worked:
SOAP::Data->name('vendorConfig')->value('<elementOne>valueOne</elementOne><elementTwo>valueTwo</elementTwo>')->type('axlapi:XVendorConfig')
Thanks for the nudge in the right direction Aaron!
01-07-2015 04:04 AM
No problem :-)
Please remember to rate useful responses and mark questions as 'answered' when appropriate to highlight useful content...
Aaron
07-29-2016 04:42 AM
Hi,
I tried getting response for getPhones for CUCM 8.6 version using powershell script. But i am getting the following response
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><S
OAP-ENV:Fault><faultcode>SOAP-ENV:Client</faultcode><faultstring>schema_reference.4: Failed to read schema document '/usr/local/thirdparty/jakarta-tomcat/webapps/axl/schema/6.1/Soa
pEnvelope.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.</faultstring><detail><axl:
Error xmlns:axl="http://www.cisco.com/AXL/API/1.0"><axl:code>5001</axl:code><axl:message>schema_reference.4: Failed to read schema document '/usr/local/thirdparty/jakarta-tomcat/we
bapps/axl/schema/6.1/SoapEnvelope.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.</a
xl:message><request>getPhone</request></axl:Error></detail></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
Pls help to overcome the issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide