#103 Multiple Persistent Chat Pools

[Bryan Stepp]

We have two pools hosting rooms on Skype for Business. When I try to join rooms on the second pool of persistent chat rooms, I get a PIDGIN SIPE error:

Error joining chat room
[6] Node <room uri=""> not found

When I try to join rooms on the first pool of persistent chat rooms - it connects fine.

Running PIDGIN in debug mode only shows traffic connecting out to our first/default persistent chat pool - which doesn't find the room uri (of course - since it's not located on that pool). I don't see any traffic of SIPE checking the other persistent chat pool.

I'm running SIPE (1.20.1-2.el7.x86_64) for CentOS 7

[Stefan Becker]

Full debug logs? Access to a test account? This might not be a bug, but a missing feature.

Very few installations have persistent chat feature and the protocol isn't very well documented. So support is best effort only.

[Bryan Stepp]

I need to run this on our development environment to pull the logs. I will get the logs to you as soon as I can so we can troubleshoot this issue. A quick look over the logging - it looks like I don't even see the discovery of our 2nd persistent chat pool SIP id at all in the debug logs, I only see it checking the first persitent chat pool SIP id. Thank you for looking into it.

[Stefan Becker]

Maybe this is a stupid question: if SIPE "doesn't discover the 2nd pool" according to the log, how can you then select such a chat room from the room list ("Buddies" -> "Join a Chat..." -> account -> "Room List")?

[Bryan Stepp]

Room list only displays the first 100 rooms. We have about 4,000 persistent chat rooms for our organization. We have a service that displays the ma-chan URI for persistent chat rooms. We then join the channel by using the ma-chan URI in PIDGIN.

[Stefan Becker]

The 100 rooms is a known M$ limitation. Unfortunately right now there is no provision in Pidgin to work around that.

If ma-chan://<domain>/<value> doesn't work then I would suspect another protocol change by M$:

