Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
obsoleted by
- rfc-8048 — Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence
Extracted elements (23)
Rather than mapping both SIP and XMPP to abstract CPIM semantics (as done in RFC3922 and SIMPLE-CPIM-MAPPING), this document directly maps semantics between SIP/SIMPLE and XMPP, because the abstract-mapping approach has never been implemented in practice.
The XMPP <show/> element (qualified by the 'jabber:client' namespace) can be included directly in PIDF XML rather than requiring a new PIDF extension, since PIDF is already extensible. This approach is RECOMMENDED to preserve availability state detail across the gateway.
XMPP presence subscriptions are long-lived (permanent until cancelled), whereas SIP presence subscriptions are short-lived with a default TTL of 3600 seconds per RFC3856 Section 6.4. This disparity requires XMPP-to-SIP gateways to manage periodic subscription refreshes on the SIP side to maintain the appearance of permanence.
In-scope mapping covers basic presence (network availability only); mapping of rich presence extensions such as RFC4480 (RPID), XEP-0107 (mood), and XEP-0108 (activity) is explicitly out of scope for this document.
When a SIP subscription expires, a SIP-to-XMPP gateway may either cancel the XMPP subscription (treating it as temporary) or maintain it as long-lived by sending a NOTIFY with PIDF 'closed' status and Subscription-State 'terminated;reason=timeout', plus an XMPP 'unavailable' stanza. The choice is implementation-defined.
A PIDF basic status of 'open' SHOULD be mapped to absence of 'type' attribute in XMPP presence, and 'closed' SHOULD be mapped to type='unavailable'.
If an XMPP-to-SIP gateway maps XMPP <priority/> values, it MUST NOT map negative values to PIDF priority; for positive values it SHOULD treat XMPP priority 0 as PIDF priority 0 and XMPP priority 127 as PIDF priority 1.
If the XMPP user approves a subscription request, the XMPP server MUST return a <presence/> stanza of type 'subscribed'; if declined, MUST return 'unsubscribed' and the XMPP-to-SIP gateway MUST transform it into an empty SIP NOTIFY with Subscription-State 'terminated' and reason 'rejected'.
Once the XMPP user's server receives a subscription request, it MUST deliver the presence subscription request to the XMPP user; if a subscription already exists in the roster, the XMPP server SHOULD auto-reply with a <presence/> stanza of type 'subscribed'.
Only XMPP <presence/> stanzas lacking a 'type' attribute or with type='unavailable' SHOULD be mapped by an XMPP-to-SIP gateway to SIP NOTIFY requests, since those are the only stanzas representing notifications.
The XMPP-to-SIP gateway MUST consider the XMPP subscription to be permanently cancelled (and inform the XMPP user) if it receives a SIP response of 403, 489, or 603; responses of 423 or 481 are transient errors and the long-lived XMPP subscription should be maintained.
The XMPP-to-SIP gateway SHOULD send a new SUBSCRIBE request to the SIP user whenever the XMPP user initiates a presence session and also SHOULD refresh before the SIP subscription expires during an active XMPP session.
Upon receiving the first NOTIFY with a subscription state of 'active', the XMPP-to-SIP gateway MUST generate a <presence/> stanza of type 'subscribed' addressed to the XMPP user.
When a SIP user refreshes a subscription, the presence-aware SIP-to-XMPP gateway MUST send a SIP NOTIFY to the user agent; if it has meaningful XMPP availability state the NOTIFY MUST communicate that information with a PIDF body, otherwise the NOTIFY MUST be empty.
When honoring long-lived XMPP semantics, a SIP-to-XMPP gateway SHOULD translate a SIP SUBSCRIBE with Expires: 0 into an XMPP <presence type='probe'/> if it does not already have presence information about the contact.
When mapping XMPP resource identifiers to PIDF tuple 'id' attributes, prepending the resourcepart with 'ID-' or another alphabetic string is RECOMMENDED because xs:ID does not allow a number as the first character.
An XMPP presence probe (<presence type='probe'/>) is translated to a SIP SUBSCRIBE with Expires: 0, which per RFC3856 cancels any subscription but triggers a NOTIFY containing current presence state.
Presence notifications are carried as SIP NOTIFY requests containing a PIDF document (application/pidf+xml) from the SIP side, and as XMPP <presence/> stanzas (with no 'type' for available or type='unavailable') from the XMPP side.
Table 1 defines the XMPP-to-SIP presence syntax mapping: <presence/> stanza maps to 'Event: presence'; XMPP resource identifier maps to PIDF tuple 'id' attribute; 'from'/'to' map to SIP From/To; 'type' maps to PIDF basic status; <status/> maps to PIDF <note/>.
To cancel a subscription from the XMPP side, the XMPP-to-SIP gateway translates a <presence/> stanza of type 'unsubscribe' into a SIP SUBSCRIBE request with Expires header set to zero.
XMPP presence subscriptions are managed using <presence/> stanzas of type 'subscribe', 'subscribed', 'unsubscribe', and 'unsubscribed', with subscription states: none, from, to, and both.
Before refreshing an XMPP user's long-lived subscription to a SIP contact, the XMPP-to-SIP gateway MUST first send an XMPP <presence type='probe'/> to the bare JID of the XMPP user; the XMPP server MUST respond per RFC6121. This places equal burden on both servers and mitigates unauthorized refresh amplification.
The mismatch between long-lived XMPP and short-lived SIP presence subscriptions enables an amplification attack from the XMPP network against SIP presence servers (each long-lived XMPP subscription causes multiple SIP refresh requests). XMPP-to-SIP gateway access SHOULD be restricted to a single controlled domain/trust realm, and SIP servers SHOULD refuse traffic from gateways whose users are not associated with the gateway's domain.