Solved: Re: AXL getPhone 500 Server Error - until "Save"

bretsfu6g3 · ‎12-30-2014

Cross-posting from support communities:

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?

bretsfu6g3 · ‎01-06-2015

Solution update! 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')

View solution in original post

npetrele · ‎01-01-2015

Does your addPhone include product-specific information (data in <vendorConfig>)?

Could you post a sanitized example of your addPhone and getPhone requests (and updatePhone if used)?

Thanks

bretsfu6g3 · ‎01-02-2015

Hi Nicholas,

As a matter of fact it does. I'm hopeful that this is a lead, if you're asking! Here is an addPhone example. I have replaced a few arbitrary fields with ALL_CAPS but left the vendorConfig section alone. Eager to hear your thoughts - thanks!

<?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:addPhone xmlns="" xmlns:axl="http://www.cisco.com/AXL/API/8.5">

<phone>

<useTrustedRelayPoint xsi:type="xsd:string">Default</useTrustedRelayPoint>

<joinAcrossLines xsi:type="xsd:string">Default</joinAcrossLines>

<softkeyTemplateName xsi:type="xsd:string">SOFTKEY_TEMPLATE_NAME</softkeyTemplateName>

<commonPhoneConfigName xsi:type="xsd:string">Standard Common Phone Profile</commonPhoneConfigName>

<networkLocale xsi:type="xsd:string">United States</networkLocale>

<description xsi:type="xsd:string">PHONE_DESCRIPTION</description>

<locationName xsi:type="xsd:string">LOCATION_NAME</locationName>

<class xsi:type="xsd:string">Phone</class>

<userlocale xsi:type="xsd:string">English United States</userlocale>

<deviceTrustMode xsi:type="xsd:string">Not Trusted</deviceTrustMode>

<preemption xsi:type="xsd:string">Default</preemption>

<dndOption xsi:type="xsd:string">Use Common Phone Profile Setting</dndOption>

<mlppIndicationStatus xsi:type="xsd:string">Default</mlppIndicationStatus>

<singleButtonBarge xsi:type="xsd:string">Default</singleButtonBarge>

<presenceGroupName xsi:type="xsd:string">Standard Presence group</presenceGroupName>

<deviceMobilityMode xsi:type="xsd:string">Default</deviceMobilityMode>

<outboundCallRollover xsi:type="xsd:string">No Rollover</outboundCallRollover>

<product xsi:type="xsd:string">Cisco 7975</product>

<certificateOperation xsi:type="xsd:string">No Pending Operation</certificateOperation>

<disableSpeakerAndHeadset xsi:type="xsd:XVendorConfig">false</disableSpeakerAndHeadset>

<disableSpeaker xsi:type="xsd:XVendorConfig">false</disableSpeaker>

</vendorConfig>

<lines>

<line>

<ringSetting xsi:type="xsd:string">Use System Default</ringSetting>

<displayAscii xsi:type="xsd:string">Bret Swanson</displayAscii>

<consecutiveRingSetting xsi:type="xsd:string">Flash Only</consecutiveRingSetting>

<display xsi:type="xsd:string">Bret Swanson</display>

<label xsi:type="xsd:long">DIRNUM</label>

<asciiLabel xsi:type="xsd:long">DIRNUM</asciiLabel>

<e164Mask xsi:type="xsd:string">1XXXXXXXXXX</e164Mask>

<dirn>

<pattern xsi:type="xsd:long">DIRNUM</pattern>

</dirn>

</enduser>

</associatedEndUsers>

</line>

</lines>

</phone>

</axl:addPhone>

</soap:Body>

</soap:Envelope>

There is nothing special about the getPhone:

<?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">

</axl:getPhone>

</soap:Body>

</soap:Envelope>

npetrele · ‎01-05-2015

Thanks for the samples.

There's a similar-looking bug involving XML and <vendorConfig> which is fixed in 8.6(2.26154.1). The workaround is basically the same -- go to the phone config page and save it.

Is it possible for you to update your installation?

bretsfu6g3 · ‎01-05-2015

Thank you for the confirmation. We are a very large organization and I have no control over the update schedule - what I do have control over is the application(s) that are causing phones to be added via AXL. I will see if adding the phones sans vendorConfig and then sending an updatePhone has any better luck. Barring that I'll document the known issue and wait patiently for an updated version to resolve this issue.

Thanks again!

npetrele · ‎01-05-2015

Glad to help!

If doing the updatePhone doesn't help, try to add delays (sleep) before/after the add, update, and/or reset operations. The bug description implies that there's a race condition somewhere, so a deftly located sleep might work around it. You'll probably have to play with the sleep duration and location of the sleeps in the code to find out what works.

bretsfu6g3 · ‎01-06-2015

Solution update! 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')

npetrele · ‎01-06-2015

Excellent! I'm so glad you found the problem. Yes, Soap libraries for various languages are typically poorly documented and can be pretty unpredictable until you stumble on issues like this. Thanks for reporting back!