| DISPATCH | J. Kim |
| Internet-Draft | W. Song |
| Intended status: Best Current Practice | H. Schulzrinne |
| Expires: October 06, 2011 | Columbia University |
| P. Boni | |
| M. Armstrong | |
| Verizon | |
| April 04, 2011 |
Emergency Text Messaging using SIP MESSAGE
draft-kim-dispatch-text-01
This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizens to authorities.
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 October 06, 2011.
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.
This document uses terms from [I-D.ietf-ecrit-framework] and [RFC3428].
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].
The SIP MESSAGE method [RFC3428] is used for page-mode messaging. In page mode, each individual message is sent independently and not as part of any session. On the other hand, there are session-mode text messaging standards such as the Message Session Relay Protocol (MSRP) [RFC4975] and Real Time Text (RTT) [RFC5194] where every message is part of an explicit session.
Which mode to use in an emergency situation depends on what the endpoint is capable of. Short Message Service (SMS), for example, is page-mode messaging. If caller wants to use SMS to send emergency text messages, a page-mode mechanism must be used. Some types of Instant Messaging (IM) systems work as page-mode messaging as well.
This document describes how the SIP MESSAGE method is used to support emergency text messaging within the framework described in [I-D.ietf-ecrit-framework]. The existing framework does not consider methods, such as the SIP MESSAGE method, that do not create a session or are not a part of it. This document describes how to deliver multiple SIP MESSAGE requests consistently to the same call taker. It also describes how non-SIP text messaging content can be converted to SIP MESSAGE requests.
Presence is beyond the scope of this document.
+-------+
| PSAP2 |
+-------+
+------+ [SIP] +-------+ +------+ +-------+
|SIP UA| ----->| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+------+ +-------+ +------+ +-------+
^
+----------+ [SMS] +--------+ | +-------+
|Cell phone| ----->| SMS GW |----+ [SIP] | PSAP3 |
+----------+ +--------+ +-------+
This document assumes that the Emergency Services IP Network (ESInet) and Public Safety Answering Point (PSAP) are SIP-based infrastructures. The caller-facing access network may or may not be SIP-based or IP-based. As shown in Figure 1, emergency text messages may be sent end-to-end from a SIP User Agent using SIP MESSAGE requests. It may also be sent in a different format and protocol, such as SMS, and converted to SIP MESSAGE requests somewhere along the path towards the call taker. Gateways, such as the SMS gateway shown in Figure 1, handles these conversions. Conversion is described in Section 6.
The SIP MESSAGE request is constructed as described in [RFC3428]. The body of the request contains the text message to be delivered. Then the values for various emergency header fields are filled as stated in [I-D.ietf-ecrit-framework]. If the location information is appended to the body of the request, the caller's message and the location information must be inserted into the body of the request as multiple MIME attachments. These are explained in more detail in Section 4.
The main difference of this approach from both the traditional SIP MESSAGE request routing and the emergency framework is in the way the SIP MESSAGE request is handled along the signaling path. In emergency handling, the path that the first SIP MESSAGE request takes is important. Subsequent SIP MESSAGE requests from the same person or device must follow the same path as the first one so that they are delivered correctly to the same call taker. Otherwise, if subsequent SIP MESSAGE requests are delivered to another call taker or another PSAP, there will be considerable confusion for both the sender and the receiver. Therefore, the path of the first SIP MESSAGE request is determined by location and/or local policy, but all subsequent SIP MESSAGE requests must follow the path of the first request regardless of location or local policy.
This means that entities within the signaling path that determine the next hop based on location or local policy need to keep track of SIP MESSAGE requests that it forwards. Emergency Service Routing Proxy [I-D.ietf-ecrit-framework] is an example of such entity. How such proxy behaves is described in Section 5. However, this behavior is not confined to proxies. SIP UAs and call distributing entities within the PSAPs are also affected. If the SIP UA does not keep track of SIP MESSAGE requests, then it would query LoST [RFC5222] every time a SIP MESSAGE is sent. This is a big problem if the caller is moving while sending messages; the SIP UA may send the SIP MESSAGE requests to different PSAPs based on LoST query results. Call distributing entities need to keep track of SIP MESSAGE requests so that requests from one caller is forwarded consistently to one call taker. For these entities, the same state-keeping mechanisms described in Section 5 can be used.
When the call taker sends a reply to the caller, the reply follows the normal SIP routing path. If the caller's original message was not SIP, then the replies from the call taker must also be converted from SIP MESSAGE requests to the original message format and transport protocol. As an example, if the caller's original message was an SMS message, then the call taker's replies to be converted to an SMS message so that the caller can receive it on his/her cell phone. There may be other protocols, such as proprietary IM protocols, that may need conversion.
Caller UAC follows the rules of SIP MESSAGE method[RFC3428] and those of [I-D.ietf-ecrit-framework]. The following description of caller UAC processing is derived from the union of the two documents mentioned earlier.
The UAC may include location information in the body as type "xml/pidf-lo" with a corresponding Geolocation header field, or include a reference to the location information in the Geolocation header field as specified in [I-D.ietf-sip-location-conveyance]. In the former case, the UAC needs to include both the sender's message and the location information in one body. To do so, the UAC must use multipart MIME. Here is an example:
----- =_RjhENkI3RjQ4NUE0QjI2Q0VEODdGNjIwMkMwNjZC
MIME-Version: 1.0
Content-ID: <3252.1224700600.5@NG911_Desktop1>
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Hello, I need help.
----- =_RjhENkI3RjQ4NUE0QjI2Q0VEODdGNjIwMkMwNjZC
MIME-Version: 1.0
Content-ID: caller@x.y
Content-Type: application/pidf+xml
Content-Transfer-Encoding: UTF-8
<?xml version="1.0" encoding="ISO-8859-1"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="sip:caller@x.y">
<tuple id="id94954">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>us</cl:country>
<cl:A1>ny</cl:A1>
<cl:A3>new york</cl:A3>
<cl:A6>amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
<cl:PC>10027</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:method>Manual</gp:method>
</gp:geopriv>
</status>
<contact priority="1.0">sip:caller@x.y</contact>
<timestamp>2008-11-14T19:43:43Z</timestamp>
</tuple>
</presence>
----- =_RjhENkI3RjQ4NUE0QjI2Q0VEODdGNjIwMkMwNjZC
The UAC should resolve the location to a URI by querying LoST [RFC5222] and should include the URI in the Route header field. This should be done only once for the initial SIP MESSAGE request to make sure that all subsequent SIP MESSAGE requests follow the same next-hop as the first request. If the UAC is not able to resolve the location, then it should not include a Route header field.
If the UAC receives a non-200 response, it should notify the sender of the response and give the sender the option of dialing the emergency number instead of sending another SIP MESSAGE request.
As described in Section 3, proxies that determine the next hop of an emergency request based on location or local policy need to keep track of SIP MESSAGE requests they handle. On the other hand, proxies that forward SIP MESSAGE requests statically, i.e., based on the To header field or the Route header field, do not need to keep track since the SIP MESSAGE requests will be delivered consistently.
The proxies that need to track SIP MESSAGE requests, e.g., the Emergency Services Routing Proxy [I-D.ietf-ecrit-framework], MUST perform additional record keeping for SIP MESSAGE requests if all of the following conditions are met.
The record is a (source, next-hop, expiration timer) triplet. The source is obtained from the From header field of the request. The next-hop is determined by a LoST query [RFC5222] based on the location information or a reference to the location information within the first request. Location information in subsequent requests do not affect the next-hop value. The expiration timer is a value in seconds during which the record will be preserved in the proxy. Each subsequent request resets the expiration timer. For example, if the configured value of the expiration timer is 30 seconds, then the countdown begins after the first request is processed. When the second request comes in, the expiration timer is reset to 30 seconds and the countdown starts again. If the timer falls to zero, the record is no longer valid.
Proxies route all subsequent SIP MESSAGE request from the same source to the same next-hop while the expiration timer is greater than zero. Each subsequent SIP MESSAGE request resets the expiration timer to its maximum value. This is to ensure that a 'conversation' between the caller and the call taker is consistent.
The original message may not be SIP. It may be an SMS message or an IM message in a proprietary format and protocol. In these cases, the original format and protocol must be converted to a SIP MESSAGE request.
The following is the minimum information needed to convert a non-SIP message to a valid SIP MESSAGE request.
| Type of Information | Corresponding SIP MESSAGE element |
|---|---|
| Origination address or number | From header field |
| User message | In the body as type "text/plain" |
| Location information | Geolocation header field and in the body as type "xml/pidf-lo" (Geolocation header field only if conveying location by reference) |
The SIP URI for the From header field must be created by merging the origination address or number and the IP address and port of the converting entity. The IP address and port of the converting entity is needed for reply message from the call taker to reach the caller. For example, let's say the origination address or number is 123-456-7890 and the IP address and port number of the converting entity is 128.59.19.184:5060. Then the SIP URI should be sip:1234567890@128.59.19.184:5060.
The To header field must contain an emergency string such as "urn:service:sos". The destination address or number, e.g., 9-1-1, in the original non-SIP message is retained and carried along with the SIP message in the History-Info header [RFC4244]. The destination address could be useful in post incident call analysis for PSAP personnel to identify network issues such as mis-routed text messages allowing more efficient trouble clearing with the appropriate network provider.
The next hop entity should be determined by querying LoST with the provided location information and it should be included in the Route header field.
If the converter receives a 200 OK response, it should send a success indicator to the original sender. There may not be a one-to-one match between SIP responses and the original protocol, especially when non-200 responses are received. In this case, the converter must indicate failure and may send the reason text as a message to the sender.
The call taker's reply, which is another SIP MESSAGE request in the reverse direction, should be sent to the origination address or number in its original format. The origination address or number can be extracted from the To header field. The From header field may contain "urn:service:sos", in which case it must be replaced with the original emergency number or string.
If the sender protocol allows provisional and final responses, the converter should make use of them to indicate the status of the call taker. For example, the converter should send a 202 Accepted response upon receiving the call taker's SIP MESSAGE request, and then a 200 OK upon receiving the final success indication from the sender. If the sender protocol does not allow such elaborate responses, the converter must send a 200 OK upon receiving the call taker's SIP MESSAGE request.
This document does not introduce new security considerations.
This memo includes no request to IANA.