In this post, we will look at Presence Call lists and how they are configured for a Cisco Unified Communications Manager (CUCM) cluster. There are two foundational areas that must be done to get presence call lists to work, 1) you need to create a presence policy and 2) you will need to enable presence call list in the cluster.
A presence policy deals with two constructs, a watcher and a presence entity. The policy must allow the watcher to request and receive presence information from the entity in order for that presence to appear in the call list or directory when those services are requested on the IP Phone.
Communications manager uses a combination of subscribe CSS which was briefly described in the previous blog and Presence Groups. Now, when devices like phones or trunks are created in the cluster, by default they are all assigned to the default ‘standard presence group’. If a presence policy needs to be further developed to prevent let’s say the intern from seeing if the CEO is busy, then just using this standard presence group would be difficult to enact a proper presence policy.
A better solution is to create more presence groups and place like members into them. For instance a Executive and employee and intern presence groups could be created and used. Now the rule is anyone within a presence group is allowed to send and receive presence information. However, between presence groups, it is not allowed by default. But if I configure 3 separate presence groups, how can CEO see the presence information on employees. Communications Manager allows you to provide ‘allow subscriptions’ between presence groups as you create them. So I would allow Executive Group to see Employee and intern, Employee group to see intern but not allow interns to see Executive or Employees or Employees to see presence information on Executives. This is completely controlled by the PBX Administrator.
Once presence groups are created then they are applied either at the phone or line level. If a presence group is assigned to the phone, the phone is now a watcher of all entities within its presence group or those allow subscribing to others and if the presence group is assigned to the line, then it becomes a presence entity which would respond to and send presence information requested by the watchers.
Now Cisco recommends you keep the Groups quite general and then use Subscribe CSS to narrow down within a grouping which watchers could ROUTE presence requests to which entities. For instance, I would have many types of Executives like CEO, President and assorted VP’s. Since they are all in the same presence group, a more defined approach would be needed to restrict the VP’s from seeing the President and CEO presence information. That is when the subscribe CSS would come in. It is configured like any other Class of Control calling search space but however instead of restricting which line can dial which number, when the calling search space is applied to the Subscribe CSS, it determines if the watcher could actually route the request to that entity.
So in order to complete the configuration of Call or Directory presence in a Communications Manager Cluster you must:
- Enable the ‘BLF for call lists’ which is an enterprise parameter
- Verify the setting of the system service parameter of call manager ‘default inter-presence group subscription is set to disallow. Note: this setting determines if presence groups automatically forward presence to all other groups by default. It is highly recommended to leave this setting as is and manually configure which presence groups are allow to forward presence to other groups.
- Create Presence groups and assign which are allowed to forward subscriptions to.
- Create Calling Search spaces for presence routing.
- Assign the presence groups to Phones as watchers and assign presence groups to lines to be a presence entity to be watched.
- Assign the subscribe CSS on phones as watchers to forward presence requests to the presence entities.
The next post will deal with Cisco’s Enhanced Presence capabilities.
Author: Joe Parlas