- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-05-2014 04:57 AM
I'm using the getGateway request method to get the gateway configurations from one cluster and then importing the gateway configuration to a target cluster. One thing I noticed is that the getGateway method returns multiple "subunits" elements under the "unit" XML hierarchy when I believe it should only be returning a single "subunits" element based on the schema. Here's an example output from the getGateway response;
'
When I believe it should be returning the following "subunits" XML hierarchy;
This is causing us a problem because we are not able to "copy/paste" the response output from the getGateway method from one cluster to the addGateway method issued to a target cluster without manipulating the XML. The result of using the response of the getGateway method without manipulating the subunits to comply with the scheme is that we only end up configuring the children configuration within the first "subunits" element. The subsequent "subunits" are ignored.
Is this working as designed?
Thanks,
Anthony
Solved! Go to Solution.
- Labels:
-
AXL
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2014 03:31 PM
Hi Anthony,
Thank you for bringing this to our attention. I have reproduced the issue with schema 8.5, and we will work on getting it resolved. It seems like it's also an issue in more recent AXL schemas like 9.0 and 10.0 as well. I'll keep you posted on the status of this defect.
Thanks,
Adrienne

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2014 08:46 AM
Hi Anthony,
What version of AXL schema and CUCM are you using?
Thanks,
Adrienne
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2014 08:55 AM
Adrienne,
CUCM 8.6.2.23900-10
AXL Schema 8.5
Thanks,
Anthony
POST https://127.0.0.1:65460/axl/
Accept: text/*
Authorization: Basic <taken out>
Content-Type: text/xml
SOAPAction: "CUCM:DB ver=8.5 getGateway"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/8.5">
<soapenv:Header/>
<soapenv:Body>
<ns:getGateway sequence="?">
<domainName>DCFDHRBLU1-2811</domainName>
<returnedTags uuid="?">
<domainName>?</domainName>
<description>?</description>
<product>?</product>
<protocol>?</protocol>
<callManagerGroupName uuid="?">?</callManagerGroupName>
<units>
<unit>
<index>?</index>
<product>?</product>
<subunits>
<subunit>
<index>?</index>
<product>?</product>
<beginPort>?</beginPort>
</subunit>
</subunits>
</unit>
</units>
<vendorConfig>
</vendorConfig>
</returnedTags>
</ns:getGateway>
</soapenv:Body>
</soapenv:Envelope>
HTTP/1.1 200 OK
Connection: close
Date: Mon, 09 Jun 2014 15:52:38 GMT
Server:
Content-Length: 1664
Content-Type: text/xml;charset=UTF-8
Client-Date: Mon, 09 Jun 2014 15:52:38 GMT
Client-Peer: 127.0.0.1:65460
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Verizon/OU=Cary/CN=cwma-cucm01-sc1/ST=NC/L=Cary
Client-SSL-Cert-Subject: /C=US/O=Verizon/OU=Cary/CN=cwma-cucm01-sc1/ST=NC/L=Cary
Client-SSL-Cipher: AES256-SHA
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Warning: Peer certificate not verified
Set-Cookie: JSESSIONIDSSO=F49AFDB0068B93F37BD9C04E1EE2ABD5; Path=/; Secure
Set-Cookie: JSESSIONID=ADCB571A7AAD54BA184C7CC4578284FC; Path=/axl; Secure; HttpOnly
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns:getGatewayResponse xmlns:ns="http://www.cisco.com/AXL/API/8.5">
<return>
<gateway uuid="{0ECE1CD4-3119-C334-2899-9EC33DB53423}">
<domainName>DCFDHRBLU1-2811</domainName>
<description>DCFDHRBLU1 451 Blue Hill Ave, Dorchester</description>
<product>Cisco 2811</product>
<protocol>MGCP</protocol>
<callManagerGroupName uuid="{11657476-26D2-F260-2D99-AFF912D1DA85}">BV1-CMG2</callManagerGroupName>
<units>
<unit>
<index>0</index>
<product>NM-4VWIC-MBRD</product>
<subunits>
<subunit>
<index>2</index>
<product>VIC2-4FXO</product>
<beginPort>0</beginPort>
</subunit>
</subunits>
<subunits>
<subunit>
<index>3</index>
<product>VIC-4FXS</product>
<beginPort>0</beginPort>
</subunit>
</subunits>
</unit>
</units>
<vendorConfig>
<globalISDNSwitchType>4ESS</globalISDNSwitchType>
<switchBack>Graceful</switchBack>
<switchBackDelay>10</switchBackDelay>
<switchBackSchedule>12:00</switchBackSchedule>
<DtmfRelay>NoChange</DtmfRelay>
<ModemPassthrough>Enable</ModemPassthrough>
<CiscoFaxRelay>Disable</CiscoFaxRelay>
<T38FaxRelay>Disable</T38FaxRelay>
<rtpPackageCapability>Enable</rtpPackageCapability>
<mtPackageCapability>Disable</mtPackageCapability>
<resPackageCapability>Disable</resPackageCapability>
<prePackageCapability>Enable</prePackageCapability>
<sstPackageCapability>Enable</sstPackageCapability>
<rtpUnreachableOnOff>Enable</rtpUnreachableOnOff>
<rtpUnreachableTimeout>1000</rtpUnreachableTimeout>
<rtcpReportInterval>0</rtcpReportInterval>
<simpleSdpEnable>Enable</simpleSdpEnable>
</vendorConfig>
</gateway>
</return>
</ns:getGatewayResponse>
</soapenv:Body>
</soapenv:Envelope>

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-09-2014 03:31 PM
Hi Anthony,
Thank you for bringing this to our attention. I have reproduced the issue with schema 8.5, and we will work on getting it resolved. It seems like it's also an issue in more recent AXL schemas like 9.0 and 10.0 as well. I'll keep you posted on the status of this defect.
Thanks,
Adrienne
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-10-2014 08:11 AM
Adrienne,
Thanks for looking into this and identifying the issue. Please do. Is there a DDTS that I can track for this?
Thanks,
Anthony

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-10-2014 02:52 PM
Hi Anthony,
The product manager will likely not fix this issue in the current releases as it’s high risk. However, we will make sure this gets fixed in future releases. The defect ID is CSCum89555.
Thanks,
Adrienne
