Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
Extracted elements (22)
An XMPP-to-SIP gateway might theoretically "upgrade" from pager mode to session mode (MSRP) when a message exceeds 1300 bytes, but this behavior is application-specific and no guidelines are provided for how to perform such an upgrade.
Only pager-mode (single) messages are covered by this document because they form the lowest common denominator for IM interworking; session-mode chat (RFC 7573) and group chat are addressed in separate documents.
This document maps semantics directly between SIP/SIMPLE and XMPP (rather than through the CPIM abstract model of RFC 3860) because that is how existing interworking systems solve the problem in practice.
RFC 3428 limits SIP MESSAGE requests outside a media session to 1300 bytes, while RFC 6120 allows XMPP stanzas up to at least 10,000 bytes. This mismatch requires gateways to enforce the 1300-byte limit when translating XMPP messages to SIP.
SIP user agents presented with an im: URI must resolve it to a sip: or sips: URI (per RFC 3428 Section 5), so the Request-URI received by a SIP-to-XMPP gateway will contain a sip: or sips: URI.
There is no SIP header field that matches the meaning of the XMPP message 'type' attribute values ("normal", "chat", "groupchat", "headline", "error"), so no general mapping is possible; the 'type' field is dropped when translating XMPP to SIP.
XMPP stanza-handling rules (RFC 6121) allow a receiving XMPP server to deliver a message stanza addressed to a bare JID to multiple connected devices, which is analogous to SIP message "forking".
A SIP-XMPP gateway MUST be compliant with the minimum security requirements of the textual chat protocols for which it translates (i.e., SIP or MSRP and XMPP).
An IM-aware SIP-to-XMPP gateway MUST process SIP messages that contain message bodies of type "text/plain" and MUST encapsulate such message bodies as the XML character data of the XMPP <body/> element.
An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html"; if so, the gateway MUST transform the "text/html" content into XHTML content conforming to the XHTML-IM Integration Set (XEP-0071).
An XMPP-to-SIP gateway SHOULD return a <policy-violation/> stanza error if an XMPP user attempts to send an XMPP message stanza that would result in a SIP MESSAGE greater than 1300 bytes.
Gateways MUST map language tagging mechanisms (XMPP xml:lang attribute and SIP Content-Language header) if they are present in the original message.
If the SIP-to-XMPP gateway has information about the GRUU of the particular SIP endpoint, it MUST map the sender's address to a full JID (localpart@domainpart/resourcepart) in the 'from' attribute of the XMPP stanza, including the GRUU as the resourcepart.
The mapping of SIP syntax to XMPP syntax MUST follow the defined table, including mapping Call-ID to <thread/>, Content-Language to xml:lang, From to the 'from' attribute, Subject to <subject/>, and the MESSAGE body to <body/>.
The mapping of XMPP syntax to SIP syntax MUST follow the defined table, including mapping <body/> to the SIP MESSAGE body, <subject/> to Subject header, <thread/> to Call-ID, and xml:lang to Content-Language.
The XMPP-to-SIP gateway MUST map the bare JID (localpart@domainpart) 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.
When transforming SIP pager-mode messages, an IM-capable SIP-to-XMPP gateway MUST specify no XMPP 'type' attribute or, equivalently, a 'type' attribute whose value is "normal".
A single SIP instant message is a SIP MESSAGE request sent from a SIP user agent, addressed to an IM URI (im:user@domain) or a SIP/SIPS URI (sip:user@domain or sips:user@domain), as defined in RFC 3428.
A single XMPP instant message is an XML <message/> stanza of type "normal" (the default, often omitted) sent over an XML stream, with the 'to' address set to a bare JID (localpart@domainpart) per RFC 6121 Section 5.1.
The SIP-to-XMPP gateway returns a SIP 200 OK to the MESSAGE sender after translating the request into an XMPP message stanza and forwarding it toward the XMPP user.
For interoperable end-to-end encryption between SIP and XMPP clients, methods such as RFC 3862/RFC 3923 exist but are not widely implemented; Off-the-Record Messaging (OTR) is more widely implemented but is not standardized.
Introducing gateways into the instant messaging security model (RFC 2779) creates new risks: end-to-end confidentiality and integrity between IM clients that interface through a gateway can only be achieved if both sides support common formats, which is currently not widely standardized.