We are trying to federate a room between an M-link server and an OpenFire server.
We have everything we think we need configured, since from M-link using Swift we can enter the room and see both users in the roster of the room both from M-link and Open Fire, but from OpenFire it only sees itself in the roster, using Spark.
In Openfire we have enabled xmpp.muc.room.fmuc.enabled in the server configuration, and the Openfire room has in the Fmuc address the Mlink one.
On the Mlink side, we have the Fmuc enabled and the room pointing to the Openfire room.
In openfire we have imported the Mlink certificate and in MLink the openfire one.
Does anyone know if there is anything missing to configure for it to work properly?
Are both servers able to connect to each-other, outside of multi-user chat room functionality? Can users on both domains chat with each other, for example?
Please check if:
DNS A, AAAA and SRV records exist (where appropriate) for the XMPP domain of both servers, but also for each component, including, crucially, the domain(s) for the multi-user chat services (typically a subdomain of the XMPP domain, such as conference.example.org).
Do the TLS certificates that are in use cover both the XMPP domain name itself, but also those component/service names (through SANs, or by using a wildcard certificate, for example).
Is network connectivity between the servers on the server-to-server ports (5269/5270 by default) impeded by something like an ACL or firewall?
Are you sure that you need to use FMUC, which is an optimization for multi-user chats to improve performance for use in constrained environments?
In (by far) most cases, it is unnecessary to use the FMUC functionality (which has only experimental support in Openfire) for users of a different server/XMPP domain to join a multi-user chatroom on another server/domain. If you’re only interested in achieving this, then FMUC is not needed.
If you do need FMUC, then it is quite possible that the implementation of that protocol in Openfire and M-Link is not compatible. Openfire implements the specification, which was authored by the creators of M-Link, Isode. M-Link’s implementation, however, appears to have gone beyond what was written down (they applied learnings, which have not made it yet to the documentation). We have yet to perform interoperability tests.
Both chats can connect, M-link users can talk to Openfire users 1-on-1 and vice versa they can too. M-link users can also connect to openfire rooms and openfire users to M-link rooms.
The DNS is created in the domains and the other as secondary
The certificates used for this test are the self-signed certificates generated by each of the servers when they are installed.
Firewalls are open, so there are no connection limitations.
In my case, it is a development for a client and the connection of federated rooms is one of the requirements.
If it is truly FMUC that you are needing, then you might sadly run into a compatibility issue. As I wrote before, we never have tested the interop between M-Link and Openfire before, and we have strong indications that they’re implementing different versions of the protocol.
To rule out other causes, you could try to setup FMUC between two servers of the same type (both Openfire, or both M-Link).