Last week I started seeing problems with the s2s federation with Google, errors like the following were appearing in the SystemOut.log.
[12/03/13 17:24:43:112 GMT] 0000003b LoggableInput 3 com.ibm.rtc.gateway.xmpp.util.LoggableInputStream read(byte b, int off, int len) XMPP logging < : length=203 msg:<presence to=”email@example.com” from=”firstname.lastname@example.org” type=”error”><error code=”503″ type=”cancel”><service-unavailable xmlns=”urn:ietf:params:xml:ns:xmpp-stanzas”/></error></presence>
It looked like Google were building white lists with approved domains. A friendly guy in IBM Support told me that there have been some changes in the Google policies and IBM are trying to “reach out” to Google in order to get a formal response and rectify these problems.
I read an article posted today called Google expected to unify chat under the name Babble and am thinking whether this is the beginning of the end for Gateway and Google federation?
LDAP and Sametime doesn’t always sit well together. There are various things you can do to try and improve LDAP performance, many of which are documented in Best Practices for using LDAP with Lotus Sametime.
STResolve seems to be the main contributor to these problems especially with the latest version of the Notes client which wants to resolve the email address of each email in the view to see whether the user is on line. We all know that email@example.com does not exist in your LDAP so how to stop the Community server sending this to LDAP only to be told that it doesn’t exist?
Well, up until this morning the only way I believed to do this was by way of desktop policies controlling the managed settings of your Notes client as detailed in Optimizing Name Lookup: Clients.
This morning I was sent a URL to Excluding certain domains from user and group directory lookups using Whitelists and Blacklist which says that ST_RESOLVE_BLACKLIST or ST_RESOLVE_WHITELIST can be added to the [CONFIG] section of the sametime.ini. This will effectively do what was previously possible in the client via the plugin_customization.ini.
The document was edited in May last year and when searching for the parameters only a few hits appear on Google so I wonder how well known they are?
I presume the parameter will stop the Community server passing the search filters via STResolve to LDAP but will not stop them being sent to the Community server in the first place. Nonetheless this should dramatically improve STResolve performance.
I will implement and see what happens in the STResolve*.txt trace files, hopefully I will see much less and my customers will be much happier!