[Bug 62557] New: MUC: service-unavailable is mapped to Channel_Full which ain't necessarily so

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62557

          Priority: medium
            Bug ID: 62557
          Assignee: telepathy-bugs at lists.freedesktop.org
           Summary: MUC: service-unavailable is mapped to Channel_Full
                    which ain't necessarily so
        QA Contact: telepathy-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: will.thompson at collabora.co.uk
          Hardware: Other
            Status: NEW
           Version: git master
         Component: gabble
           Product: Telepathy

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 at 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 at conference.collabora.co.uk/Iain
Holmes' to='iains at 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'?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.