< draft-ietf-ecrit-data-only-ea-04.txt   draft-ietf-ecrit-data-only-ea-05.txt >
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Experimental H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: May 13, 2013 Columbia U. Expires: August 29, 2013 Columbia U.
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
November 9, 2012 February 25, 2013
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-04.txt draft-ietf-ecrit-data-only-ea-05.txt
Abstract Abstract
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) can handle Internet how Public Safety Answering Points (PSAPs) can handle Internet
multimedia emergency calls natively. The exchange of multimedia multimedia emergency calls natively. The exchange of multimedia
traffic typically involves a SIP session establishment starting with traffic typically involves a SIP session establishment starting with
a SIP INVITE that negotiates various parameters for that session. a SIP INVITE that negotiates various parameters for that session.
In some cases, however, the transmission of application data is In some cases, however, the transmission of application data is
everything that is needed. Examples of such environments include a everything that is needed. Examples of such environments include a
temperature sensors issuing alerts, or vehicles sending crash data. temperature sensors issuing alerts, or vehicles sending crash data.
Often these alerts are conveyed as one-shot data transmissions and in Often these alerts are conveyed as one-shot data transmissions.
some rare cases they may require a session to be established. These These type of interactions are called 'data-only emergency calls'.
type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common
Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
transaction.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 13, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 8
4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 8 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Profiling of the CAP Document Content . . . . . . . . . . 8 4.2. Profiling of the CAP Document Content . . . . . . . . . . 8
4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . . 9
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 10 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 10
5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 10 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 10
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. Registration of the 'application/cap+xml' MIME type . . . 17 8.1. Registration of the 'application/cap+xml' MIME type . . . 19
8.2. IANA Registration for 425 Response Code . . . . . . . . . 18 8.2. IANA Registration for 425 Response Code . . . . . . . . . 20
8.3. IANA Registration of New AlertMsg-Error Header Field . . . 18 8.3. IANA Registration of New AlertMsg-Error Header Field . . . 20
8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 19 8.4. IANA Registration for the SIP AlertMsg-Error Codes . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
RFC 6443 [RFC6443] describes how devices use the Internet to place RFC 6443 [RFC6443] describes how devices use the Internet to place
emergency calls and how Public Safety Answering Points (PSAPs) can emergency calls and how Public Safety Answering Points (PSAPs) can
handle Internet multimedia emergency calls natively. The exchange of handle Internet multimedia emergency calls natively. The exchange of
multimedia traffic typically involves a SIP session establishment multimedia traffic typically involves a SIP session establishment
starting with a SIP INVITE that negotiates various parameters for starting with a SIP INVITE that negotiates various parameters for
that session. that session.
In some cases, however, there is only application data to be conveyed In some cases, however, there is only application data to be conveyed
from the end devices to a PSAP or some other intermediary. Examples from the end devices to a PSAP or some other intermediary. Examples
of such environments includes sensors issuing alerts, or vehicles of such environments includes sensors issuing alerts, or vehicles
sending crash data. These messages may be one-shot data sending crash data. These messages may be one-shot alerts to
transmissions (i.e., SIP message handling that requires no emergency authorities and do not require establishment of a session.
establishment of a session) and interactions where a sequence of These type of interactions are called 'data-only emergency calls'.
messages are transmitted in which case a session setup is useful to In this document, we use the term "call" so that similarities between
ensure that all messages are indeed routed to the same PSAP. These full sessions with interactive media can be exploited.
type of interactions are called 'data-only emergency calls'.
Data-only emergency calls are nevertheless similar to regular Data-only emergency calls are similar to regular emergency calls in
emergency calls in the sense that they require the emergency the sense that they require the emergency indications, emergency call
indications, emergency call routing functionality and may even have routing functionality and may even have the same location
the same location requirements. However, the communication requirements. However, the communication interaction will not lead
interaction will not lead to the exchange of Real-Time Protocol to the exchange of interactive media, that is, Real-Time Protocol
packets, such as voice, video data or real-time text. packets, such as voice, video data or real-time text.
This document does not define a mechanism for updates to the data
contained in data-only emergency calls.
The Common Alerting Protocol (CAP) [cap] is a document format for The Common Alerting Protocol (CAP) [cap] is a document format for
exchanging emergency alerts and public warnings. CAP is mainly used exchanging emergency alerts and public warnings. CAP is mainly used
for conveying alerts and warnings between authorities and from for conveying alerts and warnings between authorities and from
authorities to citizen/individuals. authorities to citizen/individuals. This document is concerned with
citizen to authority "alerts", where the alert is sent without any
interactive media.
This document uses the CAP payload to convey the semantic of a data- CAP payload is used to convey the alert data which is contained in
only emergency call. Note that further data may be added using the the body of a SIP MESSAGE. Note that further data may be added using
already available 'additional data' structure the already available 'additional data' structure
[I-D.ietf-ecrit-additional-data]. Whenever data can be encoded in [I-D.ietf-ecrit-additional-data]. Whenever data can be encoded in
the additional data structure it shall be used. the additional data structure it shall be used.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architectural Overview 3. Architectural Overview
This section illustrates two envisioned usage modes; targeted and This section illustrates two envisioned usage modes; targeted and
location-based emergency alert routing. location-based emergency alert routing.
1. Emergency alerts containing only data are targeted to a recipient 1. Emergency alerts containing only data are targeted to a
responsible for evaluating the next steps, which could include: intermediary recipient responsible for evaluating the next steps.
These steps could include:
1. Sending an alert containing only data toward a Public Safety 1. Sending an alert containing only data toward a Public Safety
Answering Point (PSAP); Answering Point (PSAP);
2. Establishing a third-party initiated emergency call that 2. Establishing a third-party initiated emergency call towards a
could include audio, video, and data. PSAP that could include audio, video, and data.
2. Emergency alerts targeted to a Service URN used for IP-based 2. Emergency alerts targeted to a Service URN used for IP-based
emergency calls where the recipient is not known to the emergency calls where the recipient is not known to the
originator. In this scenario, the alert may contain only data originator. In this scenario, the alert may contain only data
(e.g., a CAP and a PIDF-LO payload in a SIP MESSAGE). (e.g., a CAP and a PIDF-LO payload in a SIP MESSAGE).
Figure 1 shows a deployment variant where a sensor, is pre-configured Figure 1 shows a deployment variant where a sensor, is pre-configured
(using techniques outside the scope of this document) to issue an (using techniques outside the scope of this document) to issue an
alert to an aggregator that processes these messages and performs alert to an aggregator that processes these messages and performs
whatever steps are necessary to appropriately react on the alert. whatever steps are necessary to appropriately react on the alert.
skipping to change at page 8, line 9 skipping to change at page 8, line 9
|<-------------------| | |<-------------------| |
| | | | | |
| | | | | |
Figure 2: Location-Based Emergency Alert Routing Figure 2: Location-Based Emergency Alert Routing
4. Protocol Specification 4. Protocol Specification
4.1. CAP Transport 4.1. CAP Transport
To convey CAP payloads the SIP MESSAGE [RFC3428] is used for A CAP message may be sent on the initial message of any SIP
exchanges where no session establishment is needed, i.e.., one-shot transaction. However, this document only describes specific behavior
message exchange, and the SIP INVITE [RFC3261] where the when used with a SIP MESSAGE transaction for a one-shot, data-only
establishment of session is useful (e.g., when multiple independent emergency call. Behavior with other transactions is not defined.
messages have to be logically tied together). The CAP message is sent in the body of the message. The MIME type is
set to 'application/cap+xml'.
The MIME type is set to 'application/cap+xml'.
If the server does not support the functionality required to fulfill If the server does not support the functionality required to fulfill
the request then a 501 Not Implemented MUST be returned by RFC 3261 the request then a 501 Not Implemented MUST be returned as specified
[RFC3261]. This is the appropriate response when a UAS does not in RFC 3261 [RFC3261]. This is the appropriate response when a UAS
recognize the request method and is not capable of supporting it for does not recognize the request method and is not capable of
any user. supporting it for any user.
The 415 Unsupported Media Type error MUST be returned by RFC 3261 The 415 Unsupported Media Type error MUST be returned as specified in
[RFC3261] if the server is refusing to service the request because RFC 3261 [RFC3261] if the server is refusing to service the request
the message body of the request is in a format not supported by the because the message body of the request is in a format not supported
server for the requested method. The server MUST return a list of by the server for the requested method. The server MUST return a
acceptable formats using the Accept, Accept-Encoding, or Accept- list of acceptable formats using the Accept, Accept-Encoding, or
Language header field, depending on the specific problem with the Accept-Language header field, depending on the specific problem with
content. the content.
4.2. Profiling of the CAP Document Content 4.2. Profiling of the CAP Document Content
The usage of CAP MUST conform to the specification provided with The usage of CAP MUST conform to the specification provided with
[cap]. For the usage with SIP the following additional requirements [cap]. For the usage with SIP the following additional requirements
are imposed: are imposed:
sender: A few sub-categories for putting a value in the <sender> sender: A few sub-categories for putting a value in the <sender>
element have to be considered: element have to be considered:
skipping to change at page 9, line 7 skipping to change at page 9, line 6
Originator is a non-SIP entity, Author indication irrelevant: In Originator is a non-SIP entity, Author indication irrelevant: In
case that the alert was created by a non-SIP based entity and case that the alert was created by a non-SIP based entity and
the identity of this original sender wants to be preserved then the identity of this original sender wants to be preserved then
this identity MUST be placed into the <sender> element. In this identity MUST be placed into the <sender> element. In
this category the it is not useful to be explicit about the this category the it is not useful to be explicit about the
author of the alert. The specific type of identity being used author of the alert. The specific type of identity being used
will depends on the technology being used by the original will depends on the technology being used by the original
originator. originator.
Author indication relevant: In case the author is different from Author indication relevant: In case the author is different from
the actual originator of the message and this distinction wants the actual originator of the message and this distinction
to be preserved then the <sender> element MUST NOT contain the should be preserved then the <sender> element MUST NOT contain
SIP URI. the SIP URI of the user agent.
incidents: The <incidents> element MUST be present whenever there is incidents: The <incidents> element MUST be present. This incident
a possibility that alert information needs to be updated. The identifier MUST be chosen in such a way that it is unique for a
initial message will then contain an incident identifier carried given <sender, expires, incidents> combination. Note that the
in the <incidents> element. This incident identifier MUST be <expires> element is optional and may not be present.
chosen in such a way that it is unique for a given <sender,
expires, incidents> combination. Note that the <expires> element
is optional and may not be present.
scope: The value of the <scope> element MUST be set to "Private" as scope: The value of the <scope> element MAY be set to "Private" if
the alert is not meant for public consumption. The <addresses> the alert is not meant for public consumption. The <addresses>
element is, however, not used by this specification since the element is, however, not used by this specification since the
message routing is performed by SIP and the respective address message routing is performed by SIP and the respective address
information is already available in other SIP headers. Populating information is already available in other SIP headers. Populating
information twice into different parts of the message may lead to information twice into different parts of the message may lead to
inconsistency. inconsistency.
parameter: The <parameter> element MAY contain additional parameter: The <parameter> element MAY contain additional
information specific to the sensor. information specific to the sendor.
area: It is RECOMMENDED to omit this element when constructing a area: It is RECOMMENDED to omit this element when constructing a
message. In case that the CAP message already contained an <area> message. In case that the CAP message already contained an <area>
element then the specified location information MUST be copied element then the specified location information SHOULD be copied
into the PIDF-LO structure of the 'geolocation' header. into the PIDF-LO structure of the 'geolocation' header.
4.3. Sending a Data-Only Emergency Call
A data-only emergency call is sent using a SIP MESSAGE transaction
with a CAP body as described above in a manner similar to how an
emergency call with interactive media is sent, as described in
[I-D.ietf-ecrit-phonebcp]. The MESSAGE transaction does not create a
session or send media, but otherwise, the header content of the
transaction, routing, and processing of data-only calls are the same
as those of other emergency calls.
5. Error Handling 5. Error Handling
This section defines a new error response code and a header field for This section defines a new error response code and a header field for
additional information. additional information.
5.1. 425 (Bad Alert Message) Response Code 5.1. 425 (Bad Alert Message) Response Code
This SIP extension creates a new location-specific response code, This SIP extension creates a new location-specific response code,
defined as follows, defined as follows,
skipping to change at page 11, line 44 skipping to change at page 11, line 44
The AlertMsg-Error header field MAY be included in any response as an The AlertMsg-Error header field MAY be included in any response as an
alert message was in the request part of the same transaction. For alert message was in the request part of the same transaction. For
example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP example, a UA includes an alert in an MESSAGE to a PSAP. The PSAP
can accept this MESSAGE, thus creating a dialog, even though his UA can accept this MESSAGE, thus creating a dialog, even though his UA
determined the alert message contained in the MESSAGE was bad. The determined the alert message contained in the MESSAGE was bad. The
PSAP merely includes an AlertMsg-Error header value in the 200 OK to PSAP merely includes an AlertMsg-Error header value in the 200 OK to
the MESSAGE informing the UA that the MESSAGE was accepted but the the MESSAGE informing the UA that the MESSAGE was accepted but the
alert provided was bad. alert provided was bad.
If, on the other hand, the PSAP cannot accept the MESSAGE without a If, on the other hand, the PSAP cannot accept the transaction without
suitable alert message, a 425 response is sent. a suitable alert message, a 425 response is sent.
A SIP intermediary that requires the UA's alert message in order to A SIP intermediary that requires the UA's alert message in order to
properly process the MESSAGE may also sends a 425 with a AlertMsg- properly process the transaction may also sends a 425 with a
Error code. AlertMsg-Error code.
This document defines an initial list of error code ranges for any This document defines an initial list of error code ranges for any
SIP response, including provisional responses (other than 100 Trying) SIP response, including provisional responses (other than 100 Trying)
and the new 425 response. There MUST be no more than one AlertMsg- and the new 425 response. There MUST be no more than one AlertMsg-
Error code in a SIP response. Error code in a SIP response.
AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload" AlertMsg-Error: 100 ; code="Cannot Process the Alert Payload"
AlertMsg-Error: 101 ; code="Alert Payload was not present or could AlertMsg-Error: 101 ; code="Alert Payload was not present or could
not be found" not be found"
AlertMsg-Error: 102 ; code="Not enough information to determine the AlertMsg-Error: 102 ; code="Not enough information to determine the
purpose of the alert" purpose of the alert"
AlertMsg-Error: 103 ; code="Alert Payload was corrupted" AlertMsg-Error: 103 ; code="Alert Payload was corrupted"
Additionally, if an LR cannot or chooses not to process the alert Additionally, if an entity cannot or chooses not to process the alert
message from a SIP request, a 500 (Server Internal Error) SHOULD be message from a SIP request, a 500 (Server Internal Error) SHOULD be
used with or without a configurable Retry-After header field. used with or without a configurable Retry-After header field.
6. Example 6. Example
Figure 3 shows a CAP document indicating a BURGLARY alert issued by a Figure 3 shows a CAP document indicating a BURGLARY alert issued by a
sensor called 'sensor1@domain.com'. The location of the sensor can sensor called 'sensor1@domain.com'. The location of the sensor can
be obtained from the attached location information provided via the be obtained from the attached location information provided via the
'geolocation' header contained in the SIP MESSAGE structure. 'geolocation' header contained in the SIP MESSAGE structure.
Additionally, the sensor provided some data long with the alert Additionally, the sensor provided some data long with the alert
skipping to change at page 14, line 50 skipping to change at page 14, line 50
<gbp:retention-expiry>2010-11-14T20:00:00Z <gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry> </gbp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
<gp:method>802.11</gp:method> <gp:method>802.11</gp:method>
</gp:geopriv> </gp:geopriv>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp> <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device> </dm:device>
</presence> </presence>
--boundary1-- --boundary1--
Figure 3: Example Message conveying an Alert Figure 3: Example Message conveying an Alert to an Aggregator
Figure 4 shows the same CAP document sent as a data-only emergency
call towards a PSAP.
MESSAGE urn:service:sos SIP/2.0
Via: SIP/2.0/TCP sip:aggregator.1.example.com;branch=z9hG4bK776abssa
Max-Forwards: 70
From: sip:aggregator@example.com;tag=32336
To: 112
Call-ID: asdf33443a@example.com
Route: sip:psap1.example.gov
Geolocation: <cid:abcdef@example.com>
;routing-allowed=yes
Supported: geolocation
Accept: application/pidf+xml, application/cap+xml
CSeq: 1 MESSAGE
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
--boundary1
Content-Type: cap+xml
Content-ID: <abcdef2@example.com>
<?xml version="1.0" encoding="UTF-8"?>
<alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
<identifier>S-1</identifier>
<sender>sip:sensor1@domain.com</sender>
<sent>2008-11-19T14:57:00-07:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Private</scope>
<incidents>abc1234</incidents>
<info>
<category>Security</category>
<event>BURGLARY</event>
<urgency>Expected</urgency>
<certainty>Likely</certainty>
<severity>Moderate</severity>
<senderName>SENSOR 1</senderName>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE1</valueName>
<value>123</value>
</parameter>
<parameter>
<valueName>SENSOR-DATA-NAMESPACE2</valueName>
<value>TRUE</value>
</parameter>
</info>
</alert>
--boundary1
Content-Type: application/pidf+xml
Content-ID: <abcdef2@domain.com>
<?xml version="1.0" encoding="UTF-8"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gml="http://www.opengis.net/gml"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:alice@atlanta.example.com">
<dm:device id="sensor">
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.86726 -97.16054</gml:pos>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>
<gbp:retention-expiry>2010-11-14T20:00:00Z
</gbp:retention-expiry>
</gp:usage-rules>
<gp:method>802.11</gp:method>
</gp:geopriv>
<dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
</dm:device>
</presence>
--boundary1--
Figure 4: Example Message conveying an Alert to a PSAP
7. Security Considerations 7. Security Considerations
This section discusses security considerations when SIP user agents This section discusses security considerations when SIP user agents
issue emergency alerts utilizing CAP. Location specific threats are issue emergency alerts utilizing MESSAGE and CAP. Location specific
not unique to this document and are discussed in threats are not unique to this document and are discussed in
[I-D.ietf-ecrit-trustworthy-location] and [RFC6442]. [I-D.ietf-ecrit-trustworthy-location] and [RFC6442].
The ECRIT emergency services architecture [I-D.ietf-ecrit-phonebcp] The ECRIT emergency services architecture [RFC6443] considers
considers classical individual-to-authority emergency calling and the classical individual-to-authority emergency calling and the identity
identity of the emergency caller does not play a role at the time of of the emergency caller does not play a role at the time of the call
the call establishment itself, i.e., a response to the emergency call establishment itself, i.e., a response to the emergency call will not
will not depend on the identity of the caller. In case of emergency depend on the identity of the caller. In case of emergency alerts
alerts generated by devices, like sensors, the processing may be generated by devices, like sensors, the processing may be different
different in order to reduce the number of falsely generated in order to reduce the number of falsely generated emergency alerts.
emergency alerts. Alerts may get triggered based on certain sensor Alerts may get triggered based on certain sensor input that may have
input that may have been caused by other factors than the actual been caused by other factors than the actual occurrence of an alert
occurrence of an alert relevant event. For example, a sensor may relevant event. For example, a sensor may simply be malfunctioning.
simply be malfunctioning. For this purpose not all alert messages For this purpose not all alert messages are directly sent to a PSAP
are directly sent to a PSAP but are rather pre-processed by a but rather may be pre-processed by a separate entity, potentially
separate entity, potentially under supervision by a human, to filter under supervision by a human, to filter alerts and potentially
alerts and potentially correlate received alerts with others to correlate received alerts with others to obtain a larger picture of
obtain a larger picture of the ongoing situation. These two message the ongoing situation.
routing examples are shown in Figure 1 and in Figure 2.
In any case, for alerts that are initiated by sensors the identity In any case, for alerts that are initiated by sensors the identity
may play an important role in deciding whether to accept or ignore an may play an important role in deciding whether to accept or ignore an
incoming alert message. With the scenario shown in Figure 1 it is incoming alert message. With the scenario shown in Figure 1 it is
very likely that only authorized sensor input will be processed. For very likely that only authorized sensor input will be processed. For
this purpose it needs to be ensured that no alert messages from an this purpose it needs to be ensured that no alert messages from an
unknown origin are accepted. Two types of information elements can unknown origin are accepted. Two types of information elements can
be used for this purpose: be used for this purpose:
1. SIP itself provides security mechanisms that allow the 1. SIP itself provides security mechanisms that allow the
skipping to change at page 21, line 44 skipping to change at page 23, line 44
June 2002. June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-ecrit-additional-data] [I-D.ietf-ecrit-additional-data]
Rosen, B., Tschofenig, H., and R. Marshall, "Additional Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,
Data related to an Emergency Call", "Additional Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-05 (work in progress), draft-ietf-ecrit-additional-data-06 (work in progress),
October 2012. February 2013.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ecrit-trustworthy-location] [I-D.ietf-ecrit-trustworthy-location]
Tschofenig, H., Schulzrinne, H., and B. Aboba, Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location", "Trustworthy Location",
draft-ietf-ecrit-trustworthy-location-04 (work in draft-ietf-ecrit-trustworthy-location-04 (work in
progress), October 2012. progress), October 2012.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
 End of changes. 31 change blocks. 
99 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/