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: NEW
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: 2013-03-20 13:37 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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'?


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.