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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 27 Sep 2004 05:13:34 -0400

Greetings SIPPING-emergency folk,

Allison and I are considering the following proposal from Ted Hardie for a
new working group in the Transport Area focusing on emergency call routing.

We'd like some feedback from SIPPING-emergency subscribers about the overall
propriety of this endeavor and, in particular, the charter text and
deliverables attached below.

Personally, I think there is a lot of valuable work that we could do in this
area, and it is work that currently we ignore at our own hazard. While
defining e911 for the Internet as a whole is most likely beyond our
collective powers, there are chunks of this problem that really are our
responsibility, and we need to address them as best we can.

Jon Peterson
NeuStar, Inc.

----

Emergency Context Resolution with Internet Technologies (ECRIT)

Transport Area Director(s):
Allison Mankin <[email-masked]>
Jon Peterson <[email-masked]>

Transport Area Advisor: TBD

Working Group Chairs:  TBD

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.

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. 
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.  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.

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.  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.

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)

BCP describing strategies for associating call originators with 
physical locations.
    (Both originator-based and network-based strategies)

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.
    (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).

BCP describing the call routing strategies for ip911.
    (e.g.:  does an ERC have a sip: URI to talk to, or do we need to last
mile via PSTN?)

BCP describing how to discover ERC capabilities.
    (can a deaf person IM this center or can we route through a relay?)

Threats and security documentation
    (mainly pointers, but the pointers need to be gathered).

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Sep 2004 08:15:54 -0400

The endeavour is reasonable, but I suspect the agenda is a bit broad.  Some items 
seem a bit out of scope for the IETF.  Specific comments marked by [PTT].

> deliverables attached below.
[snip]

[snipped OK goals]

>      which is one way to model the back end store mapping location to ERC).
[PTT] This seems to be taken out of someone's conversation.  What is an Emergency 
Service Context?

>     (e.g.:  does an ERC have a sip: URI to talk to, or do we need to last
[PTT] This is surely out of scope.  It's a practical network engineering issue 
rather than a question of technology.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Sep 2004 08:49:20 -0400

I'm glad to see some progress on this issue.

My concern is that the charter already specifies or biases the solution. 
I know Ted has a particular solution in mind, possibly influenced by his 
experience at his day job, but this is far from what most people who 
have been actively working in this area have been discussing. Thus, my 

>     (mainly pointers, but the pointers need to be gathered).

I believe that the description misses a core requirement, namely the 
ability to administer the system in a fully decentralized manner that 
reflects the current administrative boundaries and delebation of 
responsibilities. It also must be international, i.e., it cannot just 
work for the US (or pick any other country) or require a US entity to 
manage the system.

It would have been nice to recognize that there has been work going on 
this area for several years, but maybe that's too much to ask.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Sep 2004 09:58:43 -0400

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.

> Emergency Context Resolution with Internet Technologies (ECRIT)
if validation of location is considered, this would not be a great name
> Working Group Chairs:  TBD
I volunteer

> 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).  
> (either as VPNs or for mobility) makes meeting them more challenging.
Okay

> 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 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.  

> 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
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.

>     (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.

>     (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.

> 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.  

>      which is one way to model the back end store mapping location to
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
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.

>     (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).
>     (mainly pointers, but the pointers need to be gathered).

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Sep 2004 10:36:15 -0500

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.

> >     (mainly pointers, but the pointers need to be gathered).

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Sep 2004 12:03:47 -0400

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:[email-masked]]
> Sent: Monday, September 27, 2004 11:36 AM
> To: Brian Rosen; 'Peterson, Jon'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency
> calling and routing
> 
> > > understood that some of the mechanisms which will be described might
> be
> > > used
> > > to

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 27 Sep 2004 15:08:37 -0400

I too agree this work is much needed.

Other comments in-line.....

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Monday, September 27, 2004 9:59 AM
> To: 'Peterson, Jon'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping-emergency] proposed charter,new wg on 
> emergency calling and routing
> 
> 
> 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 
> 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.
> 

I volunteer also.

> 
> > 
> > In a number of areas the public switched telephone network 
> (PSTN) has 
> > been configured to recognize a short, easily memorized number as
> > service contact methods and a geographically constrained context of 
> > service delivery.  Successful delivery of an emergency service call 
> 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).

I don't believe the IETF should require validation, this is a local
decision.  The IETF can describe/develop the mechanism for validation, but
it is the user(s) to determine the requirement.

> > 
> > 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
> 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.

Agree with Brian, if existing technologies can't fulfill the requirements,
something new will be needed.

> >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.

Validation is one process that would apply to civil locations only.

> >be  used  to
> 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:
> > 
> > BCP describing strategies for call originators identifying 
> emergency 
> > calls.
> 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.
> 
> > 
> 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

Again, civil location validation as required by the user(s).

> > Context lookup  by physical location.  Update, insert, and 
> > modification of the data
> > associated
> 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.

Agree with Brian, delete this statement as mechanism is
yet-to-be-determined.

> >     (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 routing may be affected by capabilities in 
> the ERC or constraints on the caller (e.g. caller with 
> disabilities engaging a relay service).
> > 

-Marc Linsner-

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 27 Sep 2004 15:08:54 -0400

In-line.....

> Sent: Monday, September 27, 2004 12:04 PM
> To: 'James M. Polk'; 'Peterson, Jon'; [email-masked]
> Cc: [email-masked]
> Importance: Low
> 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.  

So?  As long as '470 Conrad Drive, Mars, PA.' is unique, modern data
processing can handle it.

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.

Validation and routing are 2 separate issues.  If in fact, 470 Conrad.....,
is a good address, the routing function (which will be based on data from
the ERC entities) better get it right and send the call the NEWCOM center as
you describe.  All that validation *may* offer is to verify that you (the
end-user) didn't spell Conrad as Conard (or put Street instead of Drive,
etc.)!  I realize there are locales that utilize a different 'location'
address for emergency purposes than the postal address, but the IETF can't
fix this.

I'm not against validation, but your example isn't the real reason for
validation. 

[snip]

-Marc Linsner-

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 27 Sep 2004 15:20:09 -0400

Agreed that you COULD change the way the system works now to have a
translation from postal address to dispatch address.  They don't do that
now, but they could.  In that regard, maybe a bad example.  If you were to
propose that the system have a translation, then some kind of spec would
have to be written that said that, which might be a new deliverable.

Misspellings, missing or extra directionals (North, Southwest, ..),
confusion between Main Street and Main Drive, etc. are better examples.
The point is to make sure that the call will be routed correctly,
and responders will be dispatched correctly BEFORE the location is needed to
do so, and the only way we know how to do that is to compare the address
against some kind of master list.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Monday, September 27, 2004 3:09 PM
> To: 'Brian Rosen'; [email-masked]
> Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency
> calling and routing
> 
> In-line.....
>