Subject: [dispatch] Emergency Text Messaging using SIP MESSAGE

From: Jong Yul Kim <[email-masked]>
Date: Mon, 30 May 2011 08:54:03 -0400

Hi everyone, 

This draft presents mechanisms to allow page-mode text messaging in emergency situations. 

An example of page-mode messaging is when a person sends SMS to an emergency number to get help. In this case, there needs to be a way for the SMS message to reach the same call taker until the "conversation" ends. 

As emergency call centers are transitioning to a SIP-based solution, the draft outlines a mechanism based on SIP MESSAGE method to deliver page-mode messages consistently to a call taker. 

http://tools.ietf.org/html/draft-kim-dispatch-text-01

Comments on the draft or which WG it should go to are much appreciated. 
Please let us know your thoughts. 

Best regards, 

Jong Yul

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 30 May 2011 18:34:41 -0500

>This draft presents mechanisms to allow page-mode text messaging in 

Doesn't this whole idea of including text that talks about emergency 
services need to get run by the ECRIT WG before the topic can be 
included anywhere?

James

>An example of page-mode messaging is when a person sends SMS to an 
>emergency number to get help. In this case, there needs to be a way 
>for the SMS message to reach the same call taker until the 
>"conversation" ends.
>
>As emergency call centers are transitioning to a SIP-based solution, 
>the draft outlines a mechanism based on SIP MESSAGE method to 
>deliver page-mode messages consistently to a call taker.
>
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 11:51:44 -0400

> From: Jong Yul Kim [[email-masked]]
> 
> the draft outlines a mechanism based on SIP MESSAGE method to deliver
> page-mode messages consistently to a call taker.

There are technical reasons why MESSAGE is not a good solution for
ongoing conversations, which is why MESSAGE was originally specified
not to be used in this manner (RFC 3428, section 2):

   There may be a temptation to simulate a session of IMs by initiating
   a dialog, then sending MESSAGE requests in the context of that
   dialog.  This is not an adequate solution for IM sessions, in that
   this approach forces the MESSAGE requests to follow the same network
   path as any other SIP requests, even though the MESSAGE requests
   arguably carry media rather than signaling.  IM applications are
   typically high volume, and we expect the IM volume in sessions to be
   even higher.  This will likely cause congestion problems if sent over
   a transport without congestion control, and there is no clear
   mechanism in SIP to prevent some hop from forwarding a MESSAGE
   request over UDP.
   [...]
   The authors recognize that there may be valid reasons to send MESSAGE
   requests in the context of a dialog.  For example, one participant in
   a voice session may wish to send an IM to another participant, and
   associate that IM with the session.  But implementations SHOULD NOT
   create dialogs for the primary purpose of associating MESSAGE
   requests with one another.

In practice, the deaf community is pressuring the 112/911 authorities
very heavily to *require* RFC 4103 (IM conversations using SIP
signaling and T.140 media).  Assuming that this effort succeeds (and
there is every reason to believe it will), all commercial devices and
PSAPs will implement RFC 4103, making other conversation-mode SIP IM
techniques largely obsolete in the market (as RFC 4103 provides a
superior feature set to all other approaches).

Technically, I think the proposal is unnecessarily complicated.
Despite that RFC 3428 forbids it, a UA that uses MESSAGE in a
dialog-oriented mode will find that it succeeds even with *generic*
proxies:

1. UA-1 sends an out-of-dialog MESSAGE (that is, with no to-tag) to a
destination (a PSAP in this case).

2. The various proxies forward the MESSAGE request to the PSAP, and
per ordinary SIP, adding any Record-Route headers necessary for a
future request to traverse the same path.

3. The MESSAGE arrives at the PSAP UA, and gives a 200 response with a
to-tag, and (per ordinary SIP) with a Contact header and whatever
Record-Route headers were received in the request.

4. UA-1 receives the 200 response and records the properties of the
dialog that has been established, including the to-tag and the route
set.

5. UA-1 sends a further MESSAGE request within the dialog, that is,
using the to-tag and route set.

6. The various proxies forward the MESSAGE request along the same
route as the original MESSAGE to the same PSAP UA.

This approach is aligned with normal SIP usage, in that it uses only
already-defined mechanisms, and puts the burden on the UAs rather than
the proxies.  Of course, if the MESSAGE is gatewayed from another
protocol, it requires the gateway be a full UA, it must remember the
dialog information, but that is more desirable than requiring all the
SIP proxies in the universe to remember the routing information.  The
MESSAGE-in-dialog approach is also much more likely to work reliably
in the field, as it will not be defeated if the request happens to be
routed by a proxy that only implements RFC 3261.

Dale