Hi, I'm managing 3 6.1.4 clusters and got similar results in CSS restricting calls. Most of the DN CSS are unrestrictive (by company policy) but a few DNs need to be blocked any type of call (even extension to extension). Usually phones have a site Device Pool assigned to them in which they should heir location and region information but they don't have a CSS applied (set to NONE). DNs, however, do have a CSS that points to all allowed partitions, usually external routes for each kind (extensions, local, mobile, long distance and international).
Some of new deployed phones (CIPC but the problem happens with all SCCP types, never tried SIP for this issue), have a regular extension partition in their DNs but the CSS applied is a restrictive one which lists only a restrictive partition (to which there is no DN, route patterns or any other applicable element).
The phone can place calls to regular extensions in that in the same partition and to other partitions as well (that are not listed inside the restrictive CSS, not even the restrictive partition is). Dialed Number Analyzer shows that the call would be blocked.
The Device Pool has Device Mobility Group CSS information allowing all type of calls. WIll DMG CSS override the phone NONE CSS? I suppose the DN CSS should take precedence over other CSS and even DMG's CSS should not interfer in that. Even setting DMG to NONE had no effect. Restricted
Could this be a bug in CUCM 6.1.4-2000 or something very odd in the setup I'm working on? My Cisco reseller/service provider was not able to provide me a straight answer that's is a bug or not. It might be coincidence but some other cluster manager from another office where calls are more restricted said we started seeing this behavior sometime in november and cluster was upgraded from 6.1.3 in october.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...