Call Manager ignoring device css

Unanswered Question
May 27th, 2010
User Badges:

I have an issue where we're doing an integration with a 3rd party vendor (IP Trade) in call manager and have had a few weird issues pop up.  The issue I'm trying to tackle right now is that this IP Trade turret, which there are about 15 of registered to call manager, one of these ignores the device css.  These devices are essentially SIP phones.  All of the devices are setup exactly the same, line for line, but looking at the SDI traces from Call Manager, when placing a call, Call Manager clearly ignores the device calling search space and only uses the line calling search space.


Call Manager has been rebooted and it did not help the issue at all.


The Call Manager version is 6.1.3.3000-1.


The issue seems to be that the field in the database for the device css is blank and not being read vs what is actually being shown in Call Manager?

Maybe somehow related to this bug:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCso50387&from=summary


Seems like maybe the database entry is screwed up and not working the way it's actually configured to work?


Anyone have any thoughts or ideas as to why this would happen?  This has happened to another one of the devices before, and it was fixed by deleting and rebuilding the phone, but it seems to creep back, like the re-creation never makes it into the database or such.


I'm going to be opening a TAC case tomorrow on this and see if they know why it's happening.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
William Bell Thu, 05/27/2010 - 18:14
User Badges:
  • Purple, 4500 points or more

Odd. So, you have 15 devices all configured in the same exact way and one of those devices appears to ignore the device CSS.  You suspect that it has something to do with the database.  Since you have rebooted the CUCM system and have checked the configuration page to see that the Device CSS is still specified, I don't think the database data is wrong.  Though, it is possible a CUCM subscriber (if you have one) is out of whack.


First, check the db replication.  The easiest way is to check the CUC reports.


Second, check your device record configuration on EACH CUCM NODE, by connecting the console/CLI and executing this query:


admin: run sql select d.name,d.description,css.name as css from device as d inner join callingsearchspace as css on d.fkcallingsearchspace = css.pkid where d.name = 'SEPxxxxxxxxxxxx'


Substitute SEPxxxxxxxxxxxx with your device name.


Check to see if the database is the problem.  If all nodes show the same output then it isn't the database.  Another possible issue (which would be a tac case/possible defect) is that the db is fine but the real time information is innaccurate.  The subscribers in a cluster DO NOT use the database information during normal operations.  They cache realtime info into memory.  I am oversimplifying this a tad.  The important thing is to try and determine if you have a disconnect in the realtime information exchange provided via ICCS.


Check the dbnotify subscriptions on each node.


admin:show tech notify


Look for missing entries for ccm and tftp, example:


admin:show tech notify search ccm
This command shows Database Change Notify Monitor. It takes longer time... So please be patient...



-------------------- show tech notify --------------------



Database Change Notify Monitor


I=Inuse, P=Processed, H=Head, T=Tail, S=Subscribed, DB= Change Notification Queue Length



22 I   0 P 1174 H 174 T 174 S 119 ccmdb.19048
admin:show tech notify search tftp
This command shows Database Change Notify Monitor. It takes longer time... So please be patient...



-------------------- show tech notify --------------------



Database Change Notify Monitor


I=Inuse, P=Processed, H=Head, T=Tail, S=Subscribed, DB= Change Notification Queue Length



18 I   0 P 1107 H 107 T 107 S  63 ctftpdb.18234


You should also check by forcing the phone to register to another subscriber node (even the publisher ONLY IF you already have CCM service running there).  See if there is a difference.


I would also check the configs (stare and compare or dump via BAT export and go column by column) just to see.


That's all I can think of right now.


HTH.


Regards,
Bill

Please remember to rate helpful posts.

james.hagemann Thu, 05/27/2010 - 20:05
User Badges:

Bill,


Great advice, thanks for the help.


Fortunately/Unfortunately you proved that the databases' css on both nodes PUB & SUB were correct.



admin:run sql select d.name,d.description,css.name as css from device as d inner join callingsearchspace as css on d.fkcallingsearchspace = css.pkid where d.name = 'IPT256BCD123A23'

name                        description             css

=============== ============= =================

IPTXXXXXXXXXXXX Description         CHI Device Phones

on both nodes.
Show tech notify search ccm (PUB):
-------------------- show tech notify --------------------
Database Change Notify Monitor
I=Inuse, P=Processed, H=Head, T=Tail, S=Subscribed, DB= Change Notification Queue Length
9 I   0 P   0 H   0 T   0 S   1 CCMAuthentication[127.0.0.1]:32818
27 I   0 P   0 H   0 T   0 S   1 RIS_CCM
34 I   0 P   1 H   1 T   1 S  10 SNMPCCM
35 I   0 P 473 H 473 T 473 S  80 ccm
Show tech notify search ccm (SUB):
-------------------- show tech notify --------------------
Database Change Notify Monitor
I=Inuse, P=Processed, H=Head, T=Tail, S=Subscribed, DB= Change Notification Queue Length
7 I   0 P   0 H   0 T   0 S   1 CCMAuthentication[127.0.0.1]:32809
24 I   0 P   0 H   0 T   0 S   1 RIS_CCM
30 I   0 P   0 H   0 T   0 S  10 SNMPCCM
31 I   0 P 377 H 377 T 377 S  80 ccm
Show tech notify search tftp (PUB):
-------------------- show tech notify --------------------
Database Change Notify Monitor
I=Inuse, P=Processed, H=Head, T=Tail, S=Subscribed, DB= Change Notification Queue Length
31 I   0 P 291 H 291 T 291 S  40 CTFTP
Guessing this may be that disconnect in real time?  Even after a reboot, where it would have re-read that from the database?
The difference in the traces I've caught are:
Not working:
CCM|Digit analysis: match(pi="2",fqcn="XXXXXXXXXX", cn="XXXXXX", plv="5", pss="Block Toll Fraud", TodFilteredPss="Block Toll Fraud", dd="XXXXXXXX",dac="0"
Working:
CCM|Digit analysis: match(pi="2", fqcn="XXXXXXXXXX", cn="XXXXXX",plv="5", pss="Block Toll Fraud:CHI Routes:Global Common Routes:Cluster DN Presence Allowed:Cluster DN Presence Denied", TodFilteredPss="Block Toll Fraud:CHI Routes:Global Common Routes:Cluster DN Presence Allowed:Cluster DN Presence Denied", dd="XXXXXXX",dac="0")
Both have a device css and line css set,  line css has css with block toll fraud set, and device has css with rest of partitions, for some reason that particular phone doesn't use it's device css...
Again, thanks for your help!  Please let me know if the tech support details show anything odd as i'm not as familiar with those.
Thanks,
James
William Bell Thu, 05/27/2010 - 20:49
User Badges:
  • Purple, 4500 points or more

Strange.  Your show tech notify output looks ok.  Some other thoughts/things to check:


1. DNA (https://YourPublisher/dna).  Perform an analysis on the phone in question and a known-good.  Any differences?

2. Have you checked other non-CSS parameters for the device in question?  Compared to a known-good?

3. Any use of device mobility or geolocations or similar feature?


If the db data is OK and you have reset the pub/sub then I have to lean to a config issue that would affect device CSS (like device mobility) or a defect of some type.  I would even suspect the station itself since many SIP devices have a "local" dial plan they load.  Of course you have looked at the traces and have seen that the actual issue is the effectivce CSS used by the digit analysis sub-system is different.  Which brings me back to bug or config.


HTH.


Regards,
Bill

james.hagemann Fri, 05/28/2010 - 07:05
User Badges:

Bill,


Thanks for all of the input.


1. DNA shows that it would work just like a known good, which was also strange, but again is that running it against the database or what is live?


2. The device is the same, line for line.  We've had this issue before and fixed it by rebuilding all of the phones, and building a new phone with the exact same configuration didn't work, but copying a known working and changing the MAC and DN did, even though they were exactly the same...


3. Neither of those are in use that I know of.


I'm going to do a dump and a stare and compare and see if there is anything different, but from what I can see there is not, because we build it and only set a few things different, very basic config.  I know we can delete it and rebuild it and probably get this to work, but my hesitation (and reason to work with TAC) is that this scenario has happened before and comes back to working phones at some point.


I'll update this thread with what I find out from TAC.



Thanks,

James

William Bell Fri, 05/28/2010 - 07:38
User Badges:
  • Purple, 4500 points or more

James,



DNA is just guessing based on what is configured.  It doesn't take any registration/realtime information into account.  So, things like device mobility would be blissfully ignored.  This is definitely a strange situation and I am at that point of making wild guesses, which could lead you down the wrong path.  Definitely keep us posted on the Tac information.


Regards,
Bill

Rob Huffman Fri, 05/28/2010 - 06:32
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi James,


It's hard to add anything to this great info from Bill (+5 points

here Bill for this excellent reply - WOW!)


I have seen some wierd issues related to CSS when a device

and corresponding DN/DN's have been deleted and the DN not removed

completely from the Route Plan via Delete Unassigned DN's before re-building.


Just a thought


Cheers!

Rob

Actions

This Discussion

Related Content