Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
Extracted elements (27)
Although a conference event package subscription (RFC 4575/RFC 6502) is not strictly required by RFC 7701, the document recommends it because XMPP MUC's temporary presence subscriptions and room rosters are best mapped to the SIP conference event package. This allows room participant lists to be delivered via NOTIFY rather than requiring custom mechanisms.
Because the XMPP room roster is communicated as multiple presence stanzas (one per participant) while the SIP conference participant list is a single conference-info document, the SIP-to-XMPP gateway must track participants and detect when the complete roster has been received—specifically when the joining user's own in-room presence arrives (as XEP-0045 defines this as the last stanza in the initial batch).
XMPP treats groupchat messages as ordinary stanzas handled by the server or a MUC component, whereas MSRP treats groupchat as a media session (like audio/video) requiring a conference focus for signaling and a separate MSRP switch for data. This architectural difference drives the mapping complexity in this document.
In practice, SIP implementations treat <display-text/> as canonical for display, and XMPP implementations use the resourcepart of the occupant JID when <nick/> (XEP-0172) is absent. Gateways should use <display-text/> if the XCON 'nickname' attribute is absent (SIP side) and use the occupant JID resourcepart if <nick/> is absent (XMPP side).
MSRP messages may exceed the maximum message size allowed by an XMPP service on the far end of an MSRP-to-XMPP gateway. RFC 7573 discusses this size mismatch issue for one-to-one sessions; the same concern applies to groupchat.
The XMPP MUC room reflects a sender's message back to all users including the sender. The MSRP-to-XMPP gateway SHOULD wait until receiving this reflected message before sending an MSRP 200 OK reply to the original sender, to correctly handle XMPP moderated rooms where message acceptance is not guaranteed.
If an XMPP-to-MSRP gateway supports private messaging, it MUST advertise that capability by adding a 'private-messages' value to the a=chatroom SDP attribute sent to the conference focus.
If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the conference event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.
Implementations MAY wait until the nickname is set via an MSRP NICKNAME chunk before joining the XMPP MUC, or MAY choose a temporary nickname (such as the SIP From display name) to join immediately.
Implementations SHOULD apply the rules for preparation and comparison of nicknames specified in RFC 7700 (Nicknames profile of PRECIS). If there is a conflict between SIP and XMPP nicknames, the gateway is responsible for adjusting the nickname and informing the client of the unique nickname used.
The mapping of MSRP/CPIM syntax elements to XMPP syntax elements MUST follow the defined table: CPIM To maps to XMPP 'to', CPIM From maps to XMPP 'from', and the SEND request body maps to XMPP <body/>.
The mapping of RFC 4575 conference-info payload elements to XMPP participant list elements MUST follow the defined table: <conference-info/> 'entity' maps to room JID, <subject/> to room subject, <user/> 'entity' to occupant JID, <display-text/> to participant nickname, and <user/> 'associated-aors' to user full JID.
The mapping of SIP/RFC 4575 elements to XMPP syntax when broadcasting presence MUST follow the defined table: <user/> 'entity' maps to XMPP 'from', <role>participant</role> maps to role='participant', and affiliation defaults to 'none'.
The mapping of XMPP message elements to MSRP/CPIM syntax MUST follow the defined table: XMPP 'to' maps to CPIM To, 'from' maps to CPIM From, and <body/> maps to the body of the MSRP SEND request.
The mapping of XMPP syntax elements to SIP/SDP syntax elements when joining a room MUST follow the defined table: the XMPP 'from' maps to SIP From, and the XMPP 'to' (without the nickname resourcepart) maps to SIP To.
The MSRP URI authority component in the SDP 'path' attribute MUST contain the XMPP-to-MSRP gateway hostname or numeric IP address, as well as an explicit port number in accordance with RFC 4975.
The XMPP-to-SIP gateway MUST map the bare JID of the XMPP sender to the SIP From header and include the resourcepart of the full JID as the GRUU portion of the SIP URI, as specified in RFC 5627.
A private message from an XMPP user is sent as a message of type 'chat' to the recipient's occupant JID and translated into an MSRP SEND with the CPIM To header containing the occupant's SIP URI with GRUU (e.g., <sip:[email protected]>;gr=Romeo).
A public groupchat message from an XMPP user is sent as a message of type 'groupchat' to the room JID and translated by the gateway into an MSRP SEND request with a message/cpim Content-Type wrapper. The gateway must also reflect the message back to the XMPP sender, as required by XEP-0045 for moderated rooms.
A SIP user joins an XMPP MUC room by sending a SIP INVITE containing an SDP offer with an MSRP media line, mandatory 'path' and 'chatroom' attributes, and an 'accept-types' attribute specifying support for Message/CPIM. The SIP-to-XMPP gateway then sends a directed XMPP presence stanza to the MUC room.
After SIP session establishment, the gateway sets the XMPP user's room nickname using the MSRP NICKNAME method (defined in RFC 7701), sending the resourcepart of the occupant JID as the Use-Nickname header value. A 200 response indicates acceptance; a 425 response indicates a nickname conflict.
An XMPP user exits a room by sending a directed presence stanza of type 'unavailable' to their occupant JID. The gateway translates this into a SIP BYE to the conference focus, which responds with a SIP 200 OK, and the XMPP server delivers an unavailable presence to the user.
An XMPP user joins a MUC room by sending a directed <presence/> stanza to the room occupant JID (e.g., [email protected]/JuliC) containing an empty <x/> element in the 'http://jabber.org/protocol/muc' namespace. The gateway transforms this into a SIP INVITE with an SDP offer specifying an MSRP media line.
Room invitations from XMPP use mediated invitations (sent through the room via XEP-0045 <invite/> element); the gateway translates these into a SIP REFER request to the conference focus with the invitee's address in the Refer-To header, as per RFC 4579 Section 5.5.
A gateway translating between SIP/MSRP and XMPP MUST be compliant with the minimum security requirements of both protocols. Introducing gateways into the security models of MSRP, SIP, and XMPP creates new risks: end-to-end security properties (confidentiality and integrity) can only be provided if common formats are supported, but no standardized solution for end-to-end security of multi-party messaging exists.
Advanced security-relevant groupchat features (room administration, kicking/banning users, room moderation) are not addressable through the minimal interoperability baseline defined in this document; users needing these features must use native protocol clients rather than gateways.
When an MSRP switch returns a 425 (Nickname usage failed) response to a NICKNAME request, the gateway translates this into an XMPP presence stanza of type 'error' with a <conflict/> error condition. Alternatively, the gateway may generate a new nickname request on behalf of the XMPP user to shield it from the conflict.