Internet DRAFT - draft-tschofenig-ecrit-xmpp-es
draft-tschofenig-ecrit-xmpp-es
ECRIT H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track March 5, 2012
Expires: September 6, 2012
Emergency Services Functionality with the Extensible Messaging and
Presence Protocol (XMPP)
draft-tschofenig-ecrit-xmpp-es-00.txt
Abstract
The Extensible Messaging and Presence Protocol (XMPP) is a technology
that enjoys widespread deployment in the instant messaging
application domain. While many features for XMPP had been
standardized in the IETF as well as in the XMPP Standards Foundation
emergency services functionality was not part of it.
This document aims to initiate a discussion about the necessary
emergency services functionality for XMPP.
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 6, 2012.
Copyright Notice
Copyright (c) 2012 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
Tschofenig Expires September 6, 2012 [Page 1]
Internet-Draft XMPP Emergency Services March 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Interoperability Need . . . . . . . . . . . . . . . . . . . . 5
4. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Emergency Call Marking . . . . . . . . . . . . . . . . . . 7
4.2. Location . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Voice and Video . . . . . . . . . . . . . . . . . . . . . 9
4.5. Real-Time Text . . . . . . . . . . . . . . . . . . . . . . 9
4.6. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . 9
4.7. Additional Data . . . . . . . . . . . . . . . . . . . . . 10
4.8. Data Only Emergency Calls . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informational References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Tschofenig Expires September 6, 2012 [Page 2]
Internet-Draft XMPP Emergency Services March 2012
1. Introduction
The Extensible Messaging and Presence Protocol (XMPP) is a technology
for real-time communication over the Internet that uses the
Extensible Markup Language (XML) as the base format for exchanging
information. XMPP provides a way to send small snippets of XML from
one communication entity to another one. XMPP has found usage in a
variety of protocols, but most people use it primarily for instant
messaging.
With the widespread usage of XMPP on the Internet for instant
messaging and the desire to offer multi-media emergency services
support, i.e., any form of emergency support that goes beyond voice
calling, a frequently asked question is those applications that
utilize XMPP today are able to offer emergency services support
similar to what had been standardized for the Session Initiation
Protocol (SIP) over the last 10 years.
XMPP has found widespread usage for instant messaging on the
Internet. At the same time there is an increasing interest to add
multi-media support to the emergency services portfolio.
Consequently, a frequently asked question by emergency services
professionals is whether applications utilizing XMPP today will be
able to offer emergency services support in the future as well.
Standardization activities have so far exclusively focused on the
Session Initiation Protocol (SIP).
The author believes that it is time to have a discussion about the
desired level of interoperability between XMPP and the standardized,
implemented and even deployed IP-based emergency services
infrastructure that is based on SIP. This document provides a first
discussion input. The main part of the document focuses on the
various components of the emergency services functionality.
Tschofenig Expires September 6, 2012 [Page 3]
Internet-Draft XMPP Emergency Services March 2012
2. Terminology
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 RFC 2119 [RFC2119].
This document uses the terminology defined in [RFC5012].
Tschofenig Expires September 6, 2012 [Page 4]
Internet-Draft XMPP Emergency Services March 2012
3. Interoperability Need
When deciding about the required emergency services functionality in
XMPP a decision has to be made about where to put the burden for
interoperability. There only seem to be two main options, which are
graphically shown in Figure 1 and Figure 2.
In Figure 1 the XMPP is used between the XMPP client and a XMPP
server run by some provider. Whenever the interaction with the
emergency services authorities are needed a gateway translates XMPP
to SIP very similar to how legacy protocols or proprietary protocols
are translated. While the exact placement placement of the XMPP-to-
SIP gateway does not matter from a protocol point of view deployment-
wise it does. Here we assume that the emergency services
infrastructure only supports a single protocol internally, namely
SIP. This is also inline with the current standardization situation.
,-------.
,'IP-based `.
.-----------. / Emergency \
+------+ XMPP | Provider | | Services |
|XMPP |------->| .------- | | Network |
|Client| | |XMPP | | | |
+------+ | |Server | | | +------+ |
| '-------' | | |PSAP | |
| | | | +--+---+ |
| .---+---. | | | |
'-|Gateway|-' | | |
'---+---' | |SIP |
| | | |
|SIP | | |
| | | |
| | +--+---+ |
+-------------+-->|ESRP | |
| +------+ |
| |
\ /
`. ,'
'-------'
Figure 1: Backend Interoperability
The interworking between SIP and XMPP had been subject to earlier
investigations, as described in [I-D.saintandre-sip-xmpp-core],
[I-D.saintandre-sip-xmpp-media], and [I-D.saintandre-sip-xmpp-im].
Tschofenig Expires September 6, 2012 [Page 5]
Internet-Draft XMPP Emergency Services March 2012
In Figure 2 we show a deployment where XMPP is used end-to-end and
the emergency services supports XMPP in addition to SIP.
,-------.
,'IP-based `.
/ Emergency \
.-----------. | Services |
| Provider | | Network |
+------+ | .-------. | | |
|XMPP | XMPP | |XMPP | | | +------+ |
|Client|------->| |Server | | | |PSAP | |
+------+ | '-------' | | +--+---+ |
| | | | | |
'----+------' | | |
| | |XMPP |
| | | |
|XMPP | | |
| | | |
+------+ | | +--+---+ |
|XMPP | XMPP +--------------+-->|ESRP | |
|Client|----------------------------+-->| | |
+------+ | +------+ |
\ /
`. ,'
'-------'
Figure 2: End-to-End Interoperability
Not shown in the figures above is the ability for combined SIP and
XMPP usage. Requirements for such interworking are described in
[I-D.veikkolainen-sip-xmpp-coex-reqs] and guidance is provided in
[I-D.veikkolainen-sip-voip-xmpp-im].
Tschofenig Expires September 6, 2012 [Page 6]
Internet-Draft XMPP Emergency Services March 2012
4. Functionality
An important aspect in the support of emergency services in XMPP is
how far current XMPP features are equivalent to those offered by SIP.
For SIP [I-D.ietf-ecrit-phonebcp] describes the necessary
functionality for emergency calling on the Internet. A similar
specification is needed for XMPP. [I-D.ietf-ecrit-phonebcp],
however, relies on already defined functionality and 'glues' these
available building blocks together. The sub-sections below discuss
some of the most important building blocks.
4.1. Emergency Call Marking
In existing telecommunications systems, there are many well-known
communication and information services that are characterized by
long-term stability of user- visible identifiers, decentralized
administration of the underlying service, and a well-defined
resolution or mapping mechanism. [RFC5031] defines a URN namespace
that, together with resolution protocols, allows us to define global,
well-known services, while distributing the actual implementation
across a large number of service-providing entities.
[RFC5031] is not only used for marking SIP communication but it is
also used by various emergency components, such as the Location-to-
Service Translation (LoST) protocol. [RFC5031] also has to be
integrated into XMPP.
Part of the emergency call marking is also the ability to indicate a
test emergency call, as described in Section 15 of
[I-D.ietf-ecrit-phonebcp]. An equivalent feature is highly likely to
be useful for XMPP.
4.2. Location
The IETF has produced a fairly extensive set of location
specifications that are re-used for emergency services. The work
falls into various categories, as described in [RFC6280] and in
Section 6 of [RFC6443]. The requirements for obtaining high accuracy
location information are more complex for emergency services than
with commercial location applications due to the life critical nature
of the service.
Location Formats:
There are two main formats standardized for location information,
namely civic and geodetic location information. The core civic
location standard can be found in [RFC5139] and the profile for
geodetic information is available with [RFC5491]. [RFC5491]
Tschofenig Expires September 6, 2012 [Page 7]
Internet-Draft XMPP Emergency Services March 2012
supports a large set of location shapes. Various additional
extensions have been developed, such as the support for relative
location [I-D.ietf-geopriv-relative-location] and location civic
addresses [I-D.ietf-geopriv-local-civic]. It is also important to
mention that there have been efforts ongoing to map the civic
addresses in various countries to the PIDF-LO civic location
tokens, based on the recommendations in [RFC5774].
Location Encoding:
There are mainly two encodings of location information, namely a
binary encoding, as for example used by DHCP location extensions,
and an XML-based encoding based on PIDF-LO [RFC4119]. Note that
the PIDF-LO element contains more than pure location data but also
provides information about the entity that constructed the
location object (based on the 'provided-by' element) and
supplementary data about the utilized location determination
technique (based on values from the 'method' token' IANA
registry).
Location Configuration Protocols:
A Location Configuration Protocol (LCP) [RFC5687] is one mechanism
that can be used by a device to discover its own location from a
LIS. Several LCPs have been developed within Geopriv, such as
[RFC5985]. LCPs obtain location information from location servers
and are therefore indirectly relevant for location conveyed within
XMPP.
Location Derefencing:
For location derefencing two protocols have been defined, namely
one based on HTTP [I-D.ietf-geopriv-deref-protocol] and another
one based on SIP which may use filters to reduce the number of
asynchronous notifications [RFC6447]. A session setup protocol
has to support the ability to convey these references.
Location Conveyance:
The ability to convey a PIDF-LO and a location by reference in SIP
had been defined by [RFC6442]. For a single call there may be
more than one location object in a call.
While there is a location extensions available in XMPP with XEP-0080
[XEP-0080] it is not equivalent to the functionality listed above.
XEP-0080 offers a different civic location format and geodetic
location based on a reduced set of loation shapes. It uses an XML
encoding and allows this information to be conveyed in XMPP. A table
Tschofenig Expires September 6, 2012 [Page 8]
Internet-Draft XMPP Emergency Services March 2012
with a mapping to the PIDF-LO semantic is provided in XEP-0080 but
unfortunately since the functionality is not equivalent to the list
presented above there will be a loss of information during the
lifecyle of location handling in most of the scenarios.
4.3. Routing
The LoST protocol [RFC5222] offers the ability to discover service
contact URIs based on provided service identifiers and location
information. In particular, it can be used to determine the
location-appropriate Public Safety Answering Point (PSAP) for
emergency services. During the design of LoST it was already
anticipated that service contact URIs based on a variety of different
protocols (not only SIP) will be needed. As such, XMPP is seamlessly
supported by LoST.
4.4. Voice and Video
With XEP-0166 [XEP-0166] the ability to initiate and manage peer-to-
peer media sessions between two XMPP entities in a way that is
interoperable with existing Internet standards had been defined. The
protocol enables the core session management semantics (compatible
with SIP) to be used for a wide variety of application types (e.g.,
voice chat, video chat).
The ability for voice and video conference bridge as needed by
persons with disabilities for sign-language interpretation is,
however, not offered by Jingle.
4.5. Real-Time Text
RFC 5194 [RFC5194] defines the framework for Real-Time Text over IP.
All required functionality is based on SIP and the Real-Time
Transport Protocol (RTP).
XEP-0301 [XEP-0301] seems to offer functionality that is similar to
what had been defined by RFC 5194.
4.6. PSAP Callback
After an emergency call is completed it is possible that the call-
taker feels the need for further communication. For example, the
call may have been dropped by accident without the call- taker having
sufficient information about the current situation of a wounded
person. A call-taker may trigger a callback towards the emergency
caller using the contact informationprovided with the initial
emergency call, which includes the GRUU as well as the Address-of-
Record. This callback would be treated like any other call and as a
Tschofenig Expires September 6, 2012 [Page 9]
Internet-Draft XMPP Emergency Services March 2012
consequence it may get blocked by authorization policies or may get
forwarded to an answering machine.
The work on PSAP callback [I-D.ietf-ecrit-psap-callback] is an
ongoing effort to give these calls preferential treatment so that the
callback has a higher success in reaching the original emergency
call.
This functionality does not exist for XMPP yet.
4.7. Additional Data
The Internet Protocol suite offers a rich information exchange and
thereby better situational awareness for call takers and first
responders. The richness comes in various forms, including the
multi-media communication capabilities (via voice, video, instant
messaging, and real-time text), but also via more additional data
made available by various actors of the emergency signaling chain.
Sharing information between various actors will enable more
intelligent decision making and therefore better response in case of
an emergency.
In the SIP environment additional data had been provided in various
ways, as described in [I-D.ietf-ecrit-additional-data], and the same
capabilities will have to be provided in XMPP as well.
4.8. Data Only Emergency Calls
Data-only emergency calls are similar to regular emergency calls in
the sense that they require emergency call routing functionality and
may even have the same location requirements. On the other hand, the
communication interaction occurs without establishment of a voice or
video channel.
As a technical mechanism a Common Alert Protocol (CAP) payload is
pushed by the SIP User Agent towards the PSAP, as described in
[I-D.ietf-ecrit-data-only-ea]. The ability to push CAP payloads is
also available in XMPP with XEP-0127 [XEP-0127].
Tschofenig Expires September 6, 2012 [Page 10]
Internet-Draft XMPP Emergency Services March 2012
5. Security Considerations
This document focuses on the integration of emergency services
functionality into XMPP. Offering security features for emergency
calls is both important but also challenging as security failures
(such as expired certificates) may have fatal effects. SIP offers a
secure identity mechanism as well as media security. Functionality
for these two areas are specified in [I-D.ietf-ecrit-phonebcp].
Offering a solid mechanisms for identification of the persons seeking
help is important for the overal security of the emergency services
system, as described in [I-D.ietf-ecrit-trustworthy-location].
Tschofenig Expires September 6, 2012 [Page 11]
Internet-Draft XMPP Emergency Services March 2012
6. Acknowledgements
The author would like to thank the members of the European Emergency
Number Association (EENA) Next Generation 112 technical committee and
the National Emergency Number Association (NENA) Long-Term Definition
working group for their discussions around XMPP emergency services
support.
Tschofenig Expires September 6, 2012 [Page 12]
Internet-Draft XMPP Emergency Services March 2012
7. References
7.1. Normative References
[I-D.ietf-ecrit-additional-data]
Rosen, B., Tschofenig, H., and R. Marshall, "Additional
Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-02 (work in progress),
October 2011.
[I-D.ietf-ecrit-data-only-ea]
Rosen, B., Schulzrinne, H., and H. Tschofenig, "Common
Alerting Protocol (CAP) based Emergency Alerts using the
Session Initiation Protocol (SIP)",
draft-ietf-ecrit-data-only-ea-02 (work in progress),
July 2011.
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011.
[I-D.ietf-ecrit-psap-callback]
Holmberg, C., Tschofenig, H., Schulzrinne, H., and M.
Patel, "Public Safety Answering Point (PSAP) Callback",
draft-ietf-ecrit-psap-callback-03 (work in progress),
October 2011.
[I-D.ietf-geopriv-deref-protocol]
Thomson, M., Dawson, M., Winterbottom, J., Tschofenig, H.,
and H. Schulzrinne, "A Location Dereferencing Protocol
Using HELD", draft-ietf-geopriv-deref-protocol-04 (work in
progress), October 2011.
[I-D.ietf-geopriv-local-civic]
Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and
R. George, "Specifying Civic Address Extensions in
PIDF-LO", draft-ietf-geopriv-local-civic-03 (work in
progress), February 2012.
[I-D.ietf-geopriv-relative-location]
Thomson, M., Stanley, D., Rosen, B., Thomson, A., and G.
Bajko, "Relative Location Representation",
draft-ietf-geopriv-relative-location-02 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Tschofenig Expires September 6, 2012 [Page 13]
Internet-Draft XMPP Emergency Services March 2012
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031,
January 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text
over IP Using the Session Initiation Protocol (SIP)",
RFC 5194, June 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic
Addresses in the Presence Information Data Format Location
Object (PIDF-LO): Guidelines and IANA Registry
Definition", BCP 154, RFC 5774, March 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
Tschofenig Expires September 6, 2012 [Page 14]
Internet-Draft XMPP Emergency Services March 2012
for the Session Initiation Protocol", RFC 6442,
December 2011.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011.
[RFC6447] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering
Location Notifications in the Session Initiation Protocol
(SIP)", RFC 6447, January 2012.
7.2. Informational References
[I-D.ietf-ecrit-trustworthy-location]
Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location Information",
draft-ietf-ecrit-trustworthy-location-02 (work in
progress), May 2011.
[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.
[I-D.saintandre-sip-xmpp-im]
Saint-Andre, P., Houri, A., and J. Hildebrand,
"Interworking between the Session Initiation Protocol
(SIP) and the Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging",
draft-saintandre-sip-xmpp-im-01 (work in progress),
March 2009.
[I-D.saintandre-sip-xmpp-media]
Saint-Andre, P., "Interworking between the Session
Initiation Protocol (SIP) and the Extensible Messaging
and Presence Protocol (XMPP): Media Sessions",
draft-saintandre-sip-xmpp-media-01 (work in progress),
March 2009.
[I-D.veikkolainen-sip-voip-xmpp-im]
Veikkolainen, S. and M. Isomaki, "Guidelines and Protocol
Extensions for Combining SIP Based Real-time Media
Sessions With XMPP Based Instant Messaging and Presence
Service.", draft-veikkolainen-sip-voip-xmpp-im-01 (work in
progress), July 2009.
Tschofenig Expires September 6, 2012 [Page 15]
Internet-Draft XMPP Emergency Services March 2012
[I-D.veikkolainen-sip-xmpp-coex-reqs]
Veikkolainen, S. and M. Isomaki, "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 (work in
progress), January 2011.
[XEP-0080]
Hildebrand, J. and P. Saint-Andre, "User Location", XSF
XEP 0080, September 2009.
[XEP-0127]
Saint-Andre, P. and B. Fletcher, "Common Alerting Protocol
(CAP) Over XMPP", XSF XEP 0127, December 2004.
[XEP-0166]
Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan,
S., and J. Hildebrand, "Jingle", XSF XEP 0166,
December 2009.
[XEP-0301]
Rejhon, M., "In-Band Real Time Text", XSF XEP 0301,
June 2011.
Tschofenig Expires September 6, 2012 [Page 16]
Internet-Draft XMPP Emergency Services March 2012
Author's Address
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Tschofenig Expires September 6, 2012 [Page 17]
