[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

DISPATCH WG                                              S. Veikkolainen
Internet-Draft                                                M. Isomaki
Intended status: Standards Track                                   Nokia
Expires: July 30, 2011                                  January 26, 2011


   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-02

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 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 July 30, 2011.

Copyright Notice

   Copyright (c) 2011 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.



Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 1]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


Table of Contents

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






































Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 2]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


1.  Introduction

   Currently most standards-based Voice over IP (VoIP) deployments use
   Session Initiation Protocol (SIP) [RFC3261].  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] and [RFC3921]) 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 presents the document
   conventions and definitions, Section 3 defines the scope and presents
   deployment scenarios, and Section 4 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
   [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



Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 3]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


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

   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] and
   [RFC3856]).  XMPP is able to offer voice and video services via the
   Jingle extension [XEP-0166].  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.



Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 4]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


   The use cases are as follows:

   o  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.)

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

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

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



Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 5]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


   REQ-1:  When endpoint A sends an XMPP message to endpoint B, it must
           be able to include its SIP address 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 address and status
           information in XMPP presence.  The information must contain
           at least a 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.





Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 6]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [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", draft-saintandre-sip-xmpp-core-01 (work in
              progress), March 2009.

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

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3921]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Instant Messaging and Presence",
              RFC 3921, October 2004.



Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 7]


Internet-Draft  Requirements for combining SIP with XMPP    January 2011


   [XEP-0166]
              Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan,
              S., and J. Hildebrand, "Jingle", December 2009,
              <http://xmpp.org/extensions/xep-0166.html>.


Authors' Addresses

   Simo Veikkolainen
   Nokia
   P.O. Box 407
   NOKIA GROUP, FI  00045
   Finland

   Phone: +358 50 486 4463
   Email: simo.veikkolainen@nokia.com


   Markus Isomaki
   Nokia
   P.O. Box 100
   NOKIA GROUP, FI  00045
   Finland

   Phone: +358 50 522 5984
   Email: markus.isomaki@nokia.com

























Veikkolainen & Isomaki    Expires July 30, 2011                 [Page 8]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/