Interoperability between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)
draft-christou-sip-xmpp-interop-00

Abstract

This document is intended to serve as a reference point for developers and operators implementing the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) within their networks. This document does not define any new protocols but does define the different reference models for deployment of combined use of SIP and XMPP ("CUSAX") clients and SIP-XMPP interworking to ensure consistency across the community.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 11, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Reference Models
• 2.1. Single Client, Same Service Provider
• 2.2. Separate Clients, Same Service Provider
• 2.3. Separate Clients, Different Service Providers
• 2.4. Inter-Domain SIP/SIMPLE-XMPP
• 3. Security Considerations
• 4. IANA Considerations
• 5. Informative References
• Authors' Addresses

1. Introduction

Across the industry, both the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) have been implemented extensively by the vendor and developer community to provide Internet users real-time communication services, including voice, video, and IM/Chat. Initially, SIP was developed to provide the signaling underpinnings for telephony-based communication services. Similarly, XMPP was initially optimized for Instant Messaging and Chat-based communications. Since then both protocols have been extended to enable a more full-suite of features. For example, the SIMPLE protocol was defined to allow SIP to be used for IM, Chat, presence and other "enhanced" features, such as multi-user chat, server-stored contacts, file transfer, etc. The XMPP community developed the Jingle protocol extensions to define how XMPP implementations can establish end-to-end voice and video sessions.

With both suites of protocols providing similar capabilities, the adopter community has implemented both SIP/SIMPLE and XMPP. In certain cases, vendors integrating voice, video, and IM/Chat into their products have implemented SIP for telephony and XMPP for IM/Chat, especially since SIP was initially and optimized for voice/video signaling and XMPP optimized for internet-based chat. However, in other instances, vendors have implemented all capabilities using SIP/SIMPLE or XMPP/Jingle. Unfortunately, interoperability and interworking between SIP/SIMPLE and XMPP-based implementations has been fairly limited thus far.

To help alleviate this lack of interworking, two primary collection of IETF documents have emerged describing how to interoperate between SIP/SIMPLE and XMPP:

• Combined use of SIP and XMPP (CUSAX): The goal of this informational Internet-Draft [I-D.ivov-xmpp-cusax] is to define how software can be modified to enable a hybrid implementation using SIP for voice/video telephony and XMPP for IM/Chat and contact list management. This draft primarily addresses the use case where a user uses a dual stack SIP/XMPP client to access its services.
• SIP-XMPP Interworking: A suite of documents was written to describe how SIMPLE-based and XMPP-based IM/Chat implementations can interoperate. These drafts primarily focus on the use case where one user SIP/SIMPLE domain needs to communicate with users who are a member of a separate XMPP domain.

While these documents are helpful, they might not cover all deployment use cases for real-time communication services using SIP and XMPP. As a result, the goal of this document is threefold:

• Serve as reference guide for adopters implementing real-time communication services using SIP and XMPP. It can also define common terminology across both the SIP and XMPP communities as it relates to inter-working and interoperability between the two protocols.
• Define all relevant deployment scenarios for SIP and XMPP hybrid implementations.
• When necessary, provide a reference to other documents that describe any protocol enhancements that enable the combined use of SIP and XMPP or the interworking functions between the two protocols.

Therefore, this document is intended to serve as a reference point for developers and operators implementing SIP and XMPP within their networks. This document will not define any new standards or protocols but will define the different reference models for deployment of CUSAX clients and SIP-XMPP interworking to ensure consistency across the community.

2. Reference Models

This section defines the different reference models for the deployment of SIP and XMPP. These reference models are categorized as either "CUSAX", where a given network uses SIP for telephony and XMPP for IM/Chat, or as "Inter-Domain SIP/SIMPLE-XMPP", where one IM/chat domain using SIP/SIMPLE needs to interoperate with another XMPP IM/Chat domain.

2.1. Single Client, Same Service Provider

In this use case, adopters deploy a single client which uses SIP for voice/video telephony and XMPP for IM/Chat and Presence. To successfully implement CUSAX using a single client, adopters need guidance on how to provision their systems to ensure consistent account information is configured between the SIP and XMPP infrastructures for the same user. There are no other interoperability issues since presence mapping occurs within the client and the two protocols do not interact elsewhere.

The CUSAX internet-draft [I-D.ivov-xmpp-cusax] explains this use case and provides guidance for implementers when configuring clients and server-side software.

2.2. Separate Clients, Same Service Provider

In certain cases, CUSAX adopters might not have the opportunity to deploy SIP and XMPP in the same client. For example, a given service provider might implement a separate client for SIP telephony from the XMPP IM/Chat client. Alternatively, a service provider can deploy dedicated IP telephony devices (i.e., a phone) and a XMPP IM/Chat client. As a result, similar to what is provided in the CUSAX draft for a single client, guidance needs to be defined to explain how user accounts ought be configured between the two systems. This guidance will also need to define how presence is exchanged either client or server side.

2.3. Separate Clients, Different Service Providers

The third use case involves implementing SIP and XMPP on separate clients by separate service providers. For example, a user might obtain their SIP-based telephony services from a telecommunications provider and their XMPP IM/Chat service from an Internet provider. To provide appropriate guidance for those interested in this use case, a document is needed to describe how to align account information between the two service providers and how to exchange presence consistently between the two service providers for the same user/account.

2.4. Inter-Domain SIP/SIMPLE-XMPP

The second set of use cases involves scenarios where one domain deploys SIP/SIMPLE as its IM/Chat protocol and another domain implements XMPP as its IM/Chat protocol.

In order to consistently and effectively interoperate, four key areas need to be defined:

1. Presence exchange: In order to help ensure interworking between presence systems that conform to the instant message / presence requirements [RFC2779], it is important to clearly define protocol mappings between such systems. [I-D.saintandre-sip-xmpp-presence] defines this mapping and can be used by adopters that need to exchange presence between SIP/SIMPLE and XMPP systems.
2. IM interoperability: The term "instant message" usually refers to messages sent between two entities for delivery in close to real time (rather than messages that are stored and forwarded to the intended recipient upon request). [I-D.saintandre-sip-xmpp-chat] specifies mappings for one-to-one text chat sessions (sometimes called "session-mode" messaging); in particular, the document specifies mappings between XMPP and the Message Session Relay Protocol [RFC4975].
3. Address mapping: In order to inter work between the two IM/Chat systems, a mapping function needs to be defined between the identifiers that are used for XMPP and SIP/SIMPLE (JID and SIP URI). [I-D.saintandre-sip-xmpp-core] explains how to translate between the two identifiers while also explaining how to translate error conditions between the two systems.
4. Multi-User Chat (MUC)/Groupchat: Both XMPP and SIP/SIMPLE technologies enable multi-user text chat, whereby users can exchange messages in the context of a room. To ensure interworking between these technologies for the purposes of enabling "Groupchat" between the two systems, [I-D.saintandre-sip-xmpp-groupchat] defines how to map syntax and semantics between the two protocols.

3. Security Considerations

See the security considerations described in the specifications referenced herein.

4. IANA Considerations

This document has no actions for the IANA.

5. Informative References

Authors' Addresses