Re: transPattern is a directoryNumber in CUCM 11.5.1.15073-1?

stephan.steiner · ‎03-23-2020

Ran headfirst into this wall tonight. I'm working with a software that does transPatterns and devices with lines. I assumed that I can either have a directoryNumber with a certain pattern/partition or a transPattern, but not both. So at the moment I have a transpattern with 7621/p_internal.

So, if I call listTransPattern with criteria: patter = 7621, it returns my pattern as expected.

Request (minus the header bits)

<searchCriteria><pattern>7621</pattern></searchCriteria><returnedTags><pattern/><description/><routePartitionName/><calledPartyTransformationMask/><callingSearchSpaceName/></returnedTags>

Result:

<transPattern uuid="{9DA1CD92-8106-B6E2-B03A-FBC6D06B47E3}"><pattern>7621</pattern><description>TP for ciscotest1</description><routePartitionName uuid="{A7E05A3F-FD1C-FD94-45DE-DF11D5BBDFD2}">p_internal</routePartitionName><calledPartyTransformationMask>+41767777921</calledPartyTransformationMask><callingSearchSpaceName uuid="{BC3B6B1C-ADF4-2B1D-F723-4A927AAFFE89}">css_all</callingSearchSpaceName></transPattern>

So, all is well, right?

Now, do a getLine with these parameters

<pattern>7621</pattern><routePartitionName>p_internal</routePartitionName>

Result

<line uuid="{9DA1CD92-8106-B6E2-B03A-FBC6D06B47E3}"><pattern>7621</pattern><description>TP for ciscotest1</description><usage>Translation</usage><routePartitionName uuid="{A7E05A3F-FD1C-FD94-45DE-DF11D5BBDFD2}">p_internal</routePartitionName><aarNeighborhoodName/><aarDestinationMask /><aarKeepCallHistory>true</aarKeepCallHistory><aarVoiceMailEnabled>false</aarVoiceMailEnabled><callForwardAll><forwardToVoiceMail /><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><secondaryCallingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardAll><callForwardBusy><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardBusy><callForwardBusyInt><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardBusyInt><callForwardNoAnswer><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /><duration /></callForwardNoAnswer><callForwardNoAnswerInt><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /><duration /></callForwardNoAnswerInt><callForwardNoCoverage><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardNoCoverage><callForwardNoCoverageInt><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardNoCoverageInt><callForwardOnFailure><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardOnFailure><callForwardAlternateParty><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /><duration /></callForwardAlternateParty><callForwardNotRegistered><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardNotRegistered><callForwardNotRegisteredInt><forwardToVoiceMail>false</forwardToVoiceMail><callingSearchSpaceName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><destination /></callForwardNotRegisteredInt><callPickupGroupName xsi:nil="true" uuid="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/><autoAnswer>Auto Answer Off</autoAnswer><networkHoldMohAudioSourceId /><userHoldMohAudioSourceId /><alertingName/><asciiAlertingName/><presenceGroupName uuid="{AD243D17-98B4-4118-8FEB-5FF2E1B781AC}">Standard Presence group</presenceGroupName><shareLineAppearanceCssName/><voiceMailProfileName/><patternPrecedence>Default</patternPrecedence><releaseClause>No Error</releaseClause><hrDuration /><hrInterval /><cfaCssPolicy>Use System Default</cfaCssPolicy><defaultActivatedDeviceName/><parkMonForwardNoRetrieveDn /><parkMonForwardNoRetrieveIntDn /><parkMonForwardNoRetrieveVmEnabled>false</parkMonForwardNoRetrieveVmEnabled><parkMonForwardNoRetrieveIntVmEnabled>false</parkMonForwardNoRetrieveIntVmEnabled><parkMonForwardNoRetrieveCssName/><parkMonForwardNoRetrieveIntCssName/><parkMonReversionTimer /><partyEntranceTone>Default</partyEntranceTone><directoryURIs/><allowCtiControlFlag>true</allowCtiControlFlag><rejectAnonymousCall>false</rejectAnonymousCall><patternUrgency>true</patternUrgency><confidentialAccess><confidentialAccessMode /><confidentialAccessLevel>-1</confidentialAccessLevel></confidentialAccess><externalCallControlProfile/><enterpriseAltNum><numMask /><isUrgent>f</isUrgent><addLocalRoutePartition>f</addLocalRoutePartition><routePartition/><advertiseGloballyIls>f</advertiseGloballyIls></enterpriseAltNum><e164AltNum><numMask /><isUrgent>f</isUrgent><addLocalRoutePartition>f</addLocalRoutePartition><routePartition/><advertiseGloballyIls>f</advertiseGloballyIls></e164AltNum><pstnFailover /><callControlAgentProfile /><associatedDevices/><useEnterpriseAltNum>false</useEnterpriseAltNum><useE164AltNum>false</useE164AltNum><active>true</active></line>

So, umm, since when is a translationPattern a directoryNumber? If I check on CUCM, when I search for directoryNumbers, 7621 is not found. When I search for transPatterns, it is found.

Let me venture a guess: both entries are in the same SQL table: numplan. So, whomever wrote the code to extract entries to return directoryNumbers forgot a condition "WHERE tkpatternusage = 3" and thus getLine returns incorrect data.

dstaudt · ‎03-24-2020

You seem to have grasped the situation as it appears to me too...even <listLine> does not return Translation Pattern "lines" it seems.

It _is_ possible for regular phones and other things that have a line (route points, hunt pilots, various profiles, etc.) to have DNs with a translation pattern format, e.g. '99XX', so there is some conceptual overlap I guess. However, the argument that <getPhone> should exclude Translation Patterns (since we already have the better-suited <getTransPattern> is a pretty compelling one IMHO. However, the question then is, should it only return device lines (tkpatternusage = 2) or some other subset of typepatternusage?

stephan.steiner · ‎03-25-2020

I'm not even sure where I'd find most entries with a tkdevicepatternusage != 2.

Given that getPhone (and others, like getCtiRoutePoint, etc.) return <lines><line><dirn> and you get that <dirn> with getLine, I'd say getLine should return just these. Looking at typepatternusage, for 0 we have getCallPark, for 4 we have getCallPickupGroup, there's a bunch of usages that have specific get commands. Moreover, the result from getLine does not give you the information about the usage (it absolutely must if it's mean to return other non dirn "things").. and its return tag clearly are for tkdevicepatternusage = 2. When I extracted my transPattern with getLine, it returned all these tags that make zero sense in the context of a transpattern - so I'd strongly argue for tkdevicepatternusage = 2 filter.

Also, a little background: my app loads enduser, associated devices, mobility things and UDPs. If there's none, it still tries if the number the user should have could be present.. so getLine. And now that I do transPatterns, I also load the transpattern with the same pattern/partition combo. Since I can't tell if getLine returns what it's actually a transpattern, things just go very wrong from here. E.g. my app things "oh, there's a line, but I have no phone, so that line must be deleted".. because you cannto have a dirn and a transpattern with the same pattern/partition combo in the system (my customer uses transpatterns to have an internal number for users that have just a mobile phone and where they don't want to create the whole RDP/RD bits - so these transpatterns have a 4 digit internal number and are in the phone partition - making the mixup perfect).

stephan.steiner · ‎03-25-2020

I just discovered that there's a usage on directoryNumber after all.. so I used that to discard "directoryNumber"s that are in fact transPatterns. Still, I think given the naming along, it is cofusing that getLine returns the same as getTransPattern. That makes me wonder whether getPhone would also return the same as getDeviceProfile (as they share the same device table).. and a couple other commands.