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

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

When you place an emergency call, the location is used to determine where to
send the call, and it is used to dispatch responders.  If the location you
supply does not match anything the call center recognizes, the wrong thing
may happen.  What you want to do is to compare the address you have against
a list maintained by the emergency response system to make sure they know
where that is.

An example is illustrative.  If you ask me my home address, I'd tell you
that it is 470 Conrad Drive, Mars, PA.  However, that is NOT the address
that should be used to determine where to send an emergency call from my
home.  That is because the post office boundary is not the same as the
emergency call system boundary.  If you were to determine the serving ERC
without validation, you would send my emergency call to the Butler County
ERC, which serves Mars, rather than to the NEWCOM center that serves Pine
Township, where I live.  

There are many, many such problems.  The solution is that you validate the
address before use.  There is no street named "Conrad" in Mars.  Oh, there
might be, which is another one of those "many, many such problems".

Similarly, if the ERC doesn't know how to dispatch the call, even if it
comes to the correct ERC, people can die.  You don't mess around with the
quality of the data here.  You validate it before you use it.

Very few people know about this problem.  It wouldn't be obvious to me if I
hadn't been involved with this area for the last couple years.  It isn't
actually all that interesting to most users of location.  I don't care if
commercial users validate or not.  I care that we specify the way to
validate so that users have confidence they will get help when they need it.

You need to do the validation BEFORE you place an emergency call.  The
system is usually willing to accept an unvalidated location, which can
happen because real systems fail, but it treats them specially.  You can't
get into any discussion with emergency services folks about location without
the validation problem coming up early.  There is a lot of accumulated
experience on that issue which we ignore at our peril.  The problem is very
real, and there is no way I can see to avoid it.  An address has to be
compared against the Master address guide, before you use it to make a
routing decision, and before you send it to the ERC.  

Now, to be fair, you don't "validate" a geospatial location.  However, you
do worry, a whole lot, about the quality if you try to convert from civic to
geo before you use the geo.  It has all of the same problems; you have to
validate the address first.

Brian


> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> Sent: Monday, September 27, 2004 11:36 AM
> To: Brian Rosen; 'Peterson, Jon'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency
> calling and routing
> 
> I'd like to make several points:
> 
> Brian mentions geo-location needing to be validated prior to being used in
> this application - yet we know this is not possible. I find that
> interesting.
> 
> Regarding civil location being validated prior to use: Brain's alternate
> wording makes it appear this application is the primary purpose for
> providing location into endpoints, that location needs to be run by the
> local emergency services company/org/gov entity to be considered 'good
> enough' for use with all forms of location conveyance, and I think that's
> getting ahead of ourselves. Location conveyances will be a multi-billion
> $$
> industry that should not have to be vetted through this process just to be
> used.
> 
> His wording seems to (flat out does) make it necessary for any element
> location to be validated before anything else can happen - even the call.
> Is this really true? What happens if a location is not validated?
> 
> I agree location precision needs to be addressed.
> 
> I agree that some jurisdictions route a call based on the nature of the
> emergency (to police, to medical, to marine, to mountain rescue, etc), and
> should be mentioned in the routing of the call portion of the charter.
> 
> Video should be mentioned (just as IM was).
> 
> Rerouting of the media stream from the ERC to the responders (either to
> their base facilities or to those in the field), or between ERCs should be
> mentioned.
> 
> At 09:58 AM 9/27/2004 -0400, Brian Rosen wrote:
> >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
> 
> 
> cheers,
> James
> 
>                                 *******************
>                  Truth is not to be argued... it is to be presented
> 
> 




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