Refer to the exhibit. When a Calling Search Space is updated and a new member is added, how is a member defined?

Question

Exhibit

Options

• A<member uuid="{F6E6CD00-EC18-F16D-32E1-80C9A7A3D602}"> <routePartitionName uuid="{5F2B2FFD-C7D2-4F30-9EF5-60110B56B939}">pt_translation-pattern_nc</routePartitionName> <index>1</index> </member>
• B<member uuid="{F6E6CD00-EC18-F16D-32E1-80C9A7A3D602}"> <routePartitionName> <name>pt_translation-pattern_nc</name> </routePartitionName> <index>1</index> </member>
• C<member> <routePartitionName uuid="{5F2B2FFD-C7D2-4F30-9EF5-60110B56B939}">pt_translation-pattern_nc</routePartitionName> <index>1</index> </member>

• A
  6% (1)
• B
  6% (1)
• C
  88% (14)

Explanation

When adding a new member to a Calling Search Space via Cisco's AXL API, the <member> element itself carries no UUID - that attribute only appears when referencing an existing member. The route partition is correctly identified by placing its UUID as an attribute on <routePartitionName> while the partition name appears as the element's text content, exactly as option C shows.

Option A is wrong because it incorrectly places a UUID on the <member> element itself; new members don't have a pre-assigned UUID to reference.

Option B is wrong on two counts: it also incorrectly adds a UUID to <member>, and it wraps the partition name in an inner <name> sub-element, which is not valid AXL structure - the name belongs directly as text content of <routePartitionName>.

Memory tip: Think of it as "identify the what (the partition), not the slot (the member)." New members have no UUID yet, but the partition they point to already exists in CUCM and is referenced by its UUID attribute on <routePartitionName>.

No community discussion yet for this question.