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

["James M. Polk" <[e-mail]>]

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