Emergency Text Messaging using SIP MESSAGE

This document uses terms from and . 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.

The SIP MESSAGE method 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) and Real Time Text (RTT) where every message is part of a session with a definite start and end. Which mode to use in an emergency depends on what the endpoint is capable of. This document describes how the SIP MESSAGE method is used to support emergency text messaging within the framework described in . The existing framework does not consider methods that do not create a session or are not a part of it. The main difference between the existing framework and the MESSAGE approach is in the way the proxies handle SIP MESSAGE methods. This document assumes that the Emergency Services network (ESInet) and PSAPs are SIP-based infrastructures. However, the caller-facing access network may or may not be IP based. Emergency messages may be sent end-to-end using the SIP MESSAGE method, or it may be in a different format and protocol in the caller side and have to be converted to SIP MESSAGE somewhere along the path towards the call taker. Therefore, we also describe recommendations on how a SIP MESSAGE is formed from non-SIP text protocols. Presence is beyond the scope of this document.

| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker +------+ +-------+ +------+ +-------+ ^ +----------+ [SMS] +--------+ | +-------+ |Cell phone| ----->| SMS GW |----| [SIP] | PSAP3 | +----------+ +--------+ +-------+ ]]> Emergency text communication may utilize SIP MESSAGE end-to-end from the caller's end device or application to the call taker, or may start as another form of text messaging scheme such as SMS but ultimately be converted to a SIP MESSAGE. Text handling after the conversion is the same. In any case, the MESSAGE request is constructed as described in . The body of the request contains the message to be delivered. Then the values for various emergency header fields are filled as stated in . 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 . The main difference of this approach from both the traditional SIP MESSAGE routing and the emergency framework is in the way the MESSAGE is handled along the path. In emergency handling, the path that the first MESSAGE request takes is important. Subsequent 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 MESSAGE requests are delievered 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 MESSAGE request is determined by location and/or local policy, but all subsequent MESSAGE requests must follow the path of the first request regardless of location or local policy. This means that entities within the path that determine the next hop based on location or local policy need to keep track of MESSAGE requests that it forwards. Emergency Service Routing Proxy is an example of such entity. How such proxy behaves is described in . 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 MESSAGE requests, then it would query LoST everytime a MESSAGE is sent. This is a big problem if the caller is moving while sending messages. The SIP UA may send the MESSAGE requests to different PSAPs. Call distributing entities need to keep track of 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 can be used. When the call taker sends a reply to the caller, the application constructs a SIP MESSAGE request without location or other special header fields used in emergency and sends it towards the caller. The reply follows the normal SIP routing path. If the caller's original message was not SIP, then the replies from call taker must also be converted from SIP MESSAGE request to the original message format and tranport protocol. As an example, if the caller's original message was an SMS message, then the call taker's reply may have 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. Gateways, such as the SMS gateway shown in , handles these conversions. Conversion is described in .

Caller UAC follows the rules of SIP MESSAGE and those of . 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 . 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:

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

us ny new york amsterdam 1214 10027

Manual sip:caller@x.y 2008-11-14T19:43:43Z ----- =_RjhENkI3RjQ4NUE0QjI2Q0VEODdGNjIwMkMwNjZC]]> The UAC should resolve the location to a URI by querying LoST and should include the URI in the Route header field. This should be done only once in the beginning of conversation to make sure all subsequent 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. It is out of the scope of this document to decide when the conversation begins or ends. The UAC may use a user-interface-based approach for this, i.e., start a new conversation when the user opens a new chat window, and then terminate the conversation when the user closes that window. However, this is only an example. 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 MESSAGE request.

As described in , proxies that determine the next hop of an emergency request based on location or local policy need to keep track of MESSAGE requests it handles. On the other hand, proxies that foward MESSAGE requests based on the To header field or the Route header field do not need to keep track since the MESSAGE requests will be delivered consistently. The proxies that need to track MESSAGE requests, e.g., the Emergency Services Routing Proxy , MUST perform additional record keeping for MESSAGE requests if all of the following conditions are met. The destination (obtained from the To header field) is urn:service:sos. This is the first MESSAGE from a particular source (obtained from the From header field). In other words, the proxy has no record of the source sending a MESSAGE to urn:service:sos. 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 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 that will keep the record from expiring. 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 MESSAGE request from the same source to the same next-hop while the expiration timer is greater than zero. Each subsequent 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. The following is the minimum information needed to convert a non-SIP message to a valid SIP MESSAGE. Type of Information Correspoding 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. 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 . 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 quering 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 MESSAGE, 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 MESSAGE.

TBD

This memo includes no request to IANA.