processone / ejabberd

Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
https://www.process-one.net/en/ejabberd/
Other
6.03k stars 1.5k forks source link

Mucsub subscription messages are not receiving when the same user joins groupchat using Muc join #4037

Open wtomaszewski-applause opened 1 year ago

wtomaszewski-applause commented 1 year ago

Environment

Configuration (only if needed):

  mod_muc:
    hosts: ["myhost"]
    db_type: sql
    ram_db_type: sql
    access: muc
    access_create: muc_admin
    access_persistent: muc_admin
    access_admin: muc_admin
    max_users: 2500
    max_user_conferences: 2500
    ## ejabber keeps N last messages in memory, but there is no way to flush
    ## this cache we have to keep this cache at zero level for deleting messages
    history_size: 0
    default_room_options:
      allow_change_subj: true
      allow_private_messages: false
      allow_visitor_nickchange: false
      anonymous: false
      captcha_protected: false
      logging: true
      mam: true
      max_users: 500
      members_by_default: true
      persistent: true
      public: false
      public_list: false
  mod_offline:
    access_max_user_messages: max_user_offline_messages
  mod_mam:
    default: always
    db_type: sql
    assume_mam_usage: true
    use_cache: false
  mod_client_state:
    queue_chat_states: true
    queue_presence: true

Errors from error.log/crash.log

No errors

Bug description

I have two clients which uses ejabberd server, browser client and mobile client. Browser client is using mod_muc module and there was a need to add support to mobile client and at the result of discussion in this issue: https://github.com/processone/ejabberd/issues/4012 the decision was to use mucsub module for mobile client. Overall that approach is looking good, there was a need to adjust logic in browser client to detect if mobile client is subscribing to group-chat instead of checking the presence. But there is an issue which I want to report for which when we have the same user which is connecting using Strophe library to browser and mobile client in the same time, when browser client join the chat room and mobile client subscribe to the same room, the mobile client is no longer able to receive any messages in real time but browser client can receive successfully. I did a look at the documentation and there is a mention which I think is related to that issue:

If a user wants to be present in the room, they just have to join the room as defined in XEP-0045.

A subscriber MAY decide to join a conference (in the XEP-0045 sense). In this case a conference MUST behave as described in XEP-0045 7.2 Entering a Room. A conference MUST process events as described under XEP-0045 7.1 Order of Events except it MUST not send room history. When a subscriber is joined, a conference MUST stop sending subscription events and MUST switch to a regular groupchat protocol (as described in XEP-0045) until a subscriber leaves.

https://docs.ejabberd.im/developer/xmpp-clients-bots/extensions/muc-sub/#:~:text=at%20any%20time.-,Joining%20a%20MUC%20Room,-If%20a%20user

Do you have any ideas how to resolve that issue which I'm facing?

  1. I was thinking if I should switch to use mucsub inside browser client but that could be challenging and quite complex so I'm trying to find if there is a better solution.
  2. I cannot use MUC join for mobile client as mod_client_state is not working when MUC join is used (check above issue link)
  3. Is it possible to disable somehow that restriction to stop all subscriptions in the chat room when the same user is joining the room via sending the presence?
prefiks commented 1 year ago

So this work that way per design, and there is no flag to alter this behaviour. Possibly using mod_carbon_copy will help here? It i think could be setup so regular muc messages from web client will be also delivered to other clients.

badlop commented 1 year ago

Right, looking at the documentation that behavior is by design.

@wtomaszewski-applause: if the mod_carbon_copy idea does not work, an alternative would be to write a small patch with your desired behavior, that you could include in your fork.