Requirements and Use Cases for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.
draft-veikkolainen-sip-xmpp-coex-reqs-00

Abstract

This memo defines use cases and requirements for combining Session Initiation Protocol (SIP) based real-time media sessions with Extensible Messaging and Presence Protocol (XMPP) based instant messaging and presence services in a seamless manner.

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 30, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

Table of Contents

1.  Introduction
2.  Conventions Used in This Document
3.  Intended scope and deployment scenarios
4.  Use cases and requirements
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses

1.  Introduction

Currently most standards-based Voice over IP (VoIP) deployments use Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). In addition to providing basic voice service SIP has an extensive support for more advanced telephony features including interworking with the traditional Public Switched Telephone Network (PSTN). SIP is also gaining popularity in the field of video communication.

At the same time, the Extensible Messaging and Presence Protocol (XMPP; [RFC3920] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) and [RFC3921] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.)) is enjoying widespread usage in instant messaging and presence services. An interesting scenario arises when a SIP based voice and video service is combined together with an XMPP based instant messaging and presence service.

This memo presents a set of use cases and requirements for an integrated SIP User Agent and XMPP client that aims to offer a seamless user experience combining SIP based voice and video with XMPP based instant messaging and presence.

The main issues that need to be addressed when offering such combined services are identities and addressing. SIP and XMPP both use a similar addressing scheme (based on "user@domain" structure) to identify users and endpoints but there are some subtle differences as well. We do not assume any algorithmic correlation or translation between SIP and XMPP Universal Resource Identifiers (URI), even when they identify the "same" user or endpoint. New protocol mechanisms are needed to tie together communication contexts that are based on the two protocols.

The document structure is as follows: Section 2 (Conventions Used in This Document) presents the document conventions and definitions, Section 3 (Intended scope and deployment scenarios) defines the scope and presents deployment scenarios, and Section 4 (Use cases and requirements) describes use cases and requirements.

2.  Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.

3.  Intended scope and deployment scenarios

This section presents the intended scope of the work and the assumptions that are made about SIP and XMPP deployments with respect to endpoints and server infrastructure.

This work is about combined use of SIP and XMPP in a single integrated endpoint. Protocol translation through a gateway between SIP and XMPP is out of scope; that is the subject of other work, see for example [I‑D.saintandre‑sip‑xmpp‑core] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” March 2009.).

The initial focus is on one-to-one communication only. Multiparty use cases such as combining SIP voice conference with XMPP IM group chat are beyond the scope. This maybe subject of later work.

SIP is able to offer Presence and IM services via the SIP IM and Presence Leveraging Extensions (SIMPLE)(see e.g. [RFC3428] (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) and [RFC3856] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.)). XMPP is able to offer voice services via the Jingle extension [XEP‑0166] (Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, “Jingle,” December 2009.). Offering overlapping services (e.g. presence) via both SIP and XMPP is out of scope of this document. However, it is expected that such scenarios will exist, and guidelines for developers and service providers may be given in other documents.

It is assumed that combining SIP based real-time services with XMPP based presence and IM service can be accomplished purely in the endpoints; no support is needed in the service infrastructure. The intent is that the combined SIP and XMPP endpoints can use already existing SIP and XMPP services, which makes deployment much easier. In general the SIP and XMPP service infrastructures can be totally independent from each other. It is possible to achieve seamless integration even when SIP and XMPP services are offered by different service providers. It is of course possible (and likely) that the same provider offers both SIP and XMPP service, but that does not affect how endpoints use the protocols between each other.

We assume that the user initially only needs to know the contact address of the other user in one protocol space. The contact address for the other protocol must be learned by some means.

We consider only cases where two integrated endpoints interact. When an integrated endpoint communicates with a separated endpoint, normal SIP and XMPP procedures apply and no extensions defined in this memo are used.

4.  Use cases and requirements

In this section we enumerate the actual use cases that the combined service must accommodate for, and define the protol requirements that stem from these use cases.

The use cases are as follows:

• Two users who both use an integrated endpoint start an (XMPP) IM conversation. After the exchange of initial messages, their UIs show that the other party is capable of (SIP) voice and/or video in addition to IM. Either user can at any point add voice and/or video component to the conversation in such a way that at the other user’s end it arrives at the same endpoint and conversation context where the IM exchange is already taking place. (Note that for this use case the conversation initiator initially only needs to know the other user’s XMPP user id.)
• Two users who both use an integrated endpoint start a (SIP) voice and/or video call. As the call is established, their UIs show that the other party is capable for (XMPP) IM. Either user can at any point add an IM component to the conversation in such a way that at the other user’s end it arrives at the same endpoint and conversation context where the voice and/or video call is already taking place. (Note that for this use case the caller initially only needs to know the other user’s SIP user id.)

  It is possible to vary the two cases above so that one of the users initiates a "multimedia call" to the other one, i.e. SIP voice and/or video and XMPP IM are all active from the start. Technically this may happen according to the two-phased approach above, and it invisible from the end-user.

• A user of an integrated endpoint is able to publish her SIP voice and video related presence status as part of her XMPP presence. The status includes information such as user’s SIP contact address (for the integrated endpoint), media capability and availability and whether the user is currently "on the phone". Another user of an integrated endpoint can see the presence status (assuming she is authorized for that) and based on that initiate calls or populate her address book further use. For instance watcher’s UI can now for certain show that the user on her roster is capable of receiving multimedia calls. (Note that the watcher initially only needs to know the other user’s XMPP user id.)

A user who has obtained another user’s SIP URI is able to discover the other user’s XMPP URI so that she can send the other user XMPP IM or subscribe to the other user’s presence, or just populate her address book for futher use. The user is able to do this without bothering the other user, provided the other user has pre-authorized the operation. but

From the use cases, we can derive the following protocol requirements:

REQ-1:

When endpoint A sends an XMPP message to endpoint B, it must be able to include its SIP contact and correlation information in the message, so that endpoint B can initiate a SIP real-time media session with endpoint A. The SIP session initiation must be able to carry information that allows endpoint A to to correlate the session with the XMPP message it sent earlier.

As including the same information in every XMPP message would create some overhead, it is desirable to be able to convey the SIP contact and correlation only once per IM conversation/thread.

REQ-2:

When endpoints A and B establish a real-time media session with SIP, they must during the session initiation be able to exchange their XMPP contact and correlation information so that either endpoint can send an XMPP message to the other endpoint. That XMPP message must be able to carry information which allows its recipient to correlate it with the SIP session.

REQ-3:

It must be possible to include SIP real-time media related contact and status in XMPP presence information. The information must contain at least SIP contact address to identify a user or a user agent instance, media capabilities and general availability status.

REQ-4:

It must be possible for a user, who only knows another user’s SIP URI, to learn the other user’s XMPP URI.

OPEN ISSUE: Should we define requirements related to error or corner cases here. For instance what happens to communication attempts after the other party has closed the conversation context, e.g. a correlated XMPP message that is sent after the related SIP session is terminated. Or a SIP INVITE that appears two days after the XMPP IM conversation was ended.

NOTE: There is also an implicit requirement that we must take Session Border Controllers into account when defining how SIP User Agents are able to identify an existing session between them in a common manner.

5.  IANA Considerations

This document contains no IANA considerations.

6.  Security Considerations

The contact and correlation information is sensitive and we need to prevent connection hijacking and impersonation. If the contact information that is sent over one protocol is forged, the identity verification mechanism in the other no longer help as an attacker is able to assert the false identity.

7.  Acknowledgments

TBD

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses