Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
obsoletes
- rfc-7248 — Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
Extracted elements (24)
RFC 8048 corrects an architectural error in RFC 7248 where diagrams showed gateways on both sides of the protocol exchange. The correct model has a single gateway on the originating side: XMPP-originated traffic is translated by an X2S gateway and received by a normal SIP system, while SIP-originated traffic is translated by an S2X gateway and received by a normal XMPP system.
The document uses 'notification dialog' for a SIP subscription and 'presence authorization' for an XMPP subscription to prevent confusion, since both SIP and XMPP use the term 'subscription' but with different meanings: SIP subscriptions are short-lived notification sessions, while XMPP subscriptions are long-lived presence authorizations.
The XMPP <show/> element (qualified by the 'jabber:client' namespace) can be included directly in PIDF XML rather than defining a new PIDF extension, because PIDF is already extensible. Including <show/> in PIDF is RECOMMENDED as the most interoperable way to convey detailed availability states like 'away' and 'dnd'.
This document uses direct protocol-to-protocol mapping (SIP/SIMPLE to XMPP and vice versa) rather than mapping both to the abstract semantics of RFC 3860, because the direct approach is how existing interworking systems are actually implemented. The abstract mapping approach described in RFC 3860 was apparently never implemented.
SIP does not have a direct construct for cancelling an outbound presence authorization as XMPP does; instead, a SIP user terminates the notification dialog by sending SUBSCRIBE with Expires: 0 and never renewing it. XCAP (RFC 4825) could be used in SIP to remove a contact from an address list, but that is outside the scope of this gateway specification.
When an XMPP user connects with multiple clients simultaneously, each client generates a separate presence notification (keyed by distinct XMPP resourcepart), and the contact's SIP UA will receive a separate NOTIFY per client. A SIP UA should model these multiple notifications the same way it handles multiple PIDF tuples from a SIP user.
A SIP Presence Server that receives communications through an XMPP-to-SIP gateway from users not associated with a domain related to the gateway's hostname SHOULD (based on local service provisioning) refuse to service such users or refuse to receive traffic from that gateway.
An XMPP-to-SIP gateway MUST consider the XMPP presence authorization to be permanently cancelled (and inform the XMPP user) if it receives a SIP response of 403, 489, or 603. By contrast, a response of 423 or 481 is a transient error and the long-lived XMPP presence authorization should be honored.
If the XMPP <priority/> element value is negative, an XMPP-to-SIP gateway MUST NOT map the value to PIDF priority. For positive values, the gateway SHOULD map XMPP priority 0 to PIDF priority 0 and XMPP priority 127 to PIDF priority 1 with appropriately unique intermediate values.
The mapping of SIP syntax elements to XMPP MUST follow Table 2: PIDF basic status 'open' MUST be mapped to <presence/> with no 'type' attribute, and PIDF basic status 'closed' MUST be mapped to <presence/> with type='unavailable'. Content-Language maps to xml:lang, From/To map to from/to, and <note/> maps to <status/>.
The mapping of XMPP syntax elements to SIP syntax elements MUST follow Table 1: <presence/> stanza maps to 'Event: presence', XMPP resource identifier maps to PIDF tuple 'id', from/to map to From/To headers, type maps to PIDF basic status, xml:lang maps to Content-Language, <priority/> maps to PIDF contact priority, and <status/> maps to PIDF <note/>.
The XMPP-to-SIP gateway MUST map a missing 'type' attribute (available) to PIDF basic status 'open', and MUST map type='unavailable' to PIDF basic status 'closed'. Only <presence/> stanzas with no type or type='unavailable' are mapped to SIP NOTIFY requests.
The XMPP-to-SIP gateway SHOULD send a new SIP SUBSCRIBE request to the SIP contact whenever the XMPP user initiates a presence session, and also sufficiently in advance of when the SIP notification dialog is scheduled to expire during an active XMPP presence session.
When an XMPP-to-SIP gateway initially receives NOTIFY messages with a Subscription-State header value of 'pending', it MUST respond to them on the SIP side but refrain from sending any presence stanzas from the SIP contact to the XMPP user until a NOTIFY with Subscription-State 'active' is received.
When refreshing a SIP notification dialog, if the SIP-to-XMPP gateway does not have meaningful information about the XMPP user's availability state, the NOTIFY MUST be empty as allowed by RFC 6665.
Presence notifications can contain sensitive availability information, and both SIP and XMPP allow sending different notifications to different subscribers. A gateway MUST NOT route or deliver a presence notification to any entity other than the intended recipient (identified by XMPP 'to' address or SIP Request-URI), because authorization information resides at the user's home service, not at the receiving gateway.
An XMPP presence probe is translated to a SIP SUBSCRIBE request with Expires: 0 in a new dialog. Conversely, a SIP SUBSCRIBE with Expires: 0 is translated to an XMPP <presence/> stanza of type 'probe' if the gateway does not already have presence information about the contact.
For SIP-to-XMPP presence authorization, the SIP-to-XMPP gateway translates a SIP SUBSCRIBE into an XMPP <presence/> stanza of type 'subscribe'. If the XMPP user approves, the gateway sends a SIP NOTIFY with Subscription-State: active; if rejected, the gateway sends a NOTIFY with Subscription-State: terminated;reason=rejected.
The default SIP notification dialog time-to-live is 3600 seconds (per RFC 3856 Section 6.4), so SIP notification dialogs must be explicitly refreshed to last as long as the contact's presence session. XMPP notification sessions are handled automatically by the user's server based on presence state.
The XMPP-to-SIP gateway maps an XMPP resource identifier to the PIDF tuple 'id' attribute. Because the PIDF 'id' type is xs:ID (which disallows a digit as the first character, unlike XMPP resourceparts), the gateway is RECOMMENDED to prepend the resourcepart with 'ID-' or another alphabetic string.
To cancel a presence authorization in the XMPP-to-SIP direction, an XMPP unsubscribe stanza is translated to a SIP SUBSCRIBE request with Expires: 0. The gateway then sends a NOTIFY with Subscription-State: terminated to formally end the SIP dialog. Cancelling an outbound authorization does not affect any inbound authorization.
When a SIP user cancels an outbound presence authorization to an XMPP contact (via SUBSCRIBE with Expires: 0), the SIP-to-XMPP gateway sends a PIDF document with basic status 'closed' and Subscription-State terminated;reason=timeout to the SIP UA, and an XMPP <presence/> stanza of type 'unavailable' to the XMPP contact.
XMPP presence authorizations are managed using <presence/> stanzas of type 'subscribe', 'subscribed', 'unsubscribe', and 'unsubscribed', with four main states: 'none', 'from', 'to', and 'both'. SIP presence authorizations are implicitly triggered by subscription activity rather than explicit authorization stanzas.
An amplification attack is possible from the XMPP network against a SIP Presence Server, because each long-lived XMPP presence authorization results in multiple SIP notification dialog refreshes. Access to an XMPP-to-SIP gateway SHOULD be restricted to a single domain or trust realm, and the gateway should be hosted only by XMPP services with controlled account provisioning.