static gchar *generate_chanid_node(const gchar *uri, guint key)
{
  /* ma-chan://<domain>/<value> */
  gchar **parts = g_strsplit(uri, "/", 4);
  gchar *chanid = NULL;

  if (parts[2] && parts[3]) {
    chanid = g_strdup_printf("<chanid key=\"%d\" domain=\"%s\" value=\"%s\"/>",
                             key, parts[2], parts[3]);
...
gchar *chanid = generate_chanid_node(uri, 0);
if (chanid) {
    gchar *cmd = g_strdup_printf("<cmd id=\"cmd:join\" seqid=\"1\">"
                                 "<data>%s</data>"
                                 "</cmd>",
                                chanid);
  SIPE_DEBUG_INFO("sipe_core_groupchat_join: join %s",
                  uri);
  chatserver_command(sipe_private, cmd);

As you can see there is no "server ID" anywhere.

[Stefan Becker]

... and your error message would then be from the cmd:join response handler:

static void chatserver_response_join(struct sipe_core_private *sipe_private,
...
{
  if (result != 200) {
    sipe_backend_notify_error(SIPE_CORE_PUBLIC,
        _("Error joining chat room"),
        message);
    } ...

[Stefan Becker]

I think I get a hunch what might be wrong. SIPE only connects to one groupchat URI, either ocschat@domain, the advertised one or the user supplied one. I guess you have a second (development?) Lync environment, but that is advertising the default server. That chat server doesn't know about the rooms on the second server, that's why the joining fails.

I don't think talking to multiple chat servers is supported by [MS-XCCOSSIP].

I'm pretty sure that M$ hasn't implemented communication between chat servers, i.e.

• one server doesn't know what is happening on the other server and
• a server can't proxy for its clients to another server.

If you want to connect to rooms on the second server, you either need to fix the advertisement in the second environment or manually set the Group Chat Proxy field on the Advanced tab. But of course then you can't join rooms on the default chat server

[Bryan Stepp]

I entered the SIP id of the RegistrarPool of the 2nd Persistent Chat pool into the Group Chat Proxy field. I then connected with my account and was able to see/enter the rooms of that 2nd Persistent Chat pool but not the first/default Persistent Chat pool. This bug turns more into a feature request. Is it possible to define the Group Chat Proxy per persistent chat room when joining or enter multiple Group Chat Proxies that SIPE will attempt to use to connect to persistent chat rooms?

[Stefan Becker]

Unless M$ has changed the protocol to advertise multiple chat pool URIs I'm not inclined to modify SIPEs group chat implementation to support more than one active group chat server session. As there is no pool information in the ma-chan: URI the join attempt would turn into a trial & error approach with multiple server sessions.

Having 2 pools sounds like a specific problem of your organizations setup. Does even the M$ client support such a setup?

[Bryan Stepp]

Microsoft Skype for Business client has no issues connecting to multiple persistent chat pools - and no additional information/actions is required for the end user of the Microsoft Skype for Business client to connect to these persistent chat rooms on the secondary Pchat server. I was notified by our Linux users that PIDGIN with SIPE wasn't able to join these rooms. So now it looks like we may have a workaround using the Advance settings, but these users will need to run two instances of PIDGIN SIPE to connect to all chat rooms. I'm hoping that something can be added to PIDGIN SIPE or a better workaround.

[Stefan Becker]

BTW: I'm talking about the following server event:

Content-Type: application/vnd-microsoft-roaming-provisioning-v2+xml
Event: vnd-microsoft-provisioning-v2

<provisionGroupList xmlns="http://schemas.microsoft.com/2006/09/sip/provisiongrouplist-notification">
   ...
   <provisionGroup name="persistentChatConfiguration" >
       <propertyEntryList >
           <property name="EnablePersistentChat" >true</property>
           <property name="DefaultPersistentChatPoolUri" >...</property>
           ...
       </propertyEntryList>
   </provisionGroup>
   ...
</provisionGroupList>

[Stefan Becker]

My guess is that your installation also provides the following property with a white space separated URI list:

<property name="PersistentChatPoolUris" >URI1 URI2 ...</property>

as documented in [MS-SIPREGE] 2.2.2.5.11:

• DefaultPersistentChatPoolUri: Specifies the default persistent chat pool URI for the client to connect to.
• EnablePersistentChat: Specifies whether persistent chat is enabled for the client. The value MUST be "true" or "false".
• PersistentChatPoolUris: Specifies the URIs of all the persistent chat pools that the client can connect to, separated by a single whitespace.

[Stefan Becker]

Ticket moved from /p/sipe/bugs/340/

Can't be converted:

• _milestone: 1.20.x

[Bryan Stepp]

You are correct with your response (using snooper):
<property name="DefaultPersistentChatPoolUri">sip:gc-1-persistentchatservice-1@domain.com</property>
<property name="PersistentChatPoolUris">sip:gc-1-persistentchatservice-1@domain.com sip:gc-2-persistentchatservice-2@domain.com</property>

[Shane Mc Cormack]

I can confirm that I also have a similar issue in our deployment. Looking at the debug output (using PURPLE_UNSAFE_DEBUG=1 pidgin -d I can see that I get served the following:

<property name="DefaultPersistentChatPoolUri" >sip:GC-1-PersistentChatService-8@domain.com</property>
<property name="PersistentChatPoolUris" >sip:GC-1-PersistentChatService-8@domain.com sip:GC-1-PersistentChatService-14@domain.com </property>

pidgin/sipe only seems to query the -8 Pool and not the -14 Pool which causes some rooms to be inaccessible.

[Stefan Becker]

Please remember that SIPE group chat support is best effort only. Group chat is enabled on a few installations only. SIPE developers currently have no access to any account with group chat feature enabled.

This particular feature request would entail a major rewrite/refactor of the SIPE group chat code. Such an effort can only be undertaken with access to a test account.