tp_error = g_error_new (TP_ERROR, TP_ERROR_CHANNEL_FULL,
"room is full");
reason = TP_CHANNEL_GROUP_CHANGE_REASON_BUSY;
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 email@example.com' 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' firstname.lastname@example.org/Iain Holmes' email@example.com/69c77204' type='error'
* x xmlns='http://jabber.org/protocol/muc'
* x xmlns='vcard-temp:x:update'
* 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'?
-- 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.