|Summary:||MUC: service-unavailable is mapped to Channel_Full which ain't necessarily so|
|Product:||Telepathy||Reporter:||Will Thompson <will>|
|Component:||gabble||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||RESOLVED MOVED||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
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 firstname.lastname@example.org' 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' email@example.com/Iain Holmes' firstname.lastname@example.org/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.