It would be best to see your actual configuration, but MUCs normally have to be enabled as services. The service discovery is indeed the way to discover the MUC service and browse chat rooms, but the client should be able to bookmark them or put them on the roster for use next time.
Anyway, in /etc/ejabberd/ejabberd.cfg have you enabled mod_muc? If so, could you paste the settings. On my ejabberd server I use:
{mod_muc, [
%%{host, "conference.@HOST@"},
{access, muc},
{access_create, muc},
{access_persistent, muc},
{access_admin, muc_admin},
{history_size, 50},
{max_users, 500},
{default_room_options,
[
{allow_change_subj, true},
{allow_private_messages, true},
{allow_user_invites, true},
{anonymous, true},
{logging, true},
{members_by_default, true},
{persistent, true},
{public, true},
{public_list, false}
]}
]},
{mod_muc_log, [
{access_log, muc},
{dirtype, plain},
{dirname, room_jid},
{outdir, "/var/www/muclogs"},
{timezone, universal},
{spam_prevention, true}
]},
In your access rules you should also include:
%% Admins of this server are also admins of MUC service:
{access, muc_admin, [{allow, admin}]}.
%% All users are allowed to use MUC service:
{access, muc, [{allow, all}]}.
It works perfectly fine for me this way. Of course you may not want the log files or so, just adjust the respective settings. The ejabberd homepage has a thorough documentation of the available options.
Best Answer
It uses the clustering capabilities of Erlang : - The ability to message any process on a any node in the erlang cluster - it also uses mnesia, erlang's distributed database for storing the routing table, which contains the JID <-> client process id mapping.
When a message enters ejabberd, it looks up the recipient JID in this table, and sends it to the PID it finds. This process can be anywhere in the cluster, erlang takes care of routing it.