powered by Jive Software

Openfire MUC doesn't handle ghost resources and sharing MUC connections from a bare jid

We received a bug report (Pidgin #8319) at Pidgin where the user was losing his network connection and, when logging back in, he would automatically rejoin an XMPP MUC (hosted on an openfire server) which immediately disconnected him. The key is that he was not specifying an account resource, so the two connections to the MUC come from different (randomly-generated) resources. When joining the room, the server notices that the previous resource is gone. Pidgin receives (unrelated caps and priority stripped from the XML; pay attention to the resources):

<presence to="danny@example.com/df8add25" from="thewaffle@conference.example.com/danny" type="unavailable">
     <x xmlns="http://jabber.org/protocol/muc#user">
          <item jid="danny@example.com/cde4928d" affiliation="owner" role="none"/>

which causes us to believe we should disconnect from the room [side note: in an anonymous room when the user is not an administrator, there is no way to determine that the received unavailable presence is a different resource and not an indication that we should disconnect]

deryni (see comments 6 & 7 on the Pidgin ticket) discussed this in jdev@conference.jabber.org, where the thinking seemed to be that Openfire should both be tagging the user’s own presence with the 110 code and should not be routing the unavailable presence, although there has been no formal consensus on the proper way to handle this (as far as I know) and clarify the XEP.

What are the views of the Openfire developers on this issue (or is there anything that isn’t clear)?

Message was edited by: DarkRain42 s/domain name/example.com/g