RFC 7247
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
RFC 7247 ✨ Part 1 of 6
Interworking between SIP and XMPP: Architecture, Addresses, and Error Handling 💖
Title block tea ☕ This one is from the Internet Engineering Task Force (IETF) 🦋 and it's on the Standards Track 👑.
- RFC number: 7247
- Date: May 2014
- Authors: P. Saint-Andre (&yet), A. Houri (IBM), J. Hildebrand (Cisco Systems, Inc.)
- ISSN: 2070-1721
- Obsoletes / Updates: nothing is listed in this title block 🙈
Abstract 🎀
okay so this doc is the foundation for defining two-way protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) 💅. It lays out the architectural assumptions behind those mappings, and it also covers how addresses get mapped and how error conditions get mapped. ✨
Status of This Memo 🌸
this is an Internet Standards Track document 🔥.
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. if you want more on Internet Standards, check Section 2 of RFC 5741 🌈.
info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7247 💜.
Copyright Notice 🧚
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, bestie, because they spell out your rights and restrictions 🙈. code components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as the Simplified BSD License describes 💅.
Table of Contents 🗺️
1. Introduction ....................................................3
2. Intended Audience ...............................................3
3. Terminology .....................................................4
4. Architectural Assumptions .......................................4
5. Interdomain Federation ..........................................6
6. Address Mapping .................................................7
6.1. Overview ...................................................7
6.2. Local Part Mapping .........................................9
6.3. Instance-Specific Mapping .................................11
6.4. SIP to XMPP ...............................................11
6.5. XMPP to SIP ...............................................12
7. Error Mapping ..................................................14
7.1. XMPP to SIP ...............................................15
7.2. SIP to XMPP ...............................................17
8. Security Considerations ........................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................22
Appendix A. Acknowledgements ......................................241. Introduction 🦋
okay so the IETF has been working on two signaling technologies that can handle multimedia session negotiation, instant messaging, presence, capabilities discovery, notifications, and the other stuff real-time communication apps do 💬✨:
- The Session Initiation Protocol [RFC3261], along with a bunch of SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group 🎀.
- The Extensible Messaging and Presence Protocol [RFC6120], along with various XMPP extensions developed by the IETF and by the XMPP Standards Foundation (XSF) 🌸.
these technologies are super widely deployed, so it's really important to clearly define mappings between them so they can interwork 🫶. this doc gives the basis for a whole series of SIP-XMPP interworking specs by defining the architectural assumptions, the address translation methods, and the error condition mappings 💅. other docs in the series handle mappings for presence, messaging, and media sessions 🔥.
the guidelines in this series come from real implementation and deployment experience, and they describe techniques that have actually worked in the field with existing systems 👑. in practice, interworking has been achieved through direct protocol mappings, not through mapping to an abstract model like the ones described in [RFC3859] and [RFC3860] 🙈. so this series describes the direct mapping approach in enough detail that developers of new implementations can get practical interworking between SIP systems and XMPP systems 🌈.
2. Intended Audience 🧚
the docs in this series are for software developers who already have a system built on one of these technologies (say, SIP) and want to let that system talk to systems built on the other one (say, XMPP) 💖. for this doc, we assume you already know the core specs for both SIP and XMPP ✨. for the other docs in the series, we assume you know this doc too, plus the relevant SIP and XMPP extensions 💜.
3. Terminology 📖
a bunch of the terms used here are explained in [RFC3261] and [RFC6120] 🌸.
several examples use the "XML Notation" from the Internationalized Resource Identifier (IRI) specification [RFC3987] to represent Unicode characters outside the ASCII range. for example, the string "ue" stands for the Unicode character [UNICODE] LATIN SMALL LETTER U WITH DIAERESIS, U+00FC 🦋.
in architectural diagrams, SIP traffic is drawn with arrows like ***>, and XMPP traffic is drawn with arrows like ...> 🎀.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💅.
4. Architectural Assumptions 🏗️
protocol translation between SIP and XMPP could happen in a bunch of different places, depending on how the real-time communication deployment is built 👑. for example, it could happen inside a multiprotocol server (one that uses protocol-specific connection managers to start traffic to clients or other servers, and to accept traffic from them, natively over SIP/SIMPLE, XMPP, and so on) 🌈. it could also happen inside a multiprotocol client (one that lets a user set up connections natively with various servers over SIP/SIMPLE, XMPP, and so on) 💜. or it could happen inside a gateway that acts as a dedicated protocol translator, taking one protocol as input and giving another protocol as output 🔥.
this doc assumes that the translation happens inside a gateway, specifically:
- when info needs to flow from an XMPP-based system to a SIP-based system, the translation happens inside an "XMPP-to-SIP gateway" that translates XMPP syntax and semantics on behalf of an "XMPP server". together, these two logical functions make up an "XMPP service" ✨.
- when info needs to flow from a SIP-based system to an XMPP-based system, the translation happens inside a "SIP-to-XMPP gateway" that translates SIP syntax and semantics on behalf of a "SIP server". together, these two logical functions make up a "SIP service" 🫶.
these logical functions could totally live in one and the same actual entity 🙈. we split them up mainly to make things easier to explain, though honestly, in practice, these gateways are pretty common 💖.
Note: this assumption is not meant to discourage protocol translation inside multiprotocol clients or servers 🎀. it's followed mainly to clarify the discussion and examples, so that the translation principles are easier to get and client and server implementors can apply them with suitable changes to the examples and terminology 🌸.
this doc assumes that a gateway translates directly from one protocol to the other 🦋. for the examples, we also assume the translation happens in a gateway within the source domain. so info generated by a user of an XMPP system gets translated by a gateway inside that XMPP system's trust domain, and info generated by a user of a SIP system gets translated by a gateway inside that SIP system's trust domain 💅. that said, nothing in this doc ought to be taken as recommending against translation at the destination domain 🧚.
here's an architectural diagram for a possible gateway deployment. the entities mean the following, and the "#" character shows the edge of a trust domain 🗺️:
- romeo@example.net is a SIP user.
- example.net is a SIP server with an associated gateway ("S2X GW") to XMPP.
- juliet@example.com is an XMPP user.
- example.com is an XMPP server with an associated gateway ("X2S GW") to SIP.
#########################################################
# #
# +-----+ #
# | S2X | #
# +-------------+ GW |<...........>+-------------+ #
# | SIP Server +-----+ | XMPP Server | #
# | example.net | +-----+ example.com | #
# +-------------+<***********>| X2S +-------------+ #
# * | GW | : #
# * +-----+ : #
# * : #
# romeo@example.net juliet@example.com #
# #
#########################################################
Legend:
XMPP = ... or :
SIP = *
Figure 1: Possible Gateway Deployment Architecturenotice that two-way communication between the SIP server and the XMPP server can be set up over either SIP or XMPP 🌈. if the XMPP user starts the interaction, the XMPP server invokes its XMPP-to-SIP gateway, so the communication happens over SIP 💜. if the SIP user starts the interaction, the SIP server invokes its SIP-to-XMPP gateway, so the communication happens over XMPP 🔥✨.
5. Interdomain Federation 🌈
okay so the architecture we've been talking about means a SIP system and an XMPP system will chat through interdomain federation 🦋 Basically the SIP server hands things off to its own SIP-to-XMPP gateway, which then talks to the XMPP server using the native XMPP server-to-server stuff. And the XMPP server does the same thing in reverse, using its XMPP-to-SIP gateway to talk to the SIP server with the native SIP server-to-server methods 💅
When an XMPP server gets a stanza whose to address names a domain that isn't its own, it has to figure out whether that domain talks XMPP or SIP ✨ To do that, it does one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records, the way [RFC6120] describes. If the answer comes back with a hostname, the XMPP server can just try XMPP 🎀 If not, it can find the right place for SIP communication at the target domain using the procedures in [RFC3263].
SIP servers have a similar job 🧚 When a SIP server gets a message whose Request-URI or To header names a domain that isn't its own, it needs to work out whether that domain is SIP or XMPP. It starts with the procedures in [RFC3263]. If that gives back a hostname, the SIP server can try SIP. If not, it can do one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records, as specified in [RFC6120] 🍓
In both cases, the server might already know that the foreign domain is SIP or XMPP from earlier, so it wouldn't need to do those DNS lookups again 🫶 How that info gets cached is totally up to the implementation and local service policy, so it's out of scope for this doc 💜
Existing SIP and XMPP server implementations don't usually have the ability to speak the other protocol (XMPP for SIP implementations, SIP for XMPP implementations) 😭 One common pattern is to attach a gateway to the core server. In XMPP, for example, that gateway might be called a "connection manager" 🌸 Exactly how the gateway works with the core server to do things like address lookups and talk to systems on the other technology is up to the implementation. For instance, the gateway could be an add-on module that the core server trusts to act as a fallback delivery mechanism if the remote domain doesn't support the server's native protocol 👑
Here's a transport detail: because [RFC6120] binds XMPP to TCP, a gateway from SIP to XMPP will need to support TCP as its underlying transport 🔥 SIP is different. As specified in [RFC3261], either TCP or UDP can carry SIP messages, and a given SIP deployment might only support UDP 🙈 So a gateway from XMPP to SIP might need to talk to a SIP server using either TCP or UDP 🦋
6. Address Mapping 💖
6.1. Overview
okay so the basic SIP address format is a 'sip' or 'sips' URI, as specified in [RFC3261] ✨ If a SIP entity supports extensions for instant messaging, it might be identified by an 'im' URI, as specified in the Common Profile for Instant Messaging [RFC3860] (see [RFC3428]). And if a SIP entity supports extensions for presence, it might be identified by a 'pres' URI, as specified in the Common Profile for Presence [RFC3859] (see [RFC3856]) 🎀 SIP entities also typically support the 'tel' URI scheme [RFC3966], and they might support other URI schemes too 💅
The XMPP address format is specified in [RFC6122]. Lowkey, note that XMPP URIs [RFC5122] aren't used natively on the XMPP network 🙈 [RFC6121] encourages instant messaging and presence apps of XMPP to also support 'im' and 'pres' URIs as specified in [RFC3860] and [RFC3859], respectively. That support might just mean leaving the resolution of those addresses up to an XMPP server 🧚
In this document we mainly describe mappings for addresses of the form <user@domain>. We also give guidelines for mapping the addresses of specific user agent instances, which look like Globally Routable User Agent URIs (GRUUs) in SIP and "resourceparts" in XMPP 🌈 Mapping protocol-specific identifiers, like telephone numbers, is out of scope for this spec 💜 We've also ruled out mapping domain names for now, since that's a job for the Domain Name System. The real interworking issue is translating fully internationalized domain names (IDNs) into non-internationalized domain names. IDNs aren't allowed in the SIP address format, but they are allowed in the XMPP address via Internationalized Domain Names in Applications; see [RFC6122] and [XMPP-ADDRESS-FORMAT] 🍓 So, bestie, we focus mainly on the local part of an address (called "usernames", "instant inboxes", "presentities", and "localparts" depending on the protocol), secondarily on the instance-specific part, and not at all on the domain-name part 🫶
The 'sip'/'sips', 'im'/'pres', and XMPP address schemes allow different sets of characters. All three allow alphanumeric characters and disallow both spaces and control characters 😭 But some characters allowed in one scheme are disallowed in others, so those characters need to be mapped properly to make sure the systems can interwork 💀
6.2. Local Part Mapping
The local part of a 'sip'/'sips' URI inherits from the "userinfo" rule in [RFC3986], with several changes. Here we only discuss the SIP "user" rule, using ABNF as defined in [RFC5234] 🦋
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"For simplicity, we assume that the local part of an 'im'/'pres' URI inherits from the "dot-atom-text" rule in [RFC5322] instead of the more complicated "local-part" rule 🧁
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters 🌸
To sum it all up, here's the table of allowed and disallowed characters in the local part for each protocol (besides the alphanumeric, space, and control characters). It's in order by hexadecimal character number. Each "A" row shows the allowed characters and each "D" row shows the disallowed ones 🎀
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+Table 1: Allowed and Disallowed Characters
When transforming the local part of an address from one format to another, an application SHOULD proceed as follows 💅
- Unescape any escaped characters in the source address. For example, from SIP to XMPP, unescape
"%23"to"#"per [RFC3986], and from XMPP to SIP, unescape"\27"to"'"per [XEP-0106] ✨ - Leave unmodified any characters that are allowed in the destination scheme 🫶
- Escape any characters that are allowed in the source scheme but reserved in the destination scheme, since escaping is defined for the destination scheme. In particular: 🔥
- Where the destination scheme is a URI (i.e., an 'im', 'pres', 'sip', or 'sips' URI), each reserved character MUST be percent-encoded to "%hexhex" as specified in Section 2.5 of [RFC3986]. For example, when transforming from XMPP to SIP, encode "#" as
"%23"🦋 - Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to "\hexhex" as specified in [XEP-0106]. For example, when transforming from SIP to XMPP, encode "'" as
"\27"👑
- Where the destination scheme is a URI (i.e., an 'im', 'pres', 'sip', or 'sips' URI), each reserved character MUST be percent-encoded to "%hexhex" as specified in Section 2.5 of [RFC3986]. For example, when transforming from XMPP to SIP, encode "#" as
6.3. Instance-Specific Mapping
The meaning of a resourcepart in XMPP (the part of a Jabber ID (JID) after the slash, like "foo" in "user@example.com/foo") matches that of a Globally Routable User Agent URI (GRUU) in SIP [RFC5627] 🧚 In both cases, the construct identifies a particular device tied to the bare JID ("localpart@domainpart") of an XMPP entity, or to the Address of Record (AOR) of a SIP entity. So it's reasonable to map the value of a "gr" URI parameter to an XMPP resourcepart, and vice versa 💖
The mapping described here doesn't apply to temporary GRUUs. It only applies to GRUUs associated with an Address of Record 🙈
The "gr" URI parameter in SIP can only contain characters from the ASCII range (though characters outside it can be percent-encoded per [RFC3986]). An XMPP resourcepart, on the other hand, can contain nearly any Unicode character [UNICODE] 🌈 So Unicode characters outside the ASCII range need to be mapped to characters in the ASCII range, as described below 🍓
6.4. SIP to XMPP ✨
Okay bestie, here's the high-level algorithm for turning a sip, sips, im, or pres URI into an XMPP address 💖
- Remove URI scheme.
- Split at the first
@character into local part and hostname (mapping the latter is out of scope). - Translate any percent-encoded strings (
%hexhex) to percent-decoded octets. - Treat result as a UTF-8 string.
- Translate
"&"to"\26","'"to"\27", and"/"to"\2f", respectively, in order. This handles the characters that XMPP addresses don't allow butsip/sipsandim/presURIs do, as shown in Table 1 above. It's consistent with [XEP-0106] 🫶 - Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization (OPTIONAL) ✨
- Recombine local part with mapped hostname to form a bare JID ("localpart@domainpart").
- If the (SIP) address contained a "gr" URI parameter, append a slash character "/" and the "gr" value to the bare JID to form a full JID ("localpart@domainpart/resourcepart") 🦋
Several examples follow, illustrating steps 3, 5, and 8 described above. Look at them, they're iconic 🌸
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | fü@sip.example |
+----------------------------+--------------------------+
| sip:o'malley@sip.example | o\27malley@sip.example |
+----------------------------+--------------------------+
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+In the first example, the string %C3%BC is a percent-encoded version of the UTF-8-encoded Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC). The string ü is that same character, just written out for documentation purposes using the XML Notation defined in [RFC3987]. In XMPP, it would be sent directly as a UTF-8-encoded Unicode character, not percent-encoded like it is in a SIP URI, because that's what the URI syntax defined in [RFC3986] requires 💅
6.5. XMPP to SIP ✨
Now the reverse trip! Here's the high-level algorithm for mapping an XMPP address to a sip, sips, im, or pres URI 🧚
- Split XMPP address into localpart (mapping described in remaining steps), domainpart (hostname; mapping is out of scope), and resourcepart (specifier for particular device or connection, for which an OPTIONAL mapping is described below).
- Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization of the XMPP localpart (OPTIONAL).
- Translate
"\26"to"&","\27"to"'", and"\2f"to"/", respectively. This is consistent with [XEP-0106] 💜 - Determine if the foreign domain supports
imandpresURIs (discovered via [RFC2782] lookup as specified in [RFC6121]), else assume that the foreign domain supportssip/sipsURIs. - If converting into an
imorpresURI, for each byte, if the byte is in the set(),.;[\]or is a UTF-8 character outside the ASCII range, then percent-encode that byte to%hexhexformat. If converting into asiporsipsURI, for each byte, if the byte is in the set#%[\]^`{|}or is a UTF-8 character outside the ASCII range, then percent-encode that byte to%hexhexformat. It's a lot, but you've got this 🔥 - Combine resulting local part with mapped hostname to form local@domain address.
- Prepend with the string
im:(for XMPP<message/>stanzas) orpres:(for XMPP<presence/>stanzas) if foreign domain supports these, else prepend with the stringsip:orsips:according to local service policy. - If the XMPP address included a resourcepart and the destination URI scheme is
siporsips, optionally append the slash character/and then append the resourcepart (making sure to percent-encode any UTF-8 characters outside the ASCII range) as the"gr"URI parameter 🌈
Several examples follow, illustrating steps 3, 5, and 8 described above.
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+As above, in the first example the string ü is the Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC), shown for documentation purposes using the XML Notation defined in [RFC3987]. In XMPP, it would be sent directly as a UTF-8-encoded Unicode character and not percent-encoded, whereas the string %C3%BC is a percent-encoded version of that same character 🎀
7. Error Mapping ✨
Okay so this part is kind of messy, ngl 😭 Various differences between XMPP error conditions and SIP response codes make it really hard to come up with a mapping between the two protocols that's both comprehensive and consistent:
- Whereas the set of XMPP error conditions is fixed in the core XMPP specification (and supplemented where needed by application-specific extensions), the set of SIP response codes is more open to change, as evidenced by the IANA registry of SIP response codes.
- XMPP has defined fewer error conditions related to stanza handling (22 are defined in [RFC6120]) than SIP has defined response codes related to message handling (at the date of this writing, 71 SIP response codes are registered with IANA as defined in [RFC3261] and numerous SIP extensions).
- In many cases, the SIP response codes are more specific than the XMPP error conditions. For example, from an XMPP perspective the SIP codes "413 Request Entity Too Large" and "414 Request-URI Too Long" are simply two different types of response to the same bad request, and the SIP codes "415 Unsupported Media Type" and "416 Unsupported URI Scheme" are two different responses to a request that is not acceptable 💀
- SIP differentiates between responses about a particular endpoint or resource (the 4xx series) and responses about a user, i.e., all of a user's endpoints or resources (the 6xx series). There is no such distinction in XMPP, since the same error condition can be returned in relation to the "bare JID" (localpart@domainpart) of a user or the "full JID" (localpart@domainpart/resourcepart) of a particular endpoint or resource, depending on the 'to' address of the original request 🙈
As a result of these and other factors, the mapping of error conditions and response codes is more of an art than a science 🎨 This document provides suggested mappings, but implementations are free to deviate from these mappings if needed. Also, because no XMPP error conditions are equivalent to the provisional (1xx) and successful (2xx) response codes in SIP, this document suggests mappings only for the SIP redirection (3xx), request failure (4xx), server failure (5xx), and global failure (6xx) response code families.
Supplementary information about SIP response codes can be expressed in the "Reason-Phrase" in the Status-Line header, and detailed information about XMPP error conditions can be expressed in the<text/>child of the<error/>element. Although the semantics of these constructs are specified in a slightly different way, it is reasonable for a gateway to map these constructs to each other if they are found in a SIP response or XMPP error stanza. 🫶
7.1. XMPP to SIP 💌
okay bestie, this is the XMPP-to-SIP error translation table 🎀 the mapping of specific XMPP error conditions to SIP response codes SHOULD go like the table below ✨
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
+------------------------------+---------------------+
| <conflict/> | 400 |
+------------------------------+---------------------+
| <feature-not-implemented/> | 405 or 501 (1) |
+------------------------------+---------------------+
| <forbidden/> | 403 or 603 (2) |
+------------------------------+---------------------+
| <gone/> | 301 or 410 (3) |
+------------------------------+---------------------+
| <internal-server-error/> | 500 |
+------------------------------+---------------------+
| <item-not-found/> | 404 or 604 (2) |
+------------------------------+---------------------+
| <jid-malformed/> | 400 |
+------------------------------+---------------------+
| <not-acceptable/> | 406 or 606 (2) |
+------------------------------+---------------------+
| <not-allowed/> | 403 |
+------------------------------+---------------------+
| <not-authorized/> | 401 |
+------------------------------+---------------------+
| <policy-violation/> | 403 |
+------------------------------+---------------------+
| <recipient-unavailable/> | 480 or 600 (2) |
+------------------------------+---------------------+
| <redirect/> | 302 |
+------------------------------+---------------------+
| <registration-required/> | 407 |
+------------------------------+---------------------+
| <remote-server-not-found/> | 404 or 408 (4) |
+------------------------------+---------------------+
| <remote-server-timeout/> | 408 |
+------------------------------+---------------------+
+------------------------------+---------------------+
| <resource-constraint/> | 500 |
+------------------------------+---------------------+
| <service-unavailable/> | see note (5) below |
+------------------------------+---------------------+
| <subscription-required/> | 400 |
+------------------------------+---------------------+
| <undefined-condition/> | 400 |
+------------------------------+---------------------+
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+Table 2: Mapping of XMPP Error Conditions to SIP Response Codes
now for the notes, which are where the fun details live 🧐
(1) 🦋 if the error is about a "full JID" (localpart@domainpart/resourcepart), the SIP 405 response code is RECOMMENDED. if it's about a "bare JID" (localpart@domainpart), the SIP 501 response code is RECOMMENDED. 💅
(2) 🌸 if the error is about a "full JID" (localpart@domainpart/resourcepart), a SIP response code from the 4xx series is RECOMMENDED. if it's about a "bare JID" (localpart@domainpart), a SIP response code from the 6xx series is RECOMMENDED. ✨
(3) 🎀 if the <gone/> element includes XML character data specifying the new address, the error MUST be mapped to SIP 301. if it doesn't, it MUST be mapped to SIP 410. no notes, just vibes 🍓
(4) 🧚 the XMPP <remote-server-not-found/> error can mean that the remote server either (a) does not exist or (b) cannot be resolved. SIP has two different response codes for this: 404 covers (a), and 408 covers (b). two codes, two situations, very organized 👑
(5) 🌈 okay this one is the drama 🙈 the XMPP <service-unavailable/> error condition is widely used to tell the requesting entity that the intended recipient doesn't support the relevant feature, to signal that a server can't perform the requested service either generally or for a particular user, and to avoid revealing whether a given account exists at all. this is quite different from the semantics of the SIP 503 Service Unavailable response code, which is used to signal that communication with a server is impossible. (for example, even if the XMPP <service-unavailable/> error condition comes back for one specific user, the SIP 503 response code will be read as applying to all future requests to this server, not just requests for that user 😭)
so mapping the XMPP <service-unavailable/> error condition to SIP 503 Service Unavailable is NOT RECOMMENDED. 🚫 there's no precise match, but the SIP 403 Forbidden and 405 Method Not Allowed response codes are the closest in meaning to the XMPP <service-unavailable/> error condition 💜
7.2. SIP to XMPP 💖
okay bestie, when a SIP response code shows up and needs to become an XMPP error, this table is your vibe check 💅 gateways SHOULD follow it. If a gateway runs into a SIP code that isn't listed, it SHOULD map any 3xx to <redirect/>, any 4xx to <bad-request/>, any 5xx to <internal-server-error>, and any 6xx to <recipient-unavailable/> 🧚
Table 3: Mapping of SIP Response Codes to XMPP Error Conditions 🎀
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
+---------------------+---------------------------------+
| 300 | <redirect/> |
+---------------------+---------------------------------+
| 301 | <gone/> (1) |
+---------------------+---------------------------------+
| 302 | <redirect/> |
+---------------------+---------------------------------+
| 305 | <redirect/> |
+---------------------+---------------------------------+
| 380 | <not-acceptable/> |
+---------------------+---------------------------------+
| 4xx | <bad-request/> |
+---------------------+---------------------------------+
| 400 | <bad-request/> |
+---------------------+---------------------------------+
| 401 | <not-authorized/> |
+---------------------+---------------------------------+
| 402 | <bad-request/> (2) |
+---------------------+---------------------------------+
| 403 | <forbidden/> (3) |
+---------------------+---------------------------------+
| 404 | <item-not-found/> (4) |
+---------------------+---------------------------------+
| 405 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 406 | <not-acceptable/> |
+---------------------+---------------------------------+
| 407 | <registration-required/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 408 | <remote-server-timeout/> (5) |
+---------------------+---------------------------------+
| 410 | <gone/> (1) |
+---------------------+---------------------------------+
| 413 | <policy-violation/> |
+---------------------+---------------------------------+
| 414 | <policy-violation/> |
+---------------------+---------------------------------+
| 415 | <not-acceptable/> |
+---------------------+---------------------------------+
| 416 | <not-acceptable/> |
+---------------------+---------------------------------+
| 420 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 421 | <not-acceptable/> |
+---------------------+---------------------------------+
| 423 | <resource-constraint/> |
+---------------------+---------------------------------+
| 430 | <recipient-unavailable/> (6) |
+---------------------+---------------------------------+
| 439 | <feature-not-implemented/> (6) |
+---------------------+---------------------------------+
| 440 | <policy-violation/> (7) |
+---------------------+---------------------------------+
| 480 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 481 | <item-not-found/> |
+---------------------+---------------------------------+
| 482 | <not-acceptable/> |
+---------------------+---------------------------------+
| 483 | <not-acceptable/> |
+---------------------+---------------------------------+
| 484 | <item-not-found/> |
+---------------------+---------------------------------+
| 485 | <item-not-found/> |
+---------------------+---------------------------------+
| 486 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 487 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 488 | <not-acceptable/> |
+---------------------+---------------------------------+
| 489 | <policy-violation/> (8) |
+---------------------+---------------------------------+
| 491 | <unexpected-request/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 493 | <bad-request/> |
+---------------------+---------------------------------+
| 5xx | <internal-server-error/> |
+---------------------+---------------------------------+
| 500 | <internal-server-error/> |
+---------------------+---------------------------------+
| 501 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 502 | <remote-server-not-found/> |
+---------------------+---------------------------------+
| 503 | <internal-server-error/> (9) |
+---------------------+---------------------------------+
| 504 | <remote-server-timeout/> |
+---------------------+---------------------------------+
| 505 | <not-acceptable/> |
+---------------------+---------------------------------+
| 513 | <policy-violation/> |
+---------------------+---------------------------------+
| 6xx | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 600 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 603 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 604 | <item-not-found/> |
+---------------------+---------------------------------+
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+(1) When mapping SIP 301 to XMPP <gone/>, the <gone/> element MUST include XML character data specifying the new address. When mapping SIP 410 to XMPP <gone/>, the <gone/> element MUST NOT include XML character data specifying a new address. 🙈
(2) The XMPP <payment-required/> error condition was removed in [RFC6120]. Therefore, a mapping to XMPP <bad-request/> is suggested instead.
(3) Depending on the scenario, other possible translations for SIP 403 are <not-allowed/> and <policy-violation/>.
(4) Depending on the scenario, another possible translation for SIP 404 is <remote-server-not-found/>.
(5) Depending on the scenario, another possible translation for SIP 408 is <remote-server-not-found/>.
(6) Codes 430 and 439 are defined in [RFC5626].
(7) Code 440 is defined in [RFC5393].
(8) Code 489 is defined in [RFC6665].
(9) Regarding the semantic mismatch between XMPP <service-unavailable/> and SIP code 503, see note (5) in Section 7.1 of this document. 🌈
8. Security Considerations 🔐
okay this section is serious, so read it slowly 🫶 detailed security considerations for SIP and XMPP live in [RFC3261] and [RFC6120], respectively.
to protect the info moving between SIP and XMPP systems, deployed gateways SHOULD use Transport Layer Security (TLS) [RFC5246] when talking over TCP, and Datagram Transport Layer Security (DTLS) [RFC6347] when talking over UDP.
so here's the tea 🍓 as specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], a To header or a Request-URI containing a Session Initiation Protocol Secure (SIPS) URI means that all hops in a communication path need to be protected using TLS. XMPP has no way to signal that all hops need protecting, so if the To header or Request-URI of a SIP message is a SIPS URI, the SIP-to-XMPP gateway MUST NOT translate the SIP message into an XMPP stanza and MUST NOT route it to the destination XMPP server. (there might be exceptions to that policy, like explicit agreement between two operators to enforce per-hop security, but right now those are quite rare 💀)
a gateway between SIP and XMPP, in either direction, effectively acts as a SIP back-to-back user agent ("B2BUA"). the amplification vulnerability described in [RFC5393] can show up with B2BUAs (see also [B2BUA-LOOP-DETECT]), so a gateway SHOULD implement the loop-detection methods defined in that specification to help reduce the chance of amplification attacks. 😭 it would be possible to signal the Max-Forwards and Max-Breadth SIP headers over XMPP using the Stanza Headers and Internet Metadata (SHIM) extension [XEP-0131], but that extension isn't widely implemented, so defenses against excessive looping and amplification when messages bounce between SIP and XMPP networks are out of scope for this document. however, it ought to be addressed in the future, and implementations are strongly encouraged to add appropriate countermeasures wherever they can 🔥
the ability to use a wide range of Unicode characters [UNICODE] can lead to security issues, especially user confusion over identifiers containing visually similar characters (also called "confusable characters" or "confusables"). the PRECIS framework specification [PRECIS] describes some of these security issues, and more guidance can be found in [UTS39] 👑
9. References 📚
9.1. Normative References 💅
okay bestie, these are the normative ones, so they're the must-reads 📚✨
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[RFC3263]Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RFC3987]Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.[RFC5234]Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC5393]Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008.[RFC5627]Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.[RFC5630]Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.[RFC6120]Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.[RFC6122]Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, March 2011.[RFC6347]Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.[UNICODE]The Unicode Consortium, "The Unicode Standard, Version 6.3", 2013, <http://www.unicode.org/versions/Unicode6.3.0/>.
9.2. Informative References 🦋
these ones are the extra reading, the "ooh tell me more" pile 🧚
[B2BUA-LOOP-DETECT]Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Work in Progress, February 2014.[PRECIS]Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, April 2014.[RFC2782]Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.[RFC3428]Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.[RFC3454]Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.[RFC3856]Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.[RFC3859]Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.[RFC3860]Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.[RFC3966]Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.[RFC5122]Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.[RFC5322]Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.[RFC5626]Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.[RFC6121]Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.[RFC6665]Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.[UTS39]The Unicode Consortium, "Unicode Technical Standard #39: Unicode Security Mechanisms", November 2013, <http://unicode.org/reports/tr39/>.[XEP-0106]Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 0106, June 2007, <http://www.xmpp.org/extensions/xep-0106.html>.[XEP-0131]Saint-Andre, P. and J. Hildebrand, "Stanza Headers and Internet Metadata", XSF XEP 0131, July 2006, <http://xmpp.org/extensions/xep-0131.html>.[XMPP-ADDRESS-FORMAT]Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", Work in Progress, March 2014.
Appendix A. Acknowledgements 🎀
big thank-yous time 🫶
The authors wanted to thank these lovely people for their feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries, Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.
Dan Romascanu reviewed the document on behalf of the General Area Review Team. 👑
During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and Sean Turner caught several issues that needed to be addressed. 🔥
The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs, and Gonzalo Camarillo as the sponsoring Area Director. 🌸
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document. 💜
Authors' Addresses 🧚
Peter Saint-Andre
&yet
EMail: ietf@stpeter.im
Avshalom Houri
IBM
Rorberg Building, Pekris 3
Rehovot 76123
Israel
EMail: avshalom@il.ibm.com
Joe Hildebrand
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
EMail: jhildebr@cisco.comthat's the whole spec, bestie!! 🌈💖 thank you for being my favourite reader ✨
📦 where this page comes from
- ietf: rfc7247 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms