MUC: service-unavailable is mapped to Channel_Full which ain't necessarily so
Submitted by Will Thompson @wjt
Assigned to Telepathy bugs list
Description
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 error condition:
The example given there has type='wait':
``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'?
Version: git master