Unified Personal Communicator Information Flow
We can use Cisco Unified Personal Communicator to place a call using one of two different modes. A deskphone mode, in which we're controlling an actual physical desk phone – or I say a physical desk phone, it could be a software-based IP communicator. The other mode is the softphone mode where Cisco Unified Personal Communicator is acting as the phone itself. First, let's consider deskphone mode.
Here, the Cisco Unified Personal Communicator is going to authenticate with a Cisco Unified Communications Manager using appropriate end-user credentials and using the Cisco Unified Communications Manager IP phone service. Cisco Unified Personal Communicator is going to be able to pull down a list of devices controlled by a specific end user and it's going use CTIQBE to control that phone associated with user. And if a user is associated with multiple phones, the user can select which phone it is that they want to control. Also keep in mind that XMPP that we mentioned earlier that's going to be used by Cisco Unified Personal Communicator for chat and instant messaging features.
Now that we've discussed deskphone mode operation, let's think about softphone mode operation and we might need to use softphone mode operation if a user does not have a phone available, they're not at their desk .The softphone mode will still allow the user to place and receive calls. And we also mentioned earlier that this is going to be based on the CSF framework. We're connecting as a SIP client using a SIP register message to register the softphone with Cisco Unified Communications Manager and when the softphone connects with the Cisco Communications Manager server it's going to download a configuration file. And this configuration file is going to have a listing of Unified Communication Manager servers, a primary server, and a backup server. And if Cisco Unified Personal Communicator is not able to, via TFTP, download, its configuration file, it's going to attempt to load up the configuration file stored locally on the hard drive.
Compliance and Persistent Chat
Let's consider the concepts of a compliance server and persistent chat. With a persistent chat, chat messages within a group, they're going to be stored. They are going to be stored on an external database server - PostgreSQL Server specifically, and the owner of a chat room they have the ability to escalate an ad-hoc chat to a persistent chat. If it's not a persistent chat, these ad-hoc chats, that data's going to be purged from the database after the chat's over and there is also the concept of a compliance server. This typically provides more features than you would get with just a PostgreSQL database as we talked about earlier, a compliance server can add security features as an example. When an instant message comes in, the Cisco Unified Presence is going to send it to this compliance server that's going to check it against the policies and for security, maybe making sure that it doesn't have a virus, it's not spam and then the message goes back to Cisco Unified Presence and it goes out to the intended recipient assuming it passed those compliance checks.
Quality of Service
If our network is configured with quality of service mechanisms, our routers and switches can treat traffic differently based on the quality of service markings. We have a common Layer 2 marking CoS or class of service, and at Layer 3 we have IP precedence markings – that's the older way of marking at Layer 3 that's where we used the 3 leftmost bits in the ToS byte in an IP Version 4 header to mark priority. But more commonly today we use DSCP markings, the Differentiated Services Code Point markings. These markings use these six leftmost bits in the ToS byte. And the IETF has preselected some of the 64 available DSCP values and given them names and specified what their behavior should be relative to one another, and these names are often called PHBs or per-hop behaviors.
In the table above we see the recommended IP precedence, per-hop behavior, DSCP numeric value and CoS value that Cisco recommends for voice, video and call signaling traffic leaving Cisco Unified Personal Communicator from a PC. A potential challenge though is switches are often configured to not trust markings coming in from a PC. Many times a Cisco IP phone will remark this CoS value coming from a PC down to a zero and sometimes when the traffic reaches the switch even though it might have an appropriate Layer 3 marking that marking could be rewritten due to a CoS to DSCP mapping. And the challenge we have here is we have all of these properly marked frames and packets but when those markings reach the switch or the phone they may be rewritten. So what we might need to do is to apply these markings appropriately at the switch, based on the port numbers of the traffic. Next, let's check out some of more common port numbers we might want to recognize and therefore mark.
Cisco Unified Personal Communicator Port Usage
Here's a great reference table for us, showing us port numbers and whether those ports are TCP or UDP or both, but the port numbers that might be used by Cisco Unified Personal Communicator.
|143||TCP||IMAP (TLS or plain TCP)|
|993||TCP||IMAP (over SSL)|
|2748||TCP||CTI Quick Buffer Encoding (CTIQBE)|
|7993||TCP||IMAP (over TLS, Cisco Unity Connection speciffic)|
Again the reason we want to know these port numbers is we might want to classify this Cisco Unified Personal Communicator traffic coming into a switch, so that it can be marked appropriately at Layer 2 and/or at Layer 3 to avoid the switch or the IP phone from remarking these values down to a lower priority marking.