[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]
Versions: 00 01 02
DISPATCH WG S. Veikkolainen
Internet-Draft M. Isomaki
Intended status: Standards Track Nokia
Expires: August 30, 2010 February 26, 2010
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
Veikkolainen & Isomaki Expires August 30, 2010 [Page 1]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 August 30, 2010 [Page 2]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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 August 30, 2010 [Page 3]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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 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 August 30, 2010 [Page 4]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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. but
From the use cases, we can derive the following protocol
requirements:
Veikkolainen & Isomaki Expires August 30, 2010 [Page 5]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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.
Veikkolainen & Isomaki Expires August 30, 2010 [Page 6]
Internet-Draft Requirements for combining SIP with XMPP February 2010
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 August 30, 2010 [Page 7]
Internet-Draft Requirements for combining SIP with XMPP February 2010
[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 August 30, 2010 [Page 8]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/