Bug 62557 - MUC: service-unavailable is mapped to Channel_Full which ain't necessarily so
Summary: MUC: service-unavailable is mapped to Channel_Full which ain't necessarily so
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-20 13:37 UTC by Will Thompson
Modified: 2019-12-03 19:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2013-03-20 13:37:01 UTC
case WOCKY_XMPP_ERROR_SERVICE_UNAVAILABLE:
            tp_error = g_error_new (TP_ERROR, TP_ERROR_CHANNEL_FULL,
                "room is full");
            reason = TP_CHANNEL_GROUP_CHANGE_REASON_BUSY;
            break;

Sure enough XEP-0045 http://xmpp.org/extensions/xep-0045.html#enter-maxusers says:

> If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a <service-unavailable/> error condition:

The example given there has type='wait':

  <error by='coven@chat.shakespeare.lit' type='wait'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>

I've never seen by='' on <error> before, but it is defined in XMPP Core to be the JID of the entity which generated the error. Actually pretty useful, potentially. The error a user was seeing when trying to join a room is:

* presence xmlns='jabber:client' from='test@conference.collabora.co.uk/Iain Holmes' to='iains@jid.com/69c77204' type='error'
    * status
    * x xmlns='http://jabber.org/protocol/muc'
    * x xmlns='vcard-temp:x:update'
        * photo
    * error code='503' type='cancel'
        * service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'

which I happen to know was generated by his server being unable to open an S2S connection to conference.collabora.co.uk because he didn't have xmpp-server SRV records on his domain so dialback would fail.

I bet we can't reliably expect to see by='' on <error>s generated by real MUC servers so it's not that obvious how we could distinguish the two. Possibly by type='wait' vs. type='cancel'?
Comment 1 GitLab Migration User 2019-12-03 19:58:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/255.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.