[Geopriv] Geopriv for emergency calls

From: Rosen, Brian ^lt;Brian.Rosen@marconi.com>
Date: Thu Nov 13 2003 - 16:40:41 EST

At IETF58, I presented a short summary of issues of location for
emergency calls (9-1-1 in NA, 1-1-2 in GSM, ...). They are:
  1) Emergency calls route based on location (e.g. what PSAP serves
        you depends on where you are)

        Therefore, location must be on first message (INVITE in SIP)

  2) There are 2 or more intermediaries between the origination and
     termination that need location to route; it's not end to end

  3) Post Dial Delay (e.g. rule processing time) is very limited
    (fraction of a second for 2 second PDD)

  4) Rules for retention, forwarding, and to some extent, accuracy
     are determined by local laws, i.e. RM is LR

The implications of this on the geopriv work is:
1) Choice of crypto is important, because and end-to-end
mechanism is problematic, and compute resources, especially
at the originating terminal (sip phone) is limited.

2) It is not practical (or legal), for the originating user
to specify the rules for e.g. retention, retransmission,...
as they are governed by the destination or law.

There is work ongoing in SIP/SIPPING and elsewhere to deal with
emergency calls. At the moment, it appears that phones will
learn their location and report it when placing an emergency
call. At the meeting, I proposed:

a) SIP phones be required to implement S/MIME to protect
geoloc data, but use of TLS or IPSEC should be used in
an emergency call, so that intermediary routing elements
(sip proxy servers) can route based on location. We note
that in many cases, the security associations may be established
in advance, thus further reducing the delay, while maintaining
reasonable authentication, integrity and privacy of location

b) A default rule for emergency calls be specified in the RFC
for the using protocol. Emergency calls would reference this rule.

I welcome your comments on this proposal.

Geopriv mailing list
Received on Thu Nov 13 16:42:23 2003

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:24 EST