get_servers_api() has the /cucm-uds/servers response shape backwards; hostName/ipv4Address/serverType are AXL names, not UDS

[bandrel]

Summary

get_servers_api() parses /cucm-uds/servers backwards relative to what Cisco documents. It looks for hostName, ipv4Address, ipv6Address and serverType child elements first, and treats plain text inside <server> as a fallback for "newer UDS (15.x+)".

Both halves of that framing are wrong:

1. The plain-text shape is the only shape Cisco documents, and it is documented from 10.0(1) onward — not a 15.x novelty. From System Resources, byte-identical in the current and the legacy CUCM 10.x reference:

<servers version="{version}" uri="https://{host}:8443/cucm-uds/servers">
   <server>{host}</server>
   <server>{host1}</server>
   <server>{host2}</server>
</servers>

2. hostName, ipv4Address, ipv6Address and serverType are not UDS element names at all. All four grep to zero matches across every UDS doc page. That vocabulary belongs to AXL (getCallManager / listProcessNode) and the Platform/Serviceability APIs. If they were copied from a capture, it was a capture of a different API.

Impact

Functionally this is benign today — the plain-text fallback catches the documented shape, so the parser works. The cost is in the wrong places: the misleading comment will send the next reader looking for a version check that should not exist, and serverType is threaded through --servers output and the uds_servers table as a column that can never be populated. Anyone reading the DB schema will reasonably assume Publisher/Subscriber roles are being captured when they are not. UDS does not expose server role; that requires AXL.

Fix

1. Invert the parse: read <server> text content first, fall back to child-element lookup only if the text is empty. That handles the documented shape and any undocumented drift with no version branching.
2. Correct the comment. Suggested wording: UDS documents <server> as plain-text hostname (10.0(1)+); the child-element branch is defensive only and matches no documented release.
3. Decide what to do about serverType / ipv4Address — either drop them, or keep the columns and document that they are nullable and only ever filled by a hypothetical non-standard response.

Coverage caveat

Cisco's UDS "New and Changed Information" changelog stops at 12.5(1); there are no 14 or 15 sections anywhere in the docs. So "unchanged through 15" is unverified rather than confirmed — the changelog appears abandoned, not stable. The text-first-then-children approach above is what makes that uncertainty harmless. A live capture against a 14 or 15 cluster is the only way to settle the actual shape, and would be worth doing on the next engagement that has one in scope.

[bandrel]

Follow-up: independent live-capture corroboration, and a correction to the coverage caveat

Re-audited after a challenge that we might be reading a stale doc set. Two updates.

Correction to this issue's closing caveat. I wrote that Cisco publishes nothing for 14 or 15. That is wrong for 14: Cisco publishes a UDS XML Schema for v14 XSD bundle at developer.cisco.com/site/user-data-services/downloads/schemas/ (live as of 2026-07-29, present in Wayback snapshots since 2024-10-10), alongside v12.5, v12.0, v11.5 and v11.0 bundles. Files inside are named <resource>.<method>.xsd, so servers.get.xsd from the v14 bundle would definitively settle the response shape. It is behind a DevNet login (the fileMedia/download/<uuid> endpoint returns AccessDenied unauthenticated, and no public mirror exists — GitHub code search for servers.get.xsd, UDS-xsd, and path:*.xsd "cucm-uds" all return nothing). Anyone with a cisco.com account can close this issue definitively by pulling that one file. There is still no v15 artifact of any kind.

What remains true: the prose changelog genuinely stops at 12.5(1), there is no version selector or per-release UDS doc set (/latest/, /15/, /14/, ?version=, /api-reference/ all 404), and all of www.cisco.com 403s automated fetches.

Independent corroboration that <server> is plain text. ProjectDiscovery's cisco-ucm-cluster-enum.yaml — marked verified: true, meaning tested against live hosts, not written from docs — matches on '<servers uri' and '<server>' and extracts with xpath /servers/server. That is a text-node extraction; it only works if <server> contains a plain hostname. This is real-world evidence rather than more of the same documentation.

Where our four field names came from. git log -S ipv4Address points at ebdeded ("Add --servers UDS cluster enumeration", May 2026) and d8e9aa3. Both are AI-assisted commits, the commit message asserts "hostname, IPv4, IPv6, and server type" with no captured response saved anywhere, and no test fixture in the repo contains a real /cucm-uds/servers body. Exact-string counts across the full 293KB UDS API reference: hostName 0, ipv6Address 0, serverType 0. So the child-element branch appears to be invented rather than observed — which makes the cluster_servers.server_type column dead weight, not just unpopulated.

Practical upshot for the fix: parse <server> text content first, keep the child-element branch only if someone wants belt-and-braces, and drop the "15.x+" comment entirely — the polarity is backwards.

[bandrel]

RESOLVED by primary source: the official v14 XSD

Pulled UDS-xsd-14.zip from the DevNet schema downloads (requires a DevNet login). xsd/pub/servers/servers.get.xsd, verbatim and in full:

<xs:element name="servers">
    <xs:complexType>
        <xs:sequence>
            <xs:element type="xs:string" name="server" maxOccurs="unbounded" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="uri" type="xs:anyURI" use="required"/>
        <xs:attribute name="version" type="xs:string" use="required"/>
    </xs:complexType>
</xs:element>

<server> is type="xs:string" — a plain string, on CUCM 14. It has no child elements, and the schema permits none. hostName, ipv4Address, ipv6Address and serverType cannot appear in a conformant /cucm-uds/servers response on any release from 10.0(1) through 14.

This settles the issue on the strongest available evidence and inverts the code comment exactly: plain text is not a "newer UDS (15.x+)" behavior, it is the only behavior, and the child-element branch it treats as the primary path matches nothing Cisco has ever shipped.

Revised fix

1. Parse <server> text content as the only path. Delete the hostName/ipv4Address/ipv6Address/serverType regex loop — it is not defensive, it is dead.
2. Delete the "Newer UDS (15.x+)" comment.
3. Drop ipv6, server_type (and arguably ipv4) from the cluster_servers table, or document them as permanently NULL. UDS does not expose server role or addresses; resolving a hostname to an IP is a DNS lookup on our side, and server role requires AXL.
4. Update the _TEST_MODE fixture — it currently returns {'hostName': ..., 'ipv4Address': ..., 'serverType': ...}, i.e. a shape the real API cannot produce, so tests are validating against a fiction.
5. Commit a real fixture: <servers uri="..." version="14.0"><server>cucm-pub.example.com</server></servers>.

Only v14 is downloadable — the 11.0/11.5/12.0/12.5 bundles 403 on their direct CDN paths (only the v14 entry uses the authenticated /fileMedia/download/<uuid>/ redirect). v14 is the newest artifact Cisco publishes and is newer than all of its prose docs, so it is the best ceiling we have. Still unverified for 15, where Cisco publishes nothing at all — but since v14 permits no child elements, a text-first parse is correct regardless.

I saved the bundle to /tmp/UDS-xsd-14.zip; worth stashing somewhere durable, since re-downloading needs an authenticated session.