Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
Extracted elements (25)
Address mapping scope is limited to the local part (username/localpart) of addresses. Domain-name mapping is ruled out of scope as a DNS matter; instance-specific mapping (GRUU / resourcepart) is treated secondarily. Telephone numbers and other protocol-specific identifiers are explicitly out of scope.
Error mapping between SIP and XMPP is characterized as 'more of an art than a science' because XMPP defines only 22 error conditions while SIP defines over 71 response codes, many SIP codes are more specific than their XMPP counterparts, and SIP distinguishes endpoint-level (4xx) from user-level (6xx) failures while XMPP does not.
Mapping XMPP <service-unavailable/> to SIP 503 is NOT RECOMMENDED because SIP 503 signals that a server is unreachable for all future requests, whereas XMPP uses <service-unavailable/> to indicate missing feature support, user-level unavailability, or to avoid disclosing account existence. SIP 403 or 405 are the closest alternatives.
The series adopts direct protocol-to-protocol mapping rather than mapping through an abstract intermediary model (as described in RFC 3859 and RFC 3860), because practical interworking has been achieved through direct mappings in deployed systems.
The specification defines protocol translation as occurring within dedicated gateways rather than within multiprotocol clients or servers. This choice is made primarily for explanatory clarity, allowing translation principles to be understood and applied with modifications by client and server implementors.
No XMPP error conditions are equivalent to SIP provisional (1xx) or successful (2xx) response codes; therefore this document suggests error mappings only for SIP redirection (3xx), request failure (4xx), server failure (5xx), and global failure (6xx) families.
RFC 6120 binds XMPP exclusively to TCP, so a SIP-to-XMPP gateway must support TCP. By contrast, RFC 3261 allows either TCP or UDP for SIP, and a deployment may support only UDP; therefore an XMPP-to-SIP gateway may need to use either TCP or UDP.
The XMPP <feature-not-implemented/> error maps to SIP 405 when the error relates to a full JID (specific device/resource) and to SIP 501 when it relates to a bare JID (user-level). Similarly, <forbidden/>, <item-not-found/>, <not-acceptable/>, and <recipient-unavailable/> map to 4xx for full JID and 6xx for bare JID.
If the XMPP <gone/> element includes XML character data specifying a new address, it MUST be mapped to SIP 301 (Moved Permanently); if the <gone/> element carries no new address, it MUST be mapped to SIP 410 (Gone).
The mapping of SIP response codes to XMPP error conditions SHOULD follow the table in Section 7.2; for unlisted codes a gateway SHOULD map 3xx to <redirect/>, 4xx to <bad-request/>, 5xx to <internal-server-error/>, and 6xx to <recipient-unavailable/>.
The mapping of XMPP error conditions to SIP response codes SHOULD follow the table in Section 7.1, which maps, e.g., <bad-request/> to 400, <not-authorized/> to 401, <item-not-found/> to 404 or 604, <internal-server-error/> to 500, and <recipient-unavailable/> to 480 or 600.
When mapping SIP 301 to XMPP, the <gone/> element MUST include XML character data specifying the new address. When mapping SIP 410 to XMPP, the <gone/> element MUST NOT include XML character data specifying a new address.
When transforming a local part between address formats, an application SHOULD: (1) unescape escaped characters in the source address, (2) leave unmodified any characters allowed in the destination scheme, and (3) escape characters allowed in the source but reserved in the destination using the destination scheme's escaping rules.
Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to '\hexhex' format as specified in XEP-0106 (JID Escaping).
Where the destination scheme is a URI (im, pres, sip, or sips), each reserved character MUST be percent-encoded to '%hexhex' format as specified in RFC 3986 Section 2.5.
An XMPP resourcepart (the portion of a JID after the slash, e.g., 'foo' in '[email protected]/foo') corresponds semantically to a SIP Globally Routable User Agent URI (GRUU) 'gr' parameter. Both identify a particular device associated with an address of record; the 'gr' URI parameter value maps to the XMPP resourcepart. This mapping applies only to non-temporary GRUUs.
An XMPP-to-SIP gateway translates XMPP syntax and semantics on behalf of an XMPP server (together forming an 'XMPP service'), while a SIP-to-XMPP gateway translates SIP syntax and semantics on behalf of a SIP server (together forming a 'SIP service'). These two logical functions may reside in the same physical entity.
The local part character sets differ across SIP/SIPS, IM/PRES, and XMPP URIs: for example, '&', "'", and '/' are allowed in SIP/SIPS but disallowed in XMPP; '#' is allowed in XMPP and IM/PRES but disallowed in SIP/SIPS. Table 1 enumerates allowed and disallowed non-alphanumeric characters for each scheme.
The SIP-to-XMPP address mapping algorithm removes the URI scheme, splits at '@', percent-decodes the local part, treats it as UTF-8, translates '&' to '\26', "'" to '\27', and '/' to '\2f', optionally applies Nodeprep canonicalization, then recombines with the hostname; if a 'gr' URI parameter is present, it is appended as a resourcepart.
The XMPP-to-SIP address mapping algorithm splits the JID, optionally applies Nodeprep, translates '\26' to '&', '\27' to "'", '\2f' to '/', determines via DNS whether the target supports im/pres or sip/sips URIs, percent-encodes appropriate characters, prepends the chosen scheme, and optionally maps a resourcepart to a 'gr' URI parameter.
When an XMPP server receives a stanza addressed to a foreign domain, it performs DNS SRV lookups for '_xmpp-server' records per RFC 6120. If no XMPP hostname is found, it falls back to RFC 3263 SIP server location procedures. SIP servers perform the reverse: RFC 3263 first, then '_xmpp-server' SRV lookups if no SIP hostname is returned.
A SIP-XMPP gateway acts as a SIP back-to-back user agent (B2BUA), making it susceptible to the amplification vulnerability described in RFC 5393. Gateways SHOULD implement the loop-detection methods in RFC 5393 to mitigate amplification attacks.
Deployed SIP-XMPP gateways SHOULD use TLS (RFC 5246) when communicating over TCP and DTLS (RFC 6347) when communicating over UDP, to protect information flowing between SIP and XMPP systems.
If the To header or Request-URI of a SIP message contains a SIPS URI (indicating all hops must be TLS-protected), the SIP-to-XMPP gateway MUST NOT translate the message into an XMPP stanza and MUST NOT route it to the destination XMPP server, because XMPP lacks a mechanism to signal per-hop security requirements.
The broad Unicode character set allowed in XMPP addresses introduces the risk of user confusion from visually similar ('confusable') characters in identifiers. The PRECIS framework and Unicode Technical Standard #39 describe these issues and provide guidance.