For those of you who either like to run queries on the Call Manager, have customers who do so, or have tools that customers use for change management and the like, please note that I just stumbled on a change to the CUCM 6.x database structure as it relates to call forwarding.
The change is that forward destination information (i.e. the number a person forwards a call to) is no longer stored directly in the NumPlan table, though there is a call forward all branch of columns which I am still trying to piece together. The call forward destination information is now stored in the callforwarddynamic table. So, to find out if a phone is call forwarding a line to a long distance location (we do this in our health assessment, aka toll fraud (possibly)) instead of:
/*query for cucm 4.x*/
select n.dNorPattern as ‘pattern’,rp.name as ‘routePartitionName’,n.cFAVoiceMailEnabled as ‘callForwardAll.forwardToVoiceMail’, n.cFADestination as ‘callForwardAll.destination’from NumPlan as n
where ((n.cFADestination like ‘91%’) or (n.cFADestination like ‘9011%’))
You need to query multiple tables
/*query for cucm 6.x and later*/:
select n.dNorPattern as pattern, cfd.cfadestination
from NumPlan as n inner join callforwarddynamic as cfd on cfd.fkNumPlan=n.pkid
where (cfd.cfadestination like ‘91%’) or (cfd.cfadestination like ‘9011%’))
This isn’t too much of a problem, but it does make queries targeting calling search space configurations on call forward destinations (i.e. to detect possible toll fraud opportunities) a little more complicated with multiple joins.More importantly, if you had a routine that was checking for this either on a regular basis or as part of a configuration/optimization exercise and you have updated to 6.x, some changes are necessary.
Regards, Bill
Posted Oct 6, 2008, 4:51 PM by wjb