RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing

["Brian Rosen" <[e-mail]>]

I am very happy to see some motion on this very pressing problem.  In the
absence of IETF work, other national or regional groups are working on
solutions that are contrary to the "no national variants" of the Internet.
I do think mention should be made of other work, perhaps explicitly
soliciting requirements from such entities as NENA and ETSI EMTEL.

There are several problems that need to be solved that go beyond this
particular problem statement.  The most significant is that the location
that is supplied needs to be "validated" prior to using it.  This is a
primary problem, and it's essential that it be included in the charter.
I believe that making scope so narrow that only routing is considered would
be a serious mistake.

Another issue is that while in some jurisdictions, there is a single
location to which calls are directed, in some, the nature of the emergency
determines the routing.

Another issue missing from the charter is an explicit inclusion of both
civic and geo locations (street address and lat/lon/altitude).

The charter needs to cover location precision to at least a room.  It's not
clear if this is in scope or not.  The mechanism to determine location is
not in scope, but representation, and thus validation, should be.

Specific suggestions on the wording of the charter follow:


> 
> Emergency Context Resolution with Internet Technologies (ECRIT)
if validation of location is considered, this would not be a great name
> 
> 
> Transport Area Director(s):
> Allison Mankin <[e-mail]>
> Jon Peterson <[e-mail]>
> 
> Transport Area Advisor: TBD
> 
> Working Group Chairs:  TBD
I volunteer

> 
> In a number of areas the public switched telephone network (PSTN)
> has been configured to recognize a short, easily memorized number as
> a call for emergency services.   These numbers relate to an emergency
> service context and depend on a broad, regional configuration of
> service contact methods and a geographically constrained context
> of service delivery.  Successful delivery of an emergency service call
> within those systems requires both an association of the physical
> location of the originator with an appropriate emergency service
> center and call routing to deliver the call to the center.
This is incorrect.  You don't always have a short number, choice of number
is currently explicitly national (with the single exception of the EU 112
number primarily limited to mobile).  There is more to location within
emergency calling besides "context" and there are more than location that
may determine the appropriate call center.

Perhaps:
Calling for help using the publics switched telephone network (PSTN) is a
primary function which must be provided for in any Internet based
communication system.  Emergency calls for assistance are answered at
special call centers.  An emergency call must be directed to the correct
call center, which depends on the location of the caller and in some
jurisdictions, the nature of the emergency.  The call itself must include
the location either directly or indirectly.  Prior to use for determining a
call center location must be determined to be valid (known to the call
center as a location to which help may be dispatched).  
> 
> Calls placed using Internet technologies do not use the same systems to
> achieve those goals, and the common use of overlay networks and tunnels
> (either as VPNs or for mobility) makes meeting them more challenging.
Okay

> There  are, however, Internet technologies available to describe location
> and
> to manage call routing.  This working group will specify how those
> technologies
> may be used within this context.  
This presupposes that the available technologies are appropriate.  This
might be true, but it might not.  Perhaps:
Describing location and carriage of location within various protocols is
defined in other IETF working groups.  This working group will specify how
location, in both civic and geospatial forms can be validated and used to
route calls.

>Explicitly outside the scope of this
> group
> is the question of pre-emption or prioritization of emergency services
> traffic.
> This group is considering emergency services calls which might be made by
> any user of the PSTN or Internet, as opposed to government or military
> services that may impose very different authentication  and routing
> requirements.
Is this an attempt to avoid the scope of IEPREP?  If so, it's incorrect.
IEPREP is concerned with an entirely different kind of call - one made by a
responder using the existing facilities using a priority.  Agree that this
is out of scope.  There is no call for assistance (9-1-1/1-1-2) that has
preemption that I am aware of.  Priority for emergency calls is often
imposed by carriers, but rarely required.  If you intended to avoid IEPREP,
perhaps:
This group is concerned with calls made by ordinary users to request
emergency assistance.  Emergency calls by responders using Internet
facilities are the province of the IEPREP working group and out of scope for
this working group.  

> 
> The group will describe a layered approach to the problem, showing how the
> availability of location data and call routing information at different
> steps in session
> setup would enable communication between a user and a relevant emergency
> service enter.  
It's not clear that there is any layering.  I think this wording doesn't
advance anyone's understanding of what the work is.  Perhaps:
This group will describe how location may be validated prior to use, and how
validated location may be used to route calls to the correct emergency call
center.

>Though the term "call routing" is used in this document,
> it
> should be
> understood that some of the mechanisms which will be described might be
> used
> to
> enable non-voice communications (e.g. text messaging) where appropriate.
I'm not sure what is implied here.  There are two kinds of text messaging
protocols that might be used: Instant messaging and interactive text
streams.  Both have the notion of "session".  Perhaps:
While current emergency calls are voice only, the Internet provides a
variety of media streams that may be used to summon help.  This work will
include voice, video and Instant Messaging as well as interactive text.


> 
> Deliverables:
> 
> Informational RFC describing the problem
>     (needs to be simple and early, early, early)
> 
> BCP describing strategies for call originators identifying emergency
> calls.
>     (Including provisioning local targets and use of URIs)
This is somewhat problematic as it overlaps protocol groups.
Maybe need to qualify this as with the concurrence of such groups (I'm
thinking SIPPING and XMPP).  Wording may need a hint of the "nature of the
emergency" problem.

> 
> BCP describing strategies for associating call originators with
> physical locations.
>     (Both originator-based and network-based strategies)
I'm not sure what is meant here.  Right now, I think most endpoints learn
location from DHCP and supply it using SIP/XMPP with PIDF-LO.  It's worth
saying that somewhere.  Is that what was intended by this?  I hope you did
not intend to imply network based insertion of location in call flows; I
think we are constrained by geopriv to have endpoints learn location and
supply it on emergency calls.

Need a new requirement
Standards Track RFC describing how location is validated prior to use.

> 
> Standards Track RFC describing a query protocol for Emergency Service
> Context
> lookup  by physical location.  Update, insert, and modification of the
> data
> associated
> with ERC's is out of scope for this work item.
I don't see how you can ignore how the data is maintained. I suppose it
depends on the query mechanism; if you choose the right query mechanism,
there may already be mechanisms for maintaining data.  

>     (IRIS might be a candidate protocol here--it is a query only protocol
> for registry data,
>      which is one way to model the back end store mapping location to
> ERC).
This should be deleted.  You don't know what query mechanism to use.  If,
for example, you use the DNS, than this is incorrect.

> 
> BCP describing the call routing strategies for ip911.
very poor choice of acronym; has U.S. implication.  Use ipSOS

>     (e.g.:  does an ERC have a sip: URI to talk to, or do we need to last
> mile via PSTN?)
I suspect we DON'T want to work on migration strategies.  Just assume the
ERC can terminate a SIP call.  It's too late for IETF to wade into that one.

> 
> BCP describing how to discover ERC capabilities.
>     (can a deaf person IM this center or can we route through a relay?)
I'm skeptical of this, again crosses protocol groups boundaries.   Problem
does need to be solved.  Perhaps:
BCP describing how routing may be affected by capabilities in the ERC or
constraints on the caller (e.g. caller with disabilities engaging a relay
service).
> 
> Threats and security documentation
>     (mainly pointers, but the pointers need to be gathered).
> 


Brian




_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency