cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2563
Views
9
Helpful
17
Replies
Highlighted
Contributor

AXL vendorConfig

Hi all,

I can see a whole bunch of configuration fields for a phone in CUCM 10.5(1) under the "Product Specific Configuration Layout" section of the GUI but am not able to collect that same information using AXL. Some blog post pointed me to grabbing the <vendorConfig> tag but when I did - it only contained very small amount of that information. Another post pointed me to executing a SQL stored procedure (since the xml column no longer exists on the device table) called dbreaddevicexml but no information got returned from it when I executed it.

So how can I get the rest of the fields I see in the CUCM GUI?

Thank you.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Okay, it looks like it works this way: The tags in <vendorConfig> won't reflect all the values if you just leave them at the defaults.  if you change the settings, then they start to show up in <vendorConfig>. They'll continue to show up even if you change them back.  For example, <wifi> and <appInstallFromAndroidMarket> were missing from <vendorConfig> for the DX650 since they were set to the default values.  When I turned off wifi, and turned on the ability to install from the Google Play Store, these tags showed up in <vendorConfig>:

                  <wifi>0</wifi>

                  <appInstallFromAndroidMarket>true</appInstallFromAndroidMarket>


When I set them back to the defaults, they still showed up:


                  <wifi>1</wifi>

                  <appInstallFromAndroidMarket>false</appInstallFromAndroidMarket>

I don't see any simple way to get all the <vendorConfig> features and their defaults.  So far, it looks like the information is scattered across a number of tables you'd have to join, but I haven't been able to trace all the routes yet to get a picture of the information.

EDIT: Actually, I'm wrong about that -- CUCM reads in XML configuration files (and sub-files) for <vendorConfig>, which isn't stored in a way where it is accessible directly from AXL.  You might be able to access the XML files from the CLI, but then you'd have to figure out how to interpret them in such a way that the information would be useful.  And this wouldn't get you the equivalent of a getPhone readout of <vendorConfig> tags and values.  Personally, I would simply note what the defaults are in the UI, and if the tag doesn't show up, assume it is set to the default value.

If it was critical, I'd set everything to non-default values, do a getPhone, and then record all the tags. Painful, I know, but it only has to be done once per phone model.

View solution in original post

17 REPLIES 17
Highlighted
Cisco Employee

I'm still checking into this, but did you try "select * from enterprisephoneconfigxml" to see what it contains?

Highlighted

Hi, it came back with a result of 1 row and it had a ciscoCamera flag set to true in the vendorConfig. So nothing really useful there. Thank you for looking into this.

Highlighted

I'm not finding much... I tried this:

select * from devicexml4k where fkdevice=(select pkid from device where name="<device name>")

But this only returns what you can already see in the vendorConfig for getPhone. I'll dig some more. 

Highlighted

Okay, it looks like it works this way: The tags in <vendorConfig> won't reflect all the values if you just leave them at the defaults.  if you change the settings, then they start to show up in <vendorConfig>. They'll continue to show up even if you change them back.  For example, <wifi> and <appInstallFromAndroidMarket> were missing from <vendorConfig> for the DX650 since they were set to the default values.  When I turned off wifi, and turned on the ability to install from the Google Play Store, these tags showed up in <vendorConfig>:

                  <wifi>0</wifi>

                  <appInstallFromAndroidMarket>true</appInstallFromAndroidMarket>


When I set them back to the defaults, they still showed up:


                  <wifi>1</wifi>

                  <appInstallFromAndroidMarket>false</appInstallFromAndroidMarket>

I don't see any simple way to get all the <vendorConfig> features and their defaults.  So far, it looks like the information is scattered across a number of tables you'd have to join, but I haven't been able to trace all the routes yet to get a picture of the information.

EDIT: Actually, I'm wrong about that -- CUCM reads in XML configuration files (and sub-files) for <vendorConfig>, which isn't stored in a way where it is accessible directly from AXL.  You might be able to access the XML files from the CLI, but then you'd have to figure out how to interpret them in such a way that the information would be useful.  And this wouldn't get you the equivalent of a getPhone readout of <vendorConfig> tags and values.  Personally, I would simply note what the defaults are in the UI, and if the tag doesn't show up, assume it is set to the default value.

If it was critical, I'd set everything to non-default values, do a getPhone, and then record all the tags. Painful, I know, but it only has to be done once per phone model.

View solution in original post

Highlighted

You know, this is a really good point. I will set the settings I need to non-default values and execute a getPhone to see them. Will let you know if that does it for me.

Thanks so much!

Highlighted

That did it for me! Thanks so much, Nick!

Highlighted

My pleasure!  Glad I could help.

Highlighted
Beginner

Does anyone know how to update the vendorConfig information with the AXL for 10.5 +

Sending updates via addPhone or updatePhone do not appear to be updating the vendorConfig information.

I have tried using dbreaddevicexml() and dbwritedevicexml() but I didn't have any luck getting anything from the CM.

Highlighted

Testing on my 10.5 system seems to work.  Here I changed the <disableSpeaker> setting, and it was reflected on a subsequent <getPhone> request:

POST https://ds-ucm105.cisco.com:8443/axl/ HTTP/1.1

Accept-Encoding: gzip,deflate

Content-Type: text/xml;charset=UTF-8

SOAPAction: "CUCM:DB ver=10.5 updatePhone"

Content-Length: 946

Host: ds-ucm105.cisco.com:8443

Connection: Keep-Alive

User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Authorization: Basic QWRtaW5pc3RyYXRvcjpjaXNjb3BzZHQ=

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">

   <soapenv:Header/>

   <soapenv:Body>

      <ns:updatePhone>

         <name>IPCMRAEU5UCM5X7</name>

               <vendorConfig>

                  <disableSpeaker>false</disableSpeaker>

                  <autoSelectLineEnable>0</autoSelectLineEnable>

                  <deviceType>30016</deviceType>

                  <settingsAccess>1</settingsAccess>

                  <verifySoftwareVersions>0</verifySoftwareVersions>

                  <videoCapability>0</videoCapability>

                  <webAccess>0</webAccess>

                  <rtcp>0</rtcp>

                  <moreKeyReversionTimer>5</moreKeyReversionTimer>

                  <autoCallSelect>1</autoCallSelect>

                  <g722CodecSupport>0</g722CodecSupport>

               </vendorConfig>

      </ns:updatePhone>

   </soapenv:Body>

</soapenv:Envelope>

Highlighted
Contributor

The information needed to build the vendorconfig seems to be loaded into the table 'scratch'. However, it is not described in a manner that you could build xml directly from. The same information is also (as stated by npetrele) stored in xml files which is not easily accessible. I've found that they are included in the DevicePacks, so by unpacking one of those one can get hold of the files more easily than hacking into your CUCM.

Unfortunately, still not much joy since every model has two XML files which which together describe how this should be shown in the ccmadmin UI. It can't be used to generate code. At least not without parsing them through a tool that generates an xsd by merging them. Which is exactly what I intend to do

I've started to write such a tool which I will make available to anyone that is interested when finished. However, in order to correctly parse the XML files I would like to have the xsd:s for them. They are unfortunately not distributed with CUCM any longer, but I'm pretty sure they were shipped with CCM up to version 4.2(3) (i.e the last Windows version).

I was not able to get them out of the install media, and I don't feel like digging up an old server to install it on...

Does anyone still have an old CCM running, of maybe someone has a copy of the files? If so, could you send me the schema files 'displayInstance.xsd' and 'displayinstancerules.xsd'? I believe they are stored in the same directory as the AXLAPI.wsdl. They are possibly also reachable via http://CCM/CCMApi/AXL/V1/

They are only schema files, so I can't really see that there should be any issue with copying the files.

Highlighted

I was able to retrieve a dump of all the XML file pairs from a v11 CUCM, though it may require some sorting as not all files are associated with phones.  However it sounds like you may already have that data..?

Unfortunately I have not been able to find any .xsd's, which may be what you are mainly looking for...

Highlighted

Hi,

Thanks dstaudt, but yes I have those files. I have also found the XSD-files I was looking for so I am good at the moment.

The .xsd's that describes the format of these files were included in the zip along with the ccm 4.1 wsdl. Unfortunate I wasted a few hours installating a ccm 4.1 before I found out... Well, at least I got to feel a bit nostalgic .

It turns out that there has been some additions to this schema over the years, but it seems there might be two versions (or no version at all) of the schema floating around at Cisco. Looking at various *display_info.xml they reference the same namespace but at different locations. The new elements is added in different sequence in different vendorConfig files. Some files even have both type of formats in them, so they would not validate at all unless the schema i really forgiving. By design CUCM does not really care about schema validation, from what I gather, but type safety is an easy way to avoid bugs

Please understand I'm not criticizing here, I have a long pleasant experience with Cisco. This whole business with vendorConfig XML data though has caused me some grief over the years and I do know that I am not alone...

Kind Regards,

Dan

Highlighted
Contributor

I would like to share some information that I think would be useful to anyone who wants to add or update device XML (a.k.a "vendorConfig") via AXL. Please note that this is based on my own experience from working with AXL and it is not an official Cisco description.

 

The short version (which turned out to be not-so-short...):

