Tuesday, July 21, 2015

Centrally Refreshing Jabber Contact Photos in MRA Deployments

I have assisted several customers with Jabber deployments lately. Almost all of them driven by the desire to implement Mobile and Remote Access (MRA). Provisioning MRA is not the topic of this article. Instead, I wanted to touch on an operational task that has annoyed me for some time. 

The issue is with caching of Jabber contact photos. Windows and Mac Jabber clients are coded to cache various things. I assume this is an effort to minimize network transactions and optimize client performance. One of the elements cached are contact photos. I have no problem with caching but, in my experience, the issue is that old contact photos tend to be permanently cached and I can't easily (i.e. centrally) force a refresh. 

I played around with some options and found a method that worked in some test environments and my own production environment. Maybe this will work for others. I would be interested in hearing about other options. Please use the comments to enlighten me and others!

Background

There are several Jabber scenarios and it is possible that other combinations of parameters will behave differently. This article is specifically focused on the following scenario:

Software
  • Jabber for Windows (J4W) 10.5, 11.0
  • Jabber for Mac (J4M) 10.6
  • Cisco Expressway or VCS X8.5.2
  • CUCM 10.5(2)
Configuration

Cisco Mobile and Remote Access (MRA). Which implies that we are using URLs to serve up contact photos and NOT AD object attributes. Specifically, we have an entry in the jabber-config.xml that specifies a URL that should be used for downloading contact photos. Something like this:

<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PresenceDomain>ucguerrilla.com</PresenceDomain>
<BDIPresenceDomain>ucguerrilla.com</BDIPresenceDomain>
<UdsPhotoUriWithToken>http://avatar.ucguerrilla.com/%%uid%%.png</UdsPhotoUriWithToken>

</Directory>


The Issue

The issue is fairly simple. Assume that you have provisioned your MRA environment and you add or change the contact image for one or more Jabber user. What you'll find is that your J4W and J4M clients may not render the new contact photo for an existing contact in their contact list. 

Now, the user experience will vary depending on the scenario:


New Contact, New Photo

Assume that a Jabber user (e.g. jsmith@ucguerrilla.com) had a new image added to the repository. Whether the user jsmith had a previous image or not, the behavior in the "New Contact, New Photo" scenario is the same.

In this scenario, you have a watcher (someone with a contact list in Jabber) that was not watching jsmith prior to the photo change. When this user adds the contact, the new photo should be rendered. Note, I have noticed that if a Jabber user previously searched for the new contact (e.g. jsmith) to place a call (but never added the contact) then it is possible that the old image is still cached.

Existing Contact, New Photo

In this scenario, the Jabber user (jsmith) is in another user's contact list. However, jsmith never had a contact photo. So, we were seeing the "grey head" avatar. The admin uploads a new photo to the web server and expects the contact photo to automatically refresh. 

In my experience, the contact photo does not refresh for Jabber clients until something else happens. For instance, the presence status for jsmith changes or a Jabber user starts a chat with or places a call to jsmith. Logging out and logging back in would probably refresh the contact photo, too. I believe I tested that but the memory may be off. 

Existing Contact, Changed Photo

This is the annoying scenario. User jsmith is a contact for another Jabber user and we recently changed the contact photo for Mr. Smith. In my experience, the contact photo for J4W and J4M clients will never refresh. We'll just keep seeing the old photo. I tested this across a multi-day period in a production environment. Contact photos would not refresh. 

Deleting and re-adding the contact does not do squat nor does logging out/logging back in. Without some intervention, the contact image doesn't change.

What About Mobile Clients

For the sake of clarity let's talk about the iOS and Android Jabber clients. In my testing (iPhone, iPad, and Android tablet) the Jabber clients on these platforms will automatically refresh contact photos. My assumptions is that they don't cache the photos. I did observe that the Jabber watcher needs to do something on their end that forces a screen refresh in the UI. 

The Fix

There are basically two fixes that I am aware of. One is a method documented by Cisco and the other is something I experimented with in my lab and one production environment. 

Wipe the Cache

The method I have seen documented by Cisco is to basically delete the photo cache stored in the file system of the client OS. The process for Windows clients is documented here:



For OSX clients, the photo cache is located here:

/Users/<user>/Library/Application Support/Cisco/Unified Communications/Jabber/CSF/Photo Cache/

The process is simple. Shutdown the Jabber client (completely exit the application). Go to the appropriate folder and delete all of the .jpg or .png files in the photo cache. Then reload the Jabber client and your photos should be refreshed.

While functional, this method has an elevated suck factor in most environments. If you have an environment where everyone logs out of their workstation at the end of the day and when they log back in you have a method to run centralized administrative scripts, then maybe you don't care. I don't think this is as common a practice as it used to be. 

Regardless, this is the only documented method that I have come across when searching for a resolution to this problem.

Change Jabber Config File

Consider this a candidate solution at this time. I haven't exhaustively tested it but I have tested in a lab environment and my corporate production environment. Basically, I pondered the question of whether the Jabber client would detect that the contact photo URL had changed and that it would respond by retrieving new contact images. My test results were positive.

The process I used:

1. Backup the current jabber-config.xml file. You can use a TFTP client to do this or you can go to http://<CMTftpHost>:6970/jabber-config.xml and save the XML document to a text file.

2. Make the necessary changes in your environment to accommodate a change to the UdsPhotoUriWithToken attribute. For instance, in the example provided earlier, my contact photo URL was http://avatar.ucguerrilla.com/%%uid%%.jpg.

So, I added a new DNS "A" record: avatar2.ucguerrilla.com. I then updated my web server (IIS) to add the appropriate bindings. If you are modifying the DNS then you should test the DNS resolution from your Expressway-C or VCS-C appliance. Go to Maintenance > Tools > Network utilities > DNS lookup and test DNS resolution.

3. Update the jabber-config.xml file that you downloaded. Change the contact photo URL. 

4. Upload the jabber-config.xml file to all of the TFTP servers in your CUCM cluster. 

5. Restart the TFTP service on all affected TFTP nodes. 

6. Go to http://<CMTftpHost>:6970/jabber-config.xml and double check your work. 

Once this is done, I found that if I logout/login or restart the J4W or J4M clients that my contact photos refreshed. Interestingly enough, I also found that when the user with the new contact photo loads their client they still see the old contact photo. Even after the remedy is applied. If they view their own user profile then the contact photo refreshes. 


Conclusion

The process I provide above ("Change Jabber Config File") isn't what I would call fully vetted. The concept worked for me and I may test it further but your mileage may vary. I am curious if this approach works for others. Please use the comments below.


Thanks for reading. If you have time, post a comment!

2 comments:

  1. I was chatting with someone at Cisco the other day, and complaining about having to reload the TFTP server every time you change jabber-config.xml They were surprised that I didn't know about a new feature in CUCM 10.5: You only need to restart the TFTP process if there is a new file to server. If you update existing files, there is no need to restart the TFTP process. Tried it on my test & live systems and it works!

    ReplyDelete
    Replies
    1. I'll have to test that out. Good to know for sure.

      Thanks for the info.

      -Bill (@ucguerrilla)

      Delete