AXL: listRemoteDestination causing CUCM hang after upgrade to 14

[lwrightssl]

Hi,

We've recently upgraded our CUCM infrastructure to 14.0.1.12900-161 from 11.5 SU10, and since that point we've found that a script we use to list out all Remote Destinations is causing the CUCM node which is queried to CPU flatline at 100% without returning a response - the node then has to be rebooted. Example AXL query below - note the issue appears independent of the API version that's used (XML below has 11.5 in it).

This issue is directly attributable to the CUCM upgrade as it's been working fine unchanged for the past 6 years or so.

Sample, simple, XML query which demonstrates the issue via a CURL query below:

<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:ns0="http://www.cisco.com/AXL/API/11.5" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><ns1:Body><ns0:listRemoteDestination><searchCriteria><remoteDestinationProfileName>%</remoteDestinationProfileName></searchCriteria><returnedTags><name></name><destination></destination><answerTooSoonTimer></answerTooSoonTimer><answerTooLateTimer></answerTooLateTimer><delayBeforeRingingCell></delayBeforeRingingCell><remoteDestinationProfileName></remoteDestinationProfileName><enableMobileConnect></enableMobileConnect><mobilityProfileName></mobilityProfileName></returnedTags></ns0:listRemoteDestination></ns1:Body></SOAP-ENV:Envelope>

Support appreciated please - we have a formal paid-for Cisco support contract for CUCM but TAC have directed us to post here.

Thanks,

Lawrence.

[Elliot Dierksen]

I am just guessing, but perhaps this is an issue with how the SUDS libraries are interacting with CUCM 14? What version of Python are you using, and are all the libraries up to date? I am sure this isn't what you want to hear, but you really may have to redo the data queries to use Zeep to fully resolve this. Anything else you do is really a band-aid.

[lwrightssl]

So this is why I raised this issue using raw SOAP that's being sent to CUCM 14 and left the programming language out of it. Best practice being to generate a proof-of-concept failure example that can be replicated in the easiest manner possible - using cURL.

It's all down to a question of:

Is the SOAP query that I'm sending to CUCM valid? I believe it is, because:

1. CUCM isn't sending me an error like it does when you send it an invalid query
2. If you change the only piece of data in the query, i.e. the query term "%" to "A%" it works fine
3. It's worked fine for the last 6+ years against CUCM 10.5 thru 11.5

The programming language which generates the above SOAP query really should be irrelevant unless it's generating something invalid, in which case, spot on, we need to address that. However I've seen no evidence that the SOAP that's generated is invalid. Indeed, it's entirely possible (I'd actually say almost certain) that we migrate to Zeep, make a listRemoteDestination query and hit *exactly* the same bug, because from a SOAP query perspective, absolutely nothing has changed.