A common problem for adding/updating this information is to find the correct format of the XML to use. It is not documented. One could read the data from an already existing device, but it is more than likely that the retrieved information is incomplete.

The good news is that it is possible to create a complete XML with all elements relevant for any device. It requires some handywork, but it is fairly quick to do. Once done the templates can be reused over and over again.

 

I've found it easiest to just download a CUCM Device Pack. Preferably the latest. I does not really matter which CUCM version you have, the device XML does not seem to change for different CUCM versions.

Use 7zip or any other unzipper that copes with Cisco's format, and look through the files until you find a file named "<device type>_display_instance.xml". Note that devices that handles several protocols (SCCP, SIP) has more than one file so be sure to look at the right one.

 

These type of files actually contain the format that is used for "vendorConfig". They also contain a bunch of other information not directly relevant to what we want to achieve here. So, how can we use it? One quick way is to simply transform the XML using XSL. This would be a great place to show a working sample in an online XSL parser, but since Cisco has the text "* CISCO CONFIDENTIAL *" inside the display_instance.xml-files I would like for someone from Cisco giving permission first.

 

It is easy to test though. Just go to XSL Transform. Paste the contents of the chosen "<device type>_display_instance.xml" in the XML frame, and paste the XSL shown below in the XSL frame. The transformation should take place immediately and give you the result in the "Result" frame (go figure...)

 

The result would look something like (depending on which device you selected)

<disableSpeaker>ChangeMe</disableSpeaker>
<disableSpeakerAndHeadset>ChangeMe</disableSpeakerAndHeadset>
<forwardingDelay>ChangeMe</forwardingDelay>
<pcPort>ChangeMe</pcPort>

...removed for readability...

<sshAccess>ChangeMe</sshAccess>
<loginAccess>ChangeMe</loginAccess>
<fipsMode>ChangeMe</fipsMode>
<SRTCP80bit>ChangeMe</SRTCP80bit>
<customerSupportUse>ChangeMe</customerSupportUse>

The XSL I show here deliberately produces XML that is not well formed, since that is the way many programmers would like this information. At least those who just need to paste in this as a string under the vendorConfig element...

I also chose to give all elements the value "ChangeMe", just because that would product start and end tags in the XML for easier editing. I'm just giving you an example here .

I've been a bit puzzled regarding the vendorConfig element and whether the elements should be enclosed in CDATA or not. From what I understand it would actually be valid to just add them like this:

<myAxlRequest>
     <vendorConfig>
          <disableSpeaker>ChangeMe</disableSpeaker>
          <disableSpeakerAndHeadset>ChangeMe</disableSpeakerAndHeadset>
          ...and so on
     </vendorConfig>
</myAxlRequest>

The XSL used:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:axl="http://www.cisco.com/AXL/1.0">
    <!-- Created by Dan-Anders Hook <dan-anders at hook dot se 20151213-->
    <xsl:output omit-xml-declaration="yes" indent="no" />
    <xsl:output method="xml" />

    <!-- Skip over initial data -->
    <xsl:template match="/">
        <xsl:apply-templates select="/axl:displayInstance/axl:parameters" />
    </xsl:template>

    <!-- Just dig into the parameters, don't create a top element -->
    <xsl:template match="axl:parameters">
        <xsl:apply-templates select="axl:param" />
    </xsl:template>

    <xsl:template match="axl:paramGroup">
        <xsl:apply-templates select="axl:param" />
    </xsl:template>

    <xsl:template match="axl:param">
        <xsl:element name="{axl:name}"><xsl:if test="axl:index != ''"><xsl:attribute name="index"><xsl:value-of select="axl:index" /></xsl:attribute></xsl:if><xsl:apply-templates select="axl:paramGroup" />ChangeMe</xsl:element>
    </xsl:template>
</xsl:stylesheet>

This post turned out to be so looong so I might follow up with more information if there is any interest. For example, it is possible to generate XML with the default values already filled in. One could also use simple script to bulk create XML for all devices. I've also looked quite a bit at the schema part related to this. Unfortunately it is a mess, but it can be worked around in order to get data binding for this data into your programming language of choice. I also do believe that Cisco could do some quite simple enhancements here. The design for this was done +10 years ago and it might (would?) benefit from redesign. Today the vendorConfig XML is created by code that has a quite hard binding to the ccmadmin GUI (don't ask me how I know...), and the generated XML is not validated by a schema. Danger lurks in 'em waters... Anyway, I hope this is useful to someone

 

Cheers,

 

Dan

Highlighted

Thank you ! You're a genius. I was looking for this info for long for my provisionning scripts.

This widget could not be displayed.