Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions
Extracted elements (22)
The MSRP Failure-Report header field is set to 'no' by default because XEP-0184 (XMPP Message Receipts) has no mechanism for failure delivery notifications; there is therefore no mapping for failure reports across the gateway.
There is no reliable way for the gateway to determine whether the remote SIP user's client supports MSRP; if MSRP is not supported, the SIP INVITE initiated on behalf of the XMPP user may result in an error. This is an inherent limitation of the bridging approach.
XMPP chat is an informal construct requiring no session negotiation, whereas MSRP requires a formally negotiated SIP session. To bridge these paradigms, an XMPP-to-MSRP gateway must maintain additional state on behalf of the XMPP user.
MSRP supports chunked message transfer (unlike SIP page-mode messaging limited to 1300 bytes); the MSRP gateway acting as an MSRP endpoint is responsible for receiving chunked MSRP SEND requests and reassembling them into a single message before delivering to the XMPP recipient.
Per RFC 6120 Section 13.12, XMPP service maximum stanza size must not be less than 10,000 bytes; gateway implementors must account for this floor when configuring MSRP message size limits.
The MSRP gateway at an XMPP service must be configured with the same or smaller maximum MSRP message size as the XMPP service's maximum stanza size, enabling proper SDP 'max-size' attribute advertisement and correct handling of oversized messages.
XEP-0085 defines five chat states (active, inactive, gone, composing, paused) while RFC 3994 defines only two (idle, active). Gateways may either map only composing-related states or map all five XEP-0085 states; the document provides suggested mappings for both directions.
XMPP provides no explicit method for a user to formally terminate a chat session; gateways must listen for a 'gone' chat state from the XMPP user or implement a timer (XEP-0085 suggests 10 minutes of inactivity) to trigger SIP BYE.
Because the XMPP Message Receipts specification (XEP-0184) does not support failure reports, gateways SHOULD set the MSRP Failure-Report header field to 'no', preventing unnecessary MSRP failure notifications that cannot be forwarded to XMPP.
Gateways that support chat state notifications MUST support the 'gone' chat state, which is merely recommended (not required) by XEP-0085 but is essential for proper session lifecycle management across the gateway.
If an MSRP-to-XMPP gateway receives an MSRP message exceeding its configured size limit, it MUST return an MSRP 413 error, for example in response to the first SEND request whose Byte-Range header indicates a byte total exceeding the limit.
When mapping MSRP to XMPP, the mapping of SIP syntax to XMPP syntax MUST be as specified in RFC 7572.
When mapping XMPP to MSRP, the mapping of XMPP syntax to SIP syntax MUST be as specified in RFC 7572.
Composing event mapping from SIP/SIMPLE (RFC 3994) to XMPP (XEP-0085): isComposing 'active' maps to XMPP 'composing'; isComposing 'idle' maps to XMPP 'active'.
Composing event mapping from XMPP (XEP-0085) to SIP/SIMPLE (RFC 3994): XMPP 'active', 'inactive', and 'paused' all map to isComposing 'idle'; XMPP 'composing' maps to isComposing 'active'; XMPP 'gone' has no isComposing equivalent and is handled separately.
Delivery receipt mapping: XMPP <request xmlns='urn:xmpp:receipts'/> maps to MSRP 'Success-Report: yes'; XMPP <received xmlns='urn:xmpp:receipts'/> maps to an MSRP REPORT chunk. The reverse mappings apply symmetrically.
MSRP to XMPP direction: upon receiving a SIP INVITE for an XMPP-domain user, the MSRP-to-XMPP gateway accepts the session on behalf of the XMPP user by returning a SIP 200 OK with SDP, then delivers messages as XMPP <message type='chat'> stanzas.
Receipt of the XMPP 'gone' chat state at an XMPP-to-MSRP gateway serves as a trigger to send a SIP BYE, formally terminating the MSRP session. Conversely, receipt of a SIP BYE at an MSRP-to-XMPP gateway triggers a 'gone' chat state notification to the XMPP user.
The XMPP <thread/> element value is mapped to the SIP Call-ID header field, providing session continuity across the gateway. This preserves the conversational context when bridging XMPP informal sessions to MSRP formal sessions.
The XMPP-to-MSRP gateway initiates a SIP INVITE with SDP specifying 'm=message ... TCP/MSRP' and an 'a=path:msrp://...' attribute on behalf of the XMPP user when the first XMPP chat message is received for a new session.
Security considerations for this document are addressed by reference to: RFC 2779 (instant messaging requirements), RFC 4975 and RFC 3261 (MSRP and SIP), RFC 6121 and RFC 6120 (XMPP IM), RFC 7247 (SIP-XMPP interworking architecture), and RFC 7572 (end-to-end encryption of instant messages).
The XMPP-to-MSRP gateway maintains session state across five phases: (1) receive XMPP chat message, (2) send SIP INVITE on behalf of XMPP user, (3) receive 200 OK and send ACK, (4) relay messages bidirectionally via MSRP SEND, (5) terminate on SIP BYE or XMPP 'gone' chat